• 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: Instance won't shutdown with ERJGroupsSynchronizer
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Instance won't shutdown with ERJGroupsSynchronizer


  • Subject: Re: Instance won't shutdown with ERJGroupsSynchronizer
  • From: René Bock <email@hidden>
  • Date: Wed, 13 Jul 2016 08:03:36 +0000
  • Thread-topic: Instance won't shutdown with ERJGroupsSynchronizer

Hello,

I know that the ERXShutdownHook has been added  in order to stop the ERJGroupsSynchronizer correctly.  May be it's worth upgrading at least to Wonder 6 ;-)



Am 13.07.2016 um 09:52 schrieb Paul Hoadley <email@hidden>:

Hi Ted,

Excavating this from the archives:

On 1 Dec 2013, at 8:28 AM, Ted Archibald <email@hidden> wrote:

I've been having a bug where an instance won't shutdown (caveat: I haven't updated wonder in 2 years for fear of breaking stuff...)

The stack trace points to an error in ERXObjectStoreCoordinatorSynchronizer$ProcessChangesQueue.stop "Attempted to stop the ProcessChangesQueue when it wasn't already running".  I don't really care about that error, I just want the instance to shut down, but this stops the normal shutdown process.

Any ideas?

…

Caused by: java.lang.IllegalStateException: Attempted to stop the ProcessChangesQueue when it wasn't already running
        at er.extensions.eof.ERXObjectStoreCoordinatorSynchronizer$ProcessChangesQueue.stop(ERXObjectStoreCoordinatorSynchronizer.java:618)
        at er.extensions.eof.ERXObjectStoreCoordinatorSynchronizer.stopRemoteSynchronizer(ERXObjectStoreCoordinatorSynchronizer.java:132)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at com.webobjects.foundation.NSSelector._safeInvokeMethod(NSSelector.java:122)
        at com.webobjects.foundation.NSNotificationCenter$_Entry.invokeMethod(NSNotificationCenter.java:588)
        at com.webobjects.foundation.NSNotificationCenter.postNotification(NSNotificationCenter.java:532)
        at com.webobjects.foundation.NSNotificationCenter.postNotification(NSNotificationCenter.java:546)
        at er.extensions.appserver.ERXApplication.terminate(ERXApplication.java:2733)
        at com.webobjects.appserver.WOApplication._terminateFromMonitor(WOApplication.java:3607)
        at com.webobjects.appserver.WOAdminAction.instanceRequestAction(WOAdminAction.java:96)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at com.webobjects.appserver.WODirectAction.performActionNamed(WODirectAction.java:144)
        at com.webobjects.appserver._private.WOActionRequestHandler._handleRequest(WOActionRequestHandler.java:259)

I’ve just seen this as well, though I can’t reliably reproduce it. In any case, modulo some line number changes, this is the code:

public void stop() {
if (_queueThread != null && _queueThread.isAlive()) {
_running = false;
_queueThread.interrupt();
}
else {
throw new IllegalStateException("Attempted to stop the " + getClass().getSimpleName() + " when it wasn't already running");
}
}

Unfortunately the original author is long gone, but I’m not seeing the rationale for throwing an exception here. This is being called when ERXApplication.ApplicationWillTerminateNotification is posted. If _queueThread is null or not alive, couldn’t we just do nothing and log it? There’s nothing catching this exception, and it goes on to prevent termination, as Ted notes. Does anyone have any thoughts on this?


-- 
Paul Hoadley
http://logicsquad.net/



_______________________________________________
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

Mit freundlichen Grüßen 

René Bock

--
Telefon: +49 69 650096 18

salient GmbH, Lindleystraße 12, 60314 Frankfurt
Telefon Zentrale: 069 / 65 00 96 - 0  |  www.salient-doremus.de

 _______________________________________________
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

  • Follow-Ups:
    • Re: Instance won't shutdown with ERJGroupsSynchronizer
      • From: Paul Hoadley <email@hidden>
References: 
 >Re: Instance won't shutdown with ERJGroupsSynchronizer (From: Paul Hoadley <email@hidden>)

  • Prev by Date: Re: Instance won't shutdown with ERJGroupsSynchronizer
  • Next by Date: Re: Instance won't shutdown with ERJGroupsSynchronizer
  • Previous by thread: Re: Instance won't shutdown with ERJGroupsSynchronizer
  • Next by thread: Re: Instance won't shutdown with ERJGroupsSynchronizer
  • Index(es):
    • Date
    • Thread