Issue Details (XML | Word | Printable)

Key: COMMUNITY_EQUITY-409
Type: Sub-task Sub-task
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: cygnusecks1
Reporter: PRE
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
community-equity
COMMUNITY_EQUITY-407

JMS tuning

Created: 11/Jan/10 09:16 AM   Updated: 15/Feb/10 10:26 AM   Resolved: 13/Jan/10 04:20 PM
Component/s: None
Affects Version/s: Milestone 1.2
Fix Version/s: Milestone 1.3

Time Tracking:
Not Specified

Tags:


 Description  « Hide

JMS - do not set durable/persistent, not transactional,short time_to_live as messages are used to kick on the worker – tune jms settings

  1. Task1: Provide tuning parameter :
    Is this set by the application or via JMS container configuration ? ( setting via application preferred)
    Related Bean: DataManipulatorMessageConsumerBean.java
  1. Task2: why do we have 2 jms consumers


PRE added a comment - 11/Jan/10 11:33 AM

To avoid deadlock with local installed JMS and DB set JMS config from "EMBEDDED * to *LOCAL"


DmitryRyashchentsev added a comment - 11/Jan/10 04:36 PM

1. JMS queue settings are in ceq-ejb/setup/sun-resources.xml file.
But, as I can see some of parameters are ignored by GF, it is possible to set them only by GF console (timeout, for example).

2. I hope we have only 1 consumer. May be you can see in GF console old consumer (I renamed it switching from Topic to Queue), it does not used.
If not this case, can you please point where you can see 2 ones.


Misu added a comment - 12/Jan/10 12:07 PM

About the configuration (task 1).

1.The MDB bean DataManipulatorMessageConsumerBean can be configured with the deployment descriptor ejb-jar.xml.
2.The consumer (and producer can be configurative) programatically also. The problem in this case is the configuration, or more precisely how this configuration is specified - if we use a file then we have something similar with the point 1; the other alternative is the user must provide this information but then it is not clear to me how this information will be provided.
3.The used Queue is configured in a application server private manner , for the Glassfish uses a file named sun-resource.xml. Other application server may use other configuration files.

For tuning we need to define some goals (e.g. unit tests which must run a certain time), please provide more details about this.

About the subscriptionDurability.

In my opinion this must remain durable because the event must be triggered in order to process the CEQ values, otherwise some messages can be missed and in this way there is no guarantee that the CEQ are calculated (if the messages are missed).

About the transactional

The actual implementation is not transactional. The feature can not be external configurable. The only way to make he MDB running in transaction mode is to use the REQUIRED transaction attribute for the onMessage method.


Misu added a comment - 12/Jan/10 12:55 PM

Task 2:

Why we have 2 consumers.

The short answer to this question is : we have only one mdb consumer (the DataManipulatorMessageConsumerBean)

The long answer is :
The actual JMS implementation works like this : the message producer is the DataManipulatorMessageProducerBean, this bean is used to send map messages (javax.jms.MapMessage). This messages are build with a factory - all the message factory must implement the com.sun.ceq.math.model.MapMessageFactory. The reason to do this to keep separate the message building and the message sending.
The JMS message producer (DataManipulatorMessageProducerBean) sends an event and this event reach the JMS consumer (DataManipulatorMessageConsumerBean). This consumer can consume the event by using its own kind of consummers (DataManipulatorLogActionConsumer is none of them). Unfortunately the names can create problems. The reason why I choose this two layer of consumers is because I want to use more messages without to get to much JMS elements involved - in this way you can send a message to certain consumer using only one JMS producer and only one JMS consumer. More this second layer allows you to control the way how the messages are dispatched.

This solution will fits if we deal with more messages, but in our cases we only have only one message "to kick on the worker" is an overhead - a simple point to point solution will fit better.


cygnusecks1 added a comment - 12/Jan/10 09:32 PM

Much of the JMS queue configuration is appserver-specific and exposed through the existing admin interfaces (CLI, admin console, *.xml files, etc). I don't think we should further expose those through the application, even if it is programmatically settable. It is not what real world admins would expect or even use.

