From: Bill Wigger <wigger_at_us.ibm.com>
Date: Tue, 12 Feb 2013 16:12:20 -0500

I think it is a reasonable restriction for an application to wait for the
previoius message to complete before sending the next, so +1 to the
following...

"That said, I'm happy keeping this restriction in place so that the
application must wait for the previous message to complete before
sending the next. "

regards,
Bill


Bill Wigger




From: Mark Thomas <mark_at_homeinbox.net>
To: jsr356-experts_at_websocket-spec.java.net,
Date: 02/11/2013 09:09 AM
Subject: [jsr356-experts] Re: [jsr356-users] Concurrency questions



On 04/02/2013 10:42, Mark Thomas wrote:
> On 04/02/2013 01:35, Danny Coward wrote:
>> On 1/29/13 1:42 AM, Mark Thomas wrote:
>>> All,
>>>
>>> As a side-effect of grappling with why some of my unit tests are
failing
>>> I have been thinking about concurrency issues around message sending
and
>>> have the following questions.
>>>
>>> 1) If an application sends a message using a Future or a SendHandler,
is
>>> it permitted to send a second message before the first has completed?
>>> My current thinking is that this should not be permitted and an
>>> IllegalStateException be thrown
>>> My reasoning for this is that was allowed it would open up all sorts of
>>> buffering requirements for the container that could get tricky to
manage.
>> Going back to this one, would you say the same thing if you tried to
>> send a second message while you were in the middle of sending a first
>> one in pieces ? For the same reason ?
>>
>> i.e.
>>
>> sendPartialString("inter", false); // not done
>> sendPartialString("rupti", false); // not done
>> sendString(" cow !"); <- throws IllegalStateException ?
>> sendPartialString("ng ", true);
>>
>> Ditto for scnearios around the IO stream writers too ?
>
> Yes. I think one message needs to finish before you try sending the next.

Coming back to this, my original reason for suggesting this is no longer
valid (I have refactored my implementation and the buffering
requirements are now easy to implement).

That said, I'm happy keeping this restriction in place so that the
application must wait for the previous message to complete before
sending the next. If others feel this restriction is unreasonable, I
wouldn't object to removing it.

Mark