Martin, I know that there used to be a problem with this, but that was some years ago and I thought that we had removed the cause. I have very little understanding of the interaction between windows and java at the file level, but I think you're saying that James should be deleting these files and isn't because it is locked by another process, yes? Or is James holding the lock?
Would you consider using a database for the spool? MySQL works well and I think SQL server is also supported, this can be run in the same machine as James in most cases and doesn't suffer the same problems, plus you can use scheduled SQL for housekeeping. d. On Fri, Nov 20, 2009 at 11:53 AM, Martin Brown <[email protected]> wrote: > Hi, > > We use James 2.3.2 in our product as an SMTP relay - email comes in via > SMTP, gets processed, and gets sent on via SMTP using the RemoteDelivery > Mailet. > > One of our customers is reporting that files build up in the spool > folder. They are running on Windows 2003 R2. They have to restart the > server every so often to clear out the dead files, otherwise these build > up and James slows down as the Windows filesystem cannot cope. > > We haven't been able to reproduce the issue (even when running their > virtual machine on our hardware). However, looking at the source code it > appears that the system does not check whether the file could be > deleted, so if anything is holding a Windows-level lock on the file this > could happen. > > Anyone else seen this issue? > > Any ideas for a fix? Looking at the code it might be possible to do the > startup check for mismatched Stream and Object files every so often, but > the locking implications of that look complex. > > Thanks > > Martin > > > Filtered by 3BClean from http://www.3bview.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
