| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| MQ Memory Leaks? |
« View previous topic :: View next topic » |
| Author |
Message
|
| aRouleau |
 Posted: Wed Apr 16, 2014 6:29 am Post subject: MQ Memory Leaks? |
 |
|
Newbie
Joined: 16 Apr 2014
Posts: 1
|
I created a .Net application to test the health of our Queues. Application was written using C#, and connects to queue manager, sets request and reply queue, then sends and receives a message. This app loops continuously throughout the day, and sleeps 5 minutes between each iteration. Initially I was experiencing a large memory leak after each loop. After introducing a method to clear and close all connections, no more memory leaks.
| Code: |
try
{
this.reqQueue.ClearErrorCodes();
this.reqQueue.Close();
this.repQueue.ClearErrorCodes();
this.repQueue.Close();
this.queueManager.ClearErrorCodes();
this.queueManager.Disconnect();
this.queueManager.Close();
this.mqGmessage.ClearMessage();
this.mqGmessage.ClearErrorCodes();
this.mqPmessage.ClearMessage();
this.mqPmessage.ClearErrorCodes();
} |
Hope this helps answer future questions!! |
|
| Back to top |
|
 |
| RogerLacroix |
| Posted: Wed Apr 16, 2014 12:13 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
Programmer's rule # 53: If you connect it, then disconnect from it when you are done.
Programmer's rule # 54: If you open it, then close it when you are done.
Don't ever assume someone/something will cleanup for you.
The correct code is:
| Code: |
try
{
this.reqQueue.Close();
this.repQueue.Close();
this.queueManager.Disconnect();
} |
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| PaulClarke |
| Posted: Wed Apr 16, 2014 10:33 pm Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
I won't purport to understand the latest version of the .NET MQ classes.
However Roger, your post seems a little contradictory to me, you say:
| Quote: |
| Don't ever assume someone/something will cleanup for you. |
and yet you seem to be assuming more than aRouleau by not issuing calls to ClearErrorCodes() etc.
Generally speaking MQ will close all open queues when you disconnect. In my code I rarely explicitly close a queue, if you have a large number of open queues and you are running over a client then closing each individually could take a noticeable amount of time since each close() is a round trip to the server. So, I think there are times when it is reasonable to assume a certain amount of clean-up by the system.
However, as I say, I'm not an expert on the .NET classes so it may be necessary in that environment, although, to be honest, that would surprise me.
Cheers,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Thu Apr 17, 2014 8:26 am Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
| PaulClarke wrote: |
| and yet you seem to be assuming more than aRouleau by not issuing calls to ClearErrorCodes() etc. |
The error code object just holds the last error code and nothing more. So, cleaning it does not buy you anything.
.NET VMs and JVMs do not look for lost/forgotten (unreferenced) objects and then take action on them. Note: A connection pool manager is different and they generally will keep track of connection objects and close them if they are not referenced after a given period of time.
| PaulClarke wrote: |
| Generally speaking MQ will close all open queues when you disconnect. In my code I rarely explicitly close a queue, if you have a large number of open queues and you are running over a client then closing each individually could take a noticeable amount of time since each close() is a round trip to the server. So, I think there are times when it is reasonable to assume a certain amount of clean-up by the system. |
Given that you worked on the internals of MQ, I can't complain about your application code but for all of the code walkthroughs that I have attended, not closing a queue would have not been allowed. You would have been told to fix your code and schedule another code walkthrough meeting. 
After doing this for several decades, there's one important fact that I have learned from code walkthroughs, "in the end, you spend more time developing code and less time fixing bugs" - even with all the code walkthrough meetings!! Performing code walkthroughs is valuable tool for any developer/programmer. The key to a good walkthrough meeting is making sure all attendees have actually reviewed the code BEFORE the meeting. Hence, code walkthroughs need management support, so that reviewers actually have the time to do the review of the code.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Apr 17, 2014 9:36 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
I would say that it is bad form, and most certainly not a best-practice, to omit MQCLOSE (because at MQDISC the system will take care of closing any open objects).
Developers sometimes extrapolate things like this (behavior) to other environments - like not closing files.
I had a rubber mallet in my desk to get the attention of developers, and to nudge them toward best-practice.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| tczielke |
| Posted: Thu Apr 17, 2014 11:35 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
Another application review to consider is the MQ Administrator review of the application flow with an Application Activity Trace (at 7.1 and higher) or an API trace like strmqtrc -t api (a trace formatting tool like the MH06 supportpac is helpful here).
Although not all administrators are programmers, they bring a different perspective to the application flow, and can usually point out operational concerns that the programmer may miss or not be aware of.
We (the MQ administrators) have started to do this type of review of new MQ applications and have found numerous things that have helped improve the code.
FYI - The future release of the MH06 supportpac will provide a user customizeable API summary trace that will help with this endeavor. |
|
| 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
|
|
|
|
