Re: Tomcat 6.0.10 Comet question
Rémy Maucherat wrote:
On 4/3/07, Filip Hanik - Dev Lists [EMAIL PROTECTED] wrote:
yes, a proposal is coming up, my guess is that you will do a {public int
write(ByteBuffer)} on the CometEvent object. returns number of bytes
written, but nothing is set in stone yet
I hope that your proposal does not include that sort of API, because
I'm not going to like it if it does.
I'm still noodling on it :), my old brain just needs some time, ideally
I want to find a transparent way.
Filip
Rémy
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 6.0.10 Comet question
Hi, Thanks again for the reply. I can't reproduce the END event so probably I was mistaken, sorry about that. It is indeed the ERROR/TIMEOUT event. If an exception occurs during the handling of this event (an unforseen runtime exception for example), then tomcat calls the event method again with the ERROR/TIMEOUT event, ad infinitum (or at least lots of times ;-)) Regards, Sebastiaan Rémy Maucherat wrote: On 4/2/07, Rémy Maucherat [EMAIL PROTECTED] wrote: I was also just discovered that in the 6.0.10 version that an exception in the END event causes the END event to called again; this means that an uncaught RuntimeException could potentially cause Tomcat to go into a loop of an infinite number of END events. I will verify that. I have looked at it, and I don't understand the issue. First of all, END is a theorical event, which cannot really be called at the moment, except in very specific cases (when the connector is stopped). Can you give more details ? Maybe you meant ERROR ? Rémy - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 6.0.10 Comet question
Hi, Another reason that I need to be able to throw the exception in the BEGIN event is because for some requests there is no input, only output, so I might never actually get a READ event (GET requests for long pieces of data for example). However I do want to write output to the client as it comes in (which is why I need Comet) and it's not a file, it is a dynamically generated stream, making the standard servlet (serivce method) approach infeasable from a scalability point of view. You don't have to wait to be inside the processing of a read event to write data. But I need to verify if the request is valid, and since I don't know if there will be a read event the only place I can do it is in the begin event. Throwing the ServletException there was my way of dealing with the invalid request; that was why I needed to throw it in the begin event and not somewhere else. Regards, Sebastiaan - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 6.0.10 Comet question
On 4/3/07, Sebastiaan van Erk [EMAIL PROTECTED] wrote: Hi, Thanks again for the reply. I can't reproduce the END event so probably I was mistaken, sorry about that. It is indeed the ERROR/TIMEOUT event. If an exception occurs during the handling of this event (an unforseen runtime exception for example), then tomcat calls the event method again with the ERROR/TIMEOUT event, ad infinitum (or at least lots of times ;-)) Ok, it's the same for a read then (for which I could reproduce a loop), as error/timeout is not really an error (it gives you the opportunity to close end the request if you want to by calling event.close). Rémy - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 6.0.10 Comet question
Hi, Thanks for all the answers! :-) It's good to know the way the events should be treated and interpreted. It's quite different from how it's described on http://tomcat.apache.org/tomcat-6.0-doc/aio.html, and the JavaDoc does not really describe the spec either. Using the sendError method in the response and the new interpretation of the events I think I will be able to manage. One more question though: is there any way to do nonblocking output of dynamic content (streams)? The above documentation only talks about files on the file system. Regards, Sebastiaan Rémy Maucherat wrote: On 4/3/07, Sebastiaan van Erk [EMAIL PROTECTED] wrote: Hi, Thanks again for the reply. I can't reproduce the END event so probably I was mistaken, sorry about that. It is indeed the ERROR/TIMEOUT event. If an exception occurs during the handling of this event (an unforseen runtime exception for example), then tomcat calls the event method again with the ERROR/TIMEOUT event, ad infinitum (or at least lots of times ;-)) Ok, it's the same for a read then (for which I could reproduce a loop), as error/timeout is not really an error (it gives you the opportunity to close end the request if you want to by calling event.close). Rémy - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 6.0.10 Comet question
Sebastiaan van Erk wrote:
Hi,
Thanks for all the answers! :-)
It's good to know the way the events should be treated and
interpreted. It's quite different from how it's described on
http://tomcat.apache.org/tomcat-6.0-doc/aio.html, and the JavaDoc does
not really describe the spec either.
Using the sendError method in the response and the new interpretation
of the events I think I will be able to manage.
One more question though: is there any way to do nonblocking output of
dynamic content (streams)? The above documentation only talks about
files on the file system.
yes, a proposal is coming up, my guess is that you will do a {public int
write(ByteBuffer)} on the CometEvent object. returns number of bytes
written, but nothing is set in stone yet
Filip
Regards,
Sebastiaan
Rémy Maucherat wrote:
On 4/3/07, Sebastiaan van Erk [EMAIL PROTECTED] wrote:
Hi,
Thanks again for the reply. I can't reproduce the END event so probably
I was mistaken, sorry about that. It is indeed the ERROR/TIMEOUT event.
If an exception occurs during the handling of this event (an unforseen
runtime exception for example), then tomcat calls the event method
again
with the ERROR/TIMEOUT event, ad infinitum (or at least lots of
times ;-))
Ok, it's the same for a read then (for which I could reproduce a
loop), as error/timeout is not really an error (it gives you the
opportunity to close end the request if you want to by calling
event.close).
Rémy
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 6.0.10 Comet question
On 4/3/07, Filip Hanik - Dev Lists [EMAIL PROTECTED] wrote:
yes, a proposal is coming up, my guess is that you will do a {public int
write(ByteBuffer)} on the CometEvent object. returns number of bytes
written, but nothing is set in stone yet
I hope that your proposal does not include that sort of API, because
I'm not going to like it if it does.
Rémy
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 6.0.10 Comet question
Hi, Thanks for the response. To get these adjustments, do I need to download tomcat from a subversion (or CVS) repository? I was also just discovered that in the 6.0.10 version that an exception in the END event causes the END event to called again; this means that an uncaught RuntimeException could potentially cause Tomcat to go into a loop of an infinite number of END events. The reason I need to be able to throw an exception in the BEGIN event is because each request belongs to a certain client. I already know which client it belongs to from the http headers. If the client has timed out or does not exist on the server, the request is invalid. Thus I don't have to wait for a READ event to throw the error. Another reason that I need to be able to throw the exception in the BEGIN event is because for some requests there is no input, only output, so I might never actually get a READ event (GET requests for long pieces of data for example). However I do want to write output to the client as it comes in (which is why I need Comet) and it's not a file, it is a dynamically generated stream, making the standard servlet (serivce method) approach infeasable from a scalability point of view. Does this make sense or am I going about it the wrong way? Regards, Sebastiaan Rémy Maucherat wrote: I have made some adjustments. An exception there should produce an error report, and a sendError should do the same. However, an event.close should simply end the processing of the request without any change of the response state (which will be whatever was set in the servlet). Note: the purpose of begin is to setup any data structures to track the future events on the connection, so you're not really supposed to throw exceptions while processing that. Rémy - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 6.0.10 Comet question
On 4/2/07, Sebastiaan van Erk [EMAIL PROTECTED] wrote: Hi, Thanks for the response. To get these adjustments, do I need to download tomcat from a subversion (or CVS) repository? Yes. I was also just discovered that in the 6.0.10 version that an exception in the END event causes the END event to called again; this means that an uncaught RuntimeException could potentially cause Tomcat to go into a loop of an infinite number of END events. I will verify that. Another reason that I need to be able to throw the exception in the BEGIN event is because for some requests there is no input, only output, so I might never actually get a READ event (GET requests for long pieces of data for example). However I do want to write output to the client as it comes in (which is why I need Comet) and it's not a file, it is a dynamically generated stream, making the standard servlet (serivce method) approach infeasable from a scalability point of view. You don't have to wait to be inside the processing of a read event to write data. Rémy - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 6.0.10 Comet question
On 4/2/07, Rémy Maucherat [EMAIL PROTECTED] wrote: I was also just discovered that in the 6.0.10 version that an exception in the END event causes the END event to called again; this means that an uncaught RuntimeException could potentially cause Tomcat to go into a loop of an infinite number of END events. I will verify that. I have looked at it, and I don't understand the issue. First of all, END is a theorical event, which cannot really be called at the moment, except in very specific cases (when the connector is stopped). Can you give more details ? Maybe you meant ERROR ? Rémy - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat 6.0.10 Comet question
Hi,
I'm trying to use Comet in tomcat 6.0.10, and have the following test class:
public class CometServlet extends HttpServlet implements CometProcessor {
public void event(final CometEvent event) throws IOException,
ServletException {
final HttpServletRequest request = event.getHttpServletRequest();
final HttpServletResponse response = event.getHttpServletResponse();
if (event.getEventType() == CometEvent.EventType.BEGIN) {
throw new ServletException(test message);
} else if (event.getEventType() == CometEvent.EventType.ERROR) {
// ...
event.close();
} else if (event.getEventType() == CometEvent.EventType.END) {
// ...
event.close();
} else if (event.getEventType() == CometEvent.EventType.READ) {
// ...
}
}
}
When I make a request to Tomcat and set a breakpoint on the event
method, I see that I get a BEGIN event and the servlet exception is
thrown. The exception appears in my Tomcat log. However, the client
connection is not terminated. Instead, after waiting for a while, I get
another event: the ERROR/TIMEOUT event. The call to event.close() then
causes the request to be finished, and the client gets a 200 response
with an empty body.
The behavior I am trying to create is different though: I would like a
500 response to the client as soon as the error condition arises (the
exception is thrown). I tried a try { throw exception; } finally {
event.close(); }, but it seems that event.close() causes a 200 response
no matter what.
How do I get the CometProcessor to give the client a 500 response
immediately? Note that I have not written anything to the response, so
it is not comitted yet.
Thanks for any help/pointers,
Sebastiaan
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 6.0.10 Comet question
I have made some adjustments. An exception there should produce an error report, and a sendError should do the same. However, an event.close should simply end the processing of the request without any change of the response state (which will be whatever was set in the servlet). Note: the purpose of begin is to setup any data structures to track the future events on the connection, so you're not really supposed to throw exceptions while processing that. Rémy - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