I've done some research and changed a couple of things:

  • 1. Durability - according to my research, this only applies to publish/subscribe models that use JMS Topics. There is no such thing as durability for JMS queues. Durability refers to the ability for a subscriber to receive messages that were published while the subscriber had previously unsubscribed. That does not apply to queues and point-to-point messaging.
  • 2. Persistence. I do not believe persistence is needed in this case, as the messages are simply "triggers". If the system crashes it's not important that we receive possibly unsent messages when the system recovers. Messages happen frequently enough that it's not worth it to take a performance hit for this scenario.
  • 3. Transactional: Misu is correct, this does not apply here.
  • 4. Time to live: The default value is 0, so no need to increase that.
  • 5. 2 consumers: I've simplified the code by removing the intermediate consumer and moving to a simpler point to point solution as Misu suggested. There really was only one consumer, which then delegated to one or more "sub"-consumers (in this case there was only one, the DataManipulatorLogActionConsumer). Removing the intermediate may make it faster, but not by much.

So, with all of the above changes things still work I'll check this in tomorrow morning unless there are objections.


PRE added a comment - 12/Jan/10 10:31 PM

James -
Installed it on my Mac and it runs with much less error messages in the log.
good job!

A few discoveries : I imported 10 days of SunSpace updates (e.g. http://sunspace.sfbay.sun.com/feed/atom?wg=333&duration=10)

a.) sometimes I get table lock error for the GENERATOR table (see below)
b.) when importing the the feed - I can't rate (e.g. rating widget is not updating, nor comment, nor (e) activity overlay
c.) (e )activity overlay works ok in listing (e.g Community Overview page)
d.) still get UNKNOWN activities per information (http://kenai.com/jira/browse/COMMUNITY_EQUITY-417)
e.) CPU utilization is high (70-90%)
f.) import of around 915 Information took about 10' (seems to be faster )
g.) rate/comment widget does not calculate ANY equity anymore (need to investigate more

Overall - looks good to me

23:53:02.0, null, 1, SunWiki, 240, null]
UPDATE GENERATOR SET GENERATOR_VALUE = GENERATOR_VALUE + ? WHERE GENERATOR_KEY = ?
bind => [1, LOG]
SELECT GENERATOR_VALUE FROM GENERATOR WHERE GENERATOR_KEY = ?
bind => [LOG]
Local Exception Stack:
Exception [TOPLINK-4002] (Oracle TopLink Essentials - 2.1 (Build b60e-fcs (12/23/2008))): oracle.toplink.essentials.exceptions.DatabaseException
Internal Exception: java.sql.SQLException: Lock wait timeout exceeded; try restarting transaction
Error Code: 1205
Call: UPDATE GENERATOR SET GENERATOR_VALUE = GENERATOR_VALUE + ? WHERE GENERATOR_KEY = ?
bind => [1, LOG]
Query: DataModifyQuery()
at oracle.toplink.essentials.exceptions.DatabaseException.sqlException(DatabaseException.java:311)
at oracle.toplink.essentials.internal.databaseaccess.DatabaseAccessor.executeDirectNoSelect(DatabaseAccessor.java:654)
at oracle.toplink.essentials.internal.databaseaccess.DatabaseAccessor.executeNoSelect(DatabaseAccessor.java:703)
at oracle.toplink.essentials.internal.databaseaccess.DatabaseAccessor.basicExecuteCall(DatabaseAccessor.java:492)
at oracle.toplink.essentials.internal.databaseaccess.DatabaseAccessor.executeCall(DatabaseAccessor.java:452)
at oracle.toplink.essentials.internal.sessions.AbstractSession.executeCall(AbstractSession.java:690)
at oracle.toplink.essentials.internal.queryframework.DatasourceCallQueryMechanism.executeCall(DatasourceCallQueryMechanism.java:228)
at oracle.toplink.essentials.internal.queryframework.DatasourceCallQueryMechanism.executeCall(DatasourceCallQueryMechanism.java:214)
at oracle.toplink.essentials.internal.queryframework.DatasourceCallQueryMechanism.executeNoSelectCall(DatasourceCallQueryMechanism.java:257)
at oracle.toplink.essentials.internal.queryframework.DatasourceCallQueryMechanism.executeNoSelect(DatasourceCallQueryMechanism.java:237)
at oracle.toplink.essentials.queryframework.DataModifyQuery.executeDatabaseQuery(DataModifyQuery.java:86)
at oracle.toplink.essentials.queryframework.DatabaseQuery.execute(DatabaseQuery.java:628)
at oracle.toplink.essentials.internal.sessions.AbstractSession.internalExecuteQuery(AbstractSession.java:1845)
at oracle.toplink.essentials.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:952)
at oracle.toplink.essentials.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:924)
at oracle.toplink.essentials.sequencing.QuerySequence.update(QuerySequence.java:344)
at oracle.toplink.essentials.sequencing.QuerySequence.updateAndSelectSequence(QuerySequence.java:283)
at oracle.toplink.essentials.sequencing.StandardSequence.getGeneratedVector(StandardSequence.java:96)
at oracle.toplink.essentials.sequencing.Sequence.getGeneratedVector(Sequence.java:281)
at oracle.toplink.essentials.internal.sequencing.SequencingManager$Preallocation_Transaction_NoAccessor_State.getNextValue(SequencingManager.java:420)
at oracle.toplink.essentials.internal.sequencing.SequencingManager.getNextValue(SequencingManager.java:846)
at oracle.toplink.essentials.internal.sequencing.ClientSessionSequencing.getNextValue(ClientSessionSequencing.java:110)
at oracle.toplink.essentials.internal.descriptors.ObjectBuilder.assignSequenceNumber(ObjectBuilder.java:240)
at oracle.toplink.essentials.internal.sessions.UnitOfWorkImpl.assignSequenceNumber(UnitOfWorkImpl.java:355)
at oracle.toplink.essentials.internal.sessions.UnitOfWorkImpl.registerNotRegisteredNewObjectForPersist(UnitOfWorkImpl.java:3266)
at oracle.toplink.essentials.internal.ejb.cmp3.base.RepeatableWriteUnitOfWork.registerNotRegisteredNewObjectForPersist(RepeatableWriteUnitOfWork.java:432)
at oracle.toplink.essentials.internal.sessions.UnitOfWorkImpl.registerNewObjectForPersist(UnitOfWorkImpl.java:3226)
at oracle.toplink.essentials.internal.ejb.cmp3.base.EntityManagerImpl.persist(EntityManagerImpl.java:221)
at com.sun.enterprise.util.EntityManagerWrapper.persist(EntityManagerWrapper.java:238)
at com.sun.ceq.session.LogServiceImpl.addLog(LogServiceImpl.java:474)
at sun.reflect.GeneratedMethodAccessor138.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.enterprise.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1011)
at com.sun.enterprise.security.SecurityUtil.invoke(SecurityUtil.java:175)
at com.sun.ejb.containers.BaseContainer.invokeTargetBeanMethod(BaseContainer.java:2920)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:4011)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:197)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:83)
at $Proxy72.addLog(Unknown Source)
at com.sun.ceq.session.InformationServiceImpl.setInformationRating(InformationServiceImpl.java:750)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.enterprise.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1011)
at com.sun.enterprise.security.SecurityUtil.invoke(SecurityUtil.java:175)
at com.sun.ejb.containers.BaseContainer.invokeTargetBeanMethod(BaseContainer.java:2920)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:4011)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:197)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:83)
at $Proxy63.setInformationRating(Unknown Source)
at com.sun.ceq.webservices.jersey.jsonp.InformationParticipationWebServiceWithPadding.postCommentForInformationUrlEncoded(InformationParticipationWebServiceWithPadding.java:153)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)


