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).
Rémy