You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Carsten Ziegeler <cz...@s-und-n.de> on 2002/08/07 13:02:07 UTC
Is Cocoon unstable?
Looking at the last great threads, I noticed many messages
complaining that Cocoon is not stable, even from some
developers.
Is this really true? Is Cocoon not stable (and I mean
2.0.3 of course) ?
Our experience with several productive installations currently
proves the opposite. It's stable and did never crash or
had to be restarted since months. I must confess that we
are using a version between 2.0 and 2.0.1.
And if 2.0.3 is really that unstable, we should immediately
fix this and find out what has changed since 2.0.1 which
causes this!
So, constructive reports about unstable conditions are welcome.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Is Cocoon unstable?
Posted by Uli Mayring <ul...@denic.de>.
On Wed, 7 Aug 2002, Justin Fagnani-Bell wrote:
> I have a site running on Cocoon 2.0.1 that needs restarting every couple
> of days or it gets real slow. I seems like a memory leak, but the log
> files show plenty of memory available to the JVM.
If the site gets slow, then it may be something else than a memory leak,
for example excessive context changes between threads. These things are
very hard to track down. For example we recently had a similar effect and
in the end it turned out to be a method from the InetAddress class being
called repeatedly. What we didn't know, but found out then was, that every
time this method was called, it internally made a DNS lookup. This didn't
show up in testing, because we only had a couple of clients firing and
their DNS info was of course quickly cached away. In production with
hundreds of users the system got slower and slower and slower ...
eventually it would probably have run out of memory, but it became slower
at a faster rate than it consumed memory - so we would have never seen an
out of memory error.
Not very helpful, I know, but maybe entertaining. I can only recommend you
build up a testsystem that is as identical to the production system as
possible and the write a testing software that is as identical to the
real world clients as possible. Try to reproduce and compare thread dumps
between slow and fast operation. Insert debug logging statements to find
out in which part of the software the time is lost.
> done rewriting though, I'll need to revisit this. Avalon and CoP are new
> to me and I wonder if I'm missing something in a recycle() somewhere,
Avalon / Phoenix is probably not the culprit, we have stress-tested it
extensively. Maybe the ThreadManager is less than great, but I have no
proof yet. Sometimes Phoenix crashes, but it goes out with a bang, not
with a whimper ;-)
The biggest problem performance-wise is Xalan.
You can always use a professional tool like a profiler or a debugger, of
course. Personally, I prefer the "old way", because I think I learn more
that way.
Ulrich
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Is Cocoon unstable?
Posted by Justin Fagnani-Bell <ju...@paraliansoftware.com>.
I have a site running on Cocoon 2.0.1 that needs restarting every couple
of days or it gets real slow. I seems like a memory leak, but the log
files show plenty of memory available to the JVM. This doesn't even get
that much traffic. If I don't restart Tomcat, eventually the site will
crash.
I figure it could easily be my code (custom generators and actions), but
I can't find anything. I'm currently rewriting the entire system with
optimizations based on my experience, so I haven't spent much time
trying to figure out what the problem is on the old codebase. Once I'm
done rewriting though, I'll need to revisit this. Avalon and CoP are new
to me and I wonder if I'm missing something in a recycle() somewhere,
but I've checked and can't find anything. I often times see (in the
logs) components getting initialized many times, even though I though I
thought I set up cocoon.xconf to only create one instance. Probably my
fault
My biggest question is: How should I test a Cocoon deployment for memory
leaks? I've never used jdb, and only used a comercial java profiler
once. What else could be causing slow-downs if the JVM free memory seems
ok? How do other people test their Cocoon apps?
Justin
On Wednesday, August 7, 2002, at 10:39 AM, Michael Wechner wrote:
> I have a friend (Thomas Werschlein: werschlein@interlace.ch) and he is
> using 2.0.3 since Sunday
> in production for a swiss magazine, and he told me just today that he
> has to reboot the system
> approx every hour, because there seems to be a memory leak.
>
> He probably better speaks for himself. But just to let you know,
>
> Michael
>
> Carsten Ziegeler wrote:
>
>> Looking at the last great threads, I noticed many messages
>> complaining that Cocoon is not stable, even from some
>> developers.
>>
>> Is this really true? Is Cocoon not stable (and I mean
>> 2.0.3 of course) ?
>>
>> Our experience with several productive installations currently
>> proves the opposite. It's stable and did never crash or
>> had to be restarted since months. I must confess that we
>> are using a version between 2.0 and 2.0.1.
>>
>> And if 2.0.3 is really that unstable, we should immediately
>> fix this and find out what has changed since 2.0.1 which causes this!
>>
>> So, constructive reports about unstable conditions are welcome.
>>
>> Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Is Cocoon unstable?
Posted by Michael Wechner <mi...@wyona.org>.
I have a friend (Thomas Werschlein: werschlein@interlace.ch) and he is
using 2.0.3 since Sunday
in production for a swiss magazine, and he told me just today that he
has to reboot the system
approx every hour, because there seems to be a memory leak.
He probably better speaks for himself. But just to let you know,
Michael
Carsten Ziegeler wrote:
>Looking at the last great threads, I noticed many messages
>complaining that Cocoon is not stable, even from some
>developers.
>
>Is this really true? Is Cocoon not stable (and I mean
>2.0.3 of course) ?
>
>Our experience with several productive installations currently
>proves the opposite. It's stable and did never crash or
>had to be restarted since months. I must confess that we
>are using a version between 2.0 and 2.0.1.
>
>And if 2.0.3 is really that unstable, we should immediately
>fix this and find out what has changed since 2.0.1 which
>causes this!
>
>So, constructive reports about unstable conditions are welcome.
>
>Carsten
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Is Cocoon unstable?
Posted by Torsten Curdt <tc...@dff.st>.
On Wednesday 07 August 2002 13:02, Carsten Ziegeler wrote:
> Looking at the last great threads, I noticed many messages
> complaining that Cocoon is not stable, even from some
> developers.
>
> Is this really true? Is Cocoon not stable (and I mean
> 2.0.3 of course) ?
Well, we are successfully using even HEAD (but refused to update now for a
long time because of the current condition of HEAD)
> So, constructive reports about unstable conditions are welcome.
I guess what people mean by "unstable" is more a feeling and heavily
influenced by:
1) error reporting
you quite certain will never get the exact reason for the error until you
search the log files. even people that are now working with cocoon for months
sometimes do not find the exact failure from the log file. (not to talk about
the message that is presented in the browser) This has been improved a lot
but still gives a messy feeling.
2) external libraries
cocoon uses dozens of external libraries. but if they fail or have bugs it's
also cocoon that has bugs - at least from a user perspective!
3) missing testcases
we do releases without beeing able to prove we keep the same behaviour. I
always keept my fingers crossed for days when we did a cocoon upgrade...
4) changes
I have to admit avalon related changes come to my mind...
- Loggable vs. LogEnabled
- moving cocoon components to avalon
- ECM -> Fortress (sooner or later)
all made sense - but people had to change (more or less) their code
And there are more big (useful) changes to come... blocks etc.
my 2 cents
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Is Cocoon unstable?
Posted by "Enke, Michael" <mi...@wincor-nixdorf.com>.
I use 2.0.2 and had never the impression that it is unstable.
Michael
Carsten Ziegeler wrote:
>
> Looking at the last great threads, I noticed many messages
> complaining that Cocoon is not stable, even from some
> developers.
>
> Is this really true? Is Cocoon not stable (and I mean
> 2.0.3 of course) ?
>
> Our experience with several productive installations currently
> proves the opposite. It's stable and did never crash or
> had to be restarted since months. I must confess that we
> are using a version between 2.0 and 2.0.1.
>
> And if 2.0.3 is really that unstable, we should immediately
> fix this and find out what has changed since 2.0.1 which
> causes this!
>
> So, constructive reports about unstable conditions are welcome.
>
> Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Is Cocoon unstable?
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Jens Lorenz wrote:
>
> Carsten,
>
> ... a last word ...
>
> > > > I understand your concerns and know that this is a PITA, but it has
> > > > nothing to do with an unstable 2.0.x series - and that's what I'm
> > > > currently focusing on.
> > >
> > > Well, updating an application from one 2.0.x to the next version
> > > took days as well. We've had this from 2.0 to 2.0.2 and from 2.0.1
> > > to 2.0.2.
> > > And the errors were more subtle than just a missing method during
> > > compilation. Can't remember a particular one though.
> > >
> > Hmm, that's interesting, because the 2.0.x series should be compatible
> > and therefore compile problems should not occur.
>
>
> A said, _not_ compiler errors. But everything compiles smoothly but it
> does not work anyway, because the configuration of a component changed,
> a parameter was replaced by another and so on.
>
Ah, sorry, didn't get that...
> IMHO this is caused by the late binding used by Avalon in order to
> assemble components into an application. The compiler is unaware of
> the interdependencies of these components defined via XML and thus
> cannot check if everything is used the way it is supposed to be.
> But this is another story ...
>
Ok, you win (this time) - but I have the last word!
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Is Cocoon unstable?
Posted by Jens Lorenz <je...@interface-projects.de>.
----- Original Message -----
From: "Carsten Ziegeler" <cz...@s-und-n.de>
To: <co...@xml.apache.org>
Sent: Wednesday, August 07, 2002 3:54 PM
Subject: RE: Is Cocoon unstable?
Carsten,
... a last word ...
> > > I understand your concerns and know that this is a PITA, but it has
> > > nothing to do with an unstable 2.0.x series - and that's what I'm
> > > currently focusing on.
> >
> > Well, updating an application from one 2.0.x to the next version
> > took days as well. We've had this from 2.0 to 2.0.2 and from 2.0.1
> > to 2.0.2.
> > And the errors were more subtle than just a missing method during
> > compilation. Can't remember a particular one though.
> >
> Hmm, that's interesting, because the 2.0.x series should be compatible
> and therefore compile problems should not occur.
A said, _not_ compiler errors. But everything compiles smoothly but it
does not work anyway, because the configuration of a component changed,
a parameter was replaced by another and so on.
IMHO this is caused by the late binding used by Avalon in order to
assemble components into an application. The compiler is unaware of
the interdependencies of these components defined via XML and thus
cannot check if everything is used the way it is supposed to be.
But this is another story ...
Jens
--
jens.lorenz at interface-projects dot de
interface:projects GmbH \\|//
Tolkewitzer Strasse 49 (o o)
01277 Dresden ~~~~oOOo~(_)~oOOo~~~~
Germany
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Is Cocoon unstable?
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Jens Lorenz wrote:
>
> ----- Original Message -----
> From: "Carsten Ziegeler" <cz...@s-und-n.de>
> To: <co...@xml.apache.org>
> Sent: Wednesday, August 07, 2002 2:05 PM
> Subject: RE: Is Cocoon unstable?
>
>
> > Jens Lorenz wrote:
> > >
> > > I've to agree on this. Instable not with the meaning of crashes
> > > but with the meaning of fast changes of API interfaces.
> > >
> > > I can even come up with a quite good example.
> > >
> > > The move of the Source interface from Cocoon to Excalibur.
> > >
> > OK, I agree with you - only partly - because these are changes
> > between the 2.0.x series and 2.1. As 2.1-dev is called alpha
> > it's not intended for production environments.
>
> You're right. But I would distinguish between production and
> development. There are enough improvements for me to use
> 2.1 for research and development, and use 2.0.3 for production
> and projects.
Ok, I agree - we do the same...
> For example inputmodules together with sitemap integration
> are a great feature, which also would fit into 2.0.x.
> (AFAIR InputModules are in scratchpad for 2.0.x but not
> integrated with sitemap, not even with TreeProcessor)
Now, the problem is: time and resources. New features have to be
added with great care not to break anything. And sometimes new
features require "core" changes or some decisions were simply
wrong etc.
So on the one hand side we must be able to deliver bug-fix
releases and on the other hand we want new (perhaps incompatible)
features.
This is with branching, merging etc. no problem. But this is
an OS project, so everything depends on the community. If the
community acts "rather slow", then it will take time for the
next major release (2.1 in our case) - if we would have enough
resorces, 2.1 would be out the doors by the end of august
with compatibility layers, documentation etc.
>
> > > For our document managment system we invented and extended
> > > Source interface with some extra functionality. So that we
> > > could integrate nicely with existing components (generator
> > > and reader in particular), but use extended functionality
> > > by just doing "instanceof ExtendedSource".
> > >
> > > Our source still works with 2.1, but since it is wrapped up
> > > in another compatiblity class the instanceof statement fails.
> > > Even worse, there is no way to get at our wrapped (old) Source.
> > >
> > > One solution we've developed is to create a (JDK 1.3 only)
> > > dynamic proxy which replaces the Wrapper classes and still
> > > implements all interfaces of the wrapped Source thus allowing
> > > it to be used the old and the new way.
> > >
> > > Another solution is to develop a new ExcaliburSource, but this
> > > way we're unable to use it with 2.0.x. It doesn't even compile.
> > >
> > > So essentially we've to maintain two versions. One for 2.0.x and
> > > one for 2.1.x. (and that's a PITA)
> >
> > Ok, agreed - if you have any suggestions how to improve the wrapper
> > classes to avaid such problems, let us know.
>
> Will submit a patch with short description via bugzilla. Probably
> needs a bit polish and works only one way, but works as a basis.
Great!
>
> > > And the Source is only one example.
> > > Another is Loggable vs. LogEnabled.
> > >
> > Loggable still works and will work in 2.1 - so no need to upgrade.
>
> LogEnabled is great since I could use Log4J then and log to the
> syslog facility and mail admins upon fatal errors.
>
Yes, and of course you can use LogEnabled - but it is not required to
rewrite your components.
> > I understand your concerns and know that this is a PITA, but it has
> > nothing to do with an unstable 2.0.x series - and that's what I'm
> > currently focusing on.
>
> Well, updating an application from one 2.0.x to the next version
> took days as well. We've had this from 2.0 to 2.0.2 and from 2.0.1
> to 2.0.2.
> And the errors were more subtle than just a missing method during
> compilation. Can't remember a particular one though.
>
Hmm, that's interesting, because the 2.0.x series should be compatible
and therefore compile problems should not occur.
> > If there are such hard upgrade paths for upgrading to 2.1 (which is
> > still alpha, so I stronlgy suggest to not upgrade) then we should
> > detect them and provide solutions for it (at least when 2.1 hits beta).
>
> Agreed.
>
> > The wrapper classes for the source objects are one step.
>
> Will come by BugZilla.
>
Thanks, again.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Is Cocoon unstable?
Posted by Jens Lorenz <je...@interface-projects.de>.
----- Original Message -----
From: "Carsten Ziegeler" <cz...@s-und-n.de>
To: <co...@xml.apache.org>
Sent: Wednesday, August 07, 2002 2:05 PM
Subject: RE: Is Cocoon unstable?
> Jens Lorenz wrote:
> >
> > I've to agree on this. Instable not with the meaning of crashes
> > but with the meaning of fast changes of API interfaces.
> >
> > I can even come up with a quite good example.
> >
> > The move of the Source interface from Cocoon to Excalibur.
> >
> OK, I agree with you - only partly - because these are changes
> between the 2.0.x series and 2.1. As 2.1-dev is called alpha
> it's not intended for production environments.
You're right. But I would distinguish between production and
development. There are enough improvements for me to use
2.1 for research and development, and use 2.0.3 for production
and projects.
For example inputmodules together with sitemap integration
are a great feature, which also would fit into 2.0.x.
(AFAIR InputModules are in scratchpad for 2.0.x but not
integrated with sitemap, not even with TreeProcessor)
> > For our document managment system we invented and extended
> > Source interface with some extra functionality. So that we
> > could integrate nicely with existing components (generator
> > and reader in particular), but use extended functionality
> > by just doing "instanceof ExtendedSource".
> >
> > Our source still works with 2.1, but since it is wrapped up
> > in another compatiblity class the instanceof statement fails.
> > Even worse, there is no way to get at our wrapped (old) Source.
> >
> > One solution we've developed is to create a (JDK 1.3 only)
> > dynamic proxy which replaces the Wrapper classes and still
> > implements all interfaces of the wrapped Source thus allowing
> > it to be used the old and the new way.
> >
> > Another solution is to develop a new ExcaliburSource, but this
> > way we're unable to use it with 2.0.x. It doesn't even compile.
> >
> > So essentially we've to maintain two versions. One for 2.0.x and
> > one for 2.1.x. (and that's a PITA)
>
> Ok, agreed - if you have any suggestions how to improve the wrapper
> classes to avaid such problems, let us know.
Will submit a patch with short description via bugzilla. Probably
needs a bit polish and works only one way, but works as a basis.
> > And the Source is only one example.
> > Another is Loggable vs. LogEnabled.
> >
> Loggable still works and will work in 2.1 - so no need to upgrade.
LogEnabled is great since I could use Log4J then and log to the
syslog facility and mail admins upon fatal errors.
> I understand your concerns and know that this is a PITA, but it has
> nothing to do with an unstable 2.0.x series - and that's what I'm
> currently focusing on.
Well, updating an application from one 2.0.x to the next version
took days as well. We've had this from 2.0 to 2.0.2 and from 2.0.1
to 2.0.2.
And the errors were more subtle than just a missing method during
compilation. Can't remember a particular one though.
> If there are such hard upgrade paths for upgrading to 2.1 (which is
> still alpha, so I stronlgy suggest to not upgrade) then we should
> detect them and provide solutions for it (at least when 2.1 hits beta).
Agreed.
> The wrapper classes for the source objects are one step.
Will come by BugZilla.
> Thanks
> Carsten
>
Cheers,
Jens
--
jens.lorenz at interface-projects dot de
interface:projects GmbH \\|//
Tolkewitzer Strasse 49 (o o)
01277 Dresden ~~~~oOOo~(_)~oOOo~~~~
Germany
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Is Cocoon unstable?
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Jens Lorenz wrote:
>
> I've to agree on this. Instable not with the meaning of crashes
> but with the meaning of fast changes of API interfaces.
>
> I can even come up with a quite good example.
>
> The move of the Source interface from Cocoon to Excalibur.
>
OK, I agree with you - only partly - because these are changes
between the 2.0.x series and 2.1. As 2.1-dev is called alpha
it's not intended for production environments.
> For our document managment system we invented and extended
> Source interface with some extra functionality. So that we
> could integrate nicely with existing components (generator
> and reader in particular), but use extended functionality
> by just doing "instanceof ExtendedSource".
>
> Our source still works with 2.1, but since it is wrapped up
> in another compatiblity class the instanceof statement fails.
> Even worse, there is no way to get at our wrapped (old) Source.
>
> One solution we've developed is to create a (JDK 1.3 only)
> dynamic proxy which replaces the Wrapper classes and still
> implements all interfaces of the wrapped Source thus allowing
> it to be used the old and the new way.
>
> Another solution is to develop a new ExcaliburSource, but this
> way we're unable to use it with 2.0.x. It doesn't even compile.
>
> So essentially we've to maintain two versions. One for 2.0.x and
> one for 2.1.x. (and that's a PITA)
>
Ok, agreed - if you have any suggestions how to improve the wrapper
classes to avaid such problems, let us know.
>
> And the Source is only one example.
> Another is Loggable vs. LogEnabled.
>
Loggable still works and will work in 2.1 - so no need to upgrade.
I understand your concerns and know that this is a PITA, but it has
nothing to do with an unstable 2.0.x series - and that's what I'm
currently focusing on.
If there are such hard upgrade paths for upgrading to 2.1 (which is
still alpha, so I stronlgy suggest to not upgrade) then we should
detect them and provide solutions for it (at least when 2.1 hits beta).
The wrapper classes for the source objects are one step.
Thanks
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Is Cocoon unstable?
Posted by Jens Lorenz <je...@interface-projects.de>.
----- Original Message -----
From: "Leigh Dodds" <ld...@ingenta.com>
To: <co...@xml.apache.org>
Sent: Wednesday, August 07, 2002 1:21 PM
Subject: RE: Is Cocoon unstable?
> Where I've referred to instability, it's been over concern
> about how rapidly certain pieces of Cocoon seem to be
> changing/developing rather than it runtime failures.
>
> The fact that changes are happening quickly, and releases
> occur on time is a credit to the community.
>
> But it does make it seem like a moving target when deciding
> on a platform for an application.
>
> Cheers,
>
> L.
>
I've to agree on this. Instable not with the meaning of crashes
but with the meaning of fast changes of API interfaces.
I can even come up with a quite good example.
The move of the Source interface from Cocoon to Excalibur.
For our document managment system we invented and extended
Source interface with some extra functionality. So that we
could integrate nicely with existing components (generator
and reader in particular), but use extended functionality
by just doing "instanceof ExtendedSource".
Our source still works with 2.1, but since it is wrapped up
in another compatiblity class the instanceof statement fails.
Even worse, there is no way to get at our wrapped (old) Source.
One solution we've developed is to create a (JDK 1.3 only)
dynamic proxy which replaces the Wrapper classes and still
implements all interfaces of the wrapped Source thus allowing
it to be used the old and the new way.
Another solution is to develop a new ExcaliburSource, but this
way we're unable to use it with 2.0.x. It doesn't even compile.
So essentially we've to maintain two versions. One for 2.0.x and
one for 2.1.x. (and that's a PITA)
And the Source is only one example. Another is Loggable vs. LogEnabled.
Regards,
Jens
--
jens.lorenz at interface-projects dot de
interface:projects GmbH \\|//
Tolkewitzer Strasse 49 (o o)
01277 Dresden ~~~~oOOo~(_)~oOOo~~~~
Germany
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Is Cocoon unstable?
Posted by Leigh Dodds <ld...@ingenta.com>.
Where I've referred to instability, it's been over concern
about how rapidly certain pieces of Cocoon seem to be
changing/developing rather than it runtime failures.
The fact that changes are happening quickly, and releases
occur on time is a credit to the community.
But it does make it seem like a moving target when deciding
on a platform for an application.
Cheers,
L.
> -----Original Message-----
> From: Carsten Ziegeler [mailto:cziegeler@s-und-n.de]
> Sent: 07 August 2002 12:02
> To: Cocoon-Dev
> Subject: Is Cocoon unstable?
>
>
> Looking at the last great threads, I noticed many messages
> complaining that Cocoon is not stable, even from some
> developers.
>
> Is this really true? Is Cocoon not stable (and I mean
> 2.0.3 of course) ?
>
> Our experience with several productive installations currently
> proves the opposite. It's stable and did never crash or
> had to be restarted since months. I must confess that we
> are using a version between 2.0 and 2.0.1.
>
> And if 2.0.3 is really that unstable, we should immediately
> fix this and find out what has changed since 2.0.1 which
> causes this!
>
> So, constructive reports about unstable conditions are welcome.
>
> Carsten
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Is Cocoon unstable?
Posted by Giacomo Pati <gi...@apache.org>.
On Wed, 7 Aug 2002, Carsten Ziegeler wrote:
> Looking at the last great threads, I noticed many messages
> complaining that Cocoon is not stable, even from some
> developers.
>
> Is this really true? Is Cocoon not stable (and I mean
> 2.0.3 of course) ?
>
> Our experience with several productive installations currently
> proves the opposite. It's stable and did never crash or
> had to be restarted since months. I must confess that we
> are using a version between 2.0 and 2.0.1.
We are using similar version in productive installation and I fully
support this statement: Stable and did never crash or had to be restarted
since months. And I'd like to add it is fast compared to similar products
(if you'd like to compare Cocoon with other products).
Giacomo
>
> And if 2.0.3 is really that unstable, we should immediately
> fix this and find out what has changed since 2.0.1 which
> causes this!
>
> So, constructive reports about unstable conditions are welcome.
>
> Carsten
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org