| Author |
Message
|
| tso0rxp |
 Posted: Fri Apr 05, 2002 8:55 am Post subject: |
 |
|
Voyager
Joined: 07 Jan 2002
Posts: 85
|
Server A running qmgr A has sender/receiver channels to Server B running qmgr B.
Server A qmgr comes down (as do channels, naturally). Server B sender channel stays up (RUNNING). Server A qmgr comes back up and starts sender channel to Server B OK but Server B sender channel must be stopped and restarted.
Both servers running MQ Series v5.0 on Solaris.
Is there a time delay that causes Server B qmgr to think the remote queue manager is still active? |
|
| Back to top |
|
 |
| mrlinux |
| Posted: Fri Apr 05, 2002 9:12 am Post subject: |
|
|
Grand Master
Joined: 14 Feb 2002
Posts: 1261
Location: Detroit,MI USA
|
You need to upgrade to V5.2, there were lots of channel issues with V5.0,
what CSD are you at ??? I hope at least CSD8
_________________
Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
[ This Message was edited by: mrlinux on 2002-04-05 09:13 ] |
|
| Back to top |
|
|
| tso0rxp |
| Posted: Fri Apr 05, 2002 9:22 am Post subject: |
|
|
Voyager
Joined: 07 Jan 2002
Posts: 85
|
Don't know our CSD but the last level of patches applied was late 2001. I am planning on an upgrade mid-year to 5.2 but my management is pressing me for a reason this does not work correctly today. My queue manager is also ending abnormally (on occasion) with shared memory errors which has led to the discovery that the remote sender channel is not restarting.
Is shared memory utilization enhanced in later versions of MQ? |
|
| Back to top |
|
|
| mrlinux |
| Posted: Fri Apr 05, 2002 9:46 am Post subject: |
|
|
Grand Master
Joined: 14 Feb 2002
Posts: 1261
Location: Detroit,MI USA
|
Yes and no, One of the big shared memeory issue that is resolved is that the
log file is no longer mapped into shared memory. Have you tried bumping up ther kernel parms related to shared memory, the ones in the quick beginnings is for the smallest queue manager, you need to be above that.
_________________
Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
[ This Message was edited by: mrlinux on 2002-04-05 09:47 ] |
|
| Back to top |
|
|
| StefanSievert |
| Posted: Fri Apr 05, 2002 10:16 am Post subject: |
|
|
Partisan
Joined: 28 Oct 2001
Posts: 333
Location: San Francisco
|
| Quote: |
On 2002-04-05 09:22, tso0rxp wrote:
Don't know our CSD but the last level of patches applied was late 2001. I am planning on an upgrade mid-year to 5.2 but my management is pressing me for a reason this does not work correctly today. My queue manager is also ending abnormally (on occasion) with shared memory errors which has led to the discovery that the remote sender channel is not restarting.
|
Version 5.0 has a service end date of 31JAN2001, so Jeff's advice to upgrade because of great improvements (channel handling, semaphores, performance!) gets another flavour to it!
There is a new channel attribute (introduced in 5.1 I think) called HBINT, which will allow your channels on both ends to realize if the partner is gone even when no messages are flowing across the channel.
You might also want to search this forum for 'KeepAlive', a TCP/IP stack setting that applies to TCP receiver programs on a listen call.
Finally, there is an article available that talks about how to increase your channel availability. Please check out http://www-4.ibm.com/software/ts/mqseries/support/tandts/keepaliv.html
Hope that helps,
Stefan
_________________
Stefan Sievert
IBM Certified * WebSphere MQ |
|
| Back to top |
|
|
| tso0rxp |
| Posted: Fri Apr 05, 2002 11:33 am Post subject: |
|
|
Voyager
Joined: 07 Jan 2002
Posts: 85
|
HBINT (which is also available in 5.0) was the trick. I set it to 30 seconds - it was at the default of 300 seconds. The problem I had was timing. When the queue manager came down (because of shared memory) our automation scripts kicked in too swiftly to restart the queue managers. Now, on to the shared memory issues. I'm having my Unix team check the kernel parms for shmem.
Thanks to Jeff and Stephan for your help.
Regards. |
|
| Back to top |
|
|
| tso0rxp |
| Posted: Fri Apr 05, 2002 11:43 am Post subject: |
|
|
Voyager
Joined: 07 Jan 2002
Posts: 85
|
Jeff, here are the shmem kernel parms we have. How do I know what appropriate values are? This particular qmgr handles all of our ERP volume to legacy systems - which is in the neighborhood of 100K messages/day.
* These items are to support mqseries
set shmsys:shminfo_shmmax=90000000
set shmsys:shminfo_shmmin=1
set shmsys:shminfo_shmem = 1
set shmsys:shminfo_shmmni=1024
set shmsys:shminfo_shmseg=1024
set msgsys:msginfo_msgmni=50
set msgsys:msginfo_msgmap=1026
set msgsys:msginfo_msgtql=40
set msgsys:msginfo_msgseg=1024
set semsys:seminfo_semopm = 100
set semsys:seminfo_semaem = 16384
set semsys:seminfo_semvmx = 32767
set semsys:seminfo_semmni = 1024
set semsys:seminfo_semmap = 4098
set semsys:seminfo_semmns = 16384
set semsys:seminfo_semmsl = 100
set semsys:seminfo_semmnu = 2048
set semsys:seminfo_semume = 256
set semsys:seminfo_sema = 1
|
|
| Back to top |
|
|
|
|
