| Author |
Message
|
| skailash |
 Posted: Fri Apr 15, 2011 1:25 pm Post subject: Close the connection after processing every 1 million msgs |
 |
|
Newbie
Joined: 11 Apr 2011
Posts: 6
|
Hello,
Is it possible to forcibly close the client connection on the MQ server side, after say for example, every 1 million messages? This is a requirement from development team since they don't have control over the client application but want to force the application to close the connection constantly on the server side and reconnect to the queue manager again.
Let me know if I should provide more details.
Thanks
Sam |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Fri Apr 15, 2011 2:49 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| This is a requirement... |
For what purpose exactly? To solve what problem exactly?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| exerk |
| Posted: Fri Apr 15, 2011 3:54 pm Post subject: Re: Close the connection after processing every 1 million ms |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| skailash wrote: |
| ...Is it possible to forcibly close the client connection on the MQ server side, after say for example, every 1 million messages? This is a requirement from development team since they don't have control over the client application but want to force the application to close the connection... |
So why don't they set a counter and do it?
_________________
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 |
|
|
| skailash |
| Posted: Mon Apr 18, 2011 5:56 am Post subject: Close the connection after processing every 1 million ms |
|
|
Newbie
Joined: 11 Apr 2011
Posts: 6
|
Purpose - We have 3 data centers and there will be a MQ server on each data center receving messages from the corresponding clients in the 3 data centers. We are going to use Veritas HA on the 3 data centers. Since we don't have control on the client side, development wants to close the connection after every 1 million messages and reconnect. If one of the data centers is down, the client will connect to the 2nd data center and so on.
Setting a counter - where do we set the counter? Since client implementation is going to be done by a group outside of control, programmatically setting the counter on the client side is not a reliable solution for us. So, we are looking for a way to enforce this on the MQ server side if there is an in-built feature. Is that possible?
Thanks
Sam |
|
| Back to top |
|
|
| exerk |
| Posted: Mon Apr 18, 2011 6:08 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Put all three queue managers in three different CCDTs, with their order of preference changed, and divide the clients into groups. Set affinity within the CCDTs such that any given group will always connect/reconnect to its 'primary', then pick the secondary/tertiary if the primary is unavailable. Each client 'group' will always use the same queue manager and will only 'fail over' when their primary is unavailable. I see absolutely no point whatsoever in doing what the developers want you to do - if the client is reliant on the messages in any one queue manager then the design is flawed; if not reliant on those messages then why disconnect and reconnect? It's not efficient. There is no out-of-the-box solution within WMQ for what you want to achieve as far as I know, nor likely to be.
_________________
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 |
|
|
| Vitor |
| Posted: Mon Apr 18, 2011 6:13 am Post subject: Re: Close the connection after processing every 1 million ms |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| skailash wrote: |
| Purpose - We have 3 data centers and there will be a MQ server on each data center receving messages from the corresponding clients in the 3 data centers. We are going to use Veritas HA on the 3 data centers. Since we don't have control on the client side, development wants to close the connection after every 1 million messages and reconnect. If one of the data centers is down, the client will connect to the 2nd data center and so on. |
I don't see what this counter is supposed to achieve, and perhaps I'm missing the point. If a client is connected to any given data center, and that data center goes down, then the client will attempt to reconnect in exactly the same way it would have to if the connection was forceibly closed (which to the client would look like the data center had gone down).
So what's the difference in your scenario between a data center crashing and the data center forceibly closing the connection after 1 million messages? Most specifically what's the difference from the client application's perspective?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Apr 18, 2011 6:37 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
This approach seems unnecessary - even redundant.
You want to force the connection to fail on a functioning qmgr, so that the client will be forced to reconnect to a possibly failed qmgr. This makes no sense to me.
Why 1 million? Why not 10 million? Or 250k? Or 100? Or for every connection?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| skailash |
| Posted: Mon Apr 18, 2011 1:56 pm Post subject: Close the connection after processing every 1 million |
|
|
Newbie
Joined: 11 Apr 2011
Posts: 6
|
The client tries to connect to the primary queue manager and if it is down, it connects to the secondary queue manager. Once the primary is back up, the client should switch over to the primary and since only at the time of opening the connection, the client checks whether the primary is available or not, development forces the client to close the connection after every million messages for example. Doing it so for every connection will be an overkill that will affect the performance. Since we have 3 data centers, the affinity for each queue manager will be equal so I was told that whenever the client connects the 2nd time, it will unnecessarily switch over to the secondary even though primary is available.
By the way, since we are MQ classes at the client side, I guess we can't use auto-reconnect.
Thanks
Sam. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Apr 18, 2011 4:56 pm Post subject: Re: Close the connection after processing every 1 million |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| skailash wrote: |
| The client tries to connect to the primary queue manager and if it is down, it connects to the secondary queue manager. Once the primary is back up, the client should switch over to the primary and since only at the time of opening the connection, the client checks whether the primary is available or not |
It's seriously not best practice for any application to know (or care) which queue manager it's connected to. Take the advice of my most worthy associate & use a CCDT. In this way the client will connect to the first available queue manager (and you can use multiple CCDTs to handle different affinity needs) and if you want applications to fail back from secondary to primary, force close the channel at the server side.
This has nothing to do with auto-reconnect, which you may or may not be able to use. I don't understand your comment about MQ classes.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| exerk |
| Posted: Mon Apr 18, 2011 11:20 pm Post subject: Re: Close the connection after processing every 1 million |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| Vitor wrote: |
| ...I don't understand your comment about MQ classes... |
I suspect the poster means that only the jars have been copied across (when will people ever learn?) rather than a full client install.
| skailash wrote: |
| ...Since we have 3 data centers, the affinity for each queue manager will be equal... |
Only if made so; see my previous comment in regard to separate CCDTs with different affinities set within them.
| skailash wrote: |
| ...so I was told that whenever the client connects the 2nd time, it will unnecessarily switch over to the secondary even though primary is available... |
Who told you that, and what exactly did they mean?
_________________
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 |
|
|
| skailash |
| Posted: Tue Apr 19, 2011 6:24 am Post subject: Close the connection after processing every 1 million |
|
|
Newbie
Joined: 11 Apr 2011
Posts: 6
|
Development told me that when the affinity is equal for all the 3 queue managers across the data centers, client will connect to the 1st queue manager first time and the second time when the connection is made, it will connect to the 2nd queue manager even though the 1st queue manager is available (I guess because of the equal weightage). But since you mentioned about using separate CCDTs, this will be a moot point.
Based on the responses in this thread, I take that the recommendation is to use CCDT. There is a debate going on here whether to use CCDT or a properties file. The main reason for properties file is ease of maintenance. We can store the properties file in a centralized database so any changes need to be made once but with the CCDT file, whenever it changes, we need to copy it to all the clients. I don't see the CCDT file changing very often so it may not be a big overhead.
Regarding the comment about MQ classes - I am referring to "Automatic client reconnect is not supported by WebSphere® MQ classes for Java" in the WMQ manual.
Sam |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Apr 19, 2011 6:38 am Post subject: Re: Close the connection after processing every 1 million |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| skailash wrote: |
| Development told me that when the affinity is equal for all the 3 queue managers across the data centers, client will connect to the 1st queue manager first time and the second time when the connection is made, it will connect to the 2nd queue manager even though the 1st queue manager is available (I guess because of the equal weightage). But since you mentioned about using separate CCDTs, this will be a moot point. |
As far as I am aware it will only do that if you set it so, if not, the application will work down the list of entries. If you use multiple CCDTs they will contain the same entries but ordered differently, i.e. CCDT1 has A, B, C; CCDT2 has C, A, B; CCDT3 has B, C, A.
| skailash wrote: |
| There is a debate going on here whether to use CCDT or a properties file. The main reason for properties file is ease of maintenance. We can store the properties file in a centralized database so any changes need to be made once but with the CCDT file, whenever it changes, we need to copy it to all the clients. |
Keeping the details in a database exposes more of your messaging infrastructure than the application needs to know, and are you going to be keeping your client key stores in a database too? The CCDT file can be on a file share and does not need to be distributed to every client, ditto the key stores.
_________________
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 |
|
|
| shashivarungupta |
| Posted: Tue Apr 19, 2011 6:39 am Post subject: |
|
|
Grand Master
Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.
|
| skailash wrote: |
| ..I take that the recommendation is to use CCDT... |
Ya.. its good. ( refer : http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/index.jsp?topic=/com.ibm.mq.csqzae.doc/ic19850_.htm ).
I used CCDT in my system and works perfectly fine for 'fail over' and you don't have to bother about CCDT file once you have created it successfully and tested it ( unless there is some change in the existing infrastructure architecture )
_________________
*Life will beat you down, you need to decide to fight back or leave it. |
|
| Back to top |
|
|
| mvic |
| Posted: Wed Apr 20, 2011 2:41 pm Post subject: Re: Close the connection after processing every 1 million ms |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
This is a very unusual requirement, but you can always stop connections using STOP CONN in runmqsc. Make sure you've identified the right connection first, though!
If you want to implement some rule-based behaviour, run a script every now and then that checks the number of messages transferred, and calls STOP CONN if some rule is triggered.
Or you could go a different way, and implement some counting in a msgexit or an api exit.
But I agree with everyone who has said (or implied) that this sounds too weird to be good design. |
|
| Back to top |
|
|
|
|
