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 d

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 so

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.

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

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 fo

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 co

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 w

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

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 ev

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 RuntimeExcept

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

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.getHtt