DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=40967>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=40967 [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WONTFIX | ------- Additional Comments From [EMAIL PROTECTED] 2006-11-14 11:07 ------- The calculation in this patch is exactly what IIS calculates - e.g. check for PoolThreadLimit in the registry, and calculate it as MIN(2*MB, 256) otherwise. (This is described clearly in the linked technet article, and repeated throughout the IIS docs, so it's by no means guesswork). e.g. almost every IIS on a server in the world has 256 threads per process. Setting the default to 250 will still leave a small window where the connection pool can be overloaded by the web server. I'd be fine with assuming that every server OS we'll encounter has a minimum of 128MB RAM, and hard coding the 256 as the default for server OSes (with the registry check for override). I can modify the patch to do that if you agree. Like you say, as long as high rather than low, it just won't use the extra slots. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
