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 somethin
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 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
>>>
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 r
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 m
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 a
ned within 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 du
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 you have unsynchronize
> 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:
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 th
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 infinite
> 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...
Unlikel
> 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&#x
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 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 this
> 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 k
> 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 t
Hi,
we have recently had some hangups of tomcat (5.5.20 on 1.6.05 on linux
2.6.18). The tomcats just stoped replying (all connections timeouted),
but the strange thing was, that
we were unable to create a thread dump (kill -QUIT pid was just
ignored by the jvm).
The machines were idling, no high c
18 matches
Mail list logo
