>> On Mon, Apr 06, 2009 at 02:16:05PM +0300, Tuomas Makinen wrote:
>>> Hi,
>>>
>>> I'm facing a weird problem when using HttpCore & NIO-extension to send
>>> multiple requests using one connection.
>>>
>>> I have custom build performance load testing tool that is used to test
>>> our
>>> application and it's working otherwise well except for one thing:
>>>
>>
>> Tuomas,
>>
>> Firstly, a general design question. Why would you want to use NIO on the
>> client side in the first place, especially for a performance testing
>> tool?
>
> I want to use NIO because we need huge number of concurrent users and
> therefore I see NIO as most performing way to achieve this. We need over
> 1000 concurrent connections per test machine to server and by using
> NIO-extension and few threads for IOReactor dispatching we can achieve
> this without threading overhead that would be caused by creating separate
> threads for each connection and for what I have tested now, it seems to
> perform pretty well.
>
>
>>> After 100 requests sent to one connection, the framework doesn't ask
>>> for
>>> new requests from HttpRequestExecutionHandler anymore but neither is
>>> the
>>> connection closed too. Still, response has been acquired from that
>>> connection so it should block due to that.
>>>
>>> Any ideas what could be wrong?
>>>
>>
>> There is no such limit in HttpCore. However, 100 sounds like a very
>> likely limit for persistent connection re-use on the server side. Do you
>> see NHttpRequestExecutionHandler#finalizeContext even fire?
>>
>> I strongly recommend taking a look at this sample which demonstrates the
>> recommended way of managing non-blocking connections on the client side.
>>
>> http://svn.apache.org/repos/asf/httpcomponents/httpcore/trunk/httpcore-nio/src/examples/org/apache/http/examples/nio/NHttpClientConnManagement.java
>
>
> When I started to develop this application I looked at this example:
>
> http://svn.apache.org/repos/asf/httpcomponents/httpcore/trunk/httpcore-nio/src/examples/org/apache/http/examples/nio/NHttpClient.java
>
> and started working on that idea. I'll take a look at the example you
> provided but that limit could be also server side issue since I quickly
> modified that NHttpClient example and were able to reproduce issue by
> using that. We are currently using JBoss 4.2.3.GA as application server
> and I actually tried to quickly search for any configuration parameters
> but couldn't find any. I'll do one more test by setting up some small http
> server serving static content and see what happens with that.

Ok, that was actually tested quicklier than I though and you were right,
it wasn't about framework since using nginx I can do as many requests as I
want using one connection so I'll look forward to JBoss configs.

Thank you for you help anyway and if you have some other suggestions about
performance tool architecture, I would gladly hear about them :)

Br, Tuomas M.


>>> I tried to find any references to this problem from HttpCore &
>>> NIO-extension source codes but couldn't really find any. Ofcourse the
>>> problem might be in my code too but from that part it's pretty
>>> straighforward and I'm just fetching new requests from queue when
>>> submitRequest call occurs and I can see that always after 100 requests,
>>> it
>>> doesn't send new ones anymore.
>>>
>>> With best regards,
>>> Tuomas Makinen
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
>>> For additional commands, e-mail: dev-h...@hc.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
>> For additional commands, e-mail: dev-h...@hc.apache.org
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
> For additional commands, e-mail: dev-h...@hc.apache.org
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

Reply via email to