On 01/12/2012, at 4:25 AM, Michael Gargano wrote:
> okay guys,
>
> you were right... it's a deadlock the worst of all possible worlds.
> I've included the trace below for one of the deadlocks. I keep getting two
> deadlocks at the time the app goes down. I can't quite figure out
On 2012-11-30, at 10:25 AM, Michael Gargano wrote:
> okay guys,
>
> you were right... it's a deadlock the worst of all possible worlds.
Actually, they are kind of fun to debug.
WorkerThread68 is the read problem indicator. WorkerThread255 is waiting on
it. WorkerThread68 is waiti
No question. Your app.
On 2012-11-30, at 12:24 PM, Michael Gargano wrote:
> Some more info on this that I just found. This doesn't happen under load
> when concurrent dispatch is disabled. Now is that a bug in wonder or in my
> app.?
>
> -Mike
>
> On Nov 30, 2012, at 1:25 PM, Michael Garg
Some more info on this that I just found. This doesn't happen under load when
concurrent dispatch is disabled. Now is that a bug in wonder or in my app.?
-Mike
On Nov 30, 2012, at 1:25 PM, Michael Gargano wrote:
> okay guys,
>
> you were right... it's a deadlock the worst of all po
okay guys,
you were right... it's a deadlock the worst of all possible worlds.
I've included the trace below for one of the deadlocks. I keep getting two
deadlocks at the time the app goes down. I can't quite figure out why, it
seems like it's always in the same one or two places
Now that is a good thought!
On 2012-11-28, at 3:43 PM, Q wrote:
> If you are doing concurrent dispatch then this might be worth doing even
> after they have been running for a while. It could be that you have a
> deadlock issue and are slowly deadlocking all your worker threads over time
> unt
If you are doing concurrent dispatch then this might be worth doing even after
they have been running for a while. It could be that you have a deadlock issue
and are slowly deadlocking all your worker threads over time until eventually
they all become non-responsive and the app instance is effec
gt; -Mike
>>
>> From: Maik Musall [mailto:m...@selbstdenker.ag]
>> Sent: Wednesday, November 28, 2012 3:31 PM
>> To: Michael Gargano
>> Cc: WebObjects-Dev List (webobjects-dev@lists.apple.com)
>> Subject: Re: production hanging
>>
>> Without knowing enough abou
jects-Dev List (webobjects-dev@lists.apple.com)
> Subject: Re: production hanging
>
> Without knowing enough about your app, here's a wild guess. Add
>
> -XX:MaxPermSize=256m
>
> directly after your -Xmx setting for heap memory.
>
> Maik
>
>
&
ntly I have "-WOAllowsConcurrentRequestHandling YES" set on each
instance. I think that does it, no?
Thanks.
-Mike
-Original Message-
From: Chuck Hill [mailto:ch...@global-village.net]
Sent: Wednesday, November 28, 2012 3:39 PM
To: Michael Gargano
Cc: WebObjects-Dev List (webobjects-dev@lists.apple.com
Le 2012-11-28 à 15:05, Michael Gargano a écrit :
> Hi all,
>
> I’m having an issue in our production environment. I have
> two servers (vm’s w/ windows 2008 r2 64-bit) running two instances each. The
> servers are load balanced by a hardware load balancer that pings the app
; nothing unusual (notice I’m not saying no errors at all J ).
>
> -Mike
>
> From: Maik Musall [mailto:m...@selbstdenker.ag]
> Sent: Wednesday, November 28, 2012 3:31 PM
> To: Michael Gargano
> Cc: WebObjects-Dev List (webobjects-dev@lists.apple.com)
> Subject: Re:
Try running jstack on them when the start not responding:
jstack -F
That will give you a thread dump and may show something.
Have you looked in the logs for OutOfMemory and HeapSpace? It could be running
out of PermGen space
Are you dispatching requests concurrently?
Chuck
On 2012-11-28,
ons no permgen errors,
> nothing unusual (notice I’m not saying no errors at all J ).
>
> -Mike
>
> From: Maik Musall [mailto:m...@selbstdenker.ag]
> Sent: Wednesday, November 28, 2012 3:31 PM
> To: Michael Gargano
> Cc: WebObjects-Dev List (webobjects-dev@lists.apple.
, November 28, 2012 3:31 PM
To: Michael Gargano
Cc: WebObjects-Dev List (webobjects-dev@lists.apple.com)
Subject: Re: production hanging
Without knowing enough about your app, here's a wild guess. Add
-XX:MaxPermSize=256m
directly after your -Xmx setting for heap memory.
Maik
Am 28.1
Without knowing enough about your app, here's a wild guess. Add
-XX:MaxPermSize=256m
directly after your -Xmx setting for heap memory.
Maik
Am 28.11.2012 um 21:05 schrieb Michael Gargano :
> Hi all,
>
> I’m having an issue in our production environment. I have
> two serve
16 matches
Mail list logo
