On Mon, Mar 28, 2011 at 4:44 AM, Casper Bang <casper.bang_at_gmail.com> wrote:
> Hello fellow Jersey users,
>
> In designing a REST resource for uploading binary telemetric data,
> I'll be in a situation of consuming potentially 30+ small requests a
> second over a period of a minute or two. In the traditional WS-*
> world, I would've used more course-grained wrappers, and although
> that's still possible I guess, it doesn't give me some of the nice
> properties of REST (fine grained error reporting, easy to reason
> about, test etc.).
>
> I am not so much concerned about saturating the endpoint, as I'd
> simple use a thread pool. I am more concerned about the overhead
> associated with opening so many connections. Are there mechanisms in
> place for supporting HTTP pipelining in Jersey, or is this a
> transparent issue only relevant to the container and http client? Any
> users out there who have investigated the issue of letting the
> transportation layer deal with abstracting many small logical requests
> to fewer larger ones?
Unless those are fully concurrent requests, HTTP 1.1 connection reuse
should work just fine in avoiding need to open that many connections.
This is implemented at lower level by servlet container (Jetty or
Tomcat) on server side; and by http client lib on client side.
Connection reuse is about as simple as it sounds; after a logical
request is complete, physical connection may be reused.
There are usually couple of settings to define things like how long an
idle connection remains open, and for how many requests can a
connection be reused.
HTTP 1.1 does also define HTTP pipelining, which would allow use of a
single physical connection for multiple logical requests, sort of
concurrently (i.e. allow sending new requests even before matching
responses have been received). However, HTTP pipelining is not
supported by many libraries, and there isn't even general consensus on
whether it even makes sense to support it.
There are complexities in error handling, as well as potential for
added latency if/as results must be sent in same order as requests.
So depending on latencies involved, it is not always necessary to
worry too much about connection setup overhead. There are other
potential benefits from batching, so app/framework level batching
sometimes makes sense. But as with pipelining it does complicate
things, and it is rather difficult to do nicely in generic way. This
is why most often batching is done at application level.
-+ Tatu +-