You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by Vinay Srinivasaiah <vs...@spikesource.com> on 2004/07/14 21:21:41 UTC
Re: [jira] Updated: (JS1-405) [FIX] CastorRegistryService
deadlocks when calling changeBase method on early init
Hello,
Thanks for the update.
The early init() method in CastorRegistryService is already synchronized.
As per my understanding, Thread T1 and T2 try to create a object of
CastorRegistryService. Sometimes, there are 2 objects created instead of 1.
Thread T1 waits on obj1.isInit() and T2 has another object obj2 which is
initialized (obj2.isInit() is true), making thread T1 wait on obj1 to
initialize for ever while locking on CastorRegistryService.class, causing the
deadlock.
I tried the patch by Paul which loads all the registry files, which did not
work for me (may be I merged it wrong, and the code has changed a lot), also
this patch might not solve the 2 object creation problem.
If performance is the hitch in putting the fix on turbine, we could reduce
the synchronization block to a smaller part of the code and have a double lock
so that it does not create 2 objects of the same type.
Regards,
Vinay
On Tue, 2004-07-13 at 21:42, jetspeed-dev@jakarta.apache.org wrote:
> The following issue has been updated:
>
> Updater: Jeremy Ford (mailto:jford@apache.org)
> Date: Tue, 13 Jul 2004 9:41 PM
> Comment:
> The last patch is for Turbine. I would like to avoid patching Turbine if possible. What if the early init method was synchronized instead?
> Changes:
> assignee changed from Jetspeed Developer Mailing List
> summary changed from CastorRegistryService deadlocks when calling changeBase method on early init to [FIX] CastorRegistryService deadlocks when calling changeBase method on early init
> description changed from Hi!
>
> I'm running the JPortal tutorial over JetSpeed version v1.4 b4 along with JBoss-
> 3.2.2RC2. I have applied the tutorial-1 and tutorial-2 ant targets to the
> jportal base and deployed it to the JBoss server. When running the server
> (Tomcat 4.1.27) it never finishes initializing the Registry and causes a
> deadlock. The server never finishes initializing so no requests can be
> performed.
>
> The problem seems to be that while doing early initialization of the
> CastorRegistryService it tries to change the base directory that contains
> the .xreg files (and therefore initializing the portlets contained over there)
> before setting the init field to true (setInit(true)). I've detected that as a
> part of that changeBase() process a fragment gets loaded that calls again the
> init() method of the CastorRegistryService (this time called late
> initalization) and since this method does nothing but wait until the service
> itself is initialized so a deadlock appears because the same thread who calls
> the changeBase() method on init(ServletConfig) it also finishes calling init()
> and never being able to call the setInit(true).
>
> Here is the calling stack in reverse order:
>
> Thread.sleep(long) line: not available [native method]
> CastorRegistryService.init() line: 529 <----
> TurbineServices(BaseServiceBroker).getService(String) line: 304
> Registry.getService() line: 101
> Registry.getEntry(String, String) line: 135
> BasePortletEntry.getParentEntry() line: 327
> BasePortletEntry.getClassname() line: 223
> GeneratedMethodAccessor112.invoke(Object, Object[]) line: not available
> DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25
> Method.invoke(Object, Object[]) line: 324
> FieldHandlerImpl.getValue(Object) line: 373
> FieldValidator.validate(Object, ValidationContext) line: 190
> XMLClassDescriptorAdapter(XMLClassDescriptorImpl).validate(Object,
> ValidationContext) line: 885
> FieldValidator(Validator).validate(Object, ValidationContext) line: 122
> FieldValidator.validate(Object, ValidationContext) line: 233
> XMLClassDescriptorAdapter(XMLClassDescriptorImpl).validate(Object,
> ValidationContext) line: 885
> Validator.validate(Object, ValidationContext) line: 122
> UnmarshalHandler.endElement(String) line: 690
> DOMEventProducer.process(Element, DocumentHandler) line: 249
> DOMEventProducer.process(Node, DocumentHandler) line: 182
> DOMEventProducer.processChildren(Node, DocumentHandler) line: 333
> DOMEventProducer.process(Document, DocumentHandler) line: 134
> DOMEventProducer.process(Node, DocumentHandler) line: 170
> DOMEventProducer.start() line: 110
> Unmarshaller.unmarshal(EventProducer) line: 507
> Unmarshaller.unmarshal(Node) line: 591
> CastorRegistryService.loadFragment(String) line: 601
> RegistryWatcher.findFiles(File) line: 249
> RegistryWatcher.changeBase(File) line: 214
> CastorRegistryService.init(ServletConfig) line: 458 <-----
> CastorRegistryService(TurbineBaseService).init(Object) line: 108
> TurbineServices(BaseInitableBroker).initClass(String, Object) line: 149
> TurbineServices(BaseServiceBroker).doInitService(Object, String) line: 224
> TurbineServices(BaseServiceBroker).initServices(Object, boolean) line: 193
> Turbine.init() line: 257
> ....
>
> I have applied the FixPack #20076 that sincrhonizes the watcher but same
> behaviour.
> I have also placed the call to setInit(true) before the changeBase() call and
> it seems to work but I´m getting lots of NullPointerExceptions while getEntry()
> looks for some fragments that are not yet initialized.
>
> Can someone look at this please?
>
> Thanks mates. to Hi!
>
> I'm running the JPortal tutorial over JetSpeed version v1.4 b4 along with JBoss-
> 3.2.2RC2. I have applied the tutorial-1 and tutorial-2 ant targets to the
> jportal base and deployed it to the JBoss server. When running the server
> (Tomcat 4.1.27) it never finishes initializing the Registry and causes a
> deadlock. The server never finishes initializing so no requests can be
> performed.
>
> The problem seems to be that while doing early initialization of the
> CastorRegistryService it tries to change the base directory that contains
> the .xreg files (and therefore initializing the portlets contained over there)
> before setting the init field to true (setInit(true)). I've detected that as a
> part of that changeBase() process a fragment gets loaded that calls again the
> init() method of the CastorRegistryService (this time called late
> initalization) and since this method does nothing but wait until the service
> itself is initialized so a deadlock appears because the same thread who calls
> the changeBase() method on init(ServletConfig) it also finishes calling init()
> and never being able to call the setInit(true).
>
> Here is the calling stack in reverse order:
>
> Thread.sleep(long) line: not available [native method]
> CastorRegistryService.init() line: 529 <----
> TurbineServices(BaseServiceBroker).getService(String) line: 304
> Registry.getService() line: 101
> Registry.getEntry(String, String) line: 135
> BasePortletEntry.getParentEntry() line: 327
> BasePortletEntry.getClassname() line: 223
> GeneratedMethodAccessor112.invoke(Object, Object[]) line: not available
> DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25
> Method.invoke(Object, Object[]) line: 324
> FieldHandlerImpl.getValue(Object) line: 373
> FieldValidator.validate(Object, ValidationContext) line: 190
> XMLClassDescriptorAdapter(XMLClassDescriptorImpl).validate(Object,
> ValidationContext) line: 885
> FieldValidator(Validator).validate(Object, ValidationContext) line: 122
> FieldValidator.validate(Object, ValidationContext) line: 233
> XMLClassDescriptorAdapter(XMLClassDescriptorImpl).validate(Object,
> ValidationContext) line: 885
> Validator.validate(Object, ValidationContext) line: 122
> UnmarshalHandler.endElement(String) line: 690
> DOMEventProducer.process(Element, DocumentHandler) line: 249
> DOMEventProducer.process(Node, DocumentHandler) line: 182
> DOMEventProducer.processChildren(Node, DocumentHandler) line: 333
> DOMEventProducer.process(Document, DocumentHandler) line: 134
> DOMEventProducer.process(Node, DocumentHandler) line: 170
> DOMEventProducer.start() line: 110
> Unmarshaller.unmarshal(EventProducer) line: 507
> Unmarshaller.unmarshal(Node) line: 591
> CastorRegistryService.loadFragment(String) line: 601
> RegistryWatcher.findFiles(File) line: 249
> RegistryWatcher.changeBase(File) line: 214
> CastorRegistryService.init(ServletConfig) line: 458 <-----
> CastorRegistryService(TurbineBaseService).init(Object) line: 108
> TurbineServices(BaseInitableBroker).initClass(String, Object) line: 149
> TurbineServices(BaseServiceBroker).doInitService(Object, String) line: 224
> TurbineServices(BaseServiceBroker).initServices(Object, boolean) line: 193
> Turbine.init() line: 257
> ....
>
> I have applied the FixPack #20076 that sincrhonizes the watcher but same
> behaviour.
> I have also placed the call to setInit(true) before the changeBase() call and
> it seems to work but I´m getting lots of NullPointerExceptions while getEntry()
> looks for some fragments that are not yet initialized.
>
> Can someone look at this please?
>
> Thanks mates.
> environment changed from Operating System: Windows NT/2K
> Platform: PC to Operating System: Windows NT/2K
> Platform: PC
> priority changed to Blocker
> ---------------------------------------------------------------------
> For a full history of the issue, see:
>
> http://issues.apache.org/jira/browse/JS1-405?page=history
>
> ---------------------------------------------------------------------
> View the issue:
> http://issues.apache.org/jira/browse/JS1-405
>
> Here is an overview of the issue:
> ---------------------------------------------------------------------
> Key: JS1-405
> Summary: [FIX] CastorRegistryService deadlocks when calling changeBase method on early init
> Type: Bug
>
> Status: Unassigned
> Priority: Blocker
>
> Project: Jetspeed
> Components:
> Registry
> Versions:
> 1.4b4
>
> Assignee:
> Reporter: Rodrigo
>
> Created: Fri, 31 Oct 2003 2:42 PM
> Updated: Tue, 13 Jul 2004 9:41 PM
> Environment: Operating System: Windows NT/2K
> Platform: PC
>
> Description:
> Hi!
>
> I'm running the JPortal tutorial over JetSpeed version v1.4 b4 along with JBoss-
> 3.2.2RC2. I have applied the tutorial-1 and tutorial-2 ant targets to the
> jportal base and deployed it to the JBoss server. When running the server
> (Tomcat 4.1.27) it never finishes initializing the Registry and causes a
> deadlock. The server never finishes initializing so no requests can be
> performed.
>
> The problem seems to be that while doing early initialization of the
> CastorRegistryService it tries to change the base directory that contains
> the .xreg files (and therefore initializing the portlets contained over there)
> before setting the init field to true (setInit(true)). I've detected that as a
> part of that changeBase() process a fragment gets loaded that calls again the
> init() method of the CastorRegistryService (this time called late
> initalization) and since this method does nothing but wait until the service
> itself is initialized so a deadlock appears because the same thread who calls
> the changeBase() method on init(ServletConfig) it also finishes calling init()
> and never being able to call the setInit(true).
>
> Here is the calling stack in reverse order:
>
> Thread.sleep(long) line: not available [native method]
> CastorRegistryService.init() line: 529 <----
> TurbineServices(BaseServiceBroker).getService(String) line: 304
> Registry.getService() line: 101
> Registry.getEntry(String, String) line: 135
> BasePortletEntry.getParentEntry() line: 327
> BasePortletEntry.getClassname() line: 223
> GeneratedMethodAccessor112.invoke(Object, Object[]) line: not available
> DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25
> Method.invoke(Object, Object[]) line: 324
> FieldHandlerImpl.getValue(Object) line: 373
> FieldValidator.validate(Object, ValidationContext) line: 190
> XMLClassDescriptorAdapter(XMLClassDescriptorImpl).validate(Object,
> ValidationContext) line: 885
> FieldValidator(Validator).validate(Object, ValidationContext) line: 122
> FieldValidator.validate(Object, ValidationContext) line: 233
> XMLClassDescriptorAdapter(XMLClassDescriptorImpl).validate(Object,
> ValidationContext) line: 885
> Validator.validate(Object, ValidationContext) line: 122
> UnmarshalHandler.endElement(String) line: 690
> DOMEventProducer.process(Element, DocumentHandler) line: 249
> DOMEventProducer.process(Node, DocumentHandler) line: 182
> DOMEventProducer.processChildren(Node, DocumentHandler) line: 333
> DOMEventProducer.process(Document, DocumentHandler) line: 134
> DOMEventProducer.process(Node, DocumentHandler) line: 170
> DOMEventProducer.start() line: 110
> Unmarshaller.unmarshal(EventProducer) line: 507
> Unmarshaller.unmarshal(Node) line: 591
> CastorRegistryService.loadFragment(String) line: 601
> RegistryWatcher.findFiles(File) line: 249
> RegistryWatcher.changeBase(File) line: 214
> CastorRegistryService.init(ServletConfig) line: 458 <-----
> CastorRegistryService(TurbineBaseService).init(Object) line: 108
> TurbineServices(BaseInitableBroker).initClass(String, Object) line: 149
> TurbineServices(BaseServiceBroker).doInitService(Object, String) line: 224
> TurbineServices(BaseServiceBroker).initServices(Object, boolean) line: 193
> Turbine.init() line: 257
> ....
>
> I have applied the FixPack #20076 that sincrhonizes the watcher but same
> behaviour.
> I have also placed the call to setInit(true) before the changeBase() call and
> it seems to work but I´m getting lots of NullPointerExceptions while getEntry()
> looks for some fragments that are not yet initialized.
>
> Can someone look at this please?
>
> Thanks mates.
>
>
> ---------------------------------------------------------------------
> JIRA INFORMATION:
> This message is automatically generated by JIRA.
>
> If you think it was sent incorrectly contact one of the administrators:
> http://issues.apache.org/jira/secure/Administrators.jspa
>
> If you want more information on JIRA, or have a bug to report see:
> http://www.atlassian.com/software/jira
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org