Expected NULL is not reurned on a recieve() call

[arinban]

As per JMS Spec, "A blocked message consumer receive call returns null when this session is closed (i.e on calling Session.close() a blocked message consumer receive call should return Null)

For more info regarding this assertion see the following API doc [http://java.sun.com/j2ee/1.4/docs/api/javax/jms/Session.html#close(](http://java.sun.com/j2ee/1.4/docs/api/javax/jms/Session.html#close())

This behaviour is not observed when running the following CTS compatibility test with Appserver 8.2 PE using genericjmsra 1.0 and IBM MQ 6.0

TS_HOME/src/com/sun/ts/tests/jms/ee/appclient/queuetests/QueueTests#receiveNullClosedSessionQueueTest

Note: See following URL regarding how to get CTS compatibility tests https://genericjmsra.dev.java.net/issues/show_bug.cgi?id=19

Environment

Operating System: All Platform: Sun

Affected Versions

[1.0]

[arinban]

Original Issue:https://github.com/javaee/glassfish-genericjmsra/issues/20 Raised By:@glassfishrobot Created at:Fri Mar 31 09:18:56 IST 2006 Assigned To:@glassfishrobot

[arinban]

@glassfishrobot Commented on Fri Mar 31 09:18:56 IST 2006 Reported by raja_perumal

[arinban]

@glassfishrobot Commented on Mon Apr 03 14:49:19 IST 2006 binod said: Assigning to Ramesh

[arinban]

@glassfishrobot Commented on Tue Jun 06 08:48:15 IST 2006 rampsarathy said: The problem can be reproduced by having a simple app client look up a jms resource and a queue admin object. A consumer is created on a separate thread which blocks on receive. Send one message throught the producer, wait for a second and then close the session.

The behavior is different for the above scenario for the 2 implementations given below

1. The JMS resource is a connector resource ( uses the generic RA) and the Queue is an administered object. 2. The jms resources are configured in a File system object store and are looked up from the client code ( means they are not connector resources).

For 1.

The session.close call would call a close on the session adapter proxy of the generic RA, here the RA closes all the active consumers, producers and queue browsers and then returns the session back to the pool ( POINT TO NOTE: It does not close the physical session). The session pooling will lose its meaning if the session is closed.

According to JMS Spec "Closes the message consumer.

Since a provider may allocate some resources on behalf of a MessageConsumer outside the Java virtual machine, clients should close them when they are not needed. Relying on garbage collection to eventually reclaim these resources may not be timely enough.

This call blocks until a receive or message listener in progress has completed. A blocked message consumer receive call returns null when this message consumer is closed. "

the close call of a consumer should return a "null" on the receive call that is blocked, ( or the message if there is one). But Websphere MQ behavior is not according to the above explanation. A close on the consumer does not return a null.

And since this does not happen , the session close from the application does not yield in a null on receive.

For 2.

The session.close would return a null on a blocked receive, and so would work from a client app.

Whatever is mentioned in (behavior 1) can be verified by calling consumer.close() instead of session.close() and the same behavior ( as that of going through RA) can be reproduced.

So, this Issue is because of a specification incompatibility in the Web sphere MQ.

[arinban]

@glassfishrobot Commented on Fri Mar 31 09:18:56 IST 2006 Was assigned to rampsarathy

[arinban]

@glassfishrobot Commented on Mon Apr 24 13:02:02 IST 2017 This issue was imported from java.net JIRA GENERICJMSRA-20

[arinban]

@glassfishrobot Commented on Mon Sep 06 08:51:08 IST 2010 Marked as won't fix on Sunday, September 5th 2010, 8:21:08 pm

[arinban]

@glassfishrobot Closed the issue on Mon Sep 06 08:51:08 IST 2010