| Author |
Message
|
| rjlfc |
 Posted: Fri Apr 04, 2008 3:28 am Post subject: WAS MQ Connection (client channels) |
 |
|
Apprentice
Joined: 04 Apr 2008
Posts: 31
|
Hi,
We have a WAS connection to MQ (WAS 6.0.2.17 and MQ 6.0.2). Our WAS has a queue connection factory to the QM and several JMS queue connection definitions. Note that the queue connection definitions are client connections that have no client channel specified.
1. I assume this therefore uses the default server conn channel on MQ at runtime? It works (generally - see 2. below) but should this specifiy a specifically client channel that we then set up on the MQ server? By doing it the way we have, what problems might be caused?
2. Overnight MQ is stopped and started but our WAS servers are not (yet). First thing in the morning, when the application is run, it fails to write to the MQ queue with a JMS 2008 (cannot write to queue) and MQ 2009 (connection to QM lost). All subsequent tries then work. Is this something to do with the client channel creation at application runtime? Or the fact it's the first time the app is run after the bounce of MQ? We tried testing for the latter by bouncing MQ manually during the day but could not replicate the error.
Any help would be appreciated......... |
|
| Back to top |
|
 |
| Gaya3 |
| Posted: Fri Apr 04, 2008 4:08 am Post subject: |
|
|
Jedi
Joined: 12 Sep 2006
Posts: 2493
Location: Boston, US
|
You have check the channels are running or not, even listeners too.
 if the channel processes are running.
Regards
Gayathri
_________________
Regards
Gayathri
-----------------------------------------------
Do Something Before you Die |
|
| Back to top |
|
|
| rjlfc |
| Posted: Fri Apr 04, 2008 4:12 am Post subject: |
|
|
Apprentice
Joined: 04 Apr 2008
Posts: 31
|
Can you tell me what you mean by channel processes are running?
And how would the app start working automatically once the first error had occurred?
Thanks. |
|
| Back to top |
|
|
| Gaya3 |
| Posted: Fri Apr 04, 2008 4:18 am Post subject: |
|
|
Jedi
Joined: 12 Sep 2006
Posts: 2493
Location: Boston, US
|
The communication between WAS to MQ are happening through channels.
if these are not active/ready at that time, apps cant able to place messages in to the queue.
Each channel is a process to the queue manager.
so you can even search for the same if its existing or not and whats the status of that.
Regards
Gayathri
_________________
Regards
Gayathri
-----------------------------------------------
Do Something Before you Die |
|
| Back to top |
|
|
| rjlfc |
| Posted: Fri Apr 04, 2008 4:37 am Post subject: |
|
|
Apprentice
Joined: 04 Apr 2008
Posts: 31
|
I understand the principle of channels, but these are client channels and there is only a default servconn channel defined which is what I assume will be used for the client connection from WAS.
Should this default client channel (SYSTEM.DEF.SVRCONN) automatically start after a MQ restart?
I will have to check the status of this default serverconn the next time the MQ server is bounced overnight.
However, my original question still applies, how does the application manage to connect fine on the second attempt? Is it possible that the default client channel channel starts automatically after the first failed attempt - this doesn't really make sense. |
|
| Back to top |
|
|
| Gaya3 |
| Posted: Fri Apr 04, 2008 4:43 am Post subject: |
|
|
Jedi
Joined: 12 Sep 2006
Posts: 2493
Location: Boston, US
|
| rjlfc wrote: |
Should this default client channel (SYSTEM.DEF.SVRCONN) automatically start after a MQ restart? YES it starts 
However, my original question still applies, how does the application manage to connect fine on the second attempt? Is it possible that the default client channel channel starts automatically after the first failed attempt - this doesn't really make sense.
It might have started after some delay... 
|
[/b]
_________________
Regards
Gayathri
-----------------------------------------------
Do Something Before you Die |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Apr 04, 2008 5:01 am Post subject: Re: WAS MQ Connection (client channels) |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| rjlfc wrote: |
2. Overnight MQ is stopped and started but our WAS servers are not (yet). First thing in the morning, when the application is run, it fails to write to the MQ queue with a JMS 2008 (cannot write to queue) and MQ 2009 (connection to QM lost). All subsequent tries then work. Is this something to do with the client channel creation at application runtime? Or the fact it's the first time the app is run after the bounce of MQ? We tried testing for the latter by bouncing MQ manually during the day but could not replicate the error.
|
If the queue manager goes down, but WAS does not, then I would theorise that the application (or WAS itself if you've got connection pooling) is not disconnecting from the queue manager & hence retains the connection handle(s). When the application restarts, it tries to use the handle to the old queue manager instance (now long since timed out and out of scope) & fails. The recommended response to a 2009 error is to simply attempt reconnection in the first instance. This will of course suceed and you're away.
If you're going to leave your app/WAS running when the queue manager is dropped under it, ensure the app has fail if quiescing or similar coded to stop it using duff connections.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| rjlfc |
| Posted: Fri Apr 04, 2008 5:56 am Post subject: |
|
|
Apprentice
Joined: 04 Apr 2008
Posts: 31
|
Thanks for your reply Vitor - that does sound a very plausible explanation.
However, when we tried to test/replicate the error by bouncing MQ manually in the middle of the day, the error did not reoccur. Surely the connection handle is lost in this scenario too?
MQ Connection Pooling IS enabled on the MQ Connection Factory. So does this mean that WAS has the handle to the queue manager, and the application only has to Opend and PUT/GET to the queues? Or does the Java application still have to do a connect and disconnet from the queue manager?
One more question if thats ok Vitor - is there any setting on the MQ side re. the default client channel and the maximum number of connections etc?
Cheers! |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Apr 04, 2008 6:07 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| rjlfc wrote: |
| when we tried to test/replicate the error by bouncing MQ manually in the middle of the day, the error did not reoccur. Surely the connection handle is lost in this scenario too? |
I suspect there's some kind of timeout limit somewhere in play here. Client connections can be troublesome (hence the first response to a 2009 is to sigh & reconnect). This quite valid strategy would fix your issue. If not that, WAS is doing something with the connection pool (and outside my area of expertise) that's maintaining/refreshing the connections when you test it but not overnight. Others may post more information on this than I can give.
| rjlfc wrote: |
| MQ Connection Pooling IS enabled on the MQ Connection Factory. So does this mean that WAS has the handle to the queue manager, and the application only has to Opend and PUT/GET to the queues? Or does the Java application still have to do a connect and disconnet from the queue manager? |
No it still needs to connect, but it will get a connection from the WAS pool. The connect is an "expensive" opperation, so it improves performance if WAS sits & obtains all the connections, then just hands them out as required. It's somewhere in here that your 2009 is coming, as the application is being given a broken connection.
| rjlfc wrote: |
One more question if thats ok Vitor - is there any setting on the MQ side re. the default client channel and the maximum number of connections etc?
|
The default channel is SYSTEM.DEF.SVRCONN (surprisingly), and the queue manager limits the maximum number of connections to the MaxChannels setting.
 for more details.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
