Mike, that certainly makes sense. My intent was to eliminate any wait time for a connection and not to have to pool the connections myself - nor have to deal with any extraneous connections issues, ie. isStale ;-)
I hear you. It is certainly okay to do it this way. I just wanted to make sure this was intentional. Also, if you were hitting more than one host there would be some added benefit to the MTCM.
What would be a good proxy for maxConnections? If it's anything less than the number of threads, wouldn't some time be spent waiting for the next available connection?
I really depends on a lot of factors. I would suggest limiting it at some point (I usually set it to 4). Though some methods have to wait if maxConnectionsPerHost < numThreads, it also means that the executing methods will probably finish faster. The thing to keep in mind is that the sever has to handle all of the requests. At some point the overhead of the connections will outweight the benefit of concurrency. Doing a few "real-world" tests with your client/server configuration would probably be good.
Mike
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
