https://issues.apache.org/bugzilla/show_bug.cgi?id=56026
--- Comment #5 from Konstantin Preißer <kpreis...@apache.org> ---
Hi Simone,
(In reply to Simone Bordet from comment #2)
> Mark, thanks for your comments.
>
> I am frankly surprised that an expert group states that:
>
> "[async writes] 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."
>
> Now those sorts of tricky buffering requirements must be managed by the
> application, with almost 100% chance that average joe websocket get them
> wrong.
> For a simple chat application, an application developer must manage the
> buffering and possibly stack overflows due to callback invocations.
I'm not a Tomcat developer, but I have written a WebSocket example for Tomcat
("Drawboard") which uses the RemoteEndpoint.Async to send messages
asynchronously.
Mark said the Javadoc of Async does not explicitely state that concurrent calls
to this method are not allowed, but from a user's point of view, I would expect
methods like Async#sendText(String, SendHandler) not to be callable until the
previous Async operation has completed (when the SendHandler is invoked).
StackOverflows due to Callbacks should not be possible as the SendHandler
method is required to always be called from a different thread than the one
that initiated the send - see bug 55715.
Can you go into details with what you mean with "tricky buffering
requirements"? For example, at the drawboard, I used a very simple buffering
mechanism to ensure that concurrent send operations are serialized to the
client, by using a LinkedList that stores messages that have yet to be sent to
the client (and a bit synchronization).
>
> Containers should solve those problems on behalf of the application writers,
> otherwise one could say that transaction management or ORM mapping are too
> tricky to manage and better left to JEE application writers.
>
> I hope you can change your mind on this issue :)
>
> I see this problem as a lack of detail in the specification rather than a
> real intent to put burden onto application developer's shoulders.
>
> Thanks!
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
