| Author |
Message
|
| jshailes |
 Posted: Tue Jun 28, 2011 8:35 am Post subject: |
 |
|
Apprentice
Joined: 18 May 2009
Posts: 31
|
I really would've struggled to get as far as I have today without everyones help, so thanks very much for your inputs. In response to shashivarungupta's last post:
| Quote: |
| Qmgr logs full can cause your qmgr crash ! |
I'm going to increase the number of log files this evening because I read that increasing the size requires me to delete the QM. Am I right in thinking I need to restart the QM after modifying the number of log files?
| Quote: |
| Too many unclosed connections on the qmgr can keep the qmgr busy |
Is there anywhere I can see info on the connections?
It makes sense that old ones can be an overhead, and I can imagine tidying them up would be a priority if connections were commonly opened and closed. In our case I never explicitly open and close the connection apart from opening one listener for each of 3 destinations on initial load, closing on application destruction, and in the code overriding onException. Since no exceptions are in my java logs, I can't understand why connections are ever broken unless mqjeff suggestion is correct when saying:
| Quote: |
| network hardware has been configured to do things like drop connections that are open "too long" |
There don't appear to be any signs of dropping connections in the MQ FDC logs. Does anyone know how reconnection are managed? Who's responsibility is it to reconnect? Java sockets? MQ? Java MQ Library? I would've thought it must be in Java because a new Thread is spawned for the listener and the old listener thread destroyed.
I had a brief read about channel stanzas where it mentioned DefRecon param but also noted: Automatic client reconnect is not supported by WebSphere® MQ classes for Java.
| Quote: |
| reading and implementing the TCP and CHANNEL stanzas of qm.ini |
I've had a read about the TCP and channel stanza params. There were a few that look interesting - DefRecon, MQReconnectTimeout, Connect_Timeout and KeepAlive. It seems the first 2 are not used by the java library, the connect_timeout defaults to 0 which seems reasonable, and I have KeepAlive=true. My qm.ini file is as follows:
| Code: |
ExitPath:
ExitsDefaultPath=/var/mqm/exits/
ExitsDefaultPath64=/var/mqm/exits64/
#* *#
#* *#
Log:
LogPrimaryFiles=3
LogSecondaryFiles=2
LogFilePages=4096
LogType=CIRCULAR
LogBufferPages=0
LogPath=/var/mqm/log/ACT01/
LogWriteIntegrity=TripleWrite
Service:
Name=AuthorizationService
EntryPoints=13
ServiceComponent:
Service=AuthorizationService
Name=MQSeries.UNIX.auth.service
Module=/opt/mqm/lib/amqzfu
ComponentDataSize=0
TCP:
KeepAlive=YES |
|
|
| Back to top |
|
 |
