RPC Endpoints and threads

[Paul Grenyer]

Hi All

I've been thinking a lot about the GWT RPC mechanism and from the
tests that I've done it appears that the same endpoint instance is
used for every RPC call. So presumably if you've got a hundred users
all making the same RPC call all at the same time there are 100
different threads trying to access the same object. Is that correct?

Just having written that, another thought occurs that I haven't
checked for, is it just that the same endpoint object is used for a
session? So different users, who obviously have different sessions,
get their own endpoint object?

Anyway, assuming I was right the first time and an RPC endpoint is
shared by all sessions, has anyone considered pooling endpoints and
serving them up per session like I believe EJB does?

--
Thanks
Paul

Paul Grenyer
e: paul.g...@gmail.com
b: paulgrenyer.blogspot.com

[Sripathi Krishnan]

Servlet containers typically make only one object of your Servlet. This object is shared across several threads. Several threads is a configurable property on most servers, but usually varies between 15 to 30. If you have 100 users connecting simultaneously, the server will not start 100 threads - the remaining requests will be queued.

But multiple threads sharing the same Servlet (or end-point, as you put it) object does not usually matter. That is, if you follow servlet best practices.

The GWT RPC Servlet is Stateless. Even if 1000 users access it at the same time, it is OKAY - they will not interfere with each other. When you write a RPC Servlet extending RemoteServiceServlet, you should also ensure that it is stateless. There are several ways to do it, but the easiest is to NOT use member variables in your ServiceImpl.

Users in different sessions are also serviced by the same Servlet object. It is up to you to handle them differently by reading from the Session object and taking a different action for each user. And, just to go a step further, the recommended approach is to not use sessions. That gives you opportunities to scale later.

EJB's are a complicated beast and meant to solve an entirely different class of problems. Even if you already use EJBs in your project, you should still write a RPC Servlet that delegates the heavy-processing to EJB.

--Sri

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

[mmoossen]

Hi, Paul!

if you really want one service instance per thread make your service
additionally implement SingleThreadModel.
or you could also use the standard synchronization mechanism.

HTH
Michael

On Apr 15, 10:48 am, Sripathi Krishnan <sripathikrish...@gmail.com>
wrote:

> Servlet containers typically make only one object of your Servlet. This
> object is shared across several threads. Several threads is a configurable
> property on most servers, but usually varies between 15 to 30. If you have
> 100 users connecting simultaneously, the server will not start 100 threads -
> the remaining requests will be queued.
>
> But multiple threads sharing the same Servlet (or end-point, as you put it)

> object does not *usually* matter. That is, if you follow servlet best

> practices.
>
> The GWT RPC Servlet is Stateless. Even if 1000 users access it at the same
> time, it is OKAY - they will not interfere with each other. When you write a
> RPC Servlet extending RemoteServiceServlet, you should also ensure that it

> is stateless. There are several ways to do it, but the easiest is to *NOT
> use member variables in your ServiceImpl*.

>
> Users in different sessions are also serviced by the same Servlet object. It
> is up to you to handle them differently by reading from the Session object
> and taking a different action for each user. And, just to go a step further,
> the recommended approach is to not use sessions. That gives you
> opportunities to scale later.
>
> EJB's are a complicated beast and meant to solve an entirely different class
> of problems. Even if you already use EJBs in your project, you should still
> write a RPC Servlet that delegates the heavy-processing to EJB.
>
> --Sri
>

> On 15 April 2010 13:19, Paul Grenyer <paul.gren...@gmail.com> wrote:
>
> > Hi All
>
> > I've been thinking a lot about the GWT RPC mechanism and from the
> > tests that I've done it appears that the same endpoint instance is
> > used for every RPC call. So presumably if you've got a hundred users
> > all making the same RPC call all at the same time there are 100
> > different threads trying to access the same object. Is that correct?
>
> > Just having written that, another thought occurs that I haven't
> > checked for, is it just that the same endpoint object is used for a
> > session? So different users, who obviously have different sessions,
> > get their own endpoint object?
>
> > Anyway, assuming I was right the first time and an RPC endpoint is
> > shared by all sessions, has anyone considered pooling endpoints and
> > serving them up per session like I believe EJB does?
>
> > --
> > Thanks
> > Paul
>
> > Paul Grenyer

> > e: paul.gren...@gmail.com

> > b: paulgrenyer.blogspot.com
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Google Web Toolkit" group.
> > To post to this group, send email to google-we...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > google-web-tool...@googlegroups.com<google-web-toolkit%2Bunsu...@googlegroups.com>

[Paul Grenyer]

Hi Sri

Thanks for the fast response, that was really useful!

Thanks
Paul