Re: JMSBC - BPEL long running process with correlation

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Re: JMSBC - BPEL long running process with correlation

Paul Wickstrom

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:

I'm trying to emulate a long running process which sends a message to a queue (request or output) and waits async message coming from an other queue (response or input) using correlation. (two wsdl files, oneway operation in both, so an Out Message Exchange first, than an In message exchange, one BPEL process, Invoke to send, and a Pick with timeout to receive the correlated message) (using MQSeries as MOM, and latest build of openesb)

If the BPEL process is not Atomic (which should be the case if this is really long running), I get the following message in appserver log, when sending out the message:
JMSBC-I0714: JMS binding operation {}SendMessage was not marked as XATransaction but a transactional context is available in message exchange with ID 132614298371682-11856-134391574989900121; will continue to send JMS message to JMS destination TEST1 without participating in the XA transaction [J2EETransaction: txId=2 nonXAResource=null jtsTx=null localTxStatus=0 syncs=[]]

1. Is this just a warning message (I assume), and everything works, without transaction, does it mean that the message is sent immediately?
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. 

2. Can I eliminate this message with some kind of hint in BPEL or in WSDL that this is intentional?
(setting jms:operaion in BPEL to NoTransaction
<jms:operation destination="TEST1" destinationType="Queue" transaction="NoTransaction"/>
 does not help, still get the message)

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).

3. If I set the process Atomic attribute to true, what happens exactly? It seems working without warning, but it means that the Out operation commits the XA transaction? Or what is exactly the boundary of the XA transaction(s)?
Accoring to the doc:
This is XA, but starting with an Out operation, and then a Pick to either receive a correlated response or do timeout with an Alarm. This scenario and the relationship to XA attribute is not documented, as I understand. Will you please explain?

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.
  a) which throttling or other parameter limits the number of messages that JMSBC will get from the queue and will not be able to deliver?
  b) how can I specify, that these (impossible to correlate) messages should be passed to someone else? (maybe after some timeout) (according to the doc, error cases can be handled, but this is not an "error", this is just a "problem", that no business process instance exists to correlate those incoming 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 ""

5. Stopping JMSBC, while I have message exchanges waiting for a successful correlation, results:
JMSBC-I0717: Stopped inbound endpoint ID = 5a074c92-1655-41d0-87f8-89d319dee940.

JBIFW1156: Binding sun-jms-binding has been stopped.
Exception in thread "pool-5-thread-3"
        at $Proxy45.take(Unknown Source)
        at java.util.concurrent.ThreadPoolExecutor.getTask(
        at java.util.concurrent.ThreadPoolExecutor$
Caused by: java.lang.reflect.InvocationTargetException
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(
        at java.lang.reflect.Method.invoke(
        at com.sun.jbi.jmsbc.util.BlockingQueueFactory$InvocationHandlerImpl.invoke(
        ... 4 more
Caused by: java.lang.InterruptedException
        at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.reportInterruptAfterWait(
        at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(
        at java.util.concurrent.LinkedBlockingQueue.take(
        ... 9 more
Ignoring duplicate registration of endpoint,sun-jms-binding,redeliveryLoopback from component sun-jms-binding

Is this normal operational, or should we expect something different?
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.


To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]