Sorry to bump this thread. I'm willing to pay for some assistance if
anyone's interested in helping. I'm trying to figure out 2 problems
when running my system under a light-moderate load test:
1) why do my comet timeout events not get generated on time (supposed
to be every 50 seconds,
I'm trying to figure out how best to configure nio so that my comet
timeout events get generated in a timely manner. I have the comet
events set to generate a timeout every 50 seconds. Works fine with
few users. Under a moderate but reasonable load the timeout gets
generated on average every
How do I distinguish between a comet END event generated due to a
client disconnect and an end event generated for some other reason?
I'm using tomcat 6.0.18 with the nio connector. On both windows xp
sp3 and ubuntu 8.10, I'm seeing END events generated when a client
disconnects and for other
CLIENT_DISCONNECT is only used a subtype of ERROR
and that happens when the socket is closed from the client side
When a client disconnects (i.e. socket is closed from the client
side), I see an END event on both Windows and Ubuntu. I expected an
ERROR event with a subtype of
Looking for nio configuration tips for 6.0.18...
I have an ajax app that uses a single socket connection for sending
standard http requests and receiving responses, and another socket
connection to listen via comet for messages pushed out by the server.
A comet timeout is generated every 50
Thanks for the tips. Very helpful.
I also get the warning when trying to use keepAliveTimeout.
Is this property available for the nio connector?
No; it's only listed under the older connector (the one labeled Standard
Implementation that then somewhat ambiguously refers to HTTP).
I
Thanks for the pointer. That bug does look related, as does this one:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6403933 -- fixed
against java 7.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For
I'm running tomcat 6.0.18 on Ubuntu 8.10. I have a comet application
that maintains an open connection with tomcat. If I re-start my
webapp and then close the client connection, tomcat goes into a loop
and chews up all cpu. This server is not live and only has my single
client.
The
What JVM are you using? The stack trace doesn't look like anything that a
HotSpot JVM would produce.
It's Sun Java 1.6.0_10-b33. I grabbed the trace from my eclipse
debugger. And I see the loop when running both with and without vm
debug flags.
Peter
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
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 where to go
Peter Warren wrote:
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
, however, thanks for pointing it out,
you did find a regression bug about the timeout
http://svn.apache.org/viewvc?view=revrevision=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 mentioned, the last chunk doesn't
[] outputBytes = new String(0 +
DELIMITER+DELIMITER).getBytes(ENCODING);
outputStream.write(outputBytes);
outputStream.flush();
}
}
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
:
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
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
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 incessantly.
I'm using
Filip
Peter Warren wrote:
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
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 incessantly.
I'm using an unsigned applet as a comet client. To accommodate
proxies,
This post (http://www.nabble.com/comet-questions-td14673697.html#a14673697)
contains test code for both a client comet servlet. See if it
helps.
On Jan 16, 2008 10:35 AM, Siobhan [EMAIL PROTECTED] wrote:
To anyone who has successfully used Comet:
I've been trying to use Comet with Tomcat
maxThreads=500
connectionTimeout=1 keepAliveTimeout=3
maxKeepAliveRequests=-1 socket.soKeepAlive=true
socket.appReadBufSize=2048 socket.appWriteBufSize=2048
socket.rxBufSize=2048 socket.txBufSize=2048
acceptorThreadCount=2 redirectPort=8443 /
On Jan 9, 2008 12:23 PM, Peter Warren [EMAIL
), to run the checks. In my case, this buffering lasts for minutes,
with no byte sent back to the browser.
I think this can be a simple point to check...
Hugs,
Leonardo Fraga
Web Developer
[EMAIL PROTECTED]
Peter Warren wrote:
I posted this question along with some others recently. I'm
re
I posted this question along with some others recently. I'm
re-posting it in its own thread with some additional information.
I have a comet client app that works on all the machines I've tested
except one. The failing machine sends a comet request to the server
and then waits indefinitely for
I have some comet questions. I'm using the tomcat 6.0.x trunk as of
last Friday.
1) My comet event timeout setting being honored. How come? I set the
timeout for 3 hours but a timeout event gets generated every 2
minutes. If I inspect the comet event for which the timeout is
triggered, I see
it out (ie
after you've written to and flushed your stream).
also, there have been some bug fixes, that you can get from SVN, or wait
for 6.0.16 to come out
Filip
Peter Warren wrote:
I have some comet questions. I'm using the tomcat 6.0.x trunk as of
last Friday.
1) My comet event
)
- class[] (ACCB)
- org.apache.catalina.connector.Request (ACCC)
Peter
On 9/7/07, Morten [EMAIL PROTECTED] wrote:
Peter Warren [EMAIL PROTECTED] skrev i en meddelelse
news:[EMAIL PROTECTED]
Is it possible you're caching Request or Response objects somewhere
and not releasing them? I just did
Is it possible you're caching Request or Response objects somewhere
and not releasing them? I just did a bunch of memory profiling and
many of the classes you mention are the same classes I see when I open
and don't close a bunch of connections to the server.
I have a webapp that maintains many concurrent comet connections.
Transmissions between the client and server are small and infrequent.
I'm trying to lessen the memory usage by playing with buffer
configurations.
To test various configurations, I wrote a client that opens 2000
connections to a
A comet read event doesn't update the last accessed time of an
HttpSession -- which means comet read events will never prevent an
http session (not the comet session) from timing out and the
connection getting closed.
Is that by design? If so, can anyone offer me suggestions on how to
handle
How do you send multiple requests to the same comet servlet?
Sending multiple chunks of a single request is fine. My problem occurs
after the client ends the chunked transaction by sending 0CRLFCRLF to the
server. The comet servlet correctly registers the END event.
But then the client
take
a look and see why it is happening,
Filip
Peter Warren wrote:
How do you send multiple requests to the same comet servlet?
Sending multiple chunks of a single request is fine. My problem occurs
after the client ends the chunked transaction by sending 0CRLFCRLF to the
server. The comet
available, I'll run it through
Filip
Peter Warren wrote:
Yes, I'm using the NIO connector. Here is the config line from my
server.xml:
Connector port=80
protocol=org.apache.coyote.http11.Http11NioProtocol maxThreads=150
connectionTimeout=2 keepAliveTimeout=12
();
}
Peter Warren wrote:
Thanks for the suggestion. I changed the comet test servlet to read
directly from the input stream as shown in the advanced io example. I'm
still seeing the same behavior. No comet read event gets generated on
the server, only the begin event which contains
. the comet is somewhat like
a real socket, and sending up new HTTP headers might end up just being
data for the Comet servlet.
Filip
Peter Warren wrote:
My client code was the problem. I had been thinking of the comet
interaction with the server as similar to a socket, open it once
advantage of the available() method
Filip
Peter Warren wrote:
My BEGIN block in my comet servlet now looks like the code below (added
a while loop to read until the buffer is empty). Is that what you had
in mind? The buffer in the BEGIN event only contains the client's first
message. Am I
other configuration options I need to set?
Peter
Filip Hanik - Dev Lists wrote:
and you are using the APR or the NIO connector right?
Filip
Peter Warren wrote:
Thanks for the suggestion. I changed the comet test servlet to read
directly from the input stream as shown in the advanced io
The following client code generates a comet BEGIN event on the server
but not a subsequent READ event, as I was expecting. How come? Is my
code wrong? Are my expectations wrong? See sequence of events
commented in code below.
// client test method that sends messages to server and listens
already came in with the
request.
when the BEGIN happens, perform the actions as if there was a READ as
well, ie, empty out the buffer.
Filip
Peter Warren wrote:
The following client code generates a comet BEGIN event on the server
but not a subsequent READ event, as I was expecting. How come
Chris,
The application is an image gallery. I want to be able to drop images into
directories anywhere underneath the gallery webapp directory and have the
images automatically displayed as thumbnails in a table. Users can click on a
thumbnail for the full-size image. I have an
Hi Chris,
Thanks for your response. After poking around a little more, it seems that the
call
application.getRealPath(request.getServletPath())
provides the proper local file path for me. Any reason not to use that?
Peter
Christopher Schultz [EMAIL PROTECTED] wrote: Peter,
I'm
I'm trying to figure out why I get repeated directory names when calling
application.getRealPath(request.getRequestURI()) from an index.jsp
file. Clearly there's something about virtual hosts and contexts that
I'm missing.
Using Tomcat 5.5 6.0 in standalone mode under Windows XP, I see the
I have an application that links users so they can chat. My client
operates within a browser. To be firewall friendly and avoid client
server sockets listening for incoming requests, I implemented the client
so that it makes http requests and sits and waits (maybe for minutes on
end) until it
42 matches
Mail list logo
