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/09/11 13:05:49 UTC
Error Handling is NOT working
Hi,
I just have to repeat an email I wrote over a year ago, because the
problem is getting worse:
If an error occurs in the pipeline, the error handler is called and
produces some output (or a response). At this time, the original
pipeline could have already output some information and you might
get an "response already committed" exception or something like that.
Ok, so far so good, but since some time a serializer flushed the output
stream when it is recycled...so the response is always already committed
and the output stream can't be reset - and when the error handler trys
to create its output, an exception is thrown!
If we want to keep this error handler stuff I still vote for an
intermediate output stream for the normal pipeline. This output stream
"is copied" to the real output stream only if no error occurs.
This is some extra performance cost - so we could make this somewhere
configurable.
If anyone has a different solution, I'm all ears - but the current
implementation is absolutely useless.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Error Handling is NOT working
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Michael Melhem wrote:
>On Wed, Sep 11, 2002 at 01:53:01PM +0200, Carsten Ziegeler wrote:
>
>
>>Nicola Ken Barozzi wrote:
>>
>>
>>>Carsten, do what you want, I'm really fed up with error handling.
>>>I'll start to complain myself now, let's see if it helps.
>>>
>>>
>>>
>>So I count this as a +10. Thanks.
>>
>>
>
>IIRC, there was also some discussion on the list a while back (in July?)
>regarding Extending Error Handling, I dont think that stuff ever got
>implemented. Another thing on the "to do" list...*sigh* :-)
>
>
It's not implemented now, but is on my todo list (time, time, time...)
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Error Handling is NOT working
Posted by Michael Melhem <mi...@fztig938.bank.dresdner.net>.
On Wed, Sep 11, 2002 at 01:53:01PM +0200, Carsten Ziegeler wrote:
>
> Nicola Ken Barozzi wrote:
> >
> > Carsten, do what you want, I'm really fed up with error handling.
> > I'll start to complain myself now, let's see if it helps.
> >
> So I count this as a +10. Thanks.
IIRC, there was also some discussion on the list a while back (in July?)
regarding Extending Error Handling, I dont think that stuff ever got
implemented. Another thing on the "to do" list...*sigh* :-)
Regards,
Michael Melhem
>
> 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: Error Handling is NOT working
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Carsten Ziegeler wrote:
> Nicola Ken Barozzi wrote:
>
>>Carsten Ziegeler wrote:
>>
>>>Nicola Ken Barozzi wrote:
>>>
>>>
>>>>Carsten, do what you want, I'm really fed up with error handling.
>>>>I'll start to complain myself now, let's see if it helps.
>>>>
>>>
>>>So I count this as a +10. Thanks.
>>
>>It's a +1000 to have you write that code.
>>A -1000 for ranting.
>>
>>We know that to see error messages without problems we need to buffer
>>all the result and flush it at the end.
>>We all know that this decreases percieved performance and enhances
>>memory usage.
>>We all know that making this configurable is the right thing to do so we
>> have both possibilities.
>>
>>It was also said that making the response buffer bigger would have
>>solved the problem (see mail archives).
>>
>>Other than that, there was no veto IIRC on making this happen, above all
>>if it's configurable.
>>
>>While you are at it, remember that it is a TODO to make generators work
>>in handle-errors, remembering that redirects must be prohibited.
>>
>>There is no need to ask us all really, we had already discussed this
>>zillion times.
>>
>
> Sorry, but this is wrong - we had a vote on this and it got a "-1".
> So there is a need.
:-O
Can you please give me a link to it?
> And I really would like to see others doing this...(not you).
Sorry if I jump on this issue every time, thank you for your
understanding :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Error Handling is NOT working
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Nicola Ken Barozzi wrote:
>
> Carsten Ziegeler wrote:
> > Nicola Ken Barozzi wrote:
> >
> >>Carsten, do what you want, I'm really fed up with error handling.
> >>I'll start to complain myself now, let's see if it helps.
> >>
> >
> > So I count this as a +10. Thanks.
>
> It's a +1000 to have you write that code.
> A -1000 for ranting.
>
> We know that to see error messages without problems we need to buffer
> all the result and flush it at the end.
> We all know that this decreases percieved performance and enhances
> memory usage.
> We all know that making this configurable is the right thing to do so we
> have both possibilities.
>
> It was also said that making the response buffer bigger would have
> solved the problem (see mail archives).
>
> Other than that, there was no veto IIRC on making this happen, above all
> if it's configurable.
>
> While you are at it, remember that it is a TODO to make generators work
> in handle-errors, remembering that redirects must be prohibited.
>
> There is no need to ask us all really, we had already discussed this
> zillion times.
>
Sorry, but this is wrong - we had a vote on this and it got a "-1".
So there is a need.
And I really would like to see others doing this...(not you).
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Error Handling is NOT working
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Carsten Ziegeler wrote:
> Nicola Ken Barozzi wrote:
>
>>Carsten, do what you want, I'm really fed up with error handling.
>>I'll start to complain myself now, let's see if it helps.
>>
>
> So I count this as a +10. Thanks.
It's a +1000 to have you write that code.
A -1000 for ranting.
We know that to see error messages without problems we need to buffer
all the result and flush it at the end.
We all know that this decreases percieved performance and enhances
memory usage.
We all know that making this configurable is the right thing to do so we
have both possibilities.
It was also said that making the response buffer bigger would have
solved the problem (see mail archives).
Other than that, there was no veto IIRC on making this happen, above all
if it's configurable.
While you are at it, remember that it is a TODO to make generators work
in handle-errors, remembering that redirects must be prohibited.
There is no need to ask us all really, we had already discussed this
zillion times.
Just do it.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Error Handling is NOT working
Posted by Ivelin Ivanov <iv...@apache.org>.
+1
I didn't realize we're voting yet.
----- Original Message -----
From: "Carsten Ziegeler" <cz...@s-und-n.de>
To: <co...@xml.apache.org>
Sent: Wednesday, September 11, 2002 6:53 AM
Subject: RE: Error Handling is NOT working
>
> Nicola Ken Barozzi wrote:
> >
> > Carsten, do what you want, I'm really fed up with error handling.
> > I'll start to complain myself now, let's see if it helps.
> >
> So I count this as a +10. Thanks.
>
> 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: Error Handling is NOT working
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Nicola Ken Barozzi wrote:
>
> Carsten, do what you want, I'm really fed up with error handling.
> I'll start to complain myself now, let's see if it helps.
>
So I count this as a +10. Thanks.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Error Handling is NOT working
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Carsten Ziegeler wrote:
> Hi,
>
> I just have to repeat an email I wrote over a year ago, because the
> problem is getting worse:
>
> If an error occurs in the pipeline, the error handler is called and
> produces some output (or a response). At this time, the original
> pipeline could have already output some information and you might
> get an "response already committed" exception or something like that.
>
> Ok, so far so good, but since some time a serializer flushed the output
> stream when it is recycled...so the response is always already committed
> and the output stream can't be reset - and when the error handler trys
> to create its output, an exception is thrown!
>
> If we want to keep this error handler stuff I still vote for an
> intermediate output stream for the normal pipeline. This output stream
> "is copied" to the real output stream only if no error occurs.
> This is some extra performance cost - so we could make this somewhere
> configurable.
>
> If anyone has a different solution, I'm all ears - but the current
> implementation is absolutely useless.
Carsten, do what you want, I'm really fed up with error handling.
I'll start to complain myself now, let's see if it helps.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Error Handling is NOT working
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Ivelin Ivanov wrote:
> I agree with Carsten. The output should be flushed to the real output stream
> only after the sitemap processing has ended.
Since the *original* Cocoon design document, having output come out
right away because of the SAX processing was regarded as a *big
feature*, because it greatly enhances percieved performance on webapps.
Don't regard as a shortcoming something that is an important feature in
production, it's a problem usually only during debugging.
> Allowing direct access to the output stream proved to be very problematic
> for JSP applications as well.
> The 2.3 filters were warmly welcomed in the JSP world.
>
> The one big issue is the size of the buffer.
> However I was never really worried too much about it, because web
> applications are usually not ftp servers. Especially Cocoon applications.
IIRC we already configure a buffer somewhere, it has to be checked not
to interfere.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Error Handling is NOT working
Posted by Ivelin Ivanov <iv...@apache.org>.
I agree with Carsten. The output should be flushed to the real output stream
only after the sitemap processing has ended.
Allowing direct access to the output stream proved to be very problematic
for JSP applications as well.
The 2.3 filters were warmly welcomed in the JSP world.
The one big issue is the size of the buffer.
However I was never really worried too much about it, because web
applications are usually not ftp servers. Especially Cocoon applications.
Ivelin
----- Original Message -----
From: "Carsten Ziegeler" <cz...@s-und-n.de>
To: "Cocoon-Dev" <co...@xml.apache.org>
Sent: Wednesday, September 11, 2002 6:05 AM
Subject: Error Handling is NOT working
> Hi,
>
> I just have to repeat an email I wrote over a year ago, because the
> problem is getting worse:
>
> If an error occurs in the pipeline, the error handler is called and
> produces some output (or a response). At this time, the original
> pipeline could have already output some information and you might
> get an "response already committed" exception or something like that.
>
> Ok, so far so good, but since some time a serializer flushed the output
> stream when it is recycled...so the response is always already committed
> and the output stream can't be reset - and when the error handler trys
> to create its output, an exception is thrown!
>
> If we want to keep this error handler stuff I still vote for an
> intermediate output stream for the normal pipeline. This output stream
> "is copied" to the real output stream only if no error occurs.
> This is some extra performance cost - so we could make this somewhere
> configurable.
>
> If anyone has a different solution, I'm all ears - but the current
> implementation is absolutely useless.
>
> 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: Error Handling is NOT working
Posted by Vadim Gritsenko <va...@verizon.net>.
Sylvain Wallez wrote:
> Carsten Ziegeler wrote:
>
>> Hi,
>>
>> I just have to repeat an email I wrote over a year ago, because the
>> problem is getting worse:
>>
>> If an error occurs in the pipeline, the error handler is called and
>> produces some output (or a response). At this time, the original
>> pipeline could have already output some information and you might
>> get an "response already committed" exception or something like that.
>>
>> Ok, so far so good, but since some time a serializer flushed the output
>> stream when it is recycled...so the response is always already committed
>> and the output stream can't be reset - and when the error handler trys
>> to create its output, an exception is thrown!
>>
>>
>
> Why does have a serializer to flush its output when it is recycled ?
> Flushing (and output stream management) is IMO the responsibility of
> the pipeline, and not that of the serializer.
Because serializer wraps output stream with the BufferedOutputStream
environment knows nothing about. Because of this, under some
circumstances, this buffer was not flushed (giving incorrect result) -
thus flushing was added to fix this issue.
Vadim
>> If we want to keep this error handler stuff I still vote for an
>> intermediate output stream for the normal pipeline. This output stream
>> "is copied" to the real output stream only if no error occurs.
>> This is some extra performance cost - so we could make this somewhere
>> configurable.
>>
>
> Wow ! As you say, this is an important extra cost for exceptional
> conditions. I would prefer serializers not flushing and increasing the
> buffer size (using a new servlet parameter ?).
>
>> If anyone has a different solution, I'm all ears - but the current
>> implementation is absolutely useless.
>>
>>
>
> A quick grep shows that only AbstractTextSerializer flushes in its
> recycle(). The fix seems easy.
>
> Sylvain
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Error Handling is NOT working
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Nicola Ken Barozzi wrote:
>
> Sylvain Wallez wrote:
>
>> Ivelin Ivanov wrote:
>>
>>> ----- Original Message -----
>>> From: "Sylvain Wallez" <sy...@anyware-tech.com>
>>> To: <co...@xml.apache.org>
>>> Sent: Wednesday, September 11, 2002 8:01 AM
>>> Subject: Re: Error Handling is NOT working
>>>
>>>
>>>> Why does have a serializer to flush its output when it is recycled ?
>>>> Flushing (and output stream management) is IMO the responsibility
>>>> of the
>>>> pipeline, and not that of the serializer.
>>>>
>>>
>>>
>>>
>>> Agreed. The sitemap interpreter should flush the output stream when
>>> it's
>>> done interpreting a request.
>>>
>>>
>>
>> [Picky mode on]
>>
>> Nope. Read carefully : "the responsibility of the *pipeline*" ! The
>> sitemap responsibility is to build the pipeline by executing the
>> sitemap instructions. The interpreter never touches the output stream
>> : it gives the Environment object to the pipeline, and this is where
>> the pipeline gets the stream.
>
>
> I close the stream in CocoonServlet too, because errors can be written
> out there too... hmmm...
>
That's good also, since CocoonServlet is the last object in the
processing chain and implements exception handling when no sitemap
error-handler catches the exception.
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Error Handling is NOT working
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Sylvain Wallez wrote:
> Ivelin Ivanov wrote:
>
>> ----- Original Message -----
>> From: "Sylvain Wallez" <sy...@anyware-tech.com>
>> To: <co...@xml.apache.org>
>> Sent: Wednesday, September 11, 2002 8:01 AM
>> Subject: Re: Error Handling is NOT working
>>
>>
>>> Why does have a serializer to flush its output when it is recycled ?
>>> Flushing (and output stream management) is IMO the responsibility of the
>>> pipeline, and not that of the serializer.
>>>
>>
>>
>> Agreed. The sitemap interpreter should flush the output stream when it's
>> done interpreting a request.
>>
>>
>
> [Picky mode on]
>
> Nope. Read carefully : "the responsibility of the *pipeline*" ! The
> sitemap responsibility is to build the pipeline by executing the sitemap
> instructions. The interpreter never touches the output stream : it gives
> the Environment object to the pipeline, and this is where the pipeline
> gets the stream.
I close the stream in CocoonServlet too, because errors can be written
out there too... hmmm...
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Error Handling is NOT working
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Carsten Ziegeler wrote:
>Sylvain Wallez wrote:
>
>
>>Ivelin Ivanov wrote:
>>
>>
>>
>>>----- Original Message -----
>>>From: "Sylvain Wallez" <sy...@anyware-tech.com>
>>>To: <co...@xml.apache.org>
>>>Sent: Wednesday, September 11, 2002 8:01 AM
>>>Subject: Re: Error Handling is NOT working
>>>
>>>
>>>
>>>
>>>>Why does have a serializer to flush its output when it is recycled ?
>>>>Flushing (and output stream management) is IMO the responsibility of the
>>>>pipeline, and not that of the serializer.
>>>>
>>>>
>>>>
>>>>
>>>Agreed. The sitemap interpreter should flush the output stream when it's
>>>done interpreting a request.
>>>
>>>
>>>
>>>
>>[Picky mode on]
>>
>>Nope. Read carefully : "the responsibility of the *pipeline*" ! The
>>sitemap responsibility is to build the pipeline by executing the sitemap
>>instructions. The interpreter never touches the output stream : it gives
>>the Environment object to the pipeline, and this is where the pipeline
>>gets the stream.
>>
>>
>>
>
>I agree that it's the responsibility of the environment (or servlet) to
>flush and close the output stream - but you can't prevent someone from
>doing this.
>
>And yes, increasing the buffer size would eliminate an intermediate stream,
>if the size is big enough!
>
>We are always talking of "a user friendly Cocoon" and this here is such a
>point:
>The problem can be solved by a configurable parameter for the buffer size
>of the output stream. But this requires knowledge of this parameter and how
>to configure it.
>A user friendly system should be able to work as expected without changing
>configuration parameters.
>
I fully agree with you. However, there are some places where some manual
tuning is required since automatic handling is too costly. Think for
example to the pool sizes, which is IMO a much more difficult and
critical problem.
But we can do something to help the user : when an error occurs, we try
to reset the output buffer (see HttpEnvironment.tryResetResponse()). A
more explicit message logged there when the response couldn't be reset,
inviting the user to increase the buffer size.
Also, a nice "what should I do when output and error are intermixed on
screen" FAQ could also to the trick...
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon running modes (was Re: Error Handling is NOT working)
Posted by Ivelin Ivanov <iv...@apache.org>.
While generally a good idea,
different operational modes would make more sense when Cocoon 2.1 enters a
stable stage.
If we introduce modes early on, then everything that we add in the
development cycle will have to be tested twice - once in each mode.
Ivelin
----- Original Message -----
From: "Sylvain Wallez" <sy...@anyware-tech.com>
To: <co...@xml.apache.org>
Sent: Wednesday, September 11, 2002 9:45 AM
Subject: Cocoon running modes (was Re: Error Handling is NOT working)
> Torsten Curdt wrote:
>
> ><snip/>
> >
> >Guys, isn't it obvious we cannot realy provide errors in a user friendly
> >manner since we are delivering the page on-the-fly via SAX? Buffering the
> >whole page seems to reduce the positve aspects we get from using SAX and
we
> >get closer to Cocoon1.
> >
> >Maybe we should have two different modes to run cocoon or at least
pipelines
> >in: buffered and unbuffered. So one could use e.g. buffered for
development
> >und unbuffered for deployment?!
> >
> >
>
> Is this buffer size only related to development ? I don't think so.
> Error-handlers can also be used in production to handle
> exceptional-but-foreseen conditions (access denied, unavailable
> resource, etc). So the buffer size isn't only a matter of running mode.
>
> However, running mode is a great idea, which could be used for many more
> things than buffer size :
> - central configuration for automatic reload of XSPs and sitemap in dev
> mode (and no reload in production mode),
> - display the Cocoon "blue screen of death" to the browser in dev mode
> and a gentle "system currently unavailable" in production mode,
> - other ideas ?
>
> Sylvain
>
> --
> Sylvain Wallez
> Anyware Technologies Apache Cocoon
> http://www.anyware-tech.com mailto:sylvain@apache.org
>
>
>
>
> ---------------------------------------------------------------------
> 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: Cocoon running modes (was Re: Error Handling is NOT working)
Posted by Stephen McConnell <mc...@apache.org>.
Torsten
I've recently been working on the subject of exception management and
logging in the context of the Merlin container. Just like Cocoon,
Merlin tends to spit out very log stack traces that make the process of
end-user recognition of the real problem unnecessarily difficult. I've
recently put in place some changes to Merlin that solve this and I
thought it may be helpful to provide an update on this.
Firstly, there is a problem concerning the reporting of exceptions under
JDK 1.4 and later - the log file get filled with masive stack dumps
where the causal exception get dumped in full and the causal exceptions
causal exception get dumped in full, etc. etc. This results in masssive
duplication of exeception information.
The solution I have in place is:
(a) coding policy
* when an error occurs, optionally log the message, NOT the
exception,
rethrow the exception (typically inside another cascading
exeception)
* this ensures that you get a ERROR or WARNING log entry in the log
category under which the error/warning occurs, and the causal
exception is propergated up the chain of control
(b) considate error reporting somewhere high up in the application
where it makes sence to dumpt the exception to the log file
(c) generate a considated exception report
* for all of the exceptions in the chain, generate a string buffer
the contains the exception messages
* dump the stack trace of last exception in the chain into the buffer
* take the buffer result and enter it into the log
In the Merlin case - errors reporting now makes complete sence.
An example of the error log for an exception I'm throwing is include
below just to demonstrate the final error reporting. The actual
exception message is prepared using the packException method in the
org.apache.excalibur.merlin.ExceptionHelper class in the
excalibur/assembly project (which can easily be copied/plundered for
Cocoon requirements if it makes sence).
Cheers, Steve.
Code example:
-------------
try
{
// do top level stuff
{
catch( Throwable e )
{
ExceptionHelper.packException( "kernel startup failure", e );
}
Result:
-------
[ERROR ] (root.kernel): Message: kernel startup failure
===================================================================
Exception: org.apache.excalibur.merlin.container.ContainerException:
Unexpected error during container execution.
Cause: org.apache.excalibur.merlin.resource.LifecycleException:
Component named "/root/complex" failed to pass through the
initialization stage.
Cause: org.apache.avalon.framework.service.ServiceException: Service
resolution failure for role: simple
Cause: org.apache.excalibur.merlin.resource.ResourceException:
Unexpected exception while resolving the service from
service:/root/simple#17984263 for the role: simple
Cause: org.apache.excalibur.merlin.resource.LifecycleException:
Component named "/root/simple#17984263" failed to pass through the
startup stage.
Cause: java.lang.RuntimeException: Steve's demo exception just for Cocoon
===================================================================
java.lang.RuntimeException: Steve's demo exception just for Cocoon
at org.apache.excalibur.playground.SimpleComponent.start(Unknown
Source)
at
org.apache.avalon.framework.container.ContainerUtil.start(ContainerUtil.java:251)
at
org.apache.excalibur.merlin.resource.LifecycleHelper.startup(Unknown Source)
at
org.apache.excalibur.merlin.resource.AbstractLifestyleHandler.createInstance(Unknown
Source)
at
org.apache.excalibur.merlin.resource.SingletonLifestyleHandler.get(Unknown
Source)
at
org.apache.excalibur.merlin.resource.DefaultResource.access(Unknown Source)
at
org.apache.excalibur.merlin.resource.DefaultManager.get(Unknown Source)
at
org.apache.excalibur.merlin.resource.DefaultServiceManager.lookup(Unknown
Source)
at
org.apache.excalibur.playground.ComplexComponent.initialize(Unknown Source)
at
org.apache.avalon.framework.container.ContainerUtil.initialize(ContainerUtil.java:235)
at
org.apache.excalibur.merlin.resource.LifecycleHelper.startup(Unknown Source)
at
org.apache.excalibur.merlin.resource.AbstractLifestyleHandler.createInstance(Unknown
Source)
at
org.apache.excalibur.merlin.resource.SingletonLifestyleHandler.get(Unknown
Source)
at
org.apache.excalibur.merlin.resource.DefaultResource.access(Unknown Source)
at
org.apache.excalibur.merlin.assembly.ContainerManager.start(Unknown Source)
at
org.apache.excalibur.merlin.assembly.ContainerManager.start(Unknown Source)
at
org.apache.excalibur.merlin.container.DefaultContainer.start(Unknown Source)
at
org.apache.excalibur.merlin.container.ContainerResource.run(Unknown Source)
at java.lang.Thread.run(Thread.java:536)
===================================================================
tcurdt@dff.st wrote:
><snip/>
>
>
>
>>Is this buffer size only related to development ? I don't think so.
>>
>>
>
>Well, of course not necessarily... but at least I wouldn't want this burden
>that will definitly mean a drop of performance and worse scaleability for our
>deployed system.
>
>The question is: for what type of user do we create those nice error messages?
>
>Actually from our clients I can tell - they don't have the slightest idea what
>a specific exception could mean. And I bet same goes for most of the web users
>out there. If there is an error they will call anyway and I have to look into
>the logs. (Of course a nice page "Sorry, unavailable" is much nicer - but we
>need to see what is the price to pay.
>
>But where it can definitly help to speed things up is at the development
>stage... No more: "wait I need to turn this category on - do it again" or "wait
>I need only 10.000 more lines to go through"
>
>But of course people may see this differently... ;)
>
>
>
>>Error-handlers can also be used in production to handle
>>exceptional-but-foreseen conditions (access denied, unavailable
>>resource, etc). So the buffer size isn't only a matter of running mode.
>>
>>
>
>Well, of course... but I would model such conditions within the sitemap and
>don't use Exceptions ;) ...if they are foreseen...
>
>
>
>>However, running mode is a great idea, which could be used for many more
>>things than buffer size :
>>- central configuration for automatic reload of XSPs and sitemap in dev
>>mode (and no reload in production mode),
>>- display the Cocoon "blue screen of death" to the browser in dev mode
>>and a gentle "system currently unavailable" in production mode,
>>- other ideas ?
>>
>>
>
>Hey, I didn't thought about all that... sounds cool:)
>
>- provide different logkit configurations?
>--
>Torsten
>
>-------------------------------------------------
>This mail sent through IMP: http://horde.org/imp/
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon running modes (was Re: Error Handling is NOT working)
Posted by tc...@dff.st.
<snip/>
> Is this buffer size only related to development ? I don't think so.
Well, of course not necessarily... but at least I wouldn't want this burden
that will definitly mean a drop of performance and worse scaleability for our
deployed system.
The question is: for what type of user do we create those nice error messages?
Actually from our clients I can tell - they don't have the slightest idea what
a specific exception could mean. And I bet same goes for most of the web users
out there. If there is an error they will call anyway and I have to look into
the logs. (Of course a nice page "Sorry, unavailable" is much nicer - but we
need to see what is the price to pay.
But where it can definitly help to speed things up is at the development
stage... No more: "wait I need to turn this category on - do it again" or "wait
I need only 10.000 more lines to go through"
But of course people may see this differently... ;)
> Error-handlers can also be used in production to handle
> exceptional-but-foreseen conditions (access denied, unavailable
> resource, etc). So the buffer size isn't only a matter of running mode.
Well, of course... but I would model such conditions within the sitemap and
don't use Exceptions ;) ...if they are foreseen...
> However, running mode is a great idea, which could be used for many more
> things than buffer size :
> - central configuration for automatic reload of XSPs and sitemap in dev
> mode (and no reload in production mode),
> - display the Cocoon "blue screen of death" to the browser in dev mode
> and a gentle "system currently unavailable" in production mode,
> - other ideas ?
Hey, I didn't thought about all that... sounds cool:)
- provide different logkit configurations?
--
Torsten
-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Cocoon running modes (was Re: Error Handling is NOT working)
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Sylvain Wallez wrote:
> I agree that Cocoon is not a servlet, but disagree with your conclusion
> : the environment implementation makes the bridge with the actual
> running environment. In the servlet environment, the Response is just a
> thin wrapper around the HttpServletResponse and the output stream is the
> HttpServletResponse's output stream which *is buffered* by the servlet
> engine, as stated by the servlet spec.
>
> So can't we extend the Environment contract by saying that the output
> stream should be buffered, and providing a new setBufferSize() method ?
>
> This will avoid useless and inefficient double-buffering in servlet
> environment (which is the one mostly used and where perfs and memory are
> critical), and, making the command line environment buffered should be a
> couple of lines in AbstractCommandLineEnvironment.
>
> We can thus have an environment-neutral Cocoon that relies on a buffered
> output stream provided by the environment, regardless what this
> environment is.
>
Again, this extra buffering is already implemented in the
AbstractTextSerializer
and as HTML or XML are the most uses of Cocoon, the output is buffered
already
today regardless of the servlet engine, cli or whatever environment you use.
So shifting this from the serializer to the environment does not reduce
performance but solves the problem.
I just have finished a simple solution - we can decided on the
implementation
if it's ok, or we should search for a different solution.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon running modes (was Re: Error Handling is NOT working)
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Nicola Ken Barozzi wrote:
>
>
> Sylvain Wallez wrote:
>
>> Carsten Ziegeler wrote:
>>
>>> Might be worth investigating into running modes. Hmm.
>>>
>>> But comming back to the original problem ;) - We already have an
>>> intermediate
>>> output stream implemented and noone really complained about it:
>>> Its the buffered output stream in the abstract text serializer...the
>>> only
>>> problem here is that a) the size of the buffer might be too small
>>> and b) the stream is flushed on recycle().
>>>
>>> So, if we
>>> a) Move this buffered output stream handling out of the serializer
>>> into the environment and
>>> b) Don't flush the stream on recycling a serializer and
>>> c) Add a small logic checking the buffer size for the current response,
>>>
>>> we have everything we need.
>>>
>>
>> The output stream provided by the servlet engine is already buffered
>> and we can control the buffer size using
>> ServletResponse.setBufferSize(). Why do we need an additional buffer ?
>
>
> Because Cocoon is not a servlet; it's mainly used as a servlet, but it
> is *not* a servlet.
> So regardless to what the servlet container gives us, we must ensure
> Cocoon gets a neutral set of objects to work on.
I agree that Cocoon is not a servlet, but disagree with your conclusion
: the environment implementation makes the bridge with the actual
running environment. In the servlet environment, the Response is just a
thin wrapper around the HttpServletResponse and the output stream is the
HttpServletResponse's output stream which *is buffered* by the servlet
engine, as stated by the servlet spec.
So can't we extend the Environment contract by saying that the output
stream should be buffered, and providing a new setBufferSize() method ?
This will avoid useless and inefficient double-buffering in servlet
environment (which is the one mostly used and where perfs and memory are
critical), and, making the command line environment buffered should be a
couple of lines in AbstractCommandLineEnvironment.
We can thus have an environment-neutral Cocoon that relies on a buffered
output stream provided by the environment, regardless what this
environment is.
>> What about exposing this method by adding it to our Request interface
>> ? I already proposed this a while ago (see
>> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101661438030015&w=2),
>
>
> As I said, we need to expose a facade of the real stream, that is
> indipendent from the environment implementation used.
>
> Thus we should wrap any stream that is given to Cocoon in a
> CocoonStream facade, that we can control as you say, and in the
> servlet case delegate to the servlet container.
Maybe. This can give us more control on methods such as flush and close
(which, BTW, are already trapped by servlet engines that implement
persistent connections or chunked responses).
>> including the proposal for setting the buffer size either as a
>> servlet parameter or an attribute of <map:pipeline>.
>
>
> Definately not in the servlet conf, as a pipeline hint maybe, as a
> global parameter, surely.
Don't know. It may be considered as a configuration of the environment,
and thus given in web.xml for servlet and as a command line argument for
CLI...
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon running modes (was Re: Error Handling is NOT working)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Sylvain Wallez wrote:
> Carsten Ziegeler wrote:
>
>> Might be worth investigating into running modes. Hmm.
>>
>> But comming back to the original problem ;) - We already have an
>> intermediate
>> output stream implemented and noone really complained about it:
>> Its the buffered output stream in the abstract text serializer...the only
>> problem here is that a) the size of the buffer might be too small
>> and b) the stream is flushed on recycle().
>>
>> So, if we
>> a) Move this buffered output stream handling out of the serializer
>> into the environment and
>> b) Don't flush the stream on recycling a serializer and
>> c) Add a small logic checking the buffer size for the current response,
>>
>> we have everything we need.
>>
>
> The output stream provided by the servlet engine is already buffered and
> we can control the buffer size using ServletResponse.setBufferSize().
> Why do we need an additional buffer ?
Because Cocoon is not a servlet; it's mainly used as a servlet, but it
is *not* a servlet.
So regardless to what the servlet container gives us, we must ensure
Cocoon gets a neutral set of objects to work on.
> What about exposing this method by adding it to our Request interface ?
> I already proposed this a while ago (see
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101661438030015&w=2),
As I said, we need to expose a facade of the real stream, that is
indipendent from the environment implementation used.
Thus we should wrap any stream that is given to Cocoon in a CocoonStream
facade, that we can control as you say, and in the servlet case delegate
to the servlet container.
> including the proposal for setting the buffer size either as a servlet
> parameter or an attribute of <map:pipeline>.
Definately not in the servlet conf, as a pipeline hint maybe, as a
global parameter, surely.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon running modes (was Re: Error Handling is NOT working)
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Carsten Ziegeler wrote:
>Might be worth investigating into running modes. Hmm.
>
>But comming back to the original problem ;) - We already have an
>intermediate
>output stream implemented and noone really complained about it:
>Its the buffered output stream in the abstract text serializer...the only
>problem here is that a) the size of the buffer might be too small
>and b) the stream is flushed on recycle().
>
>So, if we
>a) Move this buffered output stream handling out of the serializer
> into the environment and
>b) Don't flush the stream on recycling a serializer and
>c) Add a small logic checking the buffer size for the current response,
>
>we have everything we need.
>
The output stream provided by the servlet engine is already buffered and
we can control the buffer size using ServletResponse.setBufferSize().
Why do we need an additional buffer ?
What about exposing this method by adding it to our Request interface ?
I already proposed this a while ago (see
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101661438030015&w=2),
including the proposal for setting the buffer size either as a servlet
parameter or an attribute of <map:pipeline>.
Thoughts ?
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon running modes (was Re: Error Handling is NOT working)
Posted by Vadim Gritsenko <va...@verizon.net>.
Nicola Ken Barozzi wrote:
>
> Carsten Ziegeler wrote:
>
>> Might be worth investigating into running modes. Hmm.
>
>
> BTW, I'm happy this discussion came to nice indication and real
> solutions, kudos to all that partecipate :-)
>
>> But comming back to the original problem ;) - We already have an
>> intermediate
>> output stream implemented and noone really complained about it:
>> Its the buffered output stream in the abstract text serializer...the
>> only
>> problem here is that a) the size of the buffer might be too small
>> and b) the stream is flushed on recycle().
>>
>> So, if we
>> a) Move this buffered output stream handling out of the serializer
>> into the environment
>
>
> +1 There is where it belongs architecturally IMHO, thanks for pointing
> this out, I wasn't aware.
>
>> b) Don't flush the stream on recycling a serializer
>
>
> Even better: prevent flushng alltogether by making a
> CocoonIntermediateStream that extends the output stream, and that does
> nothing on flush, and instead uses an Environment-protected method for
> flushing, so we can play safe.
>
>> c) Add a small logic checking the buffer size for the current response,
>
>
> +1 and make it configurable.
>
>> we have everything we need.
>>
>> This should work and it should also don't have any impact on the
>> performance as 99% of it is already done.
>
+1 and port to 203 when this is stable. It has same issue.
Vadim
> At least we can see how it works.
> Decoupling from the real stream gives us nice advantages it seems.
>
>> I will give this a try today - and we can see if it works.
>
>
> :-)
>
>> But we should of course continue this discussion about the running modes.
>
>
> Running modes is a nice idea that we already had sometime back, and
> that now fortunately came back.
> Basically with a single param it should be able to switch configurations.
>
> Hence we can switch from a programmer env conf to a production one
> quite easily.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon running modes (was Re: Error Handling is NOT working)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Carsten Ziegeler wrote:
> Might be worth investigating into running modes. Hmm.
BTW, I'm happy this discussion came to nice indication and real
solutions, kudos to all that partecipate :-)
> But comming back to the original problem ;) - We already have an
> intermediate
> output stream implemented and noone really complained about it:
> Its the buffered output stream in the abstract text serializer...the only
> problem here is that a) the size of the buffer might be too small
> and b) the stream is flushed on recycle().
>
> So, if we
> a) Move this buffered output stream handling out of the serializer
> into the environment
+1 There is where it belongs architecturally IMHO, thanks for pointing
this out, I wasn't aware.
> b) Don't flush the stream on recycling a serializer
Even better: prevent flushng alltogether by making a
CocoonIntermediateStream that extends the output stream, and that does
nothing on flush, and instead uses an Environment-protected method for
flushing, so we can play safe.
> c) Add a small logic checking the buffer size for the current response,
+1 and make it configurable.
> we have everything we need.
>
> This should work and it should also don't have any impact on the
> performance as 99% of it is already done.
At least we can see how it works.
Decoupling from the real stream gives us nice advantages it seems.
> I will give this a try today - and we can see if it works.
:-)
> But we should of course continue this discussion about the running modes.
Running modes is a nice idea that we already had sometime back, and that
now fortunately came back.
Basically with a single param it should be able to switch configurations.
Hence we can switch from a programmer env conf to a production one quite
easily.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Cocoon running modes (was Re: Error Handling is NOT working)
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Might be worth investigating into running modes. Hmm.
But comming back to the original problem ;) - We already have an
intermediate
output stream implemented and noone really complained about it:
Its the buffered output stream in the abstract text serializer...the only
problem here is that a) the size of the buffer might be too small
and b) the stream is flushed on recycle().
So, if we
a) Move this buffered output stream handling out of the serializer
into the environment and
b) Don't flush the stream on recycling a serializer and
c) Add a small logic checking the buffer size for the current response,
we have everything we need.
This should work and it should also don't have any impact on the
performance as 99% of it is already done.
I will give this a try today - and we can see if it works.
But we should of course continue this discussion about the running modes.
Carsten
> -----Original Message-----
> From: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
> Sent: Wednesday, September 11, 2002 4:46 PM
> To: cocoon-dev@xml.apache.org
> Subject: Cocoon running modes (was Re: Error Handling is NOT working)
>
>
> Torsten Curdt wrote:
>
> ><snip/>
> >
> >Guys, isn't it obvious we cannot realy provide errors in a user friendly
> >manner since we are delivering the page on-the-fly via SAX?
> Buffering the
> >whole page seems to reduce the positve aspects we get from using
> SAX and we
> >get closer to Cocoon1.
> >
> >Maybe we should have two different modes to run cocoon or at
> least pipelines
> >in: buffered and unbuffered. So one could use e.g. buffered for
> development
> >und unbuffered for deployment?!
> >
> >
>
> Is this buffer size only related to development ? I don't think so.
> Error-handlers can also be used in production to handle
> exceptional-but-foreseen conditions (access denied, unavailable
> resource, etc). So the buffer size isn't only a matter of running mode.
>
> However, running mode is a great idea, which could be used for many more
> things than buffer size :
> - central configuration for automatic reload of XSPs and sitemap in dev
> mode (and no reload in production mode),
> - display the Cocoon "blue screen of death" to the browser in dev mode
> and a gentle "system currently unavailable" in production mode,
> - other ideas ?
>
> Sylvain
>
> --
> Sylvain Wallez
> Anyware Technologies Apache Cocoon
> http://www.anyware-tech.com mailto:sylvain@apache.org
>
>
>
>
> ---------------------------------------------------------------------
> 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
Cocoon running modes (was Re: Error Handling is NOT working)
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Torsten Curdt wrote:
><snip/>
>
>Guys, isn't it obvious we cannot realy provide errors in a user friendly
>manner since we are delivering the page on-the-fly via SAX? Buffering the
>whole page seems to reduce the positve aspects we get from using SAX and we
>get closer to Cocoon1.
>
>Maybe we should have two different modes to run cocoon or at least pipelines
>in: buffered and unbuffered. So one could use e.g. buffered for development
>und unbuffered for deployment?!
>
>
Is this buffer size only related to development ? I don't think so.
Error-handlers can also be used in production to handle
exceptional-but-foreseen conditions (access denied, unavailable
resource, etc). So the buffer size isn't only a matter of running mode.
However, running mode is a great idea, which could be used for many more
things than buffer size :
- central configuration for automatic reload of XSPs and sitemap in dev
mode (and no reload in production mode),
- display the Cocoon "blue screen of death" to the browser in dev mode
and a gentle "system currently unavailable" in production mode,
- other ideas ?
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Error Handling is NOT working
Posted by Ivelin Ivanov <iv...@apache.org>.
Maybe I did not explain clearly what I meant.
SAX processing is extremely valuable and it should not be compromised. And
in fact it does not have to be.
Here is a simple suggestion.
What if we wrap the Cocoon servlet with another filter servlet?
This way the J2EE container (Servlets 2.3 compatible) will take care of
passing a secondary output stream to Cocoon.
Since it is just a dynamically expandable ByteArrayStream, it can be flushed
at any point.
Ivelin
----- Original Message -----
From: "Torsten Curdt" <tc...@dff.st>
To: <co...@xml.apache.org>
Sent: Wednesday, September 11, 2002 8:56 AM
Subject: Re: Error Handling is NOT working
<snip/>
Guys, isn't it obvious we cannot realy provide errors in a user friendly
manner since we are delivering the page on-the-fly via SAX? Buffering the
whole page seems to reduce the positve aspects we get from using SAX and we
get closer to Cocoon1.
Maybe we should have two different modes to run cocoon or at least pipelines
in: buffered and unbuffered. So one could use e.g. buffered for development
und unbuffered for deployment?!
With unbuffered we will always have the problem that after the first
generated
SAX event we cannot really make sure we are able to present an error page to
the user...
Or did I miss here something? Sorry, I haven't followed the thread very
closely up to now...
--
Torsten
---------------------------------------------------------------------
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: Error Handling is NOT working
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
> -----Original Message-----
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> Sent: Wednesday, September 11, 2002 4:04 PM
> To: cocoon-dev@xml.apache.org
> Subject: Re: Error Handling is NOT working
>
>
>
> Torsten Curdt wrote:
> > <snip/>
> >
> > Guys, isn't it obvious we cannot realy provide errors in a user
> friendly
> > manner since we are delivering the page on-the-fly via SAX?
> Buffering the
> > whole page seems to reduce the positve aspects we get from
> using SAX and we
> > get closer to Cocoon1.
> >
> > Maybe we should have two different modes to run cocoon or at
> least pipelines
> > in: buffered and unbuffered. So one could use e.g. buffered for
> development
> > und unbuffered for deployment?!
> >
> > With unbuffered we will always have the problem that after the
> first generated
> > SAX event we cannot really make sure we are able to present an
> error page to
> > the user...
> >
> > Or did I miss here something? Sorry, I haven't followed the thread very
> > closely up to now...
>
> What you propose above is what I *think* Carsten wants to propose, so I
> guess we are ok with it conceptually.
Exactly!
So, we only need someone who has enough time to just do it...
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Error Handling is NOT working
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Torsten Curdt wrote:
> <snip/>
>
> Guys, isn't it obvious we cannot realy provide errors in a user friendly
> manner since we are delivering the page on-the-fly via SAX? Buffering the
> whole page seems to reduce the positve aspects we get from using SAX and we
> get closer to Cocoon1.
>
> Maybe we should have two different modes to run cocoon or at least pipelines
> in: buffered and unbuffered. So one could use e.g. buffered for development
> und unbuffered for deployment?!
>
> With unbuffered we will always have the problem that after the first generated
> SAX event we cannot really make sure we are able to present an error page to
> the user...
>
> Or did I miss here something? Sorry, I haven't followed the thread very
> closely up to now...
What you propose above is what I *think* Carsten wants to propose, so I
guess we are ok with it conceptually.
From an implementation POV having an infinite buffer for the output and
prohibiting serializers to close the stream is IMHO the easy and
effective solution.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Error Handling is NOT working
Posted by Conal Tuohy <co...@paradise.net.nz>.
Torsten wrote:
> Guys, isn't it obvious we cannot realy provide errors in a
> user friendly
> manner since we are delivering the page on-the-fly via SAX?
> Buffering the
> whole page seems to reduce the positve aspects we get from
> using SAX and we
> get closer to Cocoon1.
>
> Maybe we should have two different modes to run cocoon or at
> least pipelines
> in: buffered and unbuffered. So one could use e.g. buffered
> for development
> und unbuffered for deployment?!
It seems to me that we should be able to buffer up to a point in the
pipeline, which wouldn't COMPLETELY negate the benefits of SAX. In some
cases it would be enough to buffer just the output of a Generator, for
instance. Or perhaps buffering could be turned on for a particular pipeline
with <pipeline buffer="true"> (another pipeline hint!)
Con
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Error Handling is NOT working
Posted by Torsten Curdt <tc...@dff.st>.
<snip/>
Guys, isn't it obvious we cannot realy provide errors in a user friendly
manner since we are delivering the page on-the-fly via SAX? Buffering the
whole page seems to reduce the positve aspects we get from using SAX and we
get closer to Cocoon1.
Maybe we should have two different modes to run cocoon or at least pipelines
in: buffered and unbuffered. So one could use e.g. buffered for development
und unbuffered for deployment?!
With unbuffered we will always have the problem that after the first generated
SAX event we cannot really make sure we are able to present an error page to
the user...
Or did I miss here something? Sorry, I haven't followed the thread very
closely up to now...
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Error Handling is NOT working
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Sylvain Wallez wrote:
>
> Ivelin Ivanov wrote:
>
> >----- Original Message -----
> >From: "Sylvain Wallez" <sy...@anyware-tech.com>
> >To: <co...@xml.apache.org>
> >Sent: Wednesday, September 11, 2002 8:01 AM
> >Subject: Re: Error Handling is NOT working
> >
> >
> >>Why does have a serializer to flush its output when it is recycled ?
> >>Flushing (and output stream management) is IMO the responsibility of the
> >>pipeline, and not that of the serializer.
> >>
> >>
> >
> >Agreed. The sitemap interpreter should flush the output stream when it's
> >done interpreting a request.
> >
> >
>
> [Picky mode on]
>
> Nope. Read carefully : "the responsibility of the *pipeline*" ! The
> sitemap responsibility is to build the pipeline by executing the sitemap
> instructions. The interpreter never touches the output stream : it gives
> the Environment object to the pipeline, and this is where the pipeline
> gets the stream.
>
I agree that it's the responsibility of the environment (or servlet) to
flush and close the output stream - but you can't prevent someone from
doing this.
And yes, increasing the buffer size would eliminate an intermediate stream,
if the size is big enough!
We are always talking of "a user friendly Cocoon" and this here is such a
point:
The problem can be solved by a configurable parameter for the buffer size
of the output stream. But this requires knowledge of this parameter and how
to configure it.
A user friendly system should be able to work as expected without changing
configuration parameters.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Error Handling is NOT working
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Ivelin Ivanov wrote:
>----- Original Message -----
>From: "Sylvain Wallez" <sy...@anyware-tech.com>
>To: <co...@xml.apache.org>
>Sent: Wednesday, September 11, 2002 8:01 AM
>Subject: Re: Error Handling is NOT working
>
>
>>Why does have a serializer to flush its output when it is recycled ?
>>Flushing (and output stream management) is IMO the responsibility of the
>>pipeline, and not that of the serializer.
>>
>>
>
>Agreed. The sitemap interpreter should flush the output stream when it's
>done interpreting a request.
>
>
[Picky mode on]
Nope. Read carefully : "the responsibility of the *pipeline*" ! The
sitemap responsibility is to build the pipeline by executing the sitemap
instructions. The interpreter never touches the output stream : it gives
the Environment object to the pipeline, and this is where the pipeline
gets the stream.
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Error Handling is NOT working
Posted by Ivelin Ivanov <iv...@apache.org>.
----- Original Message -----
From: "Sylvain Wallez" <sy...@anyware-tech.com>
To: <co...@xml.apache.org>
Sent: Wednesday, September 11, 2002 8:01 AM
Subject: Re: Error Handling is NOT working
>
> Why does have a serializer to flush its output when it is recycled ?
> Flushing (and output stream management) is IMO the responsibility of the
> pipeline, and not that of the serializer.
Agreed. The sitemap interpreter should flush the output stream when it's
done interpreting a request.
Ivelin
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Error Handling is NOT working
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Carsten Ziegeler wrote:
>Hi,
>
>I just have to repeat an email I wrote over a year ago, because the
>problem is getting worse:
>
>If an error occurs in the pipeline, the error handler is called and
>produces some output (or a response). At this time, the original
>pipeline could have already output some information and you might
>get an "response already committed" exception or something like that.
>
>Ok, so far so good, but since some time a serializer flushed the output
>stream when it is recycled...so the response is always already committed
>and the output stream can't be reset - and when the error handler trys
>to create its output, an exception is thrown!
>
>
Why does have a serializer to flush its output when it is recycled ?
Flushing (and output stream management) is IMO the responsibility of the
pipeline, and not that of the serializer.
>If we want to keep this error handler stuff I still vote for an
>intermediate output stream for the normal pipeline. This output stream
>"is copied" to the real output stream only if no error occurs.
>This is some extra performance cost - so we could make this somewhere
>configurable.
>
Wow ! As you say, this is an important extra cost for exceptional
conditions. I would prefer serializers not flushing and increasing the
buffer size (using a new servlet parameter ?).
>If anyone has a different solution, I'm all ears - but the current
>implementation is absolutely useless.
>
>
A quick grep shows that only AbstractTextSerializer flushes in its
recycle(). The fix seems easy.
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org