| Author |
Message
|
| PeterPotkay |
 Posted: Thu Dec 20, 2007 5:15 pm Post subject: |
 |
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
| BBM wrote: |
....so we are currently doing preemptive reboots....
|
Vitor, you're slipping! 
| BBM wrote: |
Your comment may well prove to be correct we have a fair number of clients connecting to us and some may be using incorrect queue names potentially exposing the bug. I wonder if there is a way to trap API return codes to clients.
|
Just turn on local events at the QM level. That will produce events showing you the bad q names, which may be enough for you to hunt down the culprit based on the times and/or names.
| BBM wrote: |
Just out interest what is the handle count for DLLHOST on your systems?
|
I'll check tomorrow. We are still at version 2004 for the MQS Agent though.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Fri Dec 21, 2007 10:44 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
| PeterPotkay wrote: |
| BBM wrote: |
Just out interest what is the handle count for DLLHOST on your systems?
|
I'll check tomorrow. We are still at version 2004 for the MQS Agent though. |
Whoa. 97,700. Its going up and down by about 100 as I'm watching it. The server has been up for 20 days since it was last rebooted for MSFT Security patches.
I think I got the same problem even at the 2004 version of Biztalk. But Local Events is not (yet) reporting any bad q names. I just turned that on.
What is your PMR #? Please post any new info you find.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Dec 28, 2007 9:50 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| PeterPotkay wrote: |
| BBM wrote: |
....so we are currently doing preemptive reboots....
|
Vitor, you're slipping!
|
I take one tiny little Xmas holiday....... 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| JasonE |
| Posted: Wed Jan 02, 2008 2:07 am Post subject: |
|
|
Grand Master
Joined: 03 Nov 2003
Posts: 1220
Location: Hursley
|
For reference, the handle leak fixed in the COM+ code is IC54142, and occurs whenever an internal worker thread is spawned. Its mostly relevant when these threads are spawned continually (ie the failure to connect case) but will occur over time on normal COM+ applications - Note worker threads are reused generally as long as they are not idle for longer than 30 seconds...
Peter - if you have the same problem, can you see what type of handles are being reported as leaked (eg. Handle from sysinternals.com). If you are brave (or can do this on a test system), you could try debugdiag in handle leak mode (search the web for it) |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Jan 02, 2008 9:28 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
| JasonE wrote: |
| Peter - if you have the same problem, can you see what type of handles are being reported as leaked (eg. Handle from sysinternals.com). |
SysInternal's Process Explorer shows the majority of these handles to be of the the type "Thread".
Thanks for the IC54142 pointer. Waiting till 6.0.2.4 is too long, so we'll open up a PMR to get the fix built for 6.0.2.1.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| BBM |
| Posted: Tue Mar 04, 2008 4:00 am Post subject: |
|
|
Master
Joined: 10 Nov 2005
Posts: 217
Location: London, UK
|
Hi,
Just thought I'd add an update:
We have installed 6.0.2.3 and up until now have successfully tested the fix included in it.
Last night during some testing (25msg/sec) we observed the handle count increase to 85000. This we consider abnormal, the only cause that we can attribute it to is many many queue full events (2053) that Biztalk had reported in the event log.
I have reopened our PMR (05712) and reported it to the IBM developer we were liaising with.
It;s worrying that something as inoccuous as a queue full event could cause a handle leak.
Thanks
BBM |
|
| Back to top |
|
|
|
|
