Bugs item #547831, was opened at 2002-04-23 23:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=547831&group_id=22866
Category: JBossMQ Group: v3.0 Rabbit Hole Status: Closed Resolution: Fixed Priority: 5 Submitted By: Randy Dey-Toth (rdeytoth) Assigned to: Adrian Brock (ejort) Summary: JMS Redelivery doesn't work Initial Comment: According to a posting in the forum, this is an "old bug", fixed in the 3.0 line. But it is not fixed. When using a durable persistent Topic, unacknowledged messages are only redelivered when the server is restarted. ---------------------------------------------------------------------- Comment By: Alexander Rabinowitz (raevsky) Date: 2002-12-18 16:07 Message: Logged In: YES user_id=671073 The quote you used "Subsequent subscriber objects with the same identity resume the subscription in the state it was left in by the prior subscriber." is used in the spec in the context of durable subscriptions, not queues. So, that does not look like the spec requires this behaviour. But nevertheless it makes the system unusable. Probably, because it is a problem with the soec itself. The spec cannot describe everything. ---------------------------------------------------------------------- Comment By: Alexander Rabinowitz (raevsky) Date: 2002-12-18 15:40 Message: Logged In: YES user_id=671073 Yes, I tried creating a new QueueConnection. That is how I saw the bug initially. The new QueueConnection works OK on JBoss 2.4.4. However, the first message is still lost, even when I use new QueueConnection. All the other messages are delivered OK through new QueueConnection. ---------------------------------------------------------------------- Comment By: Randy Dey-Toth (rdeytoth) Date: 2002-12-18 04:09 Message: Logged In: YES user_id=524545 raevsky: the spec can be found at <a href=http://java.sun.com/products/jms/docs.html>JMS 1.1 Spec </a> Did you try just creating a new QueueConnection, if you can't close the one you have? The spec says that, for durable subcribers, "Subsequent subscriber objects with the same identity resume the subscription in the state it was left in by the prior subscriber." If the last subscriber had one message sent to it but not acknowledged, this could be interpreted to mean the next subscriber with the same client id should immediately be delivered the sent but unacknowledged message, so that it may be in the same state. When the JBoss Server was restarted, this is how it behaved. The fix makes the behavior consistent. In any case, when the bug was posted, the session.recover() was not an option, it didn't work either. (see bug 526696 session.recover() doesn't work ). ---------------------------------------------------------------------- Comment By: Adrian Brock (ejort) Date: 2002-12-17 21:06 Message: Logged In: YES user_id=9459 Hi, The fixes you want are mainly in org.jboss.mq.server.BasicQueue org.jboss.mq.server.ClientConsumer there is also a fix for closing a non-transactional session with unacknowledged messages in org.jboss.mq.SpySession But if you look at org.jboss.mq.server for 3.0 and 2.4 you will see they are very different. http://cvs.sourceforge.net/cgi- bin/viewcvs.cgi/jboss/jbossmq/src/main/org/jboss/mq/server/? only_with_tag=Branch_2_4 http://cvs.sourceforge.net/cgi- bin/viewcvs.cgi/jboss/jbossmq/src/main/org/jboss/mq/server/? only_with_tag=Branch_3_0 The main server classes have changed and a message cache is introduced for scalability. The work I did was mainly fixing leaks in the message cache, dropped connections was just a small part of it. Rimmeraj is correct, the spec does not require this behaviour, but there is small comment in one of the javadocs that implies it. Regards, Adrian ---------------------------------------------------------------------- Comment By: Alexander Rabinowitz (raevsky) Date: 2002-12-17 20:33 Message: Logged In: YES user_id=671073 Actually, my problem is the following (JBoss 2.4.4): http://www.jboss.org/forums/thread.jsp?forum=48&thread=26224 Adrian (ejort) confirmed his fix should have fixed my problem. I just wanted to put the fix into JBoss 2.4.4 (which I am using) , and Adrian asked me to put the question into the bug description. He will hopefully tell us how to fix the bug in 2.4.4 ---------------------------------------------------------------------- Comment By: Alexander Rabinowitz (raevsky) Date: 2002-12-17 20:05 Message: Logged In: YES user_id=671073 Where can I look at that spec? What does it mean it is not supposed to? How can I recover the session if I cannot close the QueueConnection, because the network connection is lost on the client? ---------------------------------------------------------------------- Comment By: Dave Smith (rimmeraj) Date: 2002-12-17 19:11 Message: Logged In: YES user_id=486338 Read the spec. It is not supposed to . If you want the messages re-delivered then recover the session. ---------------------------------------------------------------------- Comment By: Alexander Rabinowitz (raevsky) Date: 2002-12-17 18:18 Message: Logged In: YES user_id=671073 Hi, Adrian: I'd like to install your change (that you put into JBoss 3.0.4) to Jboss 2.4.4 As I see into source code, you added two files - ExclusiveQueue.java and SelectorPersistentQueue.java Is that how the problem is fixed? Can you tell me what I need to do to put the changes to 2.4.4? Thanks very much ---------------------------------------------------------------------- Comment By: Adrian Brock (ejort) Date: 2002-10-25 10:25 Message: Logged In: YES user_id=9459 This is fixed for JBoss3.0.4, with tests included in the testsuite. The server nacks unacknowledged messages if the client drops the connection. The client nacks unacknowledged messages at session close. rdeytoth is correct, acknowledging any message acknowledges all previous messages delivered in the same session. Regards, Adrian ---------------------------------------------------------------------- Comment By: Randy Dey-Toth (rdeytoth) Date: 2002-05-10 18:46 Message: Logged In: YES user_id=524545 I'm not sure rimmeraj's test is valid. If you acknowledge any message in a session, it acknowledges all previous messages in the session as well, per the JMS specs. You need to kill the listener before acknowledging subsequent messages. ---------------------------------------------------------------------- Comment By: Dave Smith (rimmeraj) Date: 2002-05-10 17:40 Message: Logged In: YES user_id=486338 I am seeing the same thing. A simpler test is to have a listener that does not ackknowledge the first message and then acknowledge any other messages sent to it. You will see that the first unacknoledged message will never be resent but the rest will go through OK. ---------------------------------------------------------------------- Comment By: Randy Dey-Toth (rdeytoth) Date: 2002-05-06 18:40 Message: Logged In: YES user_id=524545 Any case where the JMS client exits before acknowledging receipt of a message from a Topic, and then starts up again without the server restarting, will demonstrate the failure of the server to redeliver unacknowledged messages without a restart. Attached is a Jar containing three files: JMSReceiver.java, JMSReceiver.properties, and HeartBeat.java. The last simply pumps 1000 messages into the topic, giving each a sequence number and setting a message property with the sequence number. The first fetches messages from the Topic, and prints their sequence numbers to the screen. Started with as TEST=true system property, it sleeps for a second between receiving the message and acknowledging it, making it easy to kill in between. The properties file is to configure the classes to talk to a certain Topic. To demonstrate the lack of redelivery without a restart, compile the two Java classes and do the following: 1. Set up a Topic in JBoss, and modify the JMSReceiver.properties file to point to that Topic. 2. run java aoe.jms.HeartBeat 0 This will pump 1000 test messages into the Topic. 3. run java -DTEST=true aoe.jms.JMSReceiver 4. Kill the JMSReceiver in between a receipt and an acknowledge. Note the sequence number of the message received but not acknowledged (this is the one that should be redelivered when the receiver starts up again). 5. Start the JMSReceiver again, as above. Note that the first message received is NOT the one that was acknowledge, but rather the following one. 6. Kill the JMSReceiver again. 7. Restart the JBoss server. 8. Start the JMSReceiver again. Notice that the unacknowledged messages not received before ARE now received. ---------------------------------------------------------------------- Comment By: Hiram Chirino (chirino) Date: 2002-05-03 00:44 Message: Logged In: YES user_id=175851 I've never seen this happen. Do you have test case that can reproduce this??? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=547831&group_id=22866 ------------------------------------------------------- This SF.NET email is sponsored by: Order your Holiday Geek Presents Now! Green Lasers, Hip Geek T-Shirts, Remote Control Tanks, Caffeinated Soap, MP3 Players, XBox Games, Flying Saucers, WebCams, Smart Putty. T H I N K G E E K . C O M http://www.thinkgeek.com/sf/ _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
