Let me try to summarize.
For the changes proposed - the goal here is to make it easier for the
developers to use the API based on external feedback that we have
received during JavaOne and otherwise.
What is suggested is that all the read and write be done in the
listeners as opposed to have to do part of it in the service method and
the rest in the listener. In order to achieve that we have to do the
following (apart from the cosmetic changes for making the API consistent)
* The Read and Write Listeners will be invoked once in the beginning
without the need to check for isReady().
* Subsequent invocations of the listeners will be based on the
isReady() check. This avoids the need for too many listener
invocations as has been suggested by many in the EG mailing list.
- Rajiv
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).
>
> Rémy
>