Like Tatu said, that's not a Jersey concern, but something to be handled at
a lower level. I'll add that with Jersey running in a container like Tomcat
or Jetty, 30 requests/second isn't something I'd call "heavy" traffic. More
like "moderate", as long as the request processing is fairly snappy. It
shouldn't cause a problem.
On Mon, Mar 28, 2011 at 6: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?
>
> Thanks in advance,
> /Casper
>