Martin Gainty wrote:
so the solution is put all updates/inserts to the arraylist into a synchronized
method?
You must synchronize all read and write methods, because nothing may run
in parallel with a write method, and so read methods must be prevented
from executing if a write method runs
On Fri, Dec 5, 2008 at 9:50 AM, Oliver Schoett
[EMAIL PROTECTED] wrote:
Martin Gainty wrote:
so the solution is put all updates/inserts to the arraylist into a
synchronized method?
You must synchronize all read and write methods, because nothing may run in
parallel with a write method, and
Leon Rosenberg wrote:
On Fri, Dec 5, 2008 at 9:50 AM, Oliver Schoett
[EMAIL PROTECTED] wrote:
Martin Gainty wrote:
so the solution is put all updates/inserts to the arraylist into a
synchronized method?
You must synchronize all read and write methods, because nothing may
On Fri, Dec 5, 2008 at 12:37 PM, Oliver Schoett
[EMAIL PROTECTED] wrote:
Leon Rosenberg wrote:
On Fri, Dec 5, 2008 at 9:50 AM, Oliver Schoett
[EMAIL PROTECTED] wrote:
Martin Gainty wrote:
so the solution is put all updates/inserts to the arraylist into a
synchronized method?
You
Leon Rosenberg wrote:
You should consider using synchronized lists :-) (for example Vector).
Does not help :-) If you do not put sync. brackets around
Check some property (e. g., size());
Do something according to the property value
you lose, because the property may have changed
On Fri, Dec 5, 2008 at 3:45 PM, Oliver Schoett
[EMAIL PROTECTED] wrote:
Leon Rosenberg wrote:
You should consider using synchronized lists :-) (for example Vector).
Does not help :-) If you do not put sync. brackets around
Check some property (e. g., size());
Do something according
Dec 2008 08:47:05 -0600
Subject: RE: jvm cowardly refuses to print a thread dump
From: news [mailto:[EMAIL PROTECTED] On Behalf Of Oliver Schoett
Subject: Re: jvm cowardly refuses to print a thread dump
Very likely you have unsynchronized accesses to the ArrayList
That's irrelevant
this transmission.
From: [EMAIL PROTECTED]
To: users@tomcat.apache.org
Date: Tue, 2 Dec 2008 08:47:05 -0600
Subject: RE: jvm cowardly refuses to print a thread dump
From: news [mailto:[EMAIL PROTECTED] On Behalf Of Oliver Schoett
Subject: Re: jvm cowardly refuses to print a thread dump
Very likely
Leon Rosenberg wrote:
But back to the ArrayList, how high is the probability of having
ArrayList.size() twice in the similar call-tree in one ThreadDump?
Very likely you have unsynchronized accesses to the ArrayList, which
from time to time send one of the threads involved into an
is of a confidential nature
and Sender does not endorse distribution to any party other than intended
recipient. Sender does not necessarily endorse content contained within this
transmission. To: users@tomcat.apache.org From: [EMAIL PROTECTED] Subject:
Re: jvm cowardly refuses to print a thread dump
From: news [mailto:[EMAIL PROTECTED] On Behalf Of Oliver Schoett
Subject: Re: jvm cowardly refuses to print a thread dump
Very likely you have unsynchronized accesses to the ArrayList
That's irrelevant for the size() method, where the entire code consists of this:
public int size
From: Leon Rosenberg [mailto:[EMAIL PROTECTED]
Subject: jvm cowardly refuses to print a thread dump
we were unable to create a thread dump (kill -QUIT pid was just
ignored by the jvm).
That's ugly. Sounds like either the OS failed to deliver the signal, or the
JVM is locked up internally
From: Caldarale, Charles R [mailto:[EMAIL PROTECTED]
That's ugly. Sounds like either the OS failed to deliver the
signal, or the JVM is locked up internally (probably the
latter).
That's rather what I was reckoning. I've had signal delivery fail before if
all the threads were stuck in
its very weird indeed. We had acted proactively on a tomcat which
started to show same symptoms (cpu load going higher (35%) but users
going down (means it replies slower than the other machines and the lb
gives less traffic to it) and after checking the logs, sent the QUIT
signal which worked
Leon Rosenberg schrieb:
We assume that the other tomcats didn't produce any thread dumps
because our trigger happy system admins just sent the kill -9 too soon
after the kill -3, and the jvm was overloaded. Well it's a wild guess,
but i have no better one yet (unless jvm really locked up
From: Leon Rosenberg [mailto:[EMAIL PROTECTED]
Subject: Re: jvm cowardly refuses to print a thread dump
and two in
at java.util.ArrayList.size(ArrayList.java:177)
Just for grins, can you post the full stack trace for those two? (Or e-mail me
the whole thing.) There's nothing unusual
From: Peter Crowther [mailto:[EMAIL PROTECTED]
Subject: RE: jvm cowardly refuses to print a thread dump
Might the code have ended up with all threads stuck in OS
calls? It feels a little unlikely, as I assume the JVM keeps
a couple of threads for itself...
Unlikely that everybody's off
17 matches
Mail list logo
