Please see responses in-line below in red (provided by Vivek Chaudhary). Hope this helps.
Paul Wickstrom Sun Software, SOA BI FAST [hidden email], access line x60042/+1-586-981-9987, mobile 586-871-3892, AIM paulwickstromsjc
Molnar, Istvan wrote:
Hi,This means that the message exchange has XA transaction property set, but the JMS binding operation is not enabled to participate in the transaction. This message just reminds that the JMS operation will not be performed as part of transaction that is passed in the message exchange. Since you have BPEL persistence enabled, the JMS transaction _should_ be included in the XA transaction to ensure both the JMS operation and BPEL DB operation are committed as one unit. That is, a long running BP instance with persistence enabled is layered on a series of short running XA transactions.
The message is not logged as warning, it is being logged as INFO. To eliminate the message, enable XATransaction on the JMS operation (see reasoning above).
To change the transaction attribute, go to the JMS WSDL and open jms:operation properties. There you can change the transaction attribute (illustrated below).
For out bound JMS operations. The XA boundary is not decided in the JMSBC. JMSBC would simply pull the transaction from the message property, resume that transaction and then perform the JMS operations so that all JMS operations (essentially JMS XAResource) would become a part of global transaction for that transaction context. When everything is completed successfully, JMSBC would suspend the transaction and send the response back to the caller. Now it is up to caller (or the originating party in this case BPEL SE) to either commit/rollback the transaction or continue using the same transaction context in further interactions.
4. If there are messages in the response (input) queue, when starting glassfish or jmsbc or deploying the composite app, jmsbc gets all the messages from this queue, but BPELSE is not able to correlate it to any business process (they are not persisted, so did not survive restart, or they are already timed out with the Pick). It seems that JMSBC reads maximum 15 messages, and waits indefinitely for BPELSE to consume the messages.I believe you are using sync mode. Yes, by default it would create 15 threads.You can specify throttling in CASA editor. This is explained in detail on "http://wiki.open-esb.java.net/Wiki.jsp?page=UserGuideAndEnhancements#section-UserGuideAndEnhancements-QualityOfServiceSupport"
This is not serious. This is happens when JMSBC thread pool is stopped. As you can see from the stack trace this happens when a thread that is waiting for a task is interrupted.
|Free forum by Nabble||Edit this page|