| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Websphere-jms-stateless session bean:message acknowledgement |
« View previous topic :: View next topic » |
| Author |
Message
|
| errorken |
 Posted: Fri Nov 25, 2005 9:39 am Post subject: Websphere-jms-stateless session bean:message acknowledgement |
 |
|
Newbie
Joined: 23 Nov 2005
Posts: 8
|
I'm developing using WSAD and using the internal test server with the internal JMS (which is very much like MQ).
When I create a ordinary java client (out container) that accessess this queue directly I can read messages and manually choose to acknowledge them or not (using CLIENT_ACK). So, when I read a message and I do not acknowledge it remains on the queue.
Now, when I put this code inside a stateless session ejb, I'm NOT able to do this. Regardless of my settings my messages seem always to be auto-acknowledged (and my setting is still CLIENT_ACK).
So I put a message on the queue, invoke my SSB which reads the message from the queue. The SSB ends normally without acknowledging the message. Next, I re-invoke the SSB, but no more messages are found on the queue. Which should not happen since I did not acknowledge it..
When the SSB throws a runtime exception, the message remains on the queue. So that seems to be the only trick to let it keep messages on the queue.
I allready tried every possible combination by playing with the tx attributes of the ssb (container/bean CMT, and then the tx attributes of the bean itselves: not supported etc) but nothing works. Messages are ALWAYS auto acknowledged, unless a runtime exception is thrown.
For me this is a problem. The SSB reads messages in a loop untill no more messages are available. So if I would have 10 messages, and message 9 gives problems, I can throw a runtime exception, but this means that the other 9 messages will be re-deliverd also, which it not good. I need to be able to acknowledge messages individually.
Also, I tried to do a message.acknowledge (just for testing) and then I get this exceptgion : avax.jms.IllegalStateException: MQJMS1057: Message has no session associated with it
Its all very strange...
Thanks. |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Fri Nov 25, 2005 9:56 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Acknowledgement is not the same as commitment.
You don't ever want to leave messages on the queue if they have been successfully processed. To ensure this, commit the transaction that was invoked when you got them.
Then you can commit each of the first 8 messages and throw a runtime exception when you hit the 9th, which is bad. And only the 9th will get redelivered.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| errorken |
| Posted: Fri Nov 25, 2005 10:19 am Post subject: |
|
|
Newbie
Joined: 23 Nov 2005
Posts: 8
|
ok, I tried what you suggested.
I put 10 messages on the queue. Next I created a transacted session with the ack value set to -1. For the first 5 message I receive I do a commit() . For the sixth message I throw a runtime. After that only 5 messages remain on the queue, so it works. He commited the 5 which are processed ok and the other 5 remain on the queue.
however, this scenario limits my acknowledgement to an entire session. From the moment one bad message is encoutered, I must throw a runtime, which means my SSB stops processing. Its not because message 6 is bad that message 7 is bad also.
Basicly the thing I want is to say is that message 1-5 are OK and should be removed from the queue, message 6 is NOK and should be redelivered, message 7 -10 are OK |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Nov 25, 2005 5:58 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
You cannot keep redelivering a bad message.
You need to setup a backout queue.
Set the redelivery option on the MDB to 4
Set the with backout threshold to 3
And make sure you do read up on patterns with MDB
Enjoy  |
|
| Back to top |
|
|
| errorken |
| Posted: Sat Nov 26, 2005 1:31 am Post subject: |
|
|
Newbie
Joined: 23 Nov 2005
Posts: 8
|
Well, if you read my post you would notice that I'm NOT working with an MDB here. I'm using a SSB (stateless session bean).
Regardless of the scenario I'm building, I was wondering why the message.acknowledgement is not working in my SSB (I get the 'no session associated' error) and why it completely ignores my acknowledge mode. It seems that my messages are always acknowledged unless I throw a runtime exception, regardless of the transaction mode and the acknowledge mode.
The thing is that when I do this with a standalone java client directly accessing the queues, I do not have these problems. When I set the acknowledge mode to client, the messages are being redelivered unless I do an actual acknowledge on them (which does not even work inside the container).
I do not understand why this behaviour in a java client dfferent then in the container ?
Also, I explicitly set the bean to BMT and I do not start a tx. So when I create a non transacted JMS session, it should be the same as with an ordinary standalone java client....but its not.
--------------
Now, as for the scenario I'm trying to create:
| Code: |
[client]--->-----[JMS]---->---[websphere: MDB]----<>----[Database]
________________| |
| |
[DLQ]----<---[websphere: SSB]-----<>--------
|
|
[batch]---------->-----------[File]
|
1.A client sends a message to a JMS queue. This message is a kind of log message which must be persisted. It does not really matter when, but it should get persisted no matter what.
2.On websphere a listener is configured to listen on the the queue. It will pass received messages to the MDB. Next, the MDB tries to store these message in the database.
2'. When the message could not be persisted within 5 times by the MDB (eg. db is down) then the messages are automatically put on the DLQ and they are discarded (no redelivery).
3. Every night at 12:00 a batch java application starts and connects to an SSB on the websphere. This SSB will read the DLQ and try to persist the message once again. When this fails, the message should not be acknowledged and stay on the DLQ (the db could be down again, for example). However, if the message is redelivered 5 times and can still not be persisted it is acknowledged and sent to the batch program which will store it in a file. This file must then be manually imported in the database. However, its probably rare that the database is down 2 times a day, so the messages will either get persisted or they are causing a problem with the db, in which case the problem must be manually investigated.
This scenario may seem weird: for example, the MDB could prevent a message from ending up on the DLQ and it could store the message in a file when it is reaching the max redelivery count. The fact is that we have 5 jms servers (5 websphere servers which each have an embedded JMS) on 5 different locations. So these file would always be manually be merged and copied. Using the batch system we have 1 server that connects to the 5 JMS servers and gathers the messages (that could not be persisted) in one file.
---------------------------
What I originally wanted was that the SSB would iterate over all the messages and only acknowledges the messages that it could persist.
So if I have messages 1 to 10 , I would get them of the queue and keep track of which message is persisted. I would then acknowledge each message seperately. If message 5 and 6 could not be persisted, they would remain on the DLQ untill the next batch run (next day at 12:00) .
Now, I figured out another solution by playing with the commit() and rollback() on a transacted session. I read the messages from a queue in a loop. After each message is persisted I do a comit(). When a message is unable to persist I do a rollback(). This message keeps comming over and over again untill it gets persisted or it has been redelivered 5 times. In that case I do a commit() and I sent the message back to the batch program after execution. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
