[Design of Messaging on JBoss (Messaging/JBoss)] - Message expiration infinite loop
by clebert.suconic＠jboss.com
I guess the subject of the day is expiration.. what a coincidence! :-)
This is a discussion about http://jira.jboss.org/jira/browse/JBMESSAGING-951
On my local copy, I have added a tracing at ServerSessionEndpoint that I don't want to commit but it was useful understanding this issue:
| void expireDelivery(Delivery del, Queue expiryQueue) throws Throwable
| {
| ...
| log.info("ExpireDelivery " + del + " queue = " + expiryQueue, new Exception());
| ...
| }
|
Analyzing the logs, when running ExpiredMessageTest::testExpirationTransfer, I have a sequence of messages...
This is the first one:
| java.lang.Exception
| at org.jboss.jms.server.endpoint.ServerSessionEndpoint.expireDelivery(ServerSessionEndpoint.java:720)
| at org.jboss.jms.server.endpoint.ServerConsumerEndpoint.handle(ServerConsumerEndpoint.java:207)
| at org.jboss.messaging.core.local.RoundRobinPointToPointRouter.handle(RoundRobinPointToPointRouter.java:120)
| at org.jboss.messaging.core.ChannelSupport.deliverInternal(ChannelSupport.java:612)
| at org.jboss.messaging.core.ChannelSupport.handleInternal(ChannelSupport.java:759)
| at org.jboss.messaging.core.ChannelSupport.handle(ChannelSupport.java:157)
| at org.jboss.messaging.core.local.PagingFilteredQueue.handle(PagingFilteredQueue.java:114)
| at org.jboss.messaging.core.plugin.postoffice.DefaultPostOffice.route(DefaultPostOffice.java:333)
| at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.sendMessage(ServerConnectionEndpoint.java:685)
| at org.jboss.jms.server.endpoint.ServerSessionEndpoint.send(ServerSessionEndpoint.java:298)
| at org.jboss.jms.server.endpoint.advised.SessionAdvised.org$jboss$jms$server$endpoint$advised$SessionAdvised$send$aop(SessionAdvised.java:80)
| at org.jboss.jms.server.endpoint.advised.SessionAdvised$send_6145266547759487588.invokeNext(SessionAdvised$send_6145266547759487588.java)
| at org.jboss.jms.server.container.SecurityAspect.handleSend(SecurityAspect.java:152)
| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
| at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
|
And after that... it keeps in a infinite loop between these methods...
| at org.jboss.jms.server.endpoint.ServerSessionEndpoint.expireDelivery(ServerSessionEndpoint.java:720)
| at org.jboss.jms.server.endpoint.ServerConsumerEndpoint.handle(ServerConsumerEndpoint.java:207)
| at org.jboss.messaging.core.local.RoundRobinPointToPointRouter.handle(RoundRobinPointToPointRouter.java:120)
| at org.jboss.messaging.core.ChannelSupport.deliverInternal(ChannelSupport.java:612)
| at org.jboss.messaging.core.ChannelSupport$InMemoryCallback.afterCommit(ChannelSupport.java:1035)
| at org.jboss.messaging.core.tx.Transaction.commit(Transaction.java:228)
| at org.jboss.jms.server.endpoint.ServerSessionEndpoint.moveInTransaction(ServerSessionEndpoint.java:1069)
| at org.jboss.jms.server.endpoint.ServerSessionEndpoint.expireDelivery(ServerSessionEndpoint.java:729)
| at org.jboss.jms.server.endpoint.ServerConsumerEndpoint.handle(ServerConsumerEndpoint.java:207)
| at org.jboss.messaging.core.local.RoundRobinPointToPointRouter.handle(RoundRobinPointToPointRouter.java:120)
| at org.jboss.messaging.core.ChannelSupport.deliverInternal(ChannelSupport.java:612)
| at org.jboss.messaging.core.ChannelSupport$InMemoryCallback.afterCommit(ChannelSupport.java:1035)
| at org.jboss.messaging.core.tx.Transaction.commit(Transaction.java:228)
| at org.jboss.jms.server.endpoint.ServerSessionEndpoint.moveInTransaction(ServerSessionEndpoint.java:1069)
| at org.jboss.jms.server.endpoint.ServerSessionEndpoint.expireDelivery(ServerSessionEndpoint.java:729)
| at org.jboss.jms.server.endpoint.ServerConsumerEndpoint.handle(ServerConsumerEndpoint.java:207)
| at org.jboss.messaging.core.local.RoundRobinPointToPointRouter.handle(RoundRobinPointToPointRouter.java:120)
| at org.jboss.messaging.core.ChannelSupport.deliverInternal(ChannelSupport.java:612)
| at org.jboss.messaging.core.ChannelSupport$InMemoryCallback.afterCommit(ChannelSupport.java:1035)
| at org.jboss.messaging.core.tx.Transaction.commit(Transaction.java:228)
|
So... after the message is expired.. .it is transfered to the ExpiryQueue.. and as it is expired it is transfered from the ExpiryQueue again to the ExpiryQueue and keeps in loop on that...
The fix is an easy fix probably. I will do it tomorrow first thing in the morning... (Unless Tim or Serge want to fix it before me as they are few hours ahead in Europe :-) )
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4042696#4042696
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4042696
17 years
[Design of JBoss jBPM] - suspend-resume() Method with problems
by javi0704
HiGuys , i tried to develop jbpm with some rules (drools). I use just start-state, task-node, (task with action-ActionHandler variables) and end-state.
So my problem is:
suppose a user give a value for one varable this will be controll by the drool
For example variableName is "value" So the drool-rule condition controlls if value>10 then Condition is ok the process will continue,
when not ok==>Drools(in Consequence) this Task-Node must wait, block or lock till the value variable is correct that means till value>10
I tried this with the Method: to block the Task-node processInstance.suspend() also processInstance.wait()
and to unblock the Task-Node processInstance.resume() also processInstance.signal()but it doesn't work.
please help me with this problem
with kind regards
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4042663#4042663
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4042663
17 years
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Message expiration in JBossMQ - JBAS-4328
by timfox
What's happening in this test is the messages are sent, then almost immediately they are received by the connection consumer (which lives on the client side) - at this point they are not expired.
Later on the connection consumer passes the messages onto the message listener and a delay is introduced, but by this time the messages are already on the client so won't get expired since JBossMQ doesn't do an extra client side check.
I haven't actually run this test against JBoss Messaging but we do an extra client side expiration check as well as a server side one. This is particularly important to us since we buffer messages on the client side, therefore I would expect this test to pass for JBM.
However, having said all that, the JMS spec is pretty loose about JMSExpiration:
anonymous wrote :
| When GMT is later than an undelivered message?s expiration time, the
| message should be destroyed. JMS does not define a notification of message
| expiration.
| Clients should not receive messages that have expired; however, JMS does not
| guarantee that this will not happen.
|
Since there are no guarantees I would say the JBossMQ is sub-optimal but not incorrect and is fully spec compliant.
You can't expect a general jms provider to fully honour JMSExpiration in all circumstances.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4042650#4042650
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4042650
17 years