Author |
Message
|
atheek |
Posted: Mon Nov 10, 2008 1:27 am Post subject: |
|
|
 Partisan
Joined: 01 Jun 2006 Posts: 327 Location: Sydney
|
What I meant by a pass through mdb is one which delivers the messages from its source (MQ) to a AQ without doing any validation or business logic. Within the onMessage() method just code to send message to the AQ. You may be able to do it out of the box with zero coding..check MQ/AQ messaging gateway |
|
Back to top |
|
 |
meetgaurav |
Posted: Mon Nov 10, 2008 4:51 am Post subject: |
|
|
Voyager
Joined: 08 Sep 2008 Posts: 94
|
Sorry Atheek,
My requirement is not that. Just picking a message from MQ and then business LOgic then Calling DB2. In case of DB2 exception, the XA will rollback the msg and its coming 5 times straight away..So nothing to send to AQ |
|
Back to top |
|
 |
meetgaurav |
Posted: Tue Nov 11, 2008 10:36 pm Post subject: |
|
|
Voyager
Joined: 08 Sep 2008 Posts: 94
|
HI atheek/ FJB,
1. Now i added JMSXDeliveryCount in my code and checking the count. But how to add the wait interval. Or I can put the message in the sleep mode.. Please advice ??
2. Any way the MDB will pick the same message for 5 times(Default Behaviour). This is a performance issue rite???..
3. OC4J not supports dequeue interval and dequeue retry count, I guess this is a bug in OC4J ?? |
|
Back to top |
|
 |
atheek |
Posted: Wed Nov 12, 2008 4:38 am Post subject: |
|
|
 Partisan
Joined: 01 Jun 2006 Posts: 327 Location: Sydney
|
meetgaurav wrote: |
1. Now i added JMSXDeliveryCount in my code and checking the count. But how to add the wait interval. Or I can put the message in the sleep mode.. Please advice ?? |
How about Thread.sleep()?
meetgaurav wrote: |
Any way the MDB will pick the same message for 5 times(Default Behaviour). This is a performance issue rite???.. |
I dont know how 5 became the default. It may be a default for OC4J. why do you think its a performance issue? Also what happens after message processing fails for 5th time?
meetgaurav wrote: |
OC4J not supports dequeue interval and dequeue retry count, I guess this is a bug in OC4J ?? |
OC4J should be supporting dequeue retry count. You observed its retrying for 5 times as per above.. right. Regarding dequeue interval , I think its because of the limitation of the jms provider (MQ) rather than OC4J. The base mQ product ( not the jms wrapper) is designed to deliver the message to an application as soon as an appln request for it and as such it doesn't support redelivery delay. This is as per my theory. Just wait here for other's viewpoints as well.. |
|
Back to top |
|
 |
meetgaurav |
Posted: Wed Nov 12, 2008 5:39 am Post subject: |
|
|
Voyager
Joined: 08 Sep 2008 Posts: 94
|
Atheek wrote:
Quote: |
I dont know how 5 became the default. It may be a default for OC4J. why do you think its a performance issue? Also what happens after message processing fails for 5th time?
|
OC4J default behaviour for all provider
dequeue retry interval =0
dequeu retry count = 5
Not able to overide this from OC4J side. But I overrided for AQ from Provider(AQ) side only. But for MQ there is no option. |
|
Back to top |
|
 |
meetgaurav |
Posted: Wed Nov 12, 2008 5:52 am Post subject: |
|
|
Voyager
Joined: 08 Sep 2008 Posts: 94
|
atheek wrote: |
How about Thread.sleep()?
|
Am going to use thread only. Just for confimation, that is there any other option for adding wait internal directly.
atheek wrote: |
I dont know how 5 became the default. It may be a default for OC4J. why do you think its a performance issue? Also what happens after message processing fails for 5th time?
|
After 5th time message will deleted from the Queue. I tested for (MQ, TIBCO and AQ)
atheek wrote: |
OC4J should be supporting dequeue retry count. You observed its retrying for 5 times as per above.. right. Regarding dequeue interval , I think its because of the limitation of the jms provider (MQ) rather than OC4J. The base mQ product ( not the jms wrapper) is designed to deliver the message to an application as soon as an appln request for it and as such it doesn't support redelivery delay. This is as per my theory. Just wait here for other's viewpoints as well..
|
am not sure. Please advice |
|
Back to top |
|
 |
fjb_saper |
Posted: Wed Nov 12, 2008 2:06 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20763 Location: LI,NY
|
meetgaurav wrote: |
Atheek wrote:
Quote: |
I dont know how 5 became the default. It may be a default for OC4J. why do you think its a performance issue? Also what happens after message processing fails for 5th time?
|
OC4J default behaviour for all provider
dequeue retry interval =0
dequeu retry count = 5
Not able to overide this from OC4J side. But I overrided for AQ from Provider(AQ) side only. But for MQ there is no option. |
How about setting a backout threshold on the queue?  _________________ MQ & Broker admin |
|
Back to top |
|
 |
meetgaurav |
Posted: Wed Nov 12, 2008 10:04 pm Post subject: |
|
|
Voyager
Joined: 08 Sep 2008 Posts: 94
|
Quote: |
How about setting a on the queue?
|
How to set backout threshold ??? could some one please advice..Am not an MQ expert |
|
Back to top |
|
 |
atheek |
Posted: Thu Nov 13, 2008 1:49 am Post subject: |
|
|
 Partisan
Joined: 01 Jun 2006 Posts: 327 Location: Sydney
|
The local MQ which your mdb polls has two attributes called BOTHRESH ( read BackOutThreshold) and BOQName( read BackOutQueueName) which can be configured to setup how many times a message has to be retried before moving it out from the original queue to the back out queue.
In non j2ee environment, an application which needs to use this feature can check the Backout count in the message it received with the BOTHRESH set on the queue and if it has exceeded it can put the message to the backout queue. The check and moving of messages needs to be done by the appln, where as the queue attributes are just used as a place wheer you can set a value for these: so that in future even if these change the appln need not have to change, you need to just change the attribute values at the queue.
Coming to j2ee, mdb's deployed in WAS moves the message to the BOQueue once BOTHRESHOLD has crossed with no extra involvement from the developer. Its not guaranteed with all app servers. May be you can give a shot and see if it does for your case. |
|
Back to top |
|
 |
meetgaurav |
Posted: Fri Nov 14, 2008 1:16 am Post subject: |
|
|
Voyager
Joined: 08 Sep 2008 Posts: 94
|
Thanks Atheek
Let me check and let you know |
|
Back to top |
|
 |
|