| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Any way to make a listener port more robust? |
« View previous topic :: View next topic » |
| Author |
Message
|
| matoh |
 Posted: Thu Oct 26, 2006 6:09 am Post subject: Any way to make a listener port more robust? |
 |
|
Apprentice
Joined: 04 Mar 2005
Posts: 26
|
I've got a small web application running in Websphere Application Server 5.0.2.7. It's supposed to track exceptions raised in various message flows, so the error-handling code in those flows sends a copy all errors to the in-queue of that application.
The application gets the messages from that queue through a Message Listener Service Listner Port, (i.e. via JMS) and a Message-Driven Bean.
The problem is that as some of those messages are errors so bad that the headers are malformed. This causes the Listener Port to shut down:
| Code: |
[10/26/06 13:37:03:453 GMT+01:00] 144b5525 JMSExceptionL EWMSG0018E: Error on JMSConnection for MDB MessageRecipient , JMSDestination jms/DestMessageRepositoryIncoming : javax.jms.MessageFormatException: MQJMS1050: The MQRFH2 header has an incorrect format
at com.ibm.jms.JMSMessage.newMessageFormatException(JMSMessage.java(Inlined Compiled Code))
at com.ibm.jms.JMSMessage._parseMcdFolder(JMSMessage.java(Compiled Code))
at com.ibm.jms.JMSMessage._parseMcdFolderUtf8(JMSMessage.java(Compiled Code))
at com.ibm.mq.jms.MQJMSMessage.createJMSMessage(MQJMSMessage.java(Compiled Code))
at com.ibm.mq.jms.MQSession.consume(MQSession.java(Compiled Code))
at com.ibm.mq.jms.MQSession.run(MQSession.java(Compiled Code))
at com.ibm.ejs.jms.JMSSessionHandle.run(JMSSessionHandle.java(Compiled Code))
at com.ibm.ejs.jms.listener.ServerSession.connectionConsumerOnMessage(ServerSession.java(Compiled Code))
at com.ibm.ejs.jms.listener.ServerSession.onMessage(ServerSession.java(Compiled Code))
at com.ibm.ejs.jms.listener.ServerSession.dispatch(ServerSession.java(Compiled Code))
at java.lang.reflect.Method.invoke(Native Method)
at com.ibm.ejs.jms.listener.ServerSessionDispatcher.dispatch(ServerSessionDispatcher.java(Compiled Code))
at com.ibm.ejs.container.MDBWrapper.onMessage(MDBWrapper.java(Compiled Code))
at com.ibm.ejs.container.MDBWrapper.onMessage(MDBWrapper.java(Compiled Code))
at com.ibm.ejs.jms.listener.ServerSession.run(ServerSession.java(Compiled Code))
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:672)
[10/26/06 13:37:03:464 GMT+01:00] 144b5525 MDBListenerIm I WMSG0043I: MDB Listener MessageRepositoryListenerPort stopped for JMSDestination jms/DestMessageRepositoryIncoming
|
I'd much prefer if such malformed messages are simply rejected, ending up in some kind of backout queue, rather than shut down the service entirely.
So, is there any kind of setting anywhere, that will make JMS not shut down the Listener Port upon an exception? Or is there any way of coding around this? |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Thu Oct 26, 2006 6:12 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
You can configure the MDB to perform backout processing, yes.
There are two parameters that have to be set, and one has to be set lower than the other.
Maybe search the Java/JMS forum for "poison message". Or wait for FJ to remind me of what I've forgotten .. 
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| matoh |
| Posted: Thu Oct 26, 2006 6:46 am Post subject: |
|
|
Apprentice
Joined: 04 Mar 2005
Posts: 26
|
It's the max backout count on the queue and the max backout count on the listener port.
When I checked, they were set to the same value, not a lesser value on the queue, which would be the correct setting.
So, an incorrect setting made me think the JMS implementation was less robust than it really was.  Sorry about that. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Oct 26, 2006 7:03 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| jefflowrey wrote: |
You can configure the MDB to perform backout processing, yes.
There are two parameters that have to be set, and one has to be set lower than the other.
Maybe search the Java/JMS forum for "poison message". Or wait for FJ to remind me of what I've forgotten .. |
Right on the money there Jeff.
The queue's backout threshold has to be lower than the reprocess value on the MDB. Otherwise the MDB will shutdown on a poison message (as designed).
As well if there is no backout queue specified the messages go to the DLQ (WAS don't know about Weblogic).
Wouldn't know what happens if there is no DLQ defined either...
_________________
MQ & Broker admin |
|
| 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
|
|
|
|
