Hi Mark,
Thanks for bringing these up, I don't think you've missed anything in
the spec.
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.
I think that would be reasonable too.
>
> 2) How is 1) affected when batching is enabled?
> My current thinking is that the send is completed (via the Future or
> SendHandler) once the message has been batched but before it has been
> flushed. Otherwise it would be impossible to batch multiple messages.
Is this the case where you are in batching mode and you call a send
while the container is in the middle
of sending the last batch. Can't the container start a new batch ? Scott
what do you think on this one ?
>
> 3) What happens if a message is being sent and the container is required
> to send a Pong (there could be multiple Pongs) or a Close?
> My current thinking is:
> - for Pong the most recent Pong should be buffered and sent when the
> message has completed but before the application is notified of the
> completion
> - for close the first close should be buffered (and subsequent closes
> ignored) and sent sent when the message has completed but before the
> application is notified of the completion
The RFC says that pongs should be sent by the container "as soon as is
practical" 5.5.2 so there's a lot of leeway :)
The purpose of the Pong is to notify a peer that the connection is still
active, so if the container is in the middle of a close operation, I'd
say that means telling the peer the connection is active isn't really
very useful. So if the endpoint is in the middle of closing, I don't
think the Pong should get sent at all.
If its in the middle of a send, I think its ok to Pong back either
before or after the async callback is made: I don't think it makes much
difference (given the probably uncertainty of the network) to the peer
who will get it exactly the point at which its sent.
My 2c,
- Danny
>
> If I have missed something in the specification that clarifies any of
> the above please do point me in the right direction.
>
> Thoughts?
>
> Mark
--
<http://www.oracle.com> *Danny Coward *
Java EE
Oracle Corporation