On 10/24/12 6:35 AM, Rémy Maucherat wrote:
> On 10/24/2012 02:55 PM, Greg Wilkins wrote:
>> On 23 October 2012 18:50, Rémy Maucherat <rmaucher_at_redhat.com> wrote:
>>> +1
>>>
>>> In previous discussions on the list, I described canWrite (now isReady)
>>> returning false as the trigger for the listener invocation, since
>>> otherwise:
>>> - there will be concurrency issues
>>> - the amount of callbacks will not be optimal
>>>
>>> For read, it is the same behavior: the Servlet should be forced to
>>> read all
>>> available data.
>>>
>>> I remember this clarification of the behavior was very well
>>> received, in
>>> particular by Greg (see the archives).
>> Yes - I think it is a good mechanism because it avoids the hassle of
>> being concerned about which thread dispatches the callback on a write
>> that just completes.
>>
>> But I'm now confused about what is being proposed. Shing said:
>>
>>> I propose to change the behavior that there is no need to do (a) above.
>>> The WriteListener#onWritePossible will be invoked once for every
>>> write operation permitted.
>> which I take to mean that the callback will be call no matter what -
>> ie it is not dependent on a false return from canWrite (or isReady).
>>
> Ok, I see better where the confusion from you and Mark comes from,
> since the trigger for the event is now much less clear, and that's
> indeed a significant change coming from a little language change. My bad.
>
> Maybe what they mean here is that the write event will be invoked once
> (even if the application writes no data in its initial service()
> method), and it proceeds with using the canWrite condition from there
> (this needs clarification). This main problem is that this event
> invocation could be useless, but maybe it makes things more
> consistent. I don't see it being broken depending on the clarification
> regarding subsequent write events.
>
> For read, it works like that already in many cases. The container will
> not be able to know if there is something to read in the initial
> service() method unless it polls (so isReady on the input would be
> false).
Thanks for Remy's clarification.
All subsequent invocations of the listener is the same. It is still
triggered by the canWrite status as before.
In this case, users' read/write can be in listener only and there is no
need to pass read/write status around.
Shing Wai Chan
>
> Rémy
>