| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Why should multiple listener threads be causing a problem ? |
« View previous topic :: View next topic » |
| Author |
Message
|
| Hugh_Everett |
 Posted: Wed Oct 10, 2001 5:09 am Post subject: |
 |
|
Novice
Joined: 08 Jul 2001
Posts: 19
Location: Manchester, UK
|
Environment: MQSeries for AS/400 V5.1 on meaty 8-way AS/400. 19 separate threads on a Windows NT WebSphere Appl Server (aka WAS), coded in Java, use standard Client MQI to connect to the AS/400 queue manager, open 1 i/op and 1 o/p queue each, and sit all day GETting and PUTting messages. Note that all the queues opened are the same 4 queues on the AS/400.
On the AS/400 we can see one RUNMQLSR job with 23 threads. (Incidentally, presuming that each of these threads relates to one of the WAS's threads, we can account for 19 - what are the other 4 ...?)
All works fine.
If we now duplicate the WAS's, so that there are 4, each with 19 separate threads, the number of threads in the listener goes up to 80+. And problems start to occur: mainly that performance hits the roof, CPU on the AS/400 is eaten, and threads appear to hang.
We have a number of ways around the problem (not least a migration to V5.2 on the AS/400). However, even with the help of IBM MQ Assist, we are having problems identifying the root cause of the problem.
Have you experienced a similar problem, or have you a similar environment with NO such problem ?
_________________
Hugh Everett
Manchester, UK |
|
| Back to top |
|
 |
| Hugh_Everett |
| Posted: Wed Oct 24, 2001 7:51 am Post subject: |
|
|
Novice
Joined: 08 Jul 2001
Posts: 19
Location: Manchester, UK
|
Well, seems like no-one is willing to venture any experiences. So given that, if I answer this, then I increase my number of postings and therefore expedite my promotion from Newbie, here is my reply to my own question ...
It appears that there were two contributory factors to the hanging threads:
- The customer had MQSeries for AS/400 V5.1, with back-level PTFs.
We migrated to V 5.2, and applied the latest PTFs. Some of the enhancements of V5.2 over V5.1 are very much to do with the listener jobs and performance etc - in other words they appear to address exactly the sort of problems we were seeing.
- The journalling on the AS/400 could have been contributing to the problems.
Journalling is the way the AS/400 provides disaster recovery. The customer had left the defaults, which - with the traffic and message sizes he had - meant that a new journal receiver was being created every 5 to 10 minutes, and correspondingly some 80-odd journal receivers were being created during a day. At the same time, they were running RCDMQMIMG only once a week, and not deleting old journal receivers.
Whilst integrally to the AS/400, this caused no problems, the way that MQSeries has to stop (briefly) every time a new journal receiver is attached, and the way it has to look all through historical journal receivers on a re-start, meant that poor old MQSeries was given an awful lot of extra work.
To help with this, we:
- increased the threshold size of the receivers (to 4GB, being just over the 3.5GB that they expect in one day)
- ensured that RCDMQMIMG is run every evening
- ensured that old (no longer needed) jounral receivers are deleted regularly
And all seems to be working fine so far.
Message: on an AS/400 (aka e-Server iSeries) use V5.2 and ensure that journals and their receivers are well-managed. |
|
| 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
|
|
|
|
