| Author |
Message
|
| muhilan |
 Posted: Mon Sep 01, 2008 3:07 pm Post subject: "Using Java Manual" |
 |
|
Novice
Joined: 29 Aug 2008
Posts: 11
|
Hi
Many thanks for the direction. I was wondering what the "Using Java Manual" is. Should I just run a google search?
thanks |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Mon Sep 01, 2008 3:14 pm Post subject: Re: "Using Java Manual" |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| muhilan wrote: |
Hi
Many thanks for the direction. I was wondering what the "Using Java Manual" is. Should I just run a google search?
thanks |
It's in the infocenter see link at top of page. 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| muhilan |
| Posted: Tue Sep 02, 2008 1:56 pm Post subject: JMS sample app that shows JMS syncpointing of messages |
|
|
Novice
Joined: 29 Aug 2008
Posts: 11
|
| zpat wrote: |
You want a simple fan out app.
Unless you really need the flexibility of pub sub then just code a little app to GET messages from one queue and PUT them to more than one queue (either repeat the PUT or use a Distribution List).
No need to over-complicate things! |
In regards to the simple fan out application that you mentioned last week, I went searching on this site and came up with a piece of sample code that said "
Shows JMS syncpointing of messages during put requests"
Is this something relevant for now? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Sep 02, 2008 3:49 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
If you don't want to start with pub/sub you can look at doing a receive and multiple sends in the same transaction. So yes it would be relevant.
I would advise you to create an anonymous sender (session.createSender(null) ) and pass the destination at send time.
Enjoy
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Sep 02, 2008 11:39 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
I would code it without syncpoints to get it working.
After than it might be a good idea to enclose the MQGET and MQPUTs into a unit of work to ensure consistency.
What's required is to add MQGMO_SYNCPOINT to the MQGET, MQPMO_SYNCPOINT to the MQPUTs and then MQCMIT after the MQPUTs.
However when using MQGET with SYNCPOINT there is a risk of processing backed out messages in a loop, so you then have to deal with poisoned messages etc by inspecting the Backout Count etc. |
|
| Back to top |
|
|
| muhilan |
| Posted: Wed Sep 03, 2008 5:59 am Post subject: thanks again |
|
|
Novice
Joined: 29 Aug 2008
Posts: 11
|
| zpat wrote: |
I would code it without syncpoints to get it working.
After than it might be a good idea to enclose the MQGET and MQPUTs into a unit of work to ensure consistency.
What's required is to add MQGMO_SYNCPOINT to the MQGET, MQPMO_SYNCPOINT to the MQPUTs and then MQCMIT after the MQPUTs.
However when using MQGET with SYNCPOINT there is a risk of processing backed out messages in a loop, so you then have to deal with poisoned messages etc by inspecting the Backout Count etc. |
thanks very much. I will code this and let you know how it goes. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Sep 04, 2008 4:04 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| zpat wrote: |
I would code it without syncpoints to get it working.
After than it might be a good idea to enclose the MQGET and MQPUTs into a unit of work to ensure consistency.
What's required is to add MQGMO_SYNCPOINT to the MQGET, MQPMO_SYNCPOINT to the MQPUTs and then MQCMIT after the MQPUTs.
However when using MQGET with SYNCPOINT there is a risk of processing backed out messages in a loop, so you then have to deal with poisoned messages etc by inspecting the Backout Count etc. |
As he is coding in JMS there is no SYNCPOINTING. You talk about a TRANSACTED SESSION.
I was trying to steer him clear of the base concepts as he is new in Java JMS and new to MQ. Get him first on solid JMS ground before adding base to the mix....
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| muhilan |
| Posted: Sat Sep 06, 2008 12:47 pm Post subject: ideas for Retry application |
|
|
Novice
Joined: 29 Aug 2008
Posts: 11
|
Hi
I am supposed to design a module that is supposed to do the following:
This modle will have a Retry feature which enables submitting a request many times (this request emanates from what is known as a document requesting application and our module will send this request along to what is known as the Document Generator Application.) In the case that this request fails for some reason (it cannot get processed by the Document generation application) this module has to have a Retry sub-module/capability that will enable it to resubmit the same request many times.
And the first time a request is submitted to the Doc generation application, the message retry count is set to 0.If the document generation app fails to process this request message it sends to request message to an error queue.Looking at the error code and the retry count, the retry sub-module will determine if the request needs to be resubmitted. The retry count is incremented and the message is submitted again after a configurable wait period.
Instead of sending the message to an error queue, an alternate scenario would be to have an oracle database store it.
What would be a simple way to approach this problem and implement it?
Any ideas are greatly appreciated. Thanks in advance |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Sep 06, 2008 7:16 pm Post subject: Re: ideas for Retry application |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| muhilan wrote: |
Hi
I am supposed to design a module that is supposed to do the following:
This modle will have a Retry feature which enables submitting a request many times (this request emanates from what is known as a document requesting application and our module will send this request along to what is known as the Document Generator Application.) In the case that this request fails for some reason (it cannot get processed by the Document generation application) this module has to have a Retry sub-module/capability that will enable it to resubmit the same request many times.
And the first time a request is submitted to the Doc generation application, the message retry count is set to 0.If the document generation app fails to process this request message it sends to request message to an error queue.Looking at the error code and the retry count, the retry sub-module will determine if the request needs to be resubmitted. The retry count is incremented and the message is submitted again after a configurable wait period.
Instead of sending the message to an error queue, an alternate scenario would be to have an oracle database store it.
What would be a simple way to approach this problem and implement it?
Any ideas are greatly appreciated. Thanks in advance |
Look into backout threshold and backout queue and how this is handled in JMS...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
