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]
