| Author |
Message
|
| vickas |
 Posted: Tue Jan 30, 2018 11:18 pm Post subject: setting polling Interval on JMS Input Node when using Queue |
 |
|
Centurion
Joined: 18 Aug 2013
Posts: 126
|
hi experts ,
I want to know how does the JMS Input node recieves the messages ? How frequently does the flow with JMS input node polls for messages ? Do we have any option of modifying the below JMS connection parameters in IIB while the flow act as consumer ?
*connect_attempt_count
*connect_attempt_delay
*connect_attempt_timeout
*reconnect_attmept_count |
|
| Back to top |
|
 |
| zpat |
| Posted: Wed Jan 31, 2018 1:10 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Polling is generally a very bad idea. Properly written MQ applications will have an outstanding MQGET with WAIT on the queue.
This way there is no latency when messages arrive, and no polling overhead either.
With JMS the wait interval (which is only the max time) is set on the receive timeout parameter.
The connection values you mention, relate to the MQCONN to the QM, this should not be done more than once, and unless the connection breaks - will remain connected. This is therefore the reconnection interval and nothing to do with message polling.
On the assumption that IBM are one of the few vendors who know how to code MQ applications properly (as these message nodes are) one can assume that they are using receive with timeout.
Therefore polling is not a relevant concept.
However I would suggest using MQinput nodes to read MQ messages, there is no need to use JMSinput nodes. MQinput can handle all types of MQ message including those in JMS format.
If you want to manipulate/set/remove JMS headers, this can be done in ESQL or using the various header nodes provided.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| vickas |
| Posted: Wed Jan 31, 2018 11:46 pm Post subject: |
|
|
Centurion
Joined: 18 Aug 2013
Posts: 126
|
Hi Zpat ,
I do not want to add any polling interval on the JMS INput node (however we do not have that option on the node). All i want to know is ,
how to determine at what frequency the messages are being picked by the JMS Input Node ? curios to know if we can alter the connection /retry attempts somehow ? |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Feb 01, 2018 1:28 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
You have failed to grasp the basics of MQ. Please read up on the subject.
The connection interval is for lost connections. Normally the input node will keep the queue open all the time.
There is NO polling interval. Messages will be passed to the flow immediately they are available on the queue.
IBM being one of the few vendors who understand MQ will NOT be polling.
Polling for messages is a bad idea only considered by those who do not understand how MQ or JMS works. Or if you are happy with latency.
Try to think event driven - not timer driven.
Also - it's best to use the MQINPUT node to read MQ queues.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| vickas |
| Posted: Thu Feb 01, 2018 10:32 pm Post subject: |
|
|
Centurion
Joined: 18 Aug 2013
Posts: 126
|
Hi Zpat , Thanks for the Reply.
please help me to understand the below
| Quote: |
| The connection interval is for lost connections. Normally the input node will keep the queue open all the time. |
Here , I want to understand when and after how long will the JMS Input node will try to reconnect back to the JMS Provider when there is an outage from their side ?
When the JMS service provider isnt available to the flow , for how long and how many times does it try to connect back ?
Can we make the JMS Input Node sleep for every retry attempt made to connect to the JMS server ? |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Feb 01, 2018 11:24 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
I don't work for IBM.
However IBM are sensible enough to sleep for an interval before retrying. If you want to know what that is - open a PMR.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
|
|
