• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Javamonitor help
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Javamonitor help


  • Subject: Re: Javamonitor help
  • From: Ken Anderson <email@hidden>
  • Date: Tue, 27 Feb 2007 15:11:39 -0500

James,

If you ever get that exception, it means you have a problem with locking your editing contexts. Do you use contexts you create yourself, not just the default context on the session? If so, ANY access to the context or the EOs in it should be wrapped in a try- finally block and the ec should be locked and unlocked.

Ken

On Feb 27, 2007, at 2:55 PM, James Cicenia wrote:

I had to step out...

Anyway..

I can't impress that these are really simple apps, which is really perplexing. They only read data, there is no messaging, nothing...
My session class is very simple too.. I don't even track users.


It seems like at night they just don't terminate.. it used to be the most heavily used app that would hang..

I saw this in the log of one of the instances:

[2007-02-27 03:53:39 CST] <Finalizer> java.lang.IllegalStateException: Illegal Lock usage: unlocking thread not owner.
at com.webobjects.foundation.NSRecursiveLock.unlock (NSRecursiveLock.java:207)
at com.webobjects.eocontrol.EOEditingContext.unlock (EOEditingContext.java:4720)
at com.webobjects.eocontrol.EOEditingContext._dispose (EOEditingContext.java:1158)
at com.webobjects.eocontrol.EOEditingContext.finalize (EOEditingContext.java:1178)
at java.lang.ref.Finalizer.invokeFinalizeMethod(Native Method)
at java.lang.ref.Finalizer.runFinalizer(Finalizer.java:83)
at java.lang.ref.Finalizer.access$100(Finalizer.java:14)
at java.lang.ref.Finalizer$FinalizerThread.run (Finalizer.java:160)


However, this was after the restart .. .it was in instance number 1. That one is set to restart at 1:00 am

However, my log files show that instance number 2, never rolled over, so I assume it was the one that froze. Yet it still is serving up today.

Very confused.

James



On Feb 27, 2007, at 12:29 PM, Guido Neitzer wrote:

On 27.02.2007, at 10:57, Chuck Hill wrote:

Are you sure the apps shut down correctly? I have seen this happen when the apps hang after being told to shut down. Usually this means there is a deadlocked session or a thread waiting to check out an already terminated session.

We have seen this behaviour when we had deadlocks in the apps due to the use of OpenJMS (ERChangeNotification). The deadlocks happened in the OpenJMS code when this was under heavy message load and were really hard to track down.


cug
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40jimijon.com


This email sent to email@hidden

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40anderhome.com


This email sent to email@hidden

_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: This email sent to email@hidden
References: 
 >Javamonitor help (From: James Cicenia <email@hidden>)
 >Re: Javamonitor help (From: Chuck Hill <email@hidden>)
 >Re: Javamonitor help (From: James Cicenia <email@hidden>)
 >Re: Javamonitor help (From: Chuck Hill <email@hidden>)
 >Re: Javamonitor help (From: Guido Neitzer <email@hidden>)
 >Re: Javamonitor help (From: James Cicenia <email@hidden>)

  • Prev by Date: Re: Javamonitor help
  • Next by Date: Re: Large deployment advice
  • Previous by thread: Re: Javamonitor help
  • Next by thread: Large deployment advice
  • Index(es):
    • Date
    • Thread