Thanks for the feedback guys. I should probably not have used the word
"heavy" in a Jersey context, it slipped in due to the client being a
resource constrained hand-terminal (Psion Ikon running Windows Mobile
6) over a 3G network.
/Casper
On Mon, Mar 28, 2011 at 8:03 PM, Ryan Stewart <rds6235_at_gmail.com> wrote:
> 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
>
>