PRE added a comment - 13/Jan/10 12:23 AM

I did some pretty extensive testing and the changes from James definitely improved performance and decreased load of the server.
I suggest to commit these changes


DmitryRyashchentsev added a comment - 13/Jan/10 04:11 PM

PR> a.) sometimes I get table lock error for the GENERATOR table (see below)

I created a separate ticket on that COMMUNITY_EQUITY-420


cygnusecks1 added a comment - 13/Jan/10 04:20 PM

Fixed in SVN revision 463.


Misu added a comment - 14/Jan/10 12:47 PM

I just have a rework JMS solution which I hope will solve all the async related problems.
The solution works for my test, in my last test a producer produce 1000 messages and each message can take from 0 to 100 seconds and the system still works.
The solution is stored in the CEQ_JMS_REWORK brach.

I will describe it

The CEQ uses a JMS point to point strategy, this strategy grantee that only one consumer receive and consume the involved messages. The javax.jms.Queue quarantee for this.

The actual implementation has one message producer (DataManipulatorMessageProducerBean) and only one message consumer (DataManipulatorMessageConsumerBean),
please note that both are using the Bean suffix.
The producer is a bean and it can be injected where is needed to produce messages. The messages are builded with specific factory.
The JMS consumer consumes the messages in it own way, for this it use some plain java classes named for convenience also consumers - plain consumers. Each plain consumer can consume only a certain kind of message, the canConsume method from the plain consumer is used to check if a consumer can consume a certain message. The actual implementation uses the com.sun.ceq.math.model.DataManipulatorClassConsumer like superclass for all the pain java consumers. This class contains only one method, the canConsume method, this method proves if the involved message contains a String property named "class" with the value that correspond the consumer class name. By example if the message contains for the "class" property the value "com.sun.MyConsummer" then a sub class for the DataManipulatorClassConsumer named "com.sun.MyOtherConsummer" the canConsume method will return false, in posite for a sub class named "com.sun.MyConsummer" the canConsume method will return true.
So if you want to create a new consumer (for other kind of messages) you only need to create a new class and include the class name in the message "class" property, the system does the rest.

