cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 27249] - disposed ComponentLocator exception (when sitemap has timestamp in the future?)
Date Tue, 25 May 2004 12:58:36 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=27249>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=27249

disposed ComponentLocator exception (when sitemap has timestamp in the future?)

pier@betaversion.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|Major                       |Critical



------- Additional Comments From pier@betaversion.org  2004-05-25 12:58 -------
I confirm this on my side. The weird exceptions have gone.

Now, I simply suppose that a modification timestamp in the future triggers continuous reloads
of the 
subsitemaps, so, I believe that this bug hides something slightly more serious in the release/dispose

cycle of the Excalibur pool implementation.

For sure I've already found a bug that throws a ConcurrentModificationException in the sitemap.
See the 
attached patch which should solve the problem in the immediate.

In no whatsoever case the patch is a "FINAL" fix for the problem. What I think happens is
that either the 
released/disposed component is returned by lookup calls while it's being released/disposed.
Therefore 
the order of the disallocation from the pool is wrong (first the component is disposed, and
THEN it is 
removed from the pool).

Someone with Excalibur experience should seriously look into this one.

Mime
View raw message