thanks for your work.
you patch still looks like a memory management problems.
added full comment in Jira.
=========================
BJ Freeman
Strategic Power Office with Supplier Automation
<http://www.businessesnetwork.com/automation/viewforum.php?f=52>
Specialtymarket.com <http://www.specialtymarket.com/>
Systems Integrator-- Glad to Assist
Chat Y! messenger: bjfr33man
Jacques Le Roux sent the following on 12/17/2010 4:32 AM:
Please see https://issues.apache.org/jira/browse/OFBIZ-4043
Jacques
From: "Jacques Le Roux" <jacques.le.r...@les7arts.com>
From: "Adam Heath" <doo...@brainfood.com>
On 12/10/2010 03:46 PM, Jacques Le Roux wrote:
From: "Jacques Le Roux" <jacques.le.r...@les7arts.com>
From: "Adam Heath" <doo...@brainfood.com>
On 12/10/2010 04:05 AM, Jacques Le Roux wrote:
Hi devs,
FYI, this morning the trunk demo was stale again. It was running but
not
accessible. I then stopped and restarted, same issue. I tried an
"svn
st" no issues there. I reloaded all manually (I have a script for
that)
and it was then OK.
When these issues occur, send QUIT to the java process; it'll give
you a stack dump, and a memory usage summary. Then, use jmap to get a
binary heap dump. Those 2 things will allow for debugging this. Also
keep track of which particular svn version the system is running.
I will try that
Jacques
I have tried to use both (on 3 new trunk threads running amok)
kill -QUIT PID
kill -3 PID
It goes to STDERR, where-ever that is. lsof -p PID will show you
where that is attached, but it might be a pipe.
I was not able to do it in a reasonnable time. I did not find the
STDERR for the sub-processes (blocked java threads reported by top).
Nor for the main process, but for it I had a very very long list of
files... Cetainly a pipe somewhere? Then how to find it? Asking infra?
One thing I'm sure is the problem will are-appear soon anyway...
Thanks
Jacques
