tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 50495] Comet connector needs ability to access the client send queue.
Date Tue, 04 Jan 2011 15:38:31 GMT
https://issues.apache.org/bugzilla/show_bug.cgi?id=50495

--- Comment #3 from Mark Thomas <markt@apache.org> 2011-01-04 10:38:25 EST ---
(In reply to comment #2)
> I have no idea when data is written to a socket from Tomcat.
This is open source. You could have looked it up. The users list is always very
helpful to folks trying to understand Tomcat's internals and needing a few
pointers. The short version is:
'out' -> 8k buffer -> socket

> I need to know when you write messages "under Tomcat control" - this is all I
> need.
It depends. The above buffer is flushed if it is full or if a call is made to
out.flush(). Once the buffer is flushed, Tomcat has no control over the data.

> I am sure you have some concept of "client message queue".
As I said before, Tomcat has no concept of a message so there is no message
queue. The bytes are treated as just that - bytes. There is nothing the
delimits messages which are an application defined concept. If there are 5,000
bytes to be written the client, Tomcat has no idea if they represent 10*500
byte message or 1000*5 byte messages.

> This is an a enhancement to address a bug in my opinion. As of now, a single
> client has the ability to deplete resources of the whole server.
That shouldn't happen. The NIO connector uses simulated blocking so the call to
out.write() should block if the socket send buffer is full. If memory serves me
correctly, that is around 30k. If you have a simple test case that demonstrates
an OOME then please re-open this issue, attach it and someone will take a look.

> This makes  Tomcat Comet technology a toy for college projects at best.
> Completely unsuitable for production application.
That sort of comment isn't going to encourage any of the folks here (who are
all volunteers) to help you.

> I have no choice but to look for alternative implementations.
You are, of course, free to do that is you wish.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message