ok now it is properly configured(I was missing the slash at the end of the
tag), but Im still getting null for event subtypes. Any thoughts?
On Fri, Aug 1, 2014 at 11:18 AM, Elias Kopsiaftis wrote:
> ok looks like i have the configuration of
> org.apache.catalina.valves.CometConnectionManagerV
ok looks like i have the configuration of
org.apache.catalina.valves.CometConnectionManagerValve
wrong. sorry about that. Still have the random disconnect error though
On Fri, Aug 1, 2014 at 10:46 AM, Elias Kopsiaftis wrote:
> I am developing a COMET application that is primarily based on the e
Peter Warren wrote:
Could you indulge me and try the client with the sleep?
just did, worked exactly as before.
event: BEGIN, subtype: null
event: READ, subtype: null
Read 10 bytes: comet test for session: A01334D0AC22505DCD4B323820963FEC
read error
event: ERROR, subtype: TIMEOUT
> > Could you indulge me and try the client with the sleep?
> >
> just did, worked exactly as before.
> event: BEGIN, subtype: null
> event: READ, subtype: null
> Read 10 bytes: comet test for session: A01334D0AC22505DCD4B323820963FEC
> read error
> event: ERROR, subtype: TIMEOUT
Hmm, not sure whe
Peter Warren wrote:
Could you indulge me and try the client with the sleep?
just did, worked exactly as before.
event: BEGIN, subtype: null
event: READ, subtype: null
Read 10 bytes: comet test for session: A01334D0AC22505DCD4B323820963FEC
read error
event: ERROR, subtype: TIMEOUT
I see the e
Could you indulge me and try the client with the sleep?
I see the end event when there's a break/delay between sending a chunk
and sending the last chunk. It is legal http to send the last chunk
separately from preceding chunks, isn't it?
> getting a -1 on a inputstream.read is normal (even for
getting a -1 on a inputstream.read is normal (even for a regular
servlet). that means you've reached EOF and shouldn't read anymore.
I haven't tested with the sleep, and I did try with the cometgui, and
that worked as well.
Filip
Peter Warren wrote:
Is the read error expected behavior? I g
Is the read error expected behavior? I guess I didn't expect the
comet processor to send me a read event on a last chunk since there's
nothing to be read. I thought either a read error or an end event
after a last chunk indicated a problem. If the read error is ok,
then...
Did you try the clien
works just dandy, the timeout happens after quite some time of just waiting
Jan 28, 2008 2:33:31 PM org.apache.coyote.http11.Http11NioProtocol start
INFO: Starting Coyote HTTP/1.1 on http-8080
Jan 28, 2008 2:33:31 PM org.apache.catalina.startup.Catalina start
INFO: Server startup in 1005 ms
event
ector is a supported TC6 feature
Thanks
Martin
- Original Message -
From: "Peter Warren" <[EMAIL PROTECTED]>
To: "Tomcat Users List"
Sent: Friday, January 25, 2008 2:38 PM
Subject: Re: comet end event
I put up a war file at: http://www.nomad.org/comet_test.war.
I cant say implementing the
NIOConnector is a supported TC6 feature
Thanks
Martin
- Original Message -
From: "Peter Warren" <[EMAIL PROTECTED]>
To: "Tomcat Users List"
Sent: Friday, January 25, 2008 2:38 PM
Subject: Re: comet end event
> I put up a war file at: http
I put up a war file at: http://www.nomad.org/comet_test.war.
It includes the webapp, source for the comet servlet & client, and the
server.xml file. Let me know if I missed anything.
As I mentioned before, I've also used your cometgui.jar client and see
the end event generated when using it as w
even with your code, I wasn't able to replicate what you were seeing.
what I would need to see what's going on for you:
1. a war file with your comet server, and source code
2. a test client
3. your server.xml
Filip
Peter Warren wrote:
Thanks, Filip, for your time on this! I used your change
Thanks, Filip, for your time on this! I used your changes and still
get an END event. With your changes the client and socket are
definitely staying alive now. I stepped through the client code and
see the end event appear on the server as soon as I step through the
line that writes the 0crlfcrl
as an addendum, the END event that you were seeing was caused by an EOF
being sent from your test client to the server.
Filip
Peter Warren wrote:
Just to make sure that I wasn't crazy, I did some more tests,
including using your cometgui.jar. My results still show both read
errors and END eve
your test client is wrong,I've pasted in the correct one
only three changes
1. set the timeout so that the socket stays alive
2. keep reading data so that the socket stays alive
3. 0crlfcrlf as the last chunk
works as expected. to make a workable client, it should read until it
gets the last-ch
Just to make sure that I wasn't crazy, I did some more tests,
including using your cometgui.jar. My results still show both read
errors and END events. Is it possible that it's a platform issue?
I'm running Windows XP Pro SP2. As I mentioned before I'm using the
tomcat 6.0.x trunk as of 21-01-20
cat Users List"
Sent: Tuesday, January 22, 2008 11:58 AM
Subject: Re: comet end event
> I'll take a look at this for you!
>
> Filip
>
> Peter Warren wrote:
> >> as I mentioned, the "last chunk" doesn't generate an END event, I
tried
> >>
I just tried again, and I didn't get your scenario.
however, it may appear that is happening if you try to close the comet
event asynchronously, and then send a new request directly, since at
that point, you don't have a valid chunk, instead it is trying to parse
the next request as a chunk
F
I still don't get the END event, however, thanks for pointing it out,
you did find a regression bug about the timeout
http://svn.apache.org/viewvc?view=rev&revision=614249
I've added the patch above to the proposal list for 6.0.x to fix the
timeout issue
Filip
Peter Warren wrote:
as I men
I'll take a look at this for you!
Filip
Peter Warren wrote:
as I mentioned, the "last chunk" doesn't generate an END event, I tried
it locally. of course against 6.0.x trunk.
I played around a bit because I was definitely getting an END event
and found: Sending 0crlf does not generate a
> as I mentioned, the "last chunk" doesn't generate an END event, I tried
> it locally. of course against 6.0.x trunk.
I played around a bit because I was definitely getting an END event
and found: Sending 0crlf does not generate and END event. However
sending 0crlfcrlf, which is what HttpURLCon
answers inline
Peter Warren wrote:
First off, thanks for your responses. The contributors to this list
are extremely responsive, patient, and helpful, and I really
appreciate it!
Hmm, in your test case did you set the HttpURLConnection to use
chunked transfers (setChunkedStreamingMode(...))?
First off, thanks for your responses. The contributors to this list
are extremely responsive, patient, and helpful, and I really
appreciate it!
Hmm, in your test case did you set the HttpURLConnection to use
chunked transfers (setChunkedStreamingMode(...))? I find if I use
chunked transfers, the
now I get it. I just ran through a test case, and an END event was not
thrown just because there was an end chunk.
the response is very much still open at that point
Filip
Peter Warren wrote:
What java.net.HttpURLConnection has to do with Tomcat and comet is
that HttpURLConnection is Java's
What java.net.HttpURLConnection has to do with Tomcat and comet is
that HttpURLConnection is Java's implementation of an http client and
will likely be used by people developing comet apps for Tomcat. In my
case, I want to use it because I can't use raw sockets on my applet
client due to permissio
I'm not sure what HttpURLConnection has to do with Tomcat or comet.
and yes, asynchronous writes are possible, just not after the END or
ERROR events have been issued
Filip
Peter Warren wrote:
Does that mean that HttpURLConnection cannot be used for comet
requests with asynchronous (i.e. dela
Does that mean that HttpURLConnection cannot be used for comet
requests with asynchronous (i.e. delayed) responses?
It would seem so to me since HttpURLConnection always sends an END
message before reading from the server and since the server can no
longer write to the client after closing the com
during end and error, you MUST close the Comet event
Filip
Peter Warren wrote:
What do I do to make the END event stop repeating? I don't want to
close the CometEvent yet because the server is waiting for data to
send to the client. If I don't close the comet event, the END event
repeats ince
29 matches
Mail list logo
