I'm trying to determine how to solve a problem where I have one domain I talk to that, for the most part, performs well. I can expect most request to be responded to within a few seconds (I'll call them TypeA requests), but it also supports some "special" requests which are going to take much longer (up to 2 minutes) which I'll call TypeB. From a usage perspective, it's probably going to be about 95% TypeA and 5% TypeB.
I'm currently using HttpClient 4 and I'm using ThreadSafeClientConnManager to manage connection pooling. On application startup, each HttpRoute is configured using the connectionManager.setMaxForRoute() method to establish the maximum connection pool size. Since these request share the same domain, they share the same connection pool. I'm trying to figure out how to make it so that if I get a flurry of TypeB transactions, it doesn't completely consume the connections in the pool and starve TypeA request, which are far more important than the TypeB requests. One thought is to try to force them to have separate connection pools. I'm not sure if this is possible with a single instance of HttpClient, so I guess that's my first question. My second question is: Would switching to the asynchronous client help here? I have a limited understanding of it, but I'm assuming it supports HTTP pipelining, but does that help me in this case? If I interpreted what I read about pipelining correctly, it seems that I can send multiple requests down the same connection, but the responses must be received in order they were sent. If that's the case, I'd think pipelining does not help in my use case because the TypeA responses would get held up behind a TypeB responses. In fact, this would seem far worse because now the TypeB responses aren't only affecting the pool, they're affecting individual TypeA requests. This leads me to think I may not be understanding what I read. Thanks, Mike
