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
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
Leo Sutic wrote:
Of course, when the sitemap is up for reloading, we can't accept any
new requests (otherwise you get starvation). Perhaps putting a
read-write lock around the treeprocessor would be better and easier?
The sitemap reloading is in a synchronized block, meaning that requests
comi
Carsten Ziegeler wrote:
Yes and I think we already went through this hell as we introduced
the concurrent request counter in Cocoon.java which is now only
enabled if debug logging is enabled.
In our case this counter is used for disposing a sitemap that has
been changed. Now we could argue that thi
Berin Loritsch wrote:
>
> Ugo Cei wrote:
>
> > Sylvain Wallez wrote:
> >
> >> Agree for *variables*. Here, we have a class member, which
> has to be
> >> loaded, then incremented, then stored.
> >>
> >> So as Bertrand, I stay on the safe side and synchronize.
> >
> >
> > Just to be clear, wh
On Wed, 26 May 2004 09:24:50 -0400, Berin Loritsch
<[EMAIL PROTECTED]> wrote:
> The more correct version would be:
>
> public class MyClass {
> private volatile int counter; //atomic
>
> public someMethod() {
> ++counter;
> }
> }
>
> Only longs on up should be actually synchr
Ugo Cei wrote:
Sylvain Wallez wrote:
Agree for *variables*. Here, we have a class member, which has to be
loaded, then incremented, then stored.
So as Bertrand, I stay on the safe side and synchronize.
Just to be clear, what you're suggesting is to do:
public class MyClass {
private int counte
Sylvain Wallez wrote:
Agree for *variables*. Here, we have a class member, which has to be
loaded, then incremented, then stored.
So as Bertrand, I stay on the safe side and synchronize.
Sylvain
I understand the desire for more metrics and instrumenting Cocoon so
that you can get the information
> -Original Message-
> From: Vadim Gritsenko [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, May 26, 2004 2:30 PM
> To: [EMAIL PROTECTED]
> Subject: Start 2.1.6, Re: [status update] Re: VERY odd exceptions...
>
> Carsten Ziegeler wrote:
>
> >Great!
>
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
Joerg Heinicke wrote:
On 26.05.2004 10:56, Ugo Cei wrote:
Sylvain Wallez wrote:
I was just looking in the VM spec if a increment operation on an
integer is atomic or not. My opinion it has to be in the case of
class members as the increment is surrounded by getfield/putfield
instructions.
Acces
atus update] Re: VERY odd exceptions...
>
> Sylvain Wallez wrote:
>
> > Bertrand Delacretaz wrote:
> >
> >>> touch 12011200 sitemap.xmap
> >>>
> >>> reproduces the disposed ComponentLocator problem!
> >>
> >>
>
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 TreeProcess
Ugo Cei wrote:
Sylvain Wallez wrote:
Agree for *variables*. Here, we have a class member, which has to be
loaded, then incremented, then stored.
So as Bertrand, I stay on the safe side and synchronize.
Just to be clear, what you're suggesting is to do:
public class MyClass {
private int counte
Sylvain Wallez wrote:
Agree for *variables*. Here, we have a class member, which has to be
loaded, then incremented, then stored.
So as Bertrand, I stay on the safe side and synchronize.
Just to be clear, what you're suggesting is to do:
public class MyClass {
private int counter;
public some
Ugo Cei wrote:
I don't think it is necessary, and could hurt performance, but before I
try to dig up some other reference, I'd like to know if we're talking
about the same scenario.
OK, turns out my memory is getting worse each day. I was wrong,
incrementing an "int" is most certainly *NOT* an a
Ugo Cei wrote:
Sylvain Wallez wrote:
I was just looking in the VM spec if a increment operation on an
integer is atomic or not. My opinion it has to be in the case of
class members as the increment is surrounded by getfield/putfield
instructions.
Accessing an "int" is atomic. Accessing a "long"
Le 26 mai 04, à 10:56, Ugo Cei a écrit :
..."The Java language specification allows access and storage of
[variables of type double and long] (but not those of other scalar
types) to be non-atomic."...
Hmm..smells too much like something that could be interpreted
differently by different VMs.
Me
On 26.05.2004 10:56, Ugo Cei wrote:
Sylvain Wallez wrote:
I was just looking in the VM spec if a increment operation on an
integer is atomic or not. My opinion it has to be in the case of class
members as the increment is surrounded by getfield/putfield instructions.
Accessing an "int" is atomic
Sylvain Wallez wrote:
I was just looking in the VM spec if a increment operation on an integer
is atomic or not. My opinion it has to be in the case of class members
as the increment is surrounded by getfield/putfield instructions.
Accessing an "int" is atomic. Accessing a "long" is not. This is
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
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
- tree
Ugo Cei wrote:
>
> Carsten Ziegeler wrote:
> > I think we have the second problem in Cocoon since our
> first version
> > :( I always thought about adding a counter for the
> concurrent requests
> > in a tree processor, but always forget about it :( Regarding
> > performance: is this a probl
Carsten Ziegeler wrote:
I think we have the second problem in Cocoon since our first version :(
I always thought about adding a counter for the concurrent requests
in a tree processor, but always forget about it :( Regarding
performance: is this a problem as the counter has to be synchronized?
Whay
Sylvain Wallez wrote:
>
> 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 disp
Antonio Gallardo wrote:
Stefano Mazzocchi dijo:
There is a proposal for the creation of an Excalibur TLP that will be
discussed tomorrow by the ASF board. If that passes, I would expect
things to run a little more smoothly on the community side.
Nothing against Excalibur and other projects try to
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 modifica
Stefano Mazzocchi dijo:
> There is a proposal for the creation of an Excalibur TLP that will be
> discussed tomorrow by the ASF board. If that passes, I would expect
> things to run a little more smoothly on the community side.
Nothing against Excalibur and other projects try to be TLP. Seems to b
On 25.05.2004 13:22, Vadim Gritsenko wrote:
Bertrand's problem related to CVS $Id$ in comments makes me think to
clock synchronisation problems between the CVS server and the Cocoon
server (e.g. modification date moved back in time).
I noticed sometime ago that setting sub-sitemap (not root sitem
Pier Fumagalli wrote:
Now, if my patch works, given that this is not a bug in
our code, how do we go in sticking that into the Excalibur CVS and
re-release now that community of that project has collapsed?
There is a proposal for the creation of an Excalibur TLP that will be
discussed tomorrow b
Pier Fumagalli wrote:
Well, my only problem is that the whole "shabang" is pooled to death at
the moment.
have you tried setting all the pool sizes to zero? I know it's hacky,
but might solve the issue and remove some of the pressure for now while
we look for a more reasonable solution.
--
Stef
On 25 May 2004, at 13:18, Sylvain Wallez wrote:
Pier Fumagalli wrote:
I patched Excalibur, and Bertrand is checking out if my patch solves
also his bug... Now, if my patch works, given that this is not a bug
in our code, how do we go in sticking that into the Excalibur CVS and
re-release now th
On 25 May 2004, at 13:42, Vadim Gritsenko 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
But, as far as I can tell (what's the ac
On 25 May 2004, at 13:40, Berin Loritsch wrote:
Pier Fumagalli wrote:
On 25 May 2004, at 10:05, Bertrand Delacretaz wrote:
Have you noticed, by any chance, a ConcurrentModificationException
somewhere in your tests?
I noticed that the ExcaliburComponentManager doesn't correctly
synchronize on its
Sylvain Wallez wrote:
Pier Fumagalli wrote:
I patched Excalibur, and Bertrand is checking out if my patch solves
also his bug... Now, if my patch works, given that this is not a bug
in our code, how do we go in sticking that into the Excalibur CVS and
re-release now that community of that proje
Pier Fumagalli wrote:
I patched Excalibur, and Bertrand is checking out if my patch solves
also his bug... Now, if my patch works, given that this is not a bug
in our code, how do we go in sticking that into the Excalibur CVS and
re-release now that community of that project has collapsed?
For
Pier Fumagalli wrote:
I patched Excalibur, and Bertrand is checking out if my patch solves
also his bug... Now, if my patch works, given that this is not a bug in
our code, how do we go in sticking that into the Excalibur CVS and
re-release now that community of that project has collapsed?
Stay
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
But, as far as I can tell (what's the acronym for this? ;)), this is not
related (should
Pier Fumagalli wrote:
On 25 May 2004, at 10:05, Bertrand Delacretaz wrote:
Have you noticed, by any chance, a ConcurrentModificationException
somewhere in your tests?
I noticed that the ExcaliburComponentManager doesn't correctly
synchronize on its m_componentHandlers hashmap, and that might be
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
-Bertrand
Le 25 mai 04, à 13:22, Vadim Gritsenko a écrit :
Sylvain Wallez wrote:
...
Bertrand's problem related to CVS $Id$ in comments makes me think to
clock synchronisation problems between the CVS server and the Cocoon
server (e.g. modification date moved back in time).
I noticed sometime ago that set
Gianugo Rabellino wrote:
On May 25, 2004, at 1:30 PM, Pier Fumagalli wrote:
On 25 May 2004, at 11:22, Ugo Cei wrote:
Pier Fumagalli wrote:
I seriously think (I can't see it but can definitely smell it) that
it happens because one of those handlers (somehow) gets recycled,
and it's reused before
On 25 May 2004, at 12:42, Gianugo Rabellino wrote:
On May 25, 2004, at 1:30 PM, Pier Fumagalli wrote:
On 25 May 2004, at 11:22, Ugo Cei wrote:
Pier Fumagalli wrote:
I seriously think (I can't see it but can definitely smell it) that
it happens because one of those handlers (somehow) gets recycled
Sylvain Wallez wrote:
...
Bertrand's problem related to CVS $Id$ in comments makes me think to
clock synchronisation problems between the CVS server and the Cocoon
server (e.g. modification date moved back in time).
I noticed sometime ago that setting sub-sitemap (not root sitemap!)
modificatio
Pier Fumagalli wrote:
(CRAP CRAP CRAP CRAP CRAP)
First, breathe!!! Now, think: Why in hell do you want to destroy Cocoon
servlet on running production site??? I'm referring to line from your
stacktrace:
org.apache.cocoon.servlet.CocoonServlet.destroy(CocoonServlet.java:497)
And to answer you
On May 25, 2004, at 1:30 PM, Pier Fumagalli wrote:
On 25 May 2004, at 11:22, Ugo Cei wrote:
Pier Fumagalli wrote:
I seriously think (I can't see it but can definitely smell it) that
it happens because one of those handlers (somehow) gets recycled,
and it's reused before it's actually fully disp
On 25 May 2004, at 11:22, Ugo Cei wrote:
Pier Fumagalli wrote:
I seriously think (I can't see it but can definitely smell it) that
it happens because one of those handlers (somehow) gets recycled,
and it's reused before it's actually fully disposed...
So, I _seriously_ think that by fixing the
Pier Fumagalli wrote:
I seriously think (I can't see it but can definitely smell it) that it
happens because one of those handlers (somehow) gets recycled, and it's
reused before it's actually fully disposed...
So, I _seriously_ think that by fixing the problem adding the
appropriate synchro
Ok, let's shoot them one by one... The first one I can easily spot is
the ConcurrentModificationException: relevant part of the stacktrace:
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:782)
at java.util.HashMap$KeyIterator.nex
On 25 May 2004, at 10:34, Bertrand Delacretaz wrote:
Le 25 mai 04, à 11:31, Pier Fumagalli a écrit :
...Have you noticed, by any chance, a ConcurrentModificationException
somewhere in your tests?
Not that I remember, but I've attached some logs in bugzilla, you
might want to dig in them.
Nothing
On 25 May 2004, at 10:27, Bertrand Delacretaz wrote:
Le 25 mai 04, à 11:17, Sylvain Wallez a écrit :
...But what you describe here is really weird: there's absolutely no
data related to sitemap or component manager that is persisted to
disk.
Although in bug 27249 I've seen the problem persist aft
On 25 May 2004, at 10:17, Sylvain Wallez wrote:
Pier Fumagalli wrote:
I'm having a bunch of problems with Avalon in production... And I
suppose they're kinda all interconnected.
I get some odd ConcurrentModificationException(s) and
NullPointerException(s) all coming out from the component mana
Le 25 mai 04, à 11:31, Pier Fumagalli a écrit :
...Have you noticed, by any chance, a ConcurrentModificationException
somewhere in your tests?
Not that I remember, but I've attached some logs in bugzilla, you might
want to dig in them.
IIRC, hard restarts didn't help either in this case, the on
On 25 May 2004, at 10:05, Bertrand Delacretaz wrote:
Le 25 mai 04, à 10:49, Pier Fumagalli a écrit :
...Two problems... Definitely, under load, Excalibur fails
disposing/releasing components, and somehow, Cocoon keeps state EVEN
between hard restarts of the JVM...
Anyone ever saw something like
Le 25 mai 04, à 11:17, Sylvain Wallez a écrit :
...But what you describe here is really weird: there's absolutely no
data related to sitemap or component manager that is persisted to
disk.
Although in bug 27249 I've seen the problem persist after restarting
cocoon *and* deleting the Jetty temp d
Pier Fumagalli wrote:
I'm having a bunch of problems with Avalon in production... And I
suppose they're kinda all interconnected.
I get some odd ConcurrentModificationException(s) and
NullPointerException(s) all coming out from the component manager
"release/dispose" methods: I suppose that,
Le 25 mai 04, à 10:49, Pier Fumagalli a écrit :
...Two problems... Definitely, under load, Excalibur fails
disposing/releasing components, and somehow, Cocoon keeps state EVEN
between hard restarts of the JVM...
Anyone ever saw something like this?
Might be related to this very mysterious bug
ht
56 matches
Mail list logo
