On Mon, 2005-05-09 at 15:22 -0400, J.e. Turcotte wrote: > Our OS guys feel like it's gotta be a code > problem, while I feel that perhaps our apache and/or modperl installs on > these machines are not ideal, or that in the move from mp1 to mp2, some new > capacities in modperl2 are allowing a breakdown of otherwise good structures > under mp1.
If possible, I'd suggest you try to run your code on these machines with mp1 as well, to determine if that is the source of your problems. However, if you're doing lots of work with the Apache API and had to change it to make things work under mp2, that won't be much help. Problems of this nature usually result from one of these: - A database handle that is opened prior to forking, or inadvertently stashed in a closure so that when the database connection times out the reconnection doesn't work. - Some kind of socket or file access that is opened before forking and then used simultaneously from multiple processes. - An XS module with C code that gets flaky when used in a forking scenario or in certain error conditions. To track it down, I would suggest you add significant logging and/or assertions to your application. This would allow you to check for various things (a valid database handle that responds to ping(), a valid $r object, expected input, etc.) along the way, and see where things fall apart when they do. This will lead you to the problem. You could also see what happens when you set a really short timeout on connections in the database, to check if the problem involved reconnecting. - Perrin
