believe). As a strange aside the default*.log contains a database
connection exception (it contained the same exception at the last time
James stopped 6 days ago). I don't know if this means anything - could
this exception have caused the problem? spoolmanager*.log and
mailet*.log stopped recording at 1:32 am.
I wonder if James is really failing because it is loosing db connectivity
and therfore whilst it can open smtp connections it somehow can't complete
the whole transaction quickly enough, connection pool grows to its limit
and James chokes. The first obvious symptom would be the socket limit being
reached, but the cause could be loctaed elsewhere.
I would like to add that "cat /proc/sys/fs/file-nr" returns in my case "3505 2878 209714" - so more than 200,000 sockets should be available. Also, there is another web application running on the same server, using the same database server and Internet connection. It never stopped working when James did.
If James would actually use 120 socket handles - wouldn't they appear in the netstat output? I would say so - but perhaps I am wrong on this. I believe James is only using 120 socket objects (Java objects) - but not 120 Linux sockets (otherwise they would appear in the netstat output). James (or the underlying pool implementation) doesn't seem to realize that the socket is already closed.
Michael
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
