BPEL - eventHandlers

[adrian.andrei]

Hi there,

I try to build an event based example. I can see the selector being built, I can see the event being received and the port handler in "listening for response:" but ... nothing happens.

I think the issue is related to JMS subscription (request listener versus port handler) since the onMessage event is never triggered.

Are the events implemented? Do you have a working example?

By the way, I used events with and without correlation and I see that you do not cover the former case. In RequestListener, buildSelector please chack for correlations befpre opening an iterator.

 [...]
 // reception properties
 Correlations correlations = receiver.getCorrelations();
 if ( correlations != null )
 {
 Map properties = correlations.getReceptionProperties( token );
 [...]

Regards,
AA

PS
Do you have a date in mind when BPEL is fully implemented in JBOSS extension?

[aguizar]

Are the events implemented? Do you have a working example?

Yep, the ATM example uses events.

I used events with and without correlation and I see that you do not cover the former case

This is a bug, see BPEL-90. However, without correlations, you can't distinguish between process instances, so only one instance can wait for that specific message at a time. But for some processes that might make sense.

Do you have a date in mind when BPEL is fully implemented in JBOSS extension

You can check the road map in JIRA anytime. I recently made some big changes and things are a bit messy, but they should be in order by next week.

[adrian.andrei]

Yep, the ATM example uses events.

ATM uses pick&onMessage, not event handlers. All my examples with pick work fine, none of them work with scope/event handler.

Change ATM to respond to events instead of pick while is doing "tedious" balance calculation for example and one may want to see current status.

Regards,
AA

[adrian.andrei]

As a matter a fact I can tell you where to look exactly:

The request listener uses the MessagerSession.getJmsSession to create a subscriber. Somehow this is not very well accepted by Jms since the current thread is still busy with the scope content execution.

The process freezes in attempt to close the scope consumers: RequestListener.close() if an event was received during scope execution. I had a little fun and commented out the

consumer.close();

call to see what happens. The client timesout but the BPEL process continues.

I guess the solution is to have your own jms session in RequestListener rather than using the global (and transactional) one from MessagerSession.

Hope that helps.

Regards,
AA

[aguizar]

There is an event handler in the ATM example that reports the status (/process/sequence/scope):

<scope name="connectedScope">
 [...]
 <eventHandlers>
 <onMessage operation="status" partnerLink="frontEnd" portType="atm:atm"
 variable="sessionMsg">
 <correlations>
 <correlation set="sessionInteraction" />
 </correlations>

 <sequence name="statusSequence">
 [...]
 <reply operation="status" partnerLink="frontEnd" portType="atm:atm"
 variable="statusRsp" />
 </sequence>
 </onMessage>
 </eventHandlers>
 </scope>

Anyway, when the test client requests the status, the instance isn't busy executing the normal path, so it doesn't hit the issue you describe. It makes sense: JMS delivers a session's messages serially. An activity in the normal path receives a message. It resumes execution and, at the same time, an event message arrives. The normal path completes and the scope tries to close event listeners, because it thinks no events are pending; the event message has not been delivered yet.

I don't fully understand why the consumer.close() call blocks. It is supposed to block until a listener in progress completes, but in this case the session has not delivered the message. Does the consumer "see" it has a pending message? I need to investigate more.

Once again, thanks for your help.

[adrian.andrei]

I modified the RequestListener code to allow concurrent events. In the constructor, I replace the line:

consumer = messagerSession.getJmsSession().createConsumer(destination, selector);

with

Session session = messagerSession.getMessager().getConnection().createSession(false, Session.AUTO_ACKNOWLEDGE);
consumer = session.createConsumer(destination, selector);

I can receive now event while I am processing different business logic inside the scope, but I get a Null pointer exception in MessageHandler. The scopeInstance is not found in the token's context instance.

 public void messageReceived(Receiver receiver, Element element, Token token) {
 log.debug("message received");
 ScopeInstance scopeInstance = ScopeInstance.get(token);
 if (!scopeInstance.getState().equals(ActiveState.NORMAL_PROCESSING)) {
 log.error("Incoming events are only accepted when a scope instance is normally processing");
 return;
 }

Do you intend to fix this issue or should I proceed with debugging even deeper into your code?

Regards,
AA

[aguizar]

I'm already working on it, but there is a reason why the existing JMS session is used. The problem with starting a new JMS session is, in case the message is already there when you open the listener, it will be delivered immediately. The thread that opened the listener may not have committed yet, so its changes are not visible from the thread where the message is delivered. When you use the same session, JMS will not deliver another message until the current one has been acknowledged.

This model proved problematic when I tried to implement timers, because the thread that delivers the alarm is not managed by JMS and results in similar misbehavior. I'm changing things to rely on database locking rather than JMS ordered delivery. I will also cover the message events case.