Vim, > 1. Managing worker threads.[H/W,OS and App Server configuration is the > place to find solution]
Having a pool of worker threads instead of spawning a dedicated thread per request / connection may well be a good investment for this kind of application. This is something HttpClient will not be able to help you with, though. > 2. Managing Connections between S1 and S2 is a second one..that's where > I am baffled..as sun's raw implementation is not much of help to > consider such load.. MultiThreadedConnectionManager does support connection pooling out of the box (so to speak). You can fine-tune the behaviour of the MultiThreadedConnectionManager class by defining the total maximum number of connections in the pool as well the maximum number of connections per host. For more details see <http://jakarta.apache.org/commons/httpclient/threading.html> Hope this helps Oleg -----Original Message----- From: Vimarsh Vasavada [mailto:[EMAIL PROTECTED] Sent: Thursday, April 01, 2004 10:56 To: Commons HttpClient Project Subject: RE: Connection Pooling/Piplining Well 1,00,000 threads is the worst-maximum-load-case. But least-load case we evaluate is 1000 threads.. Problem is divisible into 2 sub-probs : 1. Managing worker threads.[H/W,OS and App Server configuration is the place to find solution] 2. Managing Connections between S1 and S2 is a second one..that's where I am baffled..as sun's raw implementation is not much of help to consider such load.. HARDWARE PARAMETER SYSTEM Class Server Class or Higher End Desktop Processor PIV 2.4 GHz Memory 1 GB RAM Hard Disk IDE 40GB 7200 rpm Network Dual LAN card (one for live IP and other for internal IP) Application Server : jBoss 3.x with integrated Tomcat 4.x JDK 1.3.1 HTTP Server : Apache 2.x with jBoss RDBMS : MS SQL Server 2000 O/S Windows 2000 Server with SP3 > -----Original Message----- > From: Kalnichevski, Oleg [mailto:[EMAIL PROTECTED] > Sent: Thursday, April 01, 2004 1:44 PM > To: Commons HttpClient Project > Subject: RE: Connection Pooling/Piplining > > > Hi Vim > Are you absolutely sure you need all 100,000 threads running > simultaneously? Probably you should approach the problem from a different > angle and try to pool the worker threads rather than pooling HTTP > connections? > > Oleg > > -----Original Message----- > From: Vimarsh Vasavada [mailto:[EMAIL PROTECTED] > Sent: Thursday, April 01, 2004 9:27 > To: Commons HttpClient Project > Subject: Connection Pooling/Piplining > > > Hello all. > We have following challenge to address : > 1. We have 2 JBOSS Servers, say, S1 and S2 > 2. There will be 1,00,000 distinct-client-threads fired to > S1/TalkToS2.jsp/ > 3. S1 will have hence virtually 1,00,000-threads attempting to exchange > request/response with S2 only. > > Now questions : > 1. how do we realize Connection Pooling ? > 2. Can MultiThreadedConnectionManager be of help to realize connection > pooling? > 3. Since for all client-threads we need to make connection to single > server S2,can we realize Piplining? > > Thanks in advance > vim > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: commons-httpclient-dev- > [EMAIL PROTECTED] > For additional commands, e-mail: commons-httpclient-dev- > [EMAIL PROTECTED] > > > ************************************************************************ ** > ************************* > The information in this email is confidential and may be legally > privileged. Access to this email by anyone other than the intended > addressee is unauthorized. If you are not the intended recipient of this > message, any review, disclosure, copying, distribution, retention, or any > action taken or omitted to be taken in reliance on it is prohibited and > may be unlawful. If you are not the intended recipient, please reply to > or forward a copy of this message to the sender and delete the message, > any attachments, and any copies thereof from your system. > ************************************************************************ ** > ************************* > > --------------------------------------------------------------------- > To unsubscribe, e-mail: commons-httpclient-dev- > [EMAIL PROTECTED] > For additional commands, e-mail: commons-httpclient-dev- > [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] *************************************************************************************************** The information in this email is confidential and may be legally privileged. Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system. *************************************************************************************************** --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]