| mqjeff |
| Posted: Tue Jun 28, 2011 8:56 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
In general, you should expect that any changes to qm.ini or qmgr configuration will require a restart of the qmgr.
You can use MQExplorer or mqsc - dis conn - to see connections.
If you don't see any comments in the amq logs and no FDCs that are co-incident with the listener thread crash and restart, then it's as much likely to be an issue in the Java side than the qmgr side.
But again, if there's a network switch in between the machine hosting the qmgr and the machine hosting the java app, and this network switch decides the mq connection is 'stale' and kills it - you would only see notices on either side that the connection died, and not any information about why. |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Jun 28, 2011 9:48 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
| To see the current channels connected - use MO71 and channel status list, or the MQ explorer equivalent. |
|
| Back to top |
|
|
| shashivarungupta |
| Posted: Tue Jun 28, 2011 10:41 am Post subject: |
|
|
Grand Master
Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.
|
echo 'display chs(*) where ( chltype EQ svrconn )' | runmqsc QMGRNAME | grep STATUS | wc -l
you can see the count by this.
you can filter the type of channel as well.
_________________
*Life will beat you down, you need to decide to fight back or leave it. |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Jun 28, 2011 11:07 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
The GUIs give all the details, easy to see, sort, expand - etc. The wonderful world of the 21st century.  |
|
| Back to top |
|
|
| shashivarungupta |
| Posted: Tue Jun 28, 2011 11:19 am Post subject: |
|
|
Grand Master
Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.
|
| zpat wrote: |
| The GUIs give all the details, easy to see, sort, expand - etc. The wonderful world of the 21st century. |
We should not be forgetting from where we came into the world of 21st century.
(you are right though, now a days we have so many gui tools, to answer our questions. we can use them ofcourse without killing time, if those are already in the system and not to have to google the link/its website then download then unzip then configure then execute and then look into for the objects).
_________________
*Life will beat you down, you need to decide to fight back or leave it. |
|
| Back to top |
|
|
| shashivarungupta |
| Posted: Tue Jun 28, 2011 11:45 am Post subject: |
|
|
Grand Master
Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.
|
| jshailes wrote: |
I'm going to increase the number of log files this evening because I read that increasing the size requires me to delete the QM. Am I right in thinking I need to restart the QM after modifying the number of log files? |
To increase no. of Log Files and to increase the size of log files, of a qmgr, are two diff. things !
Note: The size of the log files specified during queue manager creation cannot be changed for a queue manager.
Note: You cannot change the logging method after a queue manager has been created.
Note : LogPrimaryFiles & LogSecondaryFiles, its value is examined when the queue manager is created or started. *You can change it after the queue manager has been created. However, a change in the value is not effective until the queue manager is restarted
_________________
*Life will beat you down, you need to decide to fight back or leave it. |
|
| Back to top |
|
|
| jshailes |
| Posted: Thu Jun 30, 2011 8:20 am Post subject: |
|
|
Apprentice
Joined: 18 May 2009
Posts: 31
|
To be honest I've never had enough time to spend with MQ to get used to the command line, and have therefore always used MQ Explorer. I don't seem to be able to find any information relating directly to the listeners though. There is a section on Subscriptions but the create instants are what I would expect if the listener had never failed. There is also a section titled 'Client Connections' but this is empty.
I've been in touch with our server hosts and they explained how it couldn't be there fault because they're only routing L2 frames.. does that make sense?
I have been looking through the logs and have finally found the exception on the java side, christ knows why its taken me so long to track down. It seems that the client receives a SocketException - connection reset. Is there any way I can work out why MQ is sending this? |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Jun 30, 2011 10:23 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| jshailes wrote: |
| I've been in touch with our server hosts and they explained how it couldn't be there fault because they're only routing L2 frames.. does that make sense? |
Yes it does. It's an industry standard that anyone associated with network and/or connectivity will always claim it can't possibly be their fault the first time they're presented with a problem. Skilled and experienced network people won't even bother to look at the problem but will just respond from instinct, like a snake striking.
(I apologise to any snakes reading this who are offended by the association)
| jshailes wrote: |
| It seems that the client receives a SocketException - connection reset. Is there any way I can work out why MQ is sending this? |
Because that's what MQ got back from the network - the formal code is ECONNRESET. Consider my comments above about network people repeated.
Suggested further diagnosis steps - print out the connection reset error, wrap it round a large fish and trout your network people until they confess.
Note that a very common cause of a connection being reset - a network switch / firewall / router deciding the connection is stale, out of scope or just looking at it in a funny way and closing it abruptly. As previously mentioned in this thread.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| skoobee |
| Posted: Thu Jun 30, 2011 10:24 am Post subject: |
|
|
Acolyte
Joined: 26 Nov 2010
Posts: 52
|
| WMQ does not send connection resets; they come out of the network layer usually. |
|
| Back to top |
|
|
| shashivarungupta |
| Posted: Thu Jun 30, 2011 11:20 am Post subject: |
|
|
Grand Master
Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.
|
| skoobee wrote: |
| WMQ does not send connection resets; they come out of the network layer usually. |
A bit more elaboration, few more words into it, would be really appreciated.
_________________
*Life will beat you down, you need to decide to fight back or leave it. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Thu Jun 30, 2011 3:22 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| shashivarungupta wrote: |
| skoobee wrote: |
| WMQ does not send connection resets; they come out of the network layer usually. |
A bit more elaboration, few more words into it, would be really appreciated. |
MQ establishes TCPIP socket connections over the network between its Message Channel Agents (including the Client MQI). Packets flow in both directions between the agents to implement the MQ protocol.
If the TCP stack detects that one end of the socket connection has failed (for whatever reason) it may return a "connection reset" status to the MQ MCA.
This usually leads to an MQI call failure. Client MCAs will typically experience a MQRC_CONNECTION_BROKEN. The only recourse is to make a new connection to MQ. The actual TCPIP socket return code (an errno, winsock error or z/OS OESockets return code) appears in the MQ error logs.
_________________
Glenn |
|
| Back to top |
|
|
|
|
