tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remy Maucherat <>
Subject Re: Comet, next steps
Date Fri, 16 Jun 2006 23:48:40 GMT
Filip Hanik - Dev Lists wrote:
>> Unfortunately, it looks like it:
>> +                for (int i=0; i<inputBuffer.activeFilters.length; i++) {
>> +                    //this resets the remaining flag and the content 
>> length on the filter
>> +                    //if we don't do this, then 
>> will return 0
>> +                    if (inputBuffer.activeFilters[i]!=null) 
>> inputBuffer.activeFilters[i].setRequest(request);
>> +                }
>> This is a big hack to avoid content delimitation.
> I see (and saw before) a simple solution to this
> 1. add to interface InputFilter.append(byte[]|ByteBuffer|ByteChunk)
> but I know you would have a field day if I changed an interface, as the 
> checkin would be much larger and I would for sure get a -1,
> at least with this one I had hoped you took a little consideration 
> befored vetoed.

It's that I have the impression you tried something to not have to use 
proper content delimitation, which is a -1. If you chunk your input (or 
use an appropriate content-length, which will be easier while testing 
since chunking by hand is quite annoying), as you are supposed to, I 
think this stuff will work as is (I did a very convincing session tying 
things in a telnet - my servlet was then doing a System.out.println of 
what was read in the read method, and since there was never any writes, 
I did quite a few read calls in a row).

> In terms of reverting my checkin, can we sit on it over the weekend, 
> since the current code enabled my async client currently, and the old 
> code is broken.

We can sit on your commit for the weekend if it makes you happy, that's 

> We're not in a hurry with the Comet stuff are we.

Hem, why are we not in a hurry ? Most of the time, there's no reason to 
rush, but there's no reason to delay things either.

> With the proposed feature set, Tomcat would excel beyond the existing 
> async implementations in like Jetty or Weblogic, yet it would support 
> the same as they have today.
> So we got a late start, that doesn't mean we can't jump ahead of them, 
> right ;)

I do not see Tomcat as being late: the needs were not well defined until 
recently. And this lame hack job that is Comet (a pathetic excuse to not 
use SIP) will never get any respect from me, that's for sure. I have 
added support for it because at the moment people have decided to stick 
with the HTTP dead end.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message