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

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.

[Tim Anderson]

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]

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]

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]

Logged In: YES
user_id=954675

I guess you are right.