| Author |
Message
|
| somasundar |
 Posted: Wed Nov 12, 2008 1:49 am Post subject: CAN MEMORY LEAK HAPPENS IN A EXECUTION GROUP |
 |
|
Newbie
Joined: 12 Nov 2008
Posts: 1
|
IF a memory leak happens in a execution group and can a message be backed out for the flow which is causing the memory leak and what may
be the resolution for this |
|
| Back to top |
|
 |
| Vitor |
| Posted: Wed Nov 12, 2008 1:53 am Post subject: Re: CAN MEMORY LEAK HAPPENS IN A EXECUTION GROUP |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| somasundar wrote: |
| IF a memory leak happens in a execution group and can a message be backed out for the flow which is causing the memory leak |
The memory leak is unlikely to affect message processing, so it will backout or be processed as normal.
| somasundar wrote: |
| what may be the resolution for this |
A PMR with IBM. The software is theirs and it shouldn't leak under any circumstances.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Nov 12, 2008 3:16 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
It can happen, eg. with WMB 6.1, IBM now require AIX ML5 to fix a memory leak.
But the effect is likely to be more generalised on the WMB JVM. |
|
| Back to top |
|
|
| joebuckeye |
| Posted: Wed Nov 12, 2008 6:21 am Post subject: |
|
|
Partisan
Joined: 24 Aug 2007
Posts: 365
Location: Columbus, OH
|
A memory leak is not an error in itself and will not result in a message being backed out. A memory leak can lead to an out of memory condition though and that can cause an execution group to run out of memory and to restart. After the execution group has restarted is when we see the message in the log stating that the message has been backed out.
But the flow that runs out of memory (ie requested more memory than was available) is not necessarily the one that has the memory issue. It was just the one that happened to make the memory request that ran the memory out.
| Quote: |
| A PMR with IBM. The software is theirs and it shouldn't leak under any circumstances. |
User-written Java code in a Java Compute node is out of IBM's control however and it can definately cause memory issues. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Nov 12, 2008 7:35 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| joebuckeye wrote: |
| User-written Java code in a Java Compute node is out of IBM's control however and it can definately cause memory issues. |
Point taken, but that should just run the JVM out of memory.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Nov 12, 2008 7:39 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Vitor wrote: |
| joebuckeye wrote: |
| User-written Java code in a Java Compute node is out of IBM's control however and it can definately cause memory issues. |
Point taken, but that should just run the JVM out of memory. |
Which can crash the EG. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Nov 12, 2008 7:44 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjeff wrote: |
| Vitor wrote: |
| joebuckeye wrote: |
| User-written Java code in a Java Compute node is out of IBM's control however and it can definately cause memory issues. |
Point taken, but that should just run the JVM out of memory. |
Which can crash the EG. |
Why do I get involved in Java problems? Why? I should just learn!
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| joebuckeye |
| Posted: Wed Nov 12, 2008 9:19 am Post subject: |
|
|
Partisan
Joined: 24 Aug 2007
Posts: 365
Location: Columbus, OH
|
| mqjeff wrote: |
| Vitor wrote: |
| joebuckeye wrote: |
| User-written Java code in a Java Compute node is out of IBM's control however and it can definately cause memory issues. |
Point taken, but that should just run the JVM out of memory. |
Which can crash the EG. |
We have seen different behavior on the EG crash depending on which component of the EG runs out of memory.
If the JVM runs out of memory we get multiple heapdump and javacore files and if the the memory problem is outside the JVM we get one core file, in whatever directory the broker thinks is it's home directory at the moment.
Cleaning up the Java code seems to have taken care of the JVM related memory errors and upgrading the WTX node seems to have fixed our other memory issues. |
|
| Back to top |
|
|
|
|
