7 Replies Latest reply on Sep 15, 2005 3:35 PM by Tim Fox

    A couple of questions on expected JMS behaviour / edge cases

    Tim Fox Master

      I have a couple of JMS use cases where I'd like to check with any JMS gurus out there what the expected behaviour should be:

      1)
      Acknowledgment after consumer is closed:

      Connection conn = cf.createConnection();
      Session sess = conn.createSession(true, Session.TRANSACTED);
      MessageConsumer consumer = sess.createConsumer(queue);
      Message m = consumer.receive();
      consumer.close();
      sess.commit();
      conn.close();

      I believe the above is legal, can anyone confirm?

      The ack should be sent when the session commits, by when the consumer is closed.

      Currently this fails in JBoss Messaging since we rightly or wrongly handle acks in the consumer.

      However it passes the TCK since there doesn't seem to be any TCK test that traps this.

      I have added a test for this anyway in our test suite.


      2) Redelivery of messages to non durable topic subscribers.

      Consider the following:

      Create 2 non durable subscribers on a topic using different sessions, each session is CLIENT_ACKNOWLEDGE:

      Session sess1 = conn1.createSession(false, Session.CLIENT_ACKNOWLEDGE);
      Session sess2 = conn1.createSession(false, Session.CLIENT_ACKNOWLEDGE);

      MessageConsumer cons1 = sess1.createConsumer(topic);
      MessageConsumer cons2 = sess2.createConsumer(topic);

      then send a message to the topic:

      producer.send(m);

      now receive the message on both consumers:

      Message m1 = (TextMessage)cons1.receive();
      Message m2 = (TextMessage)cons2.receive();

      but only ack it at *one* of the consumer sessions.

      m1.acknowledge();

      then call recover() on the *other* consumer session:

      sess2.recover();

      My understanding is that the message should not be received again at cons1, but only received again at cons2, which corresponds to sess2 which hadn't acked it.

      Is this correct?

      Again this is not what happens in the current code, but, also again, there's no TCK test to trap this.