-
1. Re: question with rollback/redelivery semantics
timfox Apr 1, 2008 4:01 AM (in response to rlucente)If a consumer is closed (is that what you mean by "destroyed"?), before the session is acknowledged, then the messages won't be visible to any other session until the session commits/rolls back.
This is normal JMS operation.
Can you be more specific about
a) What you are doing
b) What you expect to observe
c) What you actually observe
Also please mention whether you are using MDBs. -
2. Re: question with rollback/redelivery semantics
rlucente Apr 1, 2008 9:27 AM (in response to rlucente)Ok, I'm using the Apache Muse product to build a WS-Notification 1.3 based message broker. JBoss Messaging is used as a message store to buffer messages between senders/receivers. Clients can publish and subscribe using the web services offered by Muse. When a message is published to the system, Muse determines the client endpoints that should receive the message. These messages are written to client specific JMS queues for eventual delivery. A separate thread pool has periodically scheduled client delivery tasks that, within a single transaction, read messages from a client-specific queue and then attempt to deliver a batch of messages to the client using the WS-Notify SOAP message. If the delivery fails (client unavailable) the transaction is rolled back. Use of the thread pool results in different threads attempting delivery to the remote endpoint, so I use a thread local variable to cache the session and a map of session to messageconsumer for each client delivery task. JMS is providing time-to-live, prioritization, and message persistence.
I modified the DefaultMaxDeliveryAttempts to -1 to prevent rollbacks from causing messages to be sent to the DLQ.
The rollback semantics are where questions arise. When I rollback, the messages appear to be marked for redelivery only by the messageconsumer that read them. The messages are not visible to other messageconsumers at that point.
I believe I attempted closing the consumers and then rolling back the session, but that seemed to destroy the messages instead of replacing them on the queue.
I hope this gives a more complete picture of what I'm attempting to do. -
3. Re: question with rollback/redelivery semantics
rlucente Apr 1, 2008 9:56 AM (in response to rlucente)I am not using MDBs.
Also, Ray Ploski, RedHat/JBoss, was at my company location back in September for a week to review the implementation and help with performance optimization. -
4. Re: question with rollback/redelivery semantics
timfox Apr 1, 2008 10:05 AM (in response to rlucente)If you have consumed messages via a message consumer and then roll back, the same session will receive the same stream of messages.
This behaviour is as specified in the JMS spec. (1.1, sectons 4.4.7 and 4.4.11)
If you have the same message consumer(s) open on that session, then it will receive the same messages.
BTW I would strongly recommend you upgrade to 1.4.0. A lot has changed since 1.2.0 :)
Hope that helps. -
5. Re: question with rollback/redelivery semantics
rlucente Apr 1, 2008 10:47 AM (in response to rlucente)I read the JMS spec but I didn't really see the description of a session/message affinity at rollback.
Regardless, sessions are not thread-safe so using a thread-pool is an issue because it requires I have multiple sessions, only one of which can see its recently rolled back messages.
We just received the support contract for JBoss EAP 4.3, so I'll be working with 1.4.0 over the coming weeks.
Thanks for the quick reply. -
6. Re: question with rollback/redelivery semantics
timfox Apr 1, 2008 11:01 AM (in response to rlucente)"rlucente" wrote:
I read the JMS spec but I didn't really see the description of a session/message affinity at rollback.
4.4.7:
"... If a transaction rollback is done, its produced messages
are destroyed and its consumed messages are automatically recovered. For more information on session recovery, see Section 4.4.11 �Message
Acknowledgment.�
And
4.4.11:
"A session’s recover method is used to stop a session and restart it with its first unacknowledged message. *** In effect, the session’s series of delivered messages is reset to the point after its last acknowledged message ***. ..."
Regardless, sessions are not thread-safe
True. If you do use a session between multiple threads all sorts of strange things might start to happen