[JBoss-dev] [ jboss-Bugs-679090 ] EJB-QL parse error reports problem with wrong bean
Bugs item #679090, was opened at 2003-02-02 16:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=679090group_id=22866 Category: JBossCMP Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: nash (kanagawa) Assigned to: Nobody/Anonymous (nobody) Summary: EJB-QL parse error reports problem with wrong bean Initial Comment: While debugging an EJB-QL problem, I found I was banging my head against the wrong bean -- when I turned full debugging on I saw this. Here near the top, you can see its trying to deploy ProfileEntity, but when the error is finally reported, the bean identified is ChoiceEntity. 11:10:16,074 INFO [ProfileEntity] Created table 'ProfileEntity' successfully. 11:10:16,084 DEBUG [findByPrimaryKey] SQL: SELECT id FROM ProfileEntity WHERE id =? 11:10:16,094 DEBUG [ProfileEntity] Added findByPrimaryKey query command for home interface 11:10:16,104 DEBUG [findByPrimaryKey] SQL: SELECT id FROM ProfileEntity WHERE id =? 11:10:16,114 DEBUG [ProfileEntity] Added findByPrimaryKey query command for loca l home interface 11:10:16,124 DEBUG [findAll] EJB-QL: SELECT OBJECT(o) FROM ProfileEntity o 11:10:16,124 DEBUG [findAll] SQL: SELECT t0_o.id FROM ProfileEntity t0_o 11:10:16,134 DEBUG [findAll] EJB-QL: SELECT OBJECT(o) FROM ProfileEntity o 11:10:16,144 DEBUG [findAll] SQL: SELECT t0_o.id FROM ProfileEntity t0_o 11:10:16,144 DEBUG [findByOrganizationKey] EJB-QL: SELECT DISTINCT OBJECT(p) FRO M ProfileEntity p WHERE p.organization = ?1 11:10:16,204 WARN [ServiceController] Problem starting service jboss.j2ee:jndiN ame=ejb/CapOneRM/ChoiceEntity,service=EJB org.jboss.deployment.DeploymentException: Error compiling ejbql; - nested throwa ble: (org.jboss.ejb.plugins.cmp.ejbql.ParseException: Encountered 1 at line 1, column 71. Was expecting one of: IDENTIFICATION_VARIABLE ... ENTITY_VALUED_PARAMETER ... ENTITY_VALUED_PATH ... ) at org.jboss.ejb.plugins.cmp.jdbc.JDBCEJBQLQuery.init(JDBCEJBQLQuery.j ava:46) at org.jboss.ejb.plugins.cmp.jdbc.JDBCCommandFactory.createEJBQLQuery(JD BCCommandFactory.java:44) at org.jboss.ejb.plugins.cmp.jdbc.JDBCQueryManager.start(JDBCQueryManage r.java:218) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=679090group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JMS reliability (?)
Hi Calin, While there is still room for improvement in the performance category, I believe the corruption problems with large queues is fixed in the later releases of the 3.0.x series. If you use JBoss 3.0.5 or later, you shouldn't experience the problems outlined in points 1 and 2 below. JBoss 3.2.x has a new implementation that should help in high load situations, but I would suggest using the 3.0.x series for production use. Aaron On Sunday 02 February 2003 11:17 am, you wrote: Hi, I saw a couple of worrying messages in the mailing lists regarding the reliability of JBoss implementation of JMS. Is JBoss' JMS reliable and suitable for production environment? For example for the scenario of an external client (or an another JBoss server) sending messages to a JBoss server. If the answer is yes ( I hope this is the answer) , which JBoss version is the most reliable and suitable for production? Any feedbacks really appreciated, Calin Lupa - Original Message - From: Muntean Horia To: [EMAIL PROTECTED] Sent: Sunday, January 19, 2003 1:30 PM Subject: Re: [JBoss-user] jms issues Rob Finneran wrote: Hi Listees, Just to give feedback, and not to rant too much: I have also seen the problems stated in 1 and 2 of these messages. I had to remove message queueing from my production environments because of it. IMHO, It would be very big plus if the JMS reliability issues were resolved. I hate to complain because JBoss has served me well, but I would like to use JMS more frequently in my production environments. Cheers, Rob - Original Message - From: Ed Brown [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 17, 2003 12:37 PM Subject: Re: [JBoss-user] jms issues Quoting Peter Fagerlund [EMAIL PROTECTED]: torsdagen den 16 januari 2003 kl 03.49 skrev Ed Brown: Here are the list of problems that I ran into when I used the JBoss implementation: 1. If too many messages were queued up, and the server was stopped and restarted, the server hung. 2. Sometimes when the server was stopped and restarted, the message queues seemed to get corrupted and the things wouldn't work. I would have to stop JBoss, manually remove the queues and restart. 3. The message queues didn't seem to hold up under heavy load. DefaultDS is used per default unless You massage Your persistent settings the above can result as perceived. The default settings were used when this happend. 1) I suspect a corrupted DB from a not clean shutdown 2) I suspect a corrupted DB from a not clean shutdown Shutdown was done using CTRL-C at the console. Since that was the way to shut it down, corrupted queues resulting from shutdown was not acceptable. 3) Depends how heavy We talk here ? could also be my introduced thread bug ? It was single threaded. What was Your test setup HW/SW and JBoss version ? JBoss 3.0.1, on Windows 2000 and Linux. I'm not alone in finding the JBoss implementation of JMS lacking. I've read the forums. IMO, it's not ready for prime time, for that matter, neither is the JBoss inclusion of Axis. But I've written enough. Ed Brown ___ __ This mail sent via toadmail.com, web e-mail @ ToadNet - want to go fast? http://www.toadmail.com --- This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will allow you to extend the highest allowed 128 bit encryption to all your clients even if they use browsers that are limited to 40 bit encryption. Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user --- This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will allow you to extend the highest allowed 128 bit encryption to all your clients even if they use browsers that are limited to 40 bit encryption. Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user Until now, we use JBossMQ only with JVM protocol (i.e. facades sending messages that are consumed by MDB's on the same server) with File PM. We had no problems so far. But with external clients we switched to MQSeries to do the work 'cause JBossMQ can't handle simple tasks like delivering reliable a message. Maybe the latest versions of
[JBoss-dev] [ jboss-Feature Requests-679254 ] Add cause to RollbackException
Feature Requests item #679254, was opened at 2003-02-03 11:05 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376688aid=679254group_id=22866 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tom Davies (tomdavies) Assigned to: Nobody/Anonymous (nobody) Summary: Add cause to RollbackException Initial Comment: This is a reincarnation of RFE 430946 It would be very useful to be able to determine which exception caused a commit to fail. For instance, using JDO the exception might be caused by an optimistic lock error, which should be retried, or by a more permanent fault. In JDK 1.4 the initCause() method allows a RollbackException to report the cause. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376688aid=679254group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JMS reliability (?)
Can you clarify this recommendation? It sounds like you said 3.2 is better, but use 3.0.x. Is this solely because 3.2 isn't quite baked yet or is there another reason to stick with 3.0.x? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Aaron Lindsey Sent: Sunday, February 02, 2003 3:13 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JMS reliability (?) Hi Calin, While there is still room for improvement in the performance category, I believe the corruption problems with large queues is fixed in the later releases of the 3.0.x series. If you use JBoss 3.0.5 or later, you shouldn't experience the problems outlined in points 1 and 2 below. JBoss 3.2.x has a new implementation that should help in high load situations, but I would suggest using the 3.0.x series for production use. Aaron On Sunday 02 February 2003 11:17 am, you wrote: Hi, I saw a couple of worrying messages in the mailing lists regarding the reliability of JBoss implementation of JMS. Is JBoss' JMS reliable and suitable for production environment? For example for the scenario of an external client (or an another JBoss server) sending messages to a JBoss server. If the answer is yes ( I hope this is the answer) , which JBoss version is the most reliable and suitable for production? Any feedbacks really appreciated, Calin Lupa - Original Message - From: Muntean Horia To: [EMAIL PROTECTED] Sent: Sunday, January 19, 2003 1:30 PM Subject: Re: [JBoss-user] jms issues Rob Finneran wrote: Hi Listees, Just to give feedback, and not to rant too much: I have also seen the problems stated in 1 and 2 of these messages. I had to remove message queueing from my production environments because of it. IMHO, It would be very big plus if the JMS reliability issues were resolved. I hate to complain because JBoss has served me well, but I would like to use JMS more frequently in my production environments. Cheers, Rob - Original Message - From: Ed Brown [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 17, 2003 12:37 PM Subject: Re: [JBoss-user] jms issues Quoting Peter Fagerlund [EMAIL PROTECTED]: torsdagen den 16 januari 2003 kl 03.49 skrev Ed Brown: Here are the list of problems that I ran into when I used the JBoss implementation: 1. If too many messages were queued up, and the server was stopped and restarted, the server hung. 2. Sometimes when the server was stopped and restarted, the message queues seemed to get corrupted and the things wouldn't work. I would have to stop JBoss, manually remove the queues and restart. 3. The message queues didn't seem to hold up under heavy load. DefaultDS is used per default unless You massage Your persistent settings the above can result as perceived. The default settings were used when this happend. 1) I suspect a corrupted DB from a not clean shutdown 2) I suspect a corrupted DB from a not clean shutdown Shutdown was done using CTRL-C at the console. Since that was the way to shut it down, corrupted queues resulting from shutdown was not acceptable. 3) Depends how heavy We talk here ? could also be my introduced thread bug ? It was single threaded. What was Your test setup HW/SW and JBoss version ? JBoss 3.0.1, on Windows 2000 and Linux. I'm not alone in finding the JBoss implementation of JMS lacking. I've read the forums. IMO, it's not ready for prime time, for that matter, neither is the JBoss inclusion of Axis. But I've written enough. Ed Brown __ _ __ This mail sent via toadmail.com, web e-mail @ ToadNet - want to go fast? http://www.toadmail.com --- This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will allow you to extend the highest allowed 128 bit encryption to all your clients even if they use browsers that are limited to 40 bit encryption. Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user --- This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will allow you to extend the highest allowed 128 bit encryption to all your clients even if they use browsers that are limited to 40 bit encryption. Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en ___ JBoss-user mailing list [EMAIL PROTECTED]
Re: [JBoss-dev] JMS reliability (?)
Yep, I'm basing it only on the fact that 3.2 is a new implementation that hasn't been as widely tested as the 3.0 series. I'm coming at this from the viewpoint of my application which doesn't currently have throughput problems. If speed was more critical, my thoughts might be different. Aaron On Sunday 02 February 2003 09:29 pm, you wrote: Can you clarify this recommendation? It sounds like you said 3.2 is better, but use 3.0.x. Is this solely because 3.2 isn't quite baked yet or is there another reason to stick with 3.0.x? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Aaron Lindsey Sent: Sunday, February 02, 2003 3:13 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JMS reliability (?) Hi Calin, While there is still room for improvement in the performance category, I believe the corruption problems with large queues is fixed in the later releases of the 3.0.x series. If you use JBoss 3.0.5 or later, you shouldn't experience the problems outlined in points 1 and 2 below. JBoss 3.2.x has a new implementation that should help in high load situations, but I would suggest using the 3.0.x series for production use. Aaron On Sunday 02 February 2003 11:17 am, you wrote: Hi, I saw a couple of worrying messages in the mailing lists regarding the reliability of JBoss implementation of JMS. Is JBoss' JMS reliable and suitable for production environment? For example for the scenario of an external client (or an another JBoss server) sending messages to a JBoss server. If the answer is yes ( I hope this is the answer) , which JBoss version is the most reliable and suitable for production? Any feedbacks really appreciated, Calin Lupa - Original Message - From: Muntean Horia To: [EMAIL PROTECTED] Sent: Sunday, January 19, 2003 1:30 PM Subject: Re: [JBoss-user] jms issues Rob Finneran wrote: Hi Listees, Just to give feedback, and not to rant too much: I have also seen the problems stated in 1 and 2 of these messages. I had to remove message queueing from my production environments because of it. IMHO, It would be very big plus if the JMS reliability issues were resolved. I hate to complain because JBoss has served me well, but I would like to use JMS more frequently in my production environments. Cheers, Rob - Original Message - From: Ed Brown [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 17, 2003 12:37 PM Subject: Re: [JBoss-user] jms issues Quoting Peter Fagerlund [EMAIL PROTECTED]: torsdagen den 16 januari 2003 kl 03.49 skrev Ed Brown: Here are the list of problems that I ran into when I used the JBoss implementation: 1. If too many messages were queued up, and the server was stopped and restarted, the server hung. 2. Sometimes when the server was stopped and restarted, the message queues seemed to get corrupted and the things wouldn't work. I would have to stop JBoss, manually remove the queues and restart. 3. The message queues didn't seem to hold up under heavy load. DefaultDS is used per default unless You massage Your persistent settings the above can result as perceived. The default settings were used when this happend. 1) I suspect a corrupted DB from a not clean shutdown 2) I suspect a corrupted DB from a not clean shutdown Shutdown was done using CTRL-C at the console. Since that was the way to shut it down, corrupted queues resulting from shutdown was not acceptable. 3) Depends how heavy We talk here ? could also be my introduced thread bug ? It was single threaded. What was Your test setup HW/SW and JBoss version ? JBoss 3.0.1, on Windows 2000 and Linux. I'm not alone in finding the JBoss implementation of JMS lacking. I've read the forums. IMO, it's not ready for prime time, for that matter, neither is the JBoss inclusion of Axis. But I've written enough. Ed Brown __ _ __ This mail sent via toadmail.com, web e-mail @ ToadNet - want to go fast? http://www.toadmail.com --- This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will allow you to extend the highest allowed 128 bit encryption to all your clients even if they use browsers that are limited to 40 bit encryption. Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en ___ JBoss-user mailing list [EMAIL PROTECTED]