On Fri, Jul 12, 2013 at 10:13:37AM -0700, Robert DiFalco wrote:
> In this case JobServer is distributed. So you can route the client request
> to any one of multiple server instances and everything will work as
> expected. As a result I have scaled out (I can add more rest services
> without side-effect) and all my requests are short-lived (less than a few
> msecs).
What's wrong with keeping the client connected to the same server and avoiding
the overhead of it bouncing to a new one randomly?
> How would I use AsyncResponse here without making the calls long lived or
> introducing statefullness? Or should I be doing something else? I am no
> expert on REST or Jersey but this approach seemed to be the most sane. So I
> am eager to find a better approach or see where Jersey 2.0 might help me.
This part probably depends a bit on your clients. Are they a lot of shell
scripts calling curl, or are they AJAX from web browsers using HTTP/1.1 where
the browser doesn't mind having some idle sockets in a pool connected to your
server, and just opportunistically picks from the pool of idle sockets, or
queues for one of the sockets, then sends out the request on an available one
when it's time to do another polling cycle?
If your clients are browsers or other more intelligent code I think they'd
probably run fine with the AsyncResponse. I think they'd just keep the socket
in the idle pool and reuse it again later when it's time for the polling
cycle.
Maybe you could make a test REST app which has both kinds of approach, and
then do a load-test?
Matthew.