| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Connection problems |
« View previous topic :: View next topic » |
| Author |
Message
|
| ptolomeoo |
 Posted: Fri Mar 31, 2017 2:04 am Post subject: |
 |
|
Newbie
Joined: 31 Mar 2017
Posts: 3
|
Hello, I'm seeking help on this issue.
I have a consumer (based on listener) that eventually stops receiving events from the MQSeries queue.
The consumer keeps working (traces show it's alive) and the queue keeps receiving messages but the consumer is like a zombie, and doesn't consume any message.
When doing tests, we had no problems detecting disconnections or the queue being shut down, and it keeps trying to reconnect until the queue is up again.
Because of this problem, we wanted to try a different and more robust approach:
- Polling continuously for messages, and disconnecting and reconnecting if we end the timeout without receiving any message.
- Keeping the listener approach doing a ping to the queue every 'x' minutes. This would guarantee that the queue is up, but wouldn't guarantee that we keep receiving the events.
What are your expert recommendations to solve this polling problem? I don't trust the event listener and want a secondary, backup to test if my connection is OK. |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Fri Mar 31, 2017 2:32 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| ptolomeoo wrote: |
Hello, I'm seeking help on this issue.
I have a consumer (based on listener) that eventually stops receiving events from the MQSeries queue.
The consumer keeps working (traces show it's alive) and the queue keeps receiving messages but the consumer is like a zombie, and doesn't consume any message.
When doing tests, we had no problems detecting disconnections or the queue being shut down, and it keeps trying to reconnect until the queue is up again.
Because of this problem, we wanted to try a different and more robust approach:
- Polling continuously for messages, and disconnecting and reconnecting if we end the timeout without receiving any message.
- Keeping the listener approach doing a ping to the queue every 'x' minutes. This would guarantee that the queue is up, but wouldn't guarantee that we keep receiving the events.
What are your expert recommendations to solve this polling problem? I don't trust the event listener and want a secondary, backup to test if my connection is OK. |
That's what the exception listener is for. You open a queue and set a message listener on it. Set at the same time an exception listener on the connection. The exception listener should fire in the event of a disconnection... You may have to reduce your TCP/IP timeout from the default 2 hours to something like 5 mins though to detect problems faster...
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| ptolomeoo |
| Posted: Fri Mar 31, 2017 2:45 am Post subject: |
|
|
Newbie
Joined: 31 Mar 2017
Posts: 3
|
| fjb_saper wrote: |
| ptolomeoo wrote: |
Hello, I'm seeking help on this issue.
I have a consumer (based on listener) that eventually stops receiving events from the MQSeries queue.
The consumer keeps working (traces show it's alive) and the queue keeps receiving messages but the consumer is like a zombie, and doesn't consume any message.
When doing tests, we had no problems detecting disconnections or the queue being shut down, and it keeps trying to reconnect until the queue is up again.
Because of this problem, we wanted to try a different and more robust approach:
- Polling continuously for messages, and disconnecting and reconnecting if we end the timeout without receiving any message.
- Keeping the listener approach doing a ping to the queue every 'x' minutes. This would guarantee that the queue is up, but wouldn't guarantee that we keep receiving the events.
What are your expert recommendations to solve this polling problem? I don't trust the event listener and want a secondary, backup to test if my connection is OK. |
That's what the exception listener is for. You open a queue and set a message listener on it. Set at the same time an exception listener on the connection. The exception listener should fire in the event of a disconnection... You may have to reduce your TCP/IP timeout from the default 2 hours to something like 5 mins though to detect problems faster...
Have fun |
Thank you very much Sir, for the fast and accurate response.
Actually it makes sense that the timeout problem would arise after 2 hours but as we detect the problem earlier (if the number of messages in the queue only increases, it triggers an alarm), we thought we were not receiving the Exception events properly.
I will do some testing trying to reduce the default TCP/IP timeout to 5 minutes to see if this solves our problems. |
|
| Back to top |
|
|
| ptolomeoo |
| Posted: Sun Apr 02, 2017 10:05 pm Post subject: How to properly reduce the TCP timeout in a MQ Connection? |
|
|
Newbie
Joined: 31 Mar 2017
Posts: 3
|
Setting MQQueueConnectionFactory methods:
setClientReconnectTimeout(seconds)
and
setStatusRefreshInterval(milliseconds)
would be enough to reduce the TCP timeout?
Is there any other recommended way to do it?
TIA. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Apr 03, 2017 4:20 am Post subject: Re: How to properly reduce the TCP timeout in a MQ Connectio |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| ptolomeoo wrote: |
Setting MQQueueConnectionFactory methods:
setClientReconnectTimeout(seconds)
and
setStatusRefreshInterval(milliseconds)
would be enough to reduce the TCP timeout?
Is there any other recommended way to do it?
TIA. |
The TCP/IP timeout is set at the OS level in the TCP/IP stack. The default usually is around 2 hours...
_________________
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
|
|
|
|