The plain consumers are loaded automatic in the PostConstruct life cycle phase, the JMS consumer (MDB) bean uses a properties file named consummers.properites (placed in the META-INF directory) to know which plain java consummer are available to load.

The actaul consummers.properites file contains only one relevant line :

consumers com.sun.ceq.math.model.TestConsummer, com.sun.ceq.math.model.DataManipulatorLogActionConsumer

Here in this line are two plain consumers, both will be used (to consume messages).

After JMS message consumer is initialised and the plain consumer are loaded the JMS messages can be consumed. When the DataManipulatorMessageConsumerBean gets a message from the message query then iterates over all its plain consumers, the first consumer that is able to consume the message (the canConsume returns true) and the iteration ends, on a new message a new iteration is started.

I also provide an example, the MessageBeanTest injects the producer DataManipulatorMessageProducerBean and sends 3 messages, each message is build for the TestConsummer (the message "class" property has "com.sun.ceq.math.model.TestConsummer" value). The TestConsummer is the plain consumer, this consumer print a message for an number of times (random) for each consumed message. If the test runs it produce a similar output :

Send message 0
Send message 1
Send message 2
Cycle [0] starts and runs 8 times.
0.0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
Cycle [0] ends.
Cycle [0] starts and runs 5 times.
1.0
1.1
1.2
1.3
1.4
Cycle [1] ends.
Cycle [2] starts and runs 7 times.
2.0
2.1
2.2
2.3
2.4
2.5
2.6
Cycle [2] ends.

Here you can see : 3 JMS messages are send (0,1 and 2), for each of this the TestConsummer runs three times (one per message) and it prints a random number of outputs. More precisely the output between the "Cycle [0] starts and runs 8 times" and "Cycle [0] ends" represents one run for the plain consumer.


Misu added a comment - 14/Jan/10 01:18 PM

I also do an other test with 10000 messages and each message can take from 0 to 100 seconds to be consumed, the system still runs.
I think the solution is good enough to be adopted.
How about you guys ?


Misu added a comment - 15/Jan/10 07:11 AM

The solution describe before was processing messages for more than 12 hours and the system is still running. Even more if the server is stop the the unconsumed messages are not lost after the server starts again the (remains) messages are processed.
With all of this I thing this can be a reliable solution.


DmitryRyashchentsev added a comment - 17/Jan/10 04:35 PM

Got the following exception:

DXAR:start():Warning:Received diff Xid for open txnId:switching transactionId:
DXAR Xid=4D65647665642C7365727665722C50333730302C02240000006E29113D4D65647665642C7365727665722C5033373030
DXAR TXid=6388961065159492864
got Xid=null
got TXid=6388961065159507968

...

commitTransaction (XA) on JMSService:jmsdirect failed for connectionId:6388961065158812672 and onePhase:false due to unkown JMSService server error.

And so then:

JTS5031: Exception [org.omg.CORBA.INTERNAL: vmcid: 0x0 minor code: 0 completed: Maybe] on Resource [commit] operation.
EJB5018: An exception was thrown during an ejb invocation on [InformationServiceImpl]
javax.ejb.EJBException: Unable to complete container-managed transaction.; nested exception is: javax.transaction.SystemException: org.omg.CORBA.INTERNAL: JTS5031: Exception [org.omg.CORBA.INTERNAL: vmcid: 0x0 minor code: 0 completed: Maybe] on Resource [commit] operation. vmcid: 0x0 minor code: 0 completed: No
javax.transaction.SystemException: org.omg.CORBA.INTERNAL: JTS5031: Exception [org.omg.CORBA.INTERNAL: vmcid: 0x0 minor code: 0 completed: Maybe] on Resource [commit] operation. vmcid: 0x0 minor code: 0 completed: No
at com.sun.jts.jta.TransactionManagerImpl.commit(TransactionManagerImpl.java:321)
...


