all, I have made a little image that would explain the idea I have (and
implemented today) for the Tomcat model, would like to get some feedback,
Remy and I already have an open dialogue, but its subjected under a
commit, so if you didn't read that one, this one has a nice pix
also available at
this doesn't break the original Comet model, it is backwards compatible,
yet it extends a little bit further making it more useful for no latency
lagging
Filip

Lemme narrow everything down, and this will be short, I promise,

it all boils down to the Content-Length header,
if this header is omitted then it wont be possible for the client to
send more than one request.

The workaround for this, Content-Length: Integer.MAX_VALUE, this will
make the code accept more than one request

If that is acceptible workaround, I can happily revert the commit.

Filip

Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
>and that is the exact bug I fixed. Before the commit, you couldn't.
>So to support your argument, you should be in favor of the commit.
>not against.
>
, then post the request you are sending. The whole request must be a
valid HTTP/1.1 request with a properly delimited body, rather than
just a HTTP header, followed by random data.

This is not a valid request, for example:

GET /foo HTTP/1.1
Host: bla

my content (wait 10 s) more of my content

I fail to see what your purpose is to step on my toes like this, and
barge in with commit, when you didn't discuss anything.
>not sure what your toes and the ASF owned repository have in common ;)
>
To give an example: I suppose I could try committing random stuff to
the clustering module.
>
>We're discussing it now, you started it with a veto, and yes, i could
>have used the endless discussion tactic to prove the bug, but it was
>faster to come in with a solution.
>
That's what you are doing right now, rather than convince me that you
understand all the issues.

, I'm going to bed now, and then on WE. I hate it when people force
me to stay up until 2AM on friday just because I made the mistake of
checking my email before going to bed

R

To unsubscribe, e-mail: dev-unsubscribe (AT) tomcat (DOT) apache.org
For additional commands, e-mail: dev-help (AT) tomcat (DOT) apache.org
--

Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
>yes, but to do so, you would be required to pre calculate the content
>length for the 2 (or N events), and if the server hasn't responded
>(since its async) you can't send the 2nd event as you could start a
>new HTTP request on the same connection when there hasn't been a
>response. So to open your self up for async push for both client and
>server, you omit content length, or set it to an extremely large value.
>>
>see where I am getting it?
>
Yes, I do.

Comet "designers" got the idea too (most likely they want to work
somewhat with proxies), and so Comet must use chunking on input (as
any decent HTTP user agent would do automagically) and output (Tomcat
will do it automagically too). This way it works without breaking the
protocol and without having to compute the total length of the
request/response beforehand. course, you can have easy testing of
the code by using (fake) large content-length values like I did, but
that's for local testing only.
how can tomcat know the Content-Length down to the client, when servlets
and JSP call flushBuffer, or the response(s) are two big to fit in the
buffer?
At that point, its up to the servlet programmer to send the content
length, but again, how would they know in advance the size of the total
response,

so chunking becomes difficult
Filip

R

To unsubscribe, e-mail: dev-unsubscribe (AT) tomcat (DOT) apache.org
For additional commands, e-mail: dev-help (AT) tomcat (DOT) apache.org
--

I agree, chunked would be the way to go for a communication.

I reverted my fix, however, now TC6 has a DS possibility, by following
these steps

1. CometServlet.read, always return true (you wanna serve N
client requests, and you don't know how many its gonna send, so this is
not unreasonable)
2. Client sends data with Content-Length
PST /comet?count=001 HTTP/1.1\r\n
Host: 127.0.0.1:8080
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1)
Gecko/20060124 Firefox/1.5.0.1\r\n
Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5\r\n
Accept-Language: en-us,en;q=0.5\r\n
Accept-Encoding: gzip,deflate\r\n
Accept-Charset: IS,utf-8;q=0.7,*;q=0.7\r\n
Keep-Alive: 300\r\n
Connection: keep-alive\r\n
Content-Type: text/plain\r\n
Content-Length: 16\r\n
\r\n
submit=value8888
3. client then sends any data (http request, garbage, anything)
4. Tomcat server hangs in a loop on that thread

5. Repeat steps 1-4 for as many as there are threads in the pool, and we
have DS

Filip

Costin Manolache wrote:
Not sure I understand all details here - but chunking seems like a better
solution
than sending a bad Content-Length.

Sending a too large or incorrect content-length may break a lot of
things (
and be rejected,
affect proxies, etc ).

Costin
--
6/16/06, Filip Hanik - Dev Lists <devlists (AT) hanik (DOT) comwrote:
>>
>Remy Maucherat wrote:
>Filip Hanik - Dev Lists wrote:
>>yes, but to do so, you would be required to pre calculate the content
>>length for the 2 (or N events), and if the server hasn't responded
>>(since its async) you can't send the 2nd event as you could start a
>>new HTTP request on the same connection when there hasn't been a
>>response. So to open your self up for async push for both client and
>>server, you omit content length, or set it to an extremely large
>value.
>>>
>>see where I am getting it?
>>
>Yes, I do.
>>
>Comet "designers" got the idea too (most likely they want to work
>somewhat with proxies), and so Comet must use chunking on input (as
>any decent HTTP user agent would do automagically) and output (Tomcat
>will do it automagically too). This way it works without breaking the
>protocol and without having to compute the total length of the
>request/response beforehand. course, you can have easy testing of
>the code by using (fake) large content-length values like I did, but
>that's for local testing only.
>how can tomcat know the Content-Length down to the client, when servlets
>and JSP call flushBuffer, or the response(s) are two big to fit in the
>buffer?
>At that point, its up to the servlet programmer to send the content
>length, but again, how would they know in advance the size of the total
>response,
>>
>so chunking becomes difficult
>Filip
>>
>>
>Rmy
>>
>
>To unsubscribe, e-mail: dev-unsubscribe (AT) tomcat (DOT) apache.org
>For additional commands, e-mail: dev-help (AT) tomcat (DOT) apache.org
>>
>>
>>
>>
>--
>>
>>
>Filip Hanik
>>
>
>To unsubscribe, e-mail: dev-unsubscribe (AT) tomcat (DOT) apache.org
>For additional commands, e-mail: dev-help (AT) tomcat (DOT) apache.org
>>
>>

