Hi Nigel,
that's a huge progress, but still not perfect. :-(
First of all, I didn't set sendUndeliverableMsgsToDMQ to false since the
german description in the glassfish webinterface is misleading. After
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. ;-)
Then I restarted glassfish (queue still paused), no retries happening for my
faulty message, 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.
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? Could I work around it by using a standalone
JMS-consumer and stop using MDB or would I face the same issue?
Yours,
Patrick.
--
[Message sent by forum member 'pvdh']
View Post: http://forums.java.net/node/884067