Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (athena.apache.org: domain of bob.deremer@thingworx.com
 designates 207.46.163.243 as permitted sender)
From: Bob DeRemer <bob.deremer@thingworx.com>
To: Tomcat Users List <users@tomcat.apache.org>
Subject: RE: is the Tomcat-7 WsRemoteEndpointImplBase send methods
 threadsafe, or should we be synchronizing until the Future<>.get() returns?
Thread-Topic: is the Tomcat-7 WsRemoteEndpointImplBase send methods
 threadsafe, or should we be synchronizing until the Future<>.get() returns?
Thread-Index: Ac7OsIAx2veJbB5nS6ygDA0WKRmqMQADTVWAAAnWJgAADL6I0A==
Date: Tue, 22 Oct 2013 11:16:25 +0000
Message-ID: 
 <0dd5ebdefe324613a8eb76123cd62829@BLUPR06MB193.namprd06.prod.outlook.com>
References: 
 <622c3a58d5d442ad8c53d10065a12dc7@BLUPR06MB193.namprd06.prod.outlook.com>
	<CAMWuidGW+fmysbsM8ZS-24qv9T=yLeGQK3YWEpBBeDYJ+jgf8Q@mail.gmail.com>
 <CAN7Q5XShHyMeU+N8_ycsqWYyn+UsURn-i+di1Nk=s+5uCzO32A@mail.gmail.com>
In-Reply-To: 
 <CAN7Q5XShHyMeU+N8_ycsqWYyn+UsURn-i+di1Nk=s+5uCzO32A@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0


> -----Original Message-----
> From: Niki Dokovski [mailto:nickytd@gmail.com]
> Sent: Tuesday, October 22, 2013 1:11 AM
> To: Tomcat Users List
> Subject: Re: is the Tomcat-7 WsRemoteEndpointImplBase send methods
> threadsafe, or should we be synchronizing until the Future<>.get() return=
s?
>=20
> On Tue, Oct 22, 2013 at 3:29 AM, David Bullock <
> david.bullock@machaira.com.au> wrote:
>=20
> > Hi Bob,
> >
> > > I tried searching the javadocs of RemoteEndpoint.Async and
> > > associated
> > interfaces, but could not find anything describing the threadsafe
> > nature (existing or not).  It appears that the spec lets the
> > implementation determine how to handle stuff under the covers.  This
> > is fine, but we just need to understand what that means to
> > multi-threaded code that wants to send messages.
> >
>=20
> JSR 356 Specification Section 5.1 Threading Consideration discusses the t=
opic.
> In particular;
> [WSC-5.1-2] - "the implementation must not invoke an endpoint instance wi=
th
> more than one thread per peer at a time."
> [WSC-5.1-4] - "a websocket endpoint instance is never called by more than=
 one
> container thread at a time per peer."
>=20
> cheers
>=20

Thank you, Niki, for the spec clarification
bob

>=20
> >
> > I'd have thought that where an interface doesn't declare that it is
> > threadsafe, one cannot assume that it will be.  Further, if a
> > RemoteEndpoint represents 'the peer of a web socket conversation',
> > then a RemoteEndpoint, like a conversation, can surely support only a
> > single 'conversation state'?
> >
> > IMHO, the correct choice is for each thread to have its own
> > RemoteEndpoint.  If the protocol being used happens to multiplex
> > multiple conversations to/from different endpoints over the same
> > TCP/UDP socket (for example), then the plumbing will do the
> > appropriate synchronization at that point - there would be no
> > advantage (and possibly some big disadvantages) for you to do your own
> > synchronization.  Critically, a RemoteEndpoint does not necessarily
> > represent a 'heavyweight' object like a Socket, and you should not be
> > at pains to manage your own pool of them, nor necessarily (unless it
> > made sense for application logic) to have a queue of messages which is
> > dispatched from a single thread.
> >
> > However, I do think that many JSR's which ought to know better are
> > very lame about thread-safety guarantees for application authors, and
> > that more needs to be said in API documentation about patterns for
> > concurrent usage.  I encourage you to lobby your particular JSR of use
> > to include this information in future releases of the specification.
> > I did my bit recently at https://java.net/jira/browse/SERVLET_SPEC-81
> >
> > cheers,
> > David Bullock
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org