Acknowledgments need to be synchronous
--------------------------------------
Key: STOMP-7
URL:
http://jira.codehaus.org/browse/STOMP-7 Project: Stomp
Issue Type: Bug
Environment: JBoss Messaging 1.4.0SP1
Reporter: Julian Scheid
Attachments: stompconnect-1.0-sync-ack.patch
In client acknowledge mode, StompConnect currently calls Message.acknowledge() on a different thread than MessageListener.onMessage(). This causes problems with JBoss Messaging 1.4.0 SP1 - the ack is spuriously ignored causing some messages to stay in delivery indefinitely.
The JMS specification has a section on multi-threading (section 2.8) but it is not conclusive when it comes to asynchronous acks. It does say however that MessageConsumer and Session objects are not meant to be used from more than one thread at a time. While acknowledge() is technically called on a Message, I guess this can be interpreted as asynchronous acks being not necessarily supported by JMS providers.
This is why I came up with attached patch. It starts a thread for each subscription which repeatedly calls MessageConsumer.receive() with a timeout, checking for pending acks in between. Using this patch the JBoss Messaging issue goes away. The need to use a timeout is unfortunate, but I guess it's more important to be spec conformant than to offer maximum throughput?
The timeout is currently hardwired to 250ms, meaning that an ack might be up to 250ms delayed. Maybe this should be made a smaller value and maybe it should be a configurable setting.
I haven't found a nicer way to resolve this problem, if anyone has a better idea please let me know.
No test case included as this problem can only be seen when running on top of JBoss Messaging.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
