>
> Hi guys,After a lot (LOT) of using XFire I recently realized that there was a
problem with multiple threads running at the same time. My application is
heavily WebService oriented, and all of my request will involve at LEAST one web
service call. Also, most of those request will use the SAME web service at a
certain point, thus I need to be able to query a single web service with
multiple threads at the same time.
> Strangely enough I noticed that I was only receving --TOPS-- two requests at a
time when using an XFire client( I'm using XFire-1.1.2, with Spring and aegis)
but I could get more throughput with another client (say SoapUI).
> Looking around I found out that the HttpClient library has by default a value
of DEFAULT_MAX_HOST_CONNECTIONS set to two (2) by default, so I guess this is
what is causing troubles.I am currently looking for a solution because there is
NO WAY I can move into production with a max of 2 concurrent threads running.
> Still I wanted to see if any of you could help me solve this problem faster,
since even I can find out how to change that property on HttpClient, I have no
direct access to it.Please any comments are more than welcome.
> Best Regards,Andrés Bernasconi
Ohhhhhhhhhh my...holy cow.....
I've found that this is configured through the
MultiThreadedHttpConnectionManager class, using it's own
HttpConnectionManagerParams class... I'm very afraid that
this is buried inside the guts of xfire-core, inside
CommonsHttpMessageSender, open() method, (line 73 in 1.1.2).
I don't know if this has changed in newer versions, but the thing
is that the MultiThreadedHttpConnectionManager is instantiated like
this:
client.setHttpConnectionManager(new MultiThreadedHttpConnectionManager());
so I guess there is no "configuration" way of modifying this through
spring, right?
This seems the only way to do it right now, and will have very
little impact on my code.
I will create an outhandler that will read from some configuration
source the max number of connections per host.
Then it will get the HttpClient from the channel, from the message
and it will get the ConnectionManager. Finally, "knowing" the type
of connection, I will set new params to it.
this is REALLY ugly, I could say I hate it (I'm a very passionate man :P ), but
can't afford a complex solution right now. And I hate it because if
anything changes on the implementation of the Channel or any underlying
objects, I'm screwed. (I had to cast two objects, which is sign of
very bad luck ;) HttpChannel + HttpClient (the last one is the
worst, i believe).
I'll look more into this to see if there is another way but....
in the mean time, does any of you have the same
problem as I do, or you can manage with 2 connections per host?
Regards
Andres Bernasconi.
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
