I don't know why it should be different to the JDBC connections.. as I said, in the worst case all the requests being handled by the app could be trying to connect to the same host / web service, and at the same time, you will never have more than the max number of executing threads, so it is no point in making that value greater than that.

On 11/8/06, Tomek Sztelak <[EMAIL PROTECTED]> wrote:
Maybe anyone knows what are the optimal values for connections per
host and total connectons ? Any idea or performance test ? :)

On 11/6/06, Tomek Sztelak <[EMAIL PROTECTED] > wrote:
> 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.
>


--
-----
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


Reply via email to