The following comment has been added to this issue:
Author: Vinay Srini
Created: Thu, 8 Jul 2004 1:03 PM
Body:
I was able to reproduce this deadlock consistantly by adding a default constructor to
CastorRegsitryService, with a delay in it.
Also tried to apply the patch provided with the bug, which caused lot of NullPointers
and SAXExceptions.
I found that the deadlock on CastorRegistryService.class was due to 2 instances of the
object CastorRegistryService, created by
org.apache.turbine.services.BaseInitableBroker.getInitableInstance method.
Even though setInit(true) was called in CastorRegistryService before the deadlock
occured, one of the deamon threads (feeddaemon, diskcachedaemon) held lock on
CastorRegistryService.class and was waiting for init==true on the wrong
(uninitialized) object.
If the getInitableInstance object is synchronized, the deadlock would not occur since
there would be only one CastorRegistryService object.
Here is the diff of file i changed in turbine. Any inputs?
Index: src/java/org/apache/turbine/services/BaseInitableBroker.java
===================================================================
RCS file:
/home/cvspublic/jakarta-turbine-2/src/java/org/apache/turbine/services/BaseInitableBroker.java,v
retrieving revision 1.2
diff -r1.2 BaseInitableBroker.java
248c248
< protected Initable getInitableInstance( String className )
---
> protected synchronized Initable getInitableInstance( String className )
---------------------------------------------------------------------
View this comment:
http://issues.apache.org/jira/browse/JS1-405?page=comments#action_36572
---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/JS1-405
Here is an overview of the issue:
---------------------------------------------------------------------
Key: JS1-405
Summary: CastorRegistryService deadlocks when calling changeBase method on early
init
Type: Bug
Status: Open
Project: Jetspeed
Components:
Registry
Versions:
1.4b4
Assignee: Jetspeed Developer Mailing List
Reporter: Rodrigo
Created: Fri, 31 Oct 2003 2:42 PM
Updated: Thu, 8 Jul 2004 1:03 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
