#4 org.exolab.jmscts.test.connection.ListenerTest

v0.5-b1
closed-invalid
nobody
None
5
2004-01-22
2004-01-21
No

There's a race condition in method

private void runTest(TestContext context, boolean
stop,
int count) throws Exception

of class org.exolab.jmscts.test.connection.ListenerTest.

original code:

// send a message and start the connection
MessagingHelper.send(context, request, 1);
connection.start();

should read:

// send a message and start the connection
connection.start();
MessagingHelper.send(context, request, 1);

Otherwise there's a good chance that the listener hangs
forever in listener.waitForReceipt();. This happens in
pub/sub
systems when the message has already been delivered before
connection.start is called.

Discussion

  • Tim Anderson

    Tim Anderson - 2004-01-21

    Logged In: YES
    user_id=557161

    Don't think this is valid.
    If the connection is stopped, no MessageListener should
    receive any messages. From section "4.3.3 - Connection
    Setup" of the spec:
    "A JMS client typically creates a Connection, one or more
    Sessions, and a number of MessageProducers and
    MessageConsumers. When a Connection is created, it is
    in stopped mode. That means that no messages are being
    delivered to it.
    It is typical to leave the Connection in stopped mode until
    setup is complete. At that point the Connections start()
    method is called and messages begin arriving at the
    Connections consumers. This setup convention minimizes any
    client confusion that may result from asynchronous message
    delivery while the client is still in the process of setting itself
    up."

     
  • Anonymous - 2004-01-21

    Logged In: YES
    user_id=954675

    The sequence in the original code is:
    1.) setup listener 2.) send message 3.) start connection.
    It's possible that the following happens in a pub/sub system:
    1.) listener is correctly set up, but not started; i.e. no
    subscription for the
    topic exists.
    2.) The message is sent to the pub/sub system and delivered
    to all
    subscribed consumers. As there are none, the message is dropped.
    3.) The connection is started. As the message sent in step 2
    already
    left the system, no message will be delivered and the
    message listener
    waits at infinitum.

    I think the order should be:
    1.) set up listeners 2.) start connection 3.) send message.
    This order is conforming to the suggested procedure of
    section 4.3.3
    as the setup is done before the connection is started.

     
  • Tim Anderson

    Tim Anderson - 2004-01-21

    Logged In: YES
    user_id=557161

    That sounds like an incorrect provider implementation to me.
    Creation of a consumer is registration for subscription,
    irrespective of whether the connection is started or not.
    Subsequently stopping the connection does not deregister
    existing consumers (see section 4.3.4 Pausing Delivery of
    Incoming Messages)

     
  • Anonymous - 2004-01-21

    Logged In: YES
    user_id=954675

    I guess you are right.

     
  • Tim Anderson

    Tim Anderson - 2004-01-22
    • status: open --> closed-invalid
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks