You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Sylvain Wallez <sy...@apache.org> on 2004/05/26 13:56:01 UTC
[status update] Re: VERY odd exceptions...
Sylvain Wallez wrote:
> Bertrand Delacretaz wrote:
>
>>> touch 12011200 sitemap.xmap
>>>
>>> reproduces the disposed ComponentLocator problem!
>>
>>
>>
>> Definitely reproducible, see new comments in
>> http://issues.apache.org/bugzilla/show_bug.cgi?id=27249
>
>
>
> Spotted the problems, which are actually twofold in the TreeProcessor:
> - sitemap modification date is checked to be before or equal to the
> date when the treeprocessor was built, meaning continuous rebuild if
> the sitemap date is in the future
> - treeprocessor disposal (and hence its component manager) occurs as
> soon as change is detected, even if some other request (either in
> another thread or through a "cocoon:") currently use that
> treeprocessor, leading to the IllegalStateExceptions
>
> The first problem is easy to solve, but the second one is more tricky.
> My current thinking about it is to add a concurrent requests counter
> and disposal flag. When a sitemap change is detected the flag is set
> to true. The treeprocessor will be disposed if the disposal flag is
> true _and_ the concurrent requests counter is zero.
>
> Time to sleep now. I'll see if this still seems to be a good solution
> when waking up and implement it, unless someone else is faster or has
> a better idea ;-)
The fix is nearly ready on my Mac. It required some refactoring of the
TreeProcessor, now split into two classes. First tests seem to run fine,
but I'll be out at a customer this afternoon and will be able to commit
it only tomorrow morning.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
RE: Start 2.1.6, Re: [status update] Re: VERY odd exceptions...
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
> -----Original Message-----
> From: Vadim Gritsenko [mailto:vadim@reverycodes.com]
> Sent: Wednesday, May 26, 2004 2:30 PM
> To: dev@cocoon.apache.org
> Subject: Start 2.1.6, Re: [status update] Re: VERY odd exceptions...
>
> Carsten Ziegeler wrote:
>
> >Great!
> >
> >As our head contains 2.2-dev already, I guess we should
> start thinking
> >about branching for 2.1.6, right?
> >
> >
>
> Yep. Can you create a branch?
>
Sure. The question is: do we want to create the branch now or do we
wait until the svn move?
Carsten
Start 2.1.6, Re: [status update] Re: VERY odd exceptions...
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Carsten Ziegeler wrote:
>Great!
>
>As our head contains 2.2-dev already, I guess we should start thinking
>about branching for 2.1.6, right?
>
>
Yep. Can you create a branch?
Vadim
RE: [status update] Re: VERY odd exceptions...
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Sylvain Wallez wrote:
>
> Carsten Ziegeler wrote:
>
> >Great!
> >
> >As our head contains 2.2-dev already, I guess we should
> start thinking
> >about branching for 2.1.6, right?
> >
> >
>
> Doh! I certainly missed something (was really busy when the
> move to SVN was discussed and skipped that thread). Is the
> "cocoon-2.1" repository holding the 2.2-dev?
Yes.
> If so what's in
> the "cocoon-2.2" repo?
>
Good question :) The cocoon-2.2 repository can be currently seen
as our "sandbox". It has two additional things in it: the try
to move to Fortress and Pier's code for the block system.
Neither of the two should block our development efforts. So,
we simply continue with the "usual" development of Cocoon (2.2.x)
and if some new "big things" like blocks etc. are mature they
will be "merged" into the "usual" development road.
When we finally move to subversion we can clean this up.
Carsten
Re: [status update] Re: VERY odd exceptions...
Posted by Sylvain Wallez <sy...@apache.org>.
Carsten Ziegeler wrote:
>Great!
>
>As our head contains 2.2-dev already, I guess we should start thinking
>about branching for 2.1.6, right?
>
>
Doh! I certainly missed something (was really busy when the move to SVN
was discussed and skipped that thread). Is the "cocoon-2.1" repository
holding the 2.2-dev? If so what's in the "cocoon-2.2" repo?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
RE: [status update] Re: VERY odd exceptions...
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Great!
As our head contains 2.2-dev already, I guess we should start thinking
about branching for 2.1.6, right?
Carsten
> -----Original Message-----
> From: Sylvain Wallez [mailto:sylvain@apache.org]
> Sent: Wednesday, May 26, 2004 1:56 PM
> To: dev@cocoon.apache.org
> Subject: [status update] Re: VERY odd exceptions...
>
> Sylvain Wallez wrote:
>
> > Bertrand Delacretaz wrote:
> >
> >>> touch 12011200 sitemap.xmap
> >>>
> >>> reproduces the disposed ComponentLocator problem!
> >>
> >>
> >>
> >> Definitely reproducible, see new comments in
> >> http://issues.apache.org/bugzilla/show_bug.cgi?id=27249
> >
> >
> >
> > Spotted the problems, which are actually twofold in the
> TreeProcessor:
> > - sitemap modification date is checked to be before or equal to the
> > date when the treeprocessor was built, meaning continuous
> rebuild if
> > the sitemap date is in the future
> > - treeprocessor disposal (and hence its component manager)
> occurs as
> > soon as change is detected, even if some other request (either in
> > another thread or through a "cocoon:") currently use that
> > treeprocessor, leading to the IllegalStateExceptions
> >
> > The first problem is easy to solve, but the second one is
> more tricky.
> > My current thinking about it is to add a concurrent
> requests counter
> > and disposal flag. When a sitemap change is detected the
> flag is set
> > to true. The treeprocessor will be disposed if the disposal flag is
> > true _and_ the concurrent requests counter is zero.
> >
> > Time to sleep now. I'll see if this still seems to be a
> good solution
> > when waking up and implement it, unless someone else is
> faster or has
> > a better idea ;-)
>
>
> The fix is nearly ready on my Mac. It required some
> refactoring of the TreeProcessor, now split into two classes.
> First tests seem to run fine, but I'll be out at a customer
> this afternoon and will be able to commit it only tomorrow morning.
>
> Sylvain
>
> --
> Sylvain Wallez Anyware Technologies
> http://www.apache.org/~sylvain http://www.anyware-tech.com
> { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
>
>