| Author |
Message
|
| mqsnbmp1 |
 Posted: Tue Mar 28, 2006 11:51 am Post subject: Message gets read before onMessage() exits |
 |
|
Apprentice
Joined: 18 Oct 2005
Posts: 25
|
I have a strange scenario when message gets read (curdepth is decremented) before JMS client exits the onMessage() call. It looks like message gets acknowledged while application is waiting on some other event in onMessage(). All receiver sessions are created with AUTO_ACKNOWLEDGE flag.
Here is the queue creation parameters:
DEFINE QLOCAL ( 'QueueName' ) +
REPLACE +
DESCR( 'Description' ) +
USAGE(NORMAL) +
DEFPSIST( YES ) +
PUT( ENABLED ) +
GET( ENABLED ) +
SHARE DEFSOPT( SHARED ) +
MAXDEPTH( 4000000 ) +
MAXMSGL(5000)
Any help would be appreciated. I'm using WMQ 6.0 JMS client against WMQ 5.3 or WMQ 6.0 server. |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Tue Mar 28, 2006 1:02 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Curdepth has very little to do with available messages.
When getting a message curdepth will drop by 1 but if you roll back it will go up by 1 again.
When putting a message curdepth will go up by 1 but until the commit is done the message (part of curdepth) will not be available to any MQ client process.
Enjoy...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mqsnbmp1 |
| Posted: Tue Mar 28, 2006 1:08 pm Post subject: |
|
|
Apprentice
Joined: 18 Oct 2005
Posts: 25
|
| OK, but I still lose the message if the program exits without returning from onMessage(). Maybe it is an extreme example, but lets say I read a message and wait on some external event to finish processing while still inside the onMessage() call. Then I kill the client program. When I restart it, shouldn't it read the same messages that wasn't acknowledged before the client was killed? I do not see this happening -- it reads the next message and the original one gets lost. -- Thanks. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Mar 28, 2006 1:15 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Is your session transacted ?
What is the transactional behavior of your MDB?
Who is managing the transaction ? (bean managed /vs container managed)...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mqsnbmp1 |
| Posted: Tue Mar 28, 2006 2:21 pm Post subject: |
|
|
Apprentice
Joined: 18 Oct 2005
Posts: 25
|
| This is not an MDB. This is a standalone JMS client, and session is not transacted. According to JMS specification, if asynchronous client hasn't successfully returned from onMessage() call, the message will not be acknowledged for sessions with AUTO_ACKNOWLEDGE option. This works well with other JMS providers (ActiveMQ, etc) but doesn't seem to work with Websphere MQ. Basically if onMessage() doesn't return, the message should remain on the queue. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Mar 28, 2006 8:52 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Usually I like my sessions to be explicitly transacted, or not transacted.
A not transacted with autoack session would remove the message at the start of the onMessage method. The act is done as soon as you get the message.
If you want a different behavior I would suggest you transact the session. And make sure your commits are explicit as well.
Enjoy
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Mar 28, 2006 11:02 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| mqsnbmp1 wrote: |
| Basically if onMessage() doesn't return, the message should remain on the queue. |
If you believe that the WMQ implementation of the JMS specification doesn't meet the JMS specification, then you should open a PMR to that effect.
But you should make sure you really understand what the specification says and means before you do so.
As fjb_saper says, the behavior you expect is that of a transacted session, not necessarily that of an auto-acknowledged session.
Also you need to really understand exactly how much you are giving up by trying to run J2EE code (JMS) outside a J2EE container.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| mvic |
| Posted: Wed Mar 29, 2006 12:02 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| fjb_saper wrote: |
| A not transacted with autoack session would remove the message at the start of the onMessage method. The act is done as soon as you get the message. |
Do you mean "would" or "should"?
May I ask which section of the JMS spec (and which version of the spec) you're referring to? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Mar 29, 2006 3:46 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| mvic wrote: |
| fjb_saper wrote: |
| A not transacted with autoack session would remove the message at the start of the onMessage method. The act is done as soon as you get the message. |
Do you mean "would" or "should"?
May I ask which section of the JMS spec (and which version of the spec) you're referring to? |
Sorry not looking at the spec but that would be my expected behavior.
As the session is autoack I would expect the message to be acknowledged as soon as I receive it. What I do with it is immaterial. If the session is not transacted that should mean that the "deed" is done as soon as I get the message.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mqsnbmp1 |
| Posted: Wed Mar 29, 2006 4:42 am Post subject: |
|
|
Apprentice
Joined: 18 Oct 2005
Posts: 25
|
Section 4.1.11:
AUTO_ACKNOWLEDGE - With this option, the session automatically
acknowledges a client’s receipt of a message when it has either successfully
returned from a call to receive or the MessageListener it has called to process
the message successfully returns. [returns is the key here]
Section 4.4.12:
When a client uses the AUTO_ACKNOWLEDGE mode, it is not in direct
control of message acknowledgment. Since such clients cannot know for
certain if a particular message has been acknowledged, they must be prepared
for redelivery of the last consumed message. This can be caused by the client
completing its work just prior to a failure that prevents the message
acknowledgment from occurring. Only a session’s last consumed message is
subject to this ambiguity. The JMSRedelivered message header field will be set
for a message redelivered under these circumstances. |
|
| Back to top |
|
|
| mvic |
| Posted: Wed Mar 29, 2006 4:57 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| As jeff said... If you believe that the WMQ implementation of the JMS specification doesn't meet the JMS specification, then you should open a PMR to that effect. |
|
| Back to top |
|
|
|
|