No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.9.0/367 - Release Date: 6/16/2006

Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
>I agree, chunked would be the way to go for a communication.
>>
>I reverted my fix, however, now TC6 has a DS possibility, by
>following these steps
>>
>1. CometServlet.read, always return true (you wanna serve N
>client requests, and you don't know how many its gonna send, so this
>is not unreasonable)
>
I fail to see why doing that is reasonable: you're getting an event to
read data, so you have to read it even if you're not going to use it
(as in NI).
yes, and since I am receiving the read event, I'm expecting data, no
data was available, so I return true to wait for it become available.
Tomcat fails to deliver the data, even though it issues a read(req,resp)
event.
Two solutions
1. Deliver the data (my reverted checkin)
2. Read the socket, discard the data, never call read

Right now I'm not hot about reading the data first in the container:
if done, it should be in InputBuffer,
yes, that is how I suggested it to be done. The AprBuffer was reading
the socket data in my checkin.

but could mean automagically discarding data, which could become a
very sneaky problem if the user doesn't code the right way but is
interested in the data.
yes, I prefer delivering the data. option 1

There are still some serious problems though, starting with the
current C2B and B2C converters which use far too much memory. I would
like to use the NI converters instead, but they want to use
ByteBuffer and CharBuffer.
yes, and ByteBuffer and CharBuffer have historically been slower than
byte[] and char[], not sure if that is still the case.

Rmy
so where do we stand, you cool now? can I go back and work on my
checkin, improve it, and continue working on the Comet feature?

Filip

To unsubscribe, e-mail: dev-unsubscribe (AT) tomcat (DOT) apache.org
For additional commands, e-mail: dev-help (AT) tomcat (DOT) apache.org
--

Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
Right now I'm not hot about reading the data first in the container:
if done, it should be in InputBuffer,
>yes, that is how I suggested it to be done. The AprBuffer was reading
>the socket data in my checkin.
>>
but could mean automagically discarding data, which could become a
very sneaky problem if the user doesn't code the right way but is
interested in the data.
>yes, I prefer delivering the data. option 1
>
The point of your patch was not to preread the data as you are now
claiming, but instead about accepting entity bodies from invalid
requests. As I said, I prefer the current mechanism.
I see your point, and fair enough, chunked is the way to go for multi
client requests, brings a question to my mind. my patch delivered the
data. but if you don't wanna do that, you should at least discard the
data and never invoke read, (and maybe even terminate the connection)
and this is the problem I'm trying to address, to deliver or not to
deliver the data I can live with, as you are correct on the content
length, that was just one part of it, its the loop I'm trying to avoid.
Lets name that problem 1.

Problem 2. If the client aborts its connection while the async servlet
is writing, we have yet another VM crash.

I believe problem 1 and 2 are all valid problems, and if you don't mind,
I'll delve deeper into these to see how we can avoid them. I'll provide
patches for review,
how does that sound,

Filip

yes it is, the problem here is that Tomcat is initiating a
CometServlet.read when bogus data comes in after Content-Length has been
reached.
Filip

Andy Piper wrote:
Bogus content-length is asking for trouble. IIRC it can cause SSL
no-end of headaches.

andy

At 01:06 17/06/2006, Filip Hanik - Dev Lists wrote:
>Lemme narrow everything down, and this will be short, I promise,
>>
>it all boils down to the Content-Length header,
>if this header is omitted then it wont be possible for the client to
>send more than one request.
>>
>The workaround for this, Content-Length: Integer.MAX_VALUE, this will
>make the code accept more than one request
>>
>If that is acceptible workaround, I can happily revert the commit.
>>
>Filip
>>
>>
>>
>Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
and that is the exact bug I fixed. Before the commit, you couldn't.
So to support your argument, you should be in favor of the commit.
not against.

, then post the request you are sending. The whole request must be
a valid HTTP/1.1 request with a properly delimited body, rather than
just a HTTP header, followed by random data.

This is not a valid request, for example:

GET /foo HTTP/1.1
Host: bla

my content (wait 10 s) more of my content

I fail to see what your purpose is to step on my toes like this,
and barge in with commit, when you didn't discuss anything.
not sure what your toes and the ASF owned repository have in common ;)

To give an example: I suppose I could try committing random stuff to
the clustering module.

We're discussing it now, you started it with a veto, and yes, i
could have used the endless discussion tactic to prove the bug, but
it was faster to come in with a solution.

That's what you are doing right now, rather than convince me that
you understand all the issues.

, I'm going to bed now, and then on WE. I hate it when people
force me to stay up until 2AM on friday just because I made the
mistake of checking my email before going to bed

R

To unsubscribe, e-mail: dev-unsubscribe (AT) tomcat (DOT) apache.org
For additional commands, e-mail: dev-help (AT) tomcat (DOT) apache.org

>>
>>
>--
>>
>>
>Filip Hanik
>>
>
>To unsubscribe, e-mail: dev-unsubscribe (AT) tomcat (DOT) apache.org
>For additional commands, e-mail: dev-help (AT) tomcat (DOT) apache.org
>

Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.

To unsubscribe, e-mail: dev-unsubscribe (AT) tomcat (DOT) apache.org
For additional commands, e-mail: dev-help (AT) tomcat (DOT) apache.org
>
>
>