Gustaf Neumann wrote: > Dear Jeff, > > Is it possible to add test cases showing the problems to the > regression test? > This way it is easier to pinpoint the problem.
I'll clean up my testcases and add them. > for the connection queuing example, it is harder to write a > test. > yes, it is true to run in this situation in pathological > cases such > as benchmarks and "bad configurations". While i tend to agree > to this diagnosis, i am not so sure about the prosed cure. After giving it some thought, my proposed solution won't work. It may more effectively mask the problem, but it doesn't fix it. > this is not a desirable solution: connsperthread might be > set to 1 by a user > who wants always fresh threads, but setting "maxconnections" > to 1 would > lead under this rule to a single connection structure > (maxconnection == 1) > which implies sequential connection processing. Yes, this would be a problem too. > Wouldn't be > a timeout on > the queue a better solution, functioning similar to incoming > request but > handling queued requests if there are these? I'm not sure how that would work - the problem is that there is nothing running to time out, unless there was a pool watchdog thread to start up new conn threads if the pool drops below minthreads running. -J ------------------------------------------------------------------------------ Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev _______________________________________________ naviserver-devel mailing list naviserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/naviserver-devel
