On 15/03/2012 13:28, forums_at_java.net wrote:
> First of all, I didn't set sendUndeliverableMsgsToDMQ to false since the
> german description in the glassfish webinterface is misleading. After
Please log an incorrect translation as a bug in
http://java.net/jira/browse/GLASSFISH
> following your advice endpointExceptionRedeliveryInterval works fine
> and endpointExceptionRedeliveryAttempts seems to honored as well (though I
> didn't wait for 1000 retries yet. ;-)
>
> However, I have this issue: I dump 20 messages in the queue, one of them
> faulty and throwning exceptions. I fix the issue in my bean, stop the queue
> to deploy my fixed solution. First problem: the retries contiue, ignoring the
> queue-state "paused". That's surprising. ;-)
Pausing a queue stops new messages being sent from the broker. It doesn't stop messages being redelivered by the
resource adapter. But that doesn't mean you're wrong to be surprised (or that the behaviour is correct).
> Then I restarted glassfish (queue still paused), no retries happening for my
> faulty message,
Restarting GlassFish will cause the resource adapter to forget that it has a message to redeliver. This means that the
messages will be redelivered by the broker. Since the queue is paused it isn't being redelivered yet.
> so I could now deply the new MDB. Then I added 20 new
> messages to the queue and resumed queue processing. But now the 20 new
> messages were processed first, then processing of the old messages resumed.
Hmm. It appears that the broker isn't redelivering the messages immediately following the resume. We think this may be
related to a bug
http://java.net/jira/browse/MQ-120 in which pausing the queue didn't prevent you sending messages to
the queue with a direct mode (embedded) connection. That may be allowing them to "jump the queue".
Can you try running your broker in LOCAL (separate process) mode and repeating this scenario? This would help us confirm
the cause.
> That's not what I expected and could cause troulbe for my setup. Further
> testing showed that adding to a queue which retries on a faulty message is no
> principal problem and ordering is fine, as long as I do not pause the queue,
> restart the server, add messages and only later resume the queue. By doing so
> I can reproduce the issue. I'm running Glassfish 3.1.1 on my development
> environment and didn't try to reproduce the issue with more recent versions
> yet.
>
> Is this intended behaviour?
Unfortunately you seem to be hitting a bug, which may be related to the one above.
I think your very first issue (in your first post) is also a bug: when you rolled back the transaction the message
should have been redelivered before other messages. Please feel invited to log this as a bug.
> Could I work around it by using a standalone
> JMS-consumer and stop using MDB or would I face the same issue?
I don't know, but it's possible since you'll be using different client-side code. If you decide to try this, use MQ
4.5.2 (part of GlassFish 3.1.2) since there have been some changes in this area.
Nigel