On 15/08/2013 08:53, Peter Rossbach wrote:
> HI Mark,
> 
> nice fix :-) Thanks!
> 
> Why the testcase at NBReadServlet must called the 
> "listener.onDataAvailable();"?

https://issues.apache.org/bugzilla/show_bug.cgi?id=55381

> I read the 3.1 spec and think the container must call onDataAvailable and
> we do that at CoyoteAdapter.

We do, but that doesn't get triggered for the first call.

I have a patch for BZ55381 that works for BIO and NIO but not APR. I
know what the problem is - I just need to find a way around it. Oh, and
I have only tested on Windows so far. From experience, once this works
on Windows I'll need a few more tweaks to get it working on Linux and
OSX as well.

> Another question is: At which time the container must call the 
> WriteListener.onWritePossible()?
> After ReadListener.onDataAvailable is finished?

The specification doesn't define an order (there was some discussion in
the EG about what made sense) so applications should not assume any order.

> Currently we call onWritePossible before onDataAvailable is WriteListener 
> set. The example set
> WriteListener at the ReadListener has read all data! But the problem seems 
> that no date available after POST request is dispatch.
> After ReadListener set the method call result from 
> ServletInputStream.isReady() is true! Seems socket has read data.

I'm not sure I follow this. onWritePossible() and onDataAvailable() will
be called in response to a Poller event (for NIO and APR anyway). If
both a read and write event occurs, the poller will trigger an event for
each. Those events will trigger creation of a socket processor each
which gets passed to the executor. The executor will run them both. The
order of which one fires first depends on which on enters the sync block
first and that is not deterministic.

BIO is a whole different issue. I suspect that there will be some
applications that just don't work with BIO. Longer term, I'm wondering
about dropping BIO entirely.

Mark


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

Reply via email to