The clients will be mobile apps, first one will be IOS. There will be
millions of requests to the servers per day. Just from a scaling out
perspective it seems better to not leave clients connected to the server
during long running (> 1sec) operations. Those sockets are resources too,
not just the threads that process them. Are you thinking that is not an
issue? I didn't think the C10K problem was just a number of threads issue.
And I've always heard it is bad practice to have a REST request take longer
than a 500-1000 milliseconds.
Unless I'm missing something it seems like the AsyncResponse approach does
not scale very well. I have to keep the connection in tact for the length
of the operation AND I need to have some thread either blocked or polling
to know when to resume the response. So with REDIS that would mean a thread
either blocked on BLPOP waiting for a response from the worker process or a
thread polling to see if the result was ready. No?
On Fri, Jul 12, 2013 at 10:27 AM, Matthew Hall <mhall_at_mhcomputing.net>wrote:
> 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.
>