On 11/6/06, Andres Bernasconi <[EMAIL PROTECTED]> wrote:
I'm glad to see this threa got good attention.
Tomek: I am not directly usgin XFire's API, so I can't really do that unless
it is configurable through Spring, which I believe it is not, or at least do
not know how to do it.
Also as a suggestion, I would set the number of connections per host equal
to the maximum total number of connections. And I would put those to the
number of "execute threads" on the application server. In the worst case,
you might have all threads calling we b services, and you do not want to be
delayed just because you did not asigned enough connections.
So setting max conns to the double of conns per host really makes no sense
to me: your conns per host will be the bottleneck. (worst-case scenario,
which usually happens in Production :P )
If you want, Tomek I can post more info on how I solved the issue, but it is
not a very clean solution since I'm coupled with XFire's inner workings.
If you can, post here or attach to jira isse piece of code with
httpclient config. If i will find some time, i'll try to fix this
today.
Regards
Andrés Bernasconi
On 11/5/06, Hodges, Chris <[EMAIL PROTECTED]> wrote:
> I am new to XFire and I am having a similar problem. After reading this
conversation I went back to my code and tried creating my own HttpClient but
I am still getting a maximum of two Threads. Am I doing something wrong?
>
> Object webServiceClient = new
XFireProxyFactory().create(myService, myUrl);
>
> Client client = Client.getInstance(webServiceClient);
>
> MultiThreadedHttpConnectionManager manager = new
MultiThreadedHttpConnectionManager();
> HttpConnectionManagerParams myParams = new HttpConnectionManagerParams();
> myParams.setDefaultMaxConnectionsPerHost(25);
> myParams.setMaxTotalConnections(50);
> manager.setParams(myParams);
> HttpClient myHTTPClient = new HttpClient(manager);
> client.setProperty(CommonsHttpMessageSender.HTTP_CLIENT,
myHTTPClient);
>
> -----Original Message-----
> From: Tomek Sztelak [mailto:[EMAIL PROTECTED]
> Sent: Saturday, November 04, 2006 4:52 AM
> To: [email protected]
> Subject: Re: [xfire-user] Re: Urgent! How to change Maximum Number of
connections for HTTPClient through XFire
>
> You can create you own HttpClient, configure it as you want and set on
> client with client.setProperty(CommonsHttpMessageSender. HTTP_CLIENT,
> myHTTPClient )
>
> On 11/4/06, Andres Bernasconi <[EMAIL PROTECTED]> wrote:
> > >
> > > 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
> >
> >
>
>
> --
> -----
> When one of our products stops working, we'll blame another vendor
> within 24 hours.
>
>
---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>
**********************************************************************
> HTC Disclaimer: The information contained in this message may be
privileged and confidential and protected from disclosure. If the reader of
this message is not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient, you are
hereby notified that any dissemination, distribution or copying of this
communication is strictly prohibited. If you have received this
communication in error, please notify us immediately by replying to the
message and deleting it from your computer. Thank you.
>
**********************************************************************
>
>
>
---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
--
-----
When one of our products stops working, we'll blame another vendor
within 24 hours.
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