PRE added a comment - 18/Jan/10 08:52 AM

Dima -
I don't get these error
Try to set following parameter in the Glassfish JMS properties
-Type: Local (this should fix the above error message)

  • Reconnect:Enabled -Whether JMS service attempts to reconnect when a connection is lost (might help as well)

DmitryRyashchentsev added a comment - 24/Jan/10 05:12 PM

I get JMS exception even with LOCAL type:

com.sun.messaging.jms.JMSException: MQRA:CA:createSession failed-Only one JMS Session allowed when managed connection is involved in a transaction
at com.sun.messaging.jms.ra.ConnectionAdapter.createSession(ConnectionAdapter.java:372)
at com.sun.ceq.math.model.DataManipulatorMessageProducerBean.trigger(DataManipulatorMessageProducerBean.java:149)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.enterprise.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1011)
at com.sun.enterprise.security.SecurityUtil.invoke(SecurityUtil.java:175)
at com.sun.ejb.containers.BaseContainer.invokeTargetBeanMethod(BaseContainer.java:2920)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:4011)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:197)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:127)
at $Proxy141.trigger(Unknown Source)
at com.sun.ceq.math.model.DataManipulatorMessageConsumerBean.onMessage(DataManipulatorMessageConsumerBean.java:95)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.enterprise.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1011)
at com.sun.enterprise.security.SecurityUtil.invoke(SecurityUtil.java:175)
at com.sun.ejb.containers.BaseContainer.invokeTargetBeanMethod(BaseContainer.java:2920)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:4011)
at com.sun.ejb.containers.MessageBeanContainer.deliverMessage(MessageBeanContainer.java:1111)
at com.sun.ejb.containers.MessageBeanListenerImpl.deliverMessage(MessageBeanListenerImpl.java:74)
at com.sun.enterprise.connectors.inflow.MessageEndpointInvocationHandler.invoke(MessageEndpointInvocationHandler.java:179)
at $Proxy163.onMessage(Unknown Source)
at com.sun.messaging.jms.ra.OnMessageRunner.run(OnMessageRunner.java:258)
at com.sun.enterprise.connectors.work.OneWork.doWork(OneWork.java:76)
at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:555)
The log message is null.
com.sun.ceq.math.model.ProducerException: com.sun.messaging.jms.JMSException: MQRA:CA:createSession failed-Only one JMS Session allowed when managed connection is involved in a transaction
at com.sun.ceq.math.model.DataManipulatorMessageProducerBean.trigger(DataManipulatorMessageProducerBean.java:159)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.enterprise.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1011)
at com.sun.enterprise.security.SecurityUtil.invoke(SecurityUtil.java:175)
at com.sun.ejb.containers.BaseContainer.invokeTargetBeanMethod(BaseContainer.java:2920)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:4011)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:197)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:127)
at $Proxy141.trigger(Unknown Source)
at com.sun.ceq.math.model.DataManipulatorMessageConsumerBean.onMessage(DataManipulatorMessageConsumerBean.java:95)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.enterprise.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1011)
at com.sun.enterprise.security.SecurityUtil.invoke(SecurityUtil.java:175)
at com.sun.ejb.containers.BaseContainer.invokeTargetBeanMethod(BaseContainer.java:2920)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:4011)
at com.sun.ejb.containers.MessageBeanContainer.deliverMessage(MessageBeanContainer.java:1111)
at com.sun.ejb.containers.MessageBeanListenerImpl.deliverMessage(MessageBeanListenerImpl.java:74)
at com.sun.enterprise.connectors.inflow.MessageEndpointInvocationHandler.invoke(MessageEndpointInvocationHandler.java:179)
at $Proxy163.onMessage(Unknown Source)
at com.sun.messaging.jms.ra.OnMessageRunner.run(OnMessageRunner.java:258)
at com.sun.enterprise.connectors.work.OneWork.doWork(OneWork.java:76)
at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:555)
Caused by: com.sun.messaging.jms.JMSException: MQRA:CA:createSession failed-Only one JMS Session allowed when managed connection is involved in a transaction
at com.sun.messaging.jms.ra.ConnectionAdapter.createSession(ConnectionAdapter.java:372)
at com.sun.ceq.math.model.DataManipulatorMessageProducerBean.trigger(DataManipulatorMessageProducerBean.java:149)
... 27 more
onMessage: Ok


PRE added a comment - 15/Feb/10 10:26 AM

closed all ticket for Milestone Release 1.3