ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum IndexGeneral IBM MQ SupportIBM MQ XMS.NET client reconnect timeout can't be changed

Post new topicReply to topic Goto page 1, 2  Next
IBM MQ XMS.NET client reconnect timeout can't be changed View previous topic :: View next topic
Author Message
dudetom
PostPosted: Fri Dec 28, 2018 5:20 am Post subject: IBM MQ XMS.NET client reconnect timeout can't be changed Reply with quote

Apprentice

Joined: 29 Sep 2017
Posts: 45

IBM MQ has an automatic client renonnect functionality, and it has a default timeout of 30 minutes. After 30 minutes it stops trying to reconnect (source - p35).

I want to change the timeout so it lasts a longer time retrying (for example 2 hours). I suppose I can use the property XMSC.WMQ_CLIENT_RECONNECT_TIMEOUT for this because it's available in the XMSC class.

I can simulate a connection failure by blocking the port 1414 where the client application makes connection to IBM MQ. And for testing purposes, I lower the timeout value to 5 minutes (instead of 30 minutes).

What I can see in the logging is that the client application receives XMSException with reason code 2544 (reconnecting) which says it tries to reconnect.

This occurs for 30 minutes, and after that, I get an XMSException with reason code 2009 (connection broken). And auto reconnect fails.

I can conclude that changing the timeout value has no effect... Am I configuring the reconnect timeout in a wrong way?

Below, there is a code snippet:

XMSFactoryFactory factory = XMSFactoryFactory.GetInstance(XMSC.CT_WMQ);
IConnectionFactory connectionFactory = factory.CreateConnectionFactory();
connectionFactory.SetStringProperty(XMSC.WMQ_HOST_NAME, "hostname");
connectionFactory.SetIntProperty(XMSC.WMQ_PORT, 1414);
connectionFactory.SetStringProperty(XMSC.WMQ_CHANNEL, "channel_name");
connectionFactory.SetIntProperty(XMSC.WMQ_CONNECTION_MODE, XMSC.WMQ_CM_CLIENT_UNMANAGED);
connectionFactory.SetStringProperty(XMSC.WMQ_QUEUE_MANAGER, "*");
connectionFactory.SetIntProperty(XMSC.WMQ_CLIENT_RECONNECT_OPTIONS, XMSC.WMQ_CLIENT_RECONNECT_Q_MGR);
connectionFactory.SetIntProperty(XMSC.WMQ_CLIENT_RECONNECT_TIMEOUT, 300); //300 seconds = 5 minutes

IConnection conn = cf.CreateConnection();
conn.Start();

IBM MQ Client version: 8.0.0.5

Also asked here: https://stackoverflow.com/questions/53959233/ibm-mq-xms-net-client-reconnect-timeout-cant-be-changed
Back to top
View user's profile Send private message
exerk
PostPosted: Fri Dec 28, 2018 8:50 am Post subject: Reply with quote

Jedi Council

Joined: 02 Nov 2006
Posts: 5980

To help me understand better:

1. Do you mean that the application attempts reconnection and fails, then waits 5 minutes, attempts reconnection again, and so on, until 30 minutes has elapsed; that is, 6 attempts are made and then no further attempts? Or;

2. Do you mean that the reconnection attempt is made and 'hangs' for 30 minutes? Or;

3. Did you have the channel running, then 'break' the connection and have the application try to reconnect, or, not have the channel running and then try to connect?

Also, have you considered using the mqclient.ini file and a CCDT to handle your connections? This would also give you the ability to better tune your delay timings.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys.

Back to top
View user's profile Send private message
dudetom
PostPosted: Sat Dec 29, 2018 11:32 am Post subject: Reply with quote

Apprentice

Joined: 29 Sep 2017
Posts: 45

Hi exerk

Channel is always running. I manipulate the client side application by blocking the port 1414 on OS level.

I set the reconnection timeout to 5 minutes for testing purposes. So it should fail faster and stop trying to reconnect. But changing this parameter has no effect, it applies the default timeout of 30 minutes. Maybe you ask how I know this? After 30 minutes the exceptionlistener raises reason code 2009 (connection broken), during the 30 minutes I receive reason code 2454 (reconnecting) which should normally follow by a 2455 reason code (reconnected) which never happens because the port is blocked obviously. I hope this helps you understanding better the scenario.

And other ways of configuration is not an option for me. This is the most basic thing that should be configurable...
Back to top
View user's profile Send private message
bruce2359
PostPosted: Sat Dec 29, 2018 12:24 pm Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 8252
Location: US: west coast, almost. Otherwise, enroute.

dudetom wrote:
And other ways of configuration is not an option for me.

What other ways are not available to you?
_________________
There are two types of people in this world:
1) Those that can extrapolate from incomplete data
Back to top
View user's profile Send private message
exerk
PostPosted: Sat Dec 29, 2018 1:06 pm Post subject: Reply with quote

Jedi Council

Joined: 02 Nov 2006
Posts: 5980

dudetom wrote:
...Channel is always running. I manipulate the client side application by blocking the port 1414 on OS level...

A running channel will continue to run after a Listener is stopped or blocked until such time as a disconnect occurs, so, again, how are you interrupting the channel?

dudetom wrote:
...And other ways of configuration is not an option for me. This is the most basic thing that should be configurable...

And I echo the question of my most eminent colleague - why are the 'other ways' not an option?
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys.

Back to top
View user's profile Send private message
bruce2359
PostPosted: Sat Dec 29, 2018 5:35 pm Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 8252
Location: US: west coast, almost. Otherwise, enroute.

dudetom wrote:
Channel is always running. I manipulate the client side application by blocking the port 1414 on OS level.

No, you didn't manipulate the client side app at all. Which SVRCONN channel is RUNNING? Is this channel dedicated to only this client-side app?

What do you mean by 'Channel is always running'? How do you know this?

What is the client app doing? In an MQGET? With a long waitinterval?

Post the SVRCONN channel definition here.

How does reconnect work for you if you kill off and restart the client-side app?

P35 of what?
_________________
There are two types of people in this world:
1) Those that can extrapolate from incomplete data
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Sat Dec 29, 2018 10:01 pm Post subject: Reply with quote

Grand Poobah

Joined: 18 Nov 2003
Posts: 19855
Location: LI,NY

dudetom wrote:
I manipulate the client side application by blocking the port 1414 on OS level.

So what is the 30 mins? A TCP/IP delay?
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
dudetom
PostPosted: Mon Dec 31, 2018 1:03 am Post subject: Reply with quote

Apprentice

Joined: 29 Sep 2017
Posts: 45

Here is the source document where I can see there is a timeout of 30 minutes of retry time: https://www-01.ibm.com/support/docview.wss?uid=swg27038186&aid=1 (page 35).

@bruce2359

as I stated also in my post, I manipulated on OS level. With OS level I mean I blocked the port for all outgoing traffic on Windows Firewall level. I think this is clear enough?

Unfortunately I can't retrieve SVRCONN channel information. I can't access the QM side.

I suppose the channel is always running because if I don't block the port 1414, I can always connect successfully...

And related to your last question, I don't kill the client-side app, I just block the MQ port (1414 on Windows Firewall level) after client connection is made.

Other ways are not an option because we faced also other problems with SSL and message compression and a lot of other stuff too. We need to connect with XMS.NET unmanaged mode, because changing this will bring a lot of headache again...

I have written a code-snippet, this can easily be reproduced, if you really want to help me...
Back to top
View user's profile Send private message
exerk
PostPosted: Mon Dec 31, 2018 6:18 am Post subject: Reply with quote

Jedi Council

Joined: 02 Nov 2006
Posts: 5980

dudetom wrote:
...as I stated also in my post, I manipulated on OS level. With OS level I mean I blocked the port for all outgoing traffic on Windows Firewall level. I think this is clear enough?

Clear...

dudetom wrote:
...Unfortunately I can't retrieve SVRCONN channel information. I can't access the QM side.

...but you can ask the admin responsible for the details...

dudetom wrote:
...I suppose the channel is always running because if I don't block the port 1414, I can always connect successfully...

...and no, the channel will only be running when you instantiate a connection - a SVRCONN is passive and only runs when a successful connection request is made...

dudetom wrote:
...And related to your last question, I don't kill the client-side app, I just block the MQ port (1414 on Windows Firewall level) after client connection is made...

...so the channel is already running, and as I have previously stated, will continue to run until such time as the connection is broken, at which point the client-side should re-initiate connection - it's possible that port blocking is not being interpreted as a broken connection...

dudetom wrote:
...Other ways are not an option because we faced also other problems with SSL and message compression and a lot of other stuff too. We need to connect with XMS.NET unmanaged mode, because changing this will bring a lot of headache again...

...which sounds to me an issue with the 'other' (server) end because setting up and controlling the connection via mqclient.ini and CCDT files is a lot easier and painless than through code.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys.

Back to top
View user's profile Send private message
bruce2359
PostPosted: Mon Dec 31, 2018 7:37 am Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 8252
Location: US: west coast, almost. Otherwise, enroute.

dudetom wrote:
... if you really want to help me...

We are trying to help you.

The usual process problem source identification involves us asking, and you answering questions, testing different scenarios, and repeating the cycle. You need to be fully involved, and be precise in your answers.

I misunderstood, from your earlier post, where (client or server platform) you blocked port traffic, and also where (client or server platform) you saw the channel in RUNNING state.

I asked you how you determined that the channel was RUNNING state. SVRCONN channels exist only on the server, and not the client.

dudetom wrote:
I suppose the channel is always running because if I don't block the port 1414, I can always connect successfully...

This is not evidence that the SVRCONN channel was RUNNING; or, if it was, that it was RUNNING because of your client app. An MQ trace on both client and server would confirm this. As mentioned by my colleague, a SVRCONN channel is RUNNING while an app is MQCONNected.

Does this client app use a dedicated SVRCONN channel? Or, is the SVRCONN channel shared by other client instances?

How do you expect the client app to be able to reconnect if you've blocked the outbound port?

I also asked you to do a simple test, namely: start the client app normally, then kill and restart the client app, and observe and report how reconnect normally functions. The underlying design of reconnect presumes that it will most likely be the client platform that fails.

How did IBM respond to your PMR on this issue?

We are volunteers here. Most of us work full-time. Many of us have decades of experience with MQ (read: subject matter experts). Quite a few volunteers currently or previously worked for IBM authoring and supporting MQ.
_________________
There are two types of people in this world:
1) Those that can extrapolate from incomplete data
Back to top
View user's profile Send private message
dudetom
PostPosted: Wed Jan 02, 2019 5:28 am Post subject: Reply with quote

Apprentice

Joined: 29 Sep 2017
Posts: 45

First of all, sorry for saying "channel is always running", what I meant was "QM (server) is always running". (I'm not an IBM MQ expert, sorry).

But we solved this problem by just using a mqclient.ini file in the bin directory of the client application and with following configuration:

CHANNELS:
MQReconnectTimeout = 3600

I can conclude that configuring using code does not work

So this line has no effect:
connectionFactory.SetIntProperty(XMSC.WMQ_CLIENT_RECONNECT_TIMEOUT, 3600);


Happy new year!


How can you do quotes btw? If I do, then I see the brackets as plain text. Even bold, italic and underline does not work here...
Back to top
View user's profile Send private message
exerk
PostPosted: Wed Jan 02, 2019 5:33 am Post subject: Reply with quote

Jedi Council

Joined: 02 Nov 2006
Posts: 5980

So after saying you couldn't, you did this:

dudetom wrote:
...But we solved this problem by just using a mqclient.ini file in the bin directory of the client application...


Not so difficult after all
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys.

Back to top
View user's profile Send private message
bruce2359
PostPosted: Wed Jan 02, 2019 5:45 am Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 8252
Location: US: west coast, almost. Otherwise, enroute.

dudetom wrote:
How can you do quotes btw? If I do, then I see the brackets as plain text. Even bold, italic and underline does not work here...

First: highlight the text you want to bold, quote, URL, etc...
Next: press the appropriate bold,quote, URL button.
Next: press the Preview button to the left of the Submit button. The Preview button will display your post - without actually posting.
Last: press Submit button to post.
_________________
There are two types of people in this world:
1) Those that can extrapolate from incomplete data
Back to top
View user's profile Send private message
dudetom
PostPosted: Wed Jan 02, 2019 10:55 pm Post subject: Reply with quote

Apprentice

Joined: 29 Sep 2017
Posts: 45

bruce2359 wrote:
dudetom wrote:
How can you do quotes btw? If I do, then I see the brackets as plain text. Even bold, italic and underline does not work here...

First: highlight the text you want to bold, quote, URL, etc...
Next: press the appropriate bold,quote, URL button.
Next: press the Preview button to the left of the Submit button. The Preview button will display your post - without actually posting.
Last: press Submit button to post.


That's what I'm doing too?

for example this is bold. What I see is: [b] this is bold [/ b]
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Fri Jan 04, 2019 10:32 pm Post subject: Reply with quote

Grand Poobah

Joined: 18 Nov 2003
Posts: 19855
Location: LI,NY

dudetom wrote:
bruce2359 wrote:
dudetom wrote:
How can you do quotes btw? If I do, then I see the brackets as plain text. Even bold, italic and underline does not work here...

First: highlight the text you want to bold, quote, URL, etc...
Next: press the appropriate bold,quote, URL button.
Next: press the Preview button to the left of the Submit button. The Preview button will display your post - without actually posting.
Last: press Submit button to post.


That's what I'm doing too?

for example this is bold. What I see is: [b] this is bold [/ b]


When you do post make sure that disable BBCode and Disable Smilies is not checked...
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
Display posts from previous:
Post new topicReply to topic Goto page 1, 2  Next Page 1 of 2

MQSeries.net Forum IndexGeneral IBM MQ SupportIBM MQ XMS.NET client reconnect timeout can't be changed
Jump to:



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
Protected by Anti-Spam ACP


Theme by Dustin Baccetti
Powered by phpBB 2001, 2002 phpBB Group

Copyright MQSeries.net. All rights reserved.