FileStreamStore diskspace leak for removed messages in file based spool under windows -------------------------------------------------------------------------------------
Key: JAMES-584 URL: http://issues.apache.org/jira/browse/JAMES-584 Project: James Issue Type: Bug Components: MailStore & MailRepository Environment: Win32 Reporter: Stefano Bagnara Iwasa Kazmi reported this on server-user: ----- Hi, I sent a message to a local user and the delivery was done successfully, but a FileStreamStore file is still in the `spool' directory. Is the FileStreamStore file used ? I'm using james-2.3.0rc1 on WinXP. I did the following: 1. edit config.xml for disable server name detection. <servernames autodetect="false" autodetectIP="true"> <servername>localhost</servername> </servernames> 2. add user `iwasa'. 3. send email to [EMAIL PROTECTED] Thank you, Iwasa Kazmi ------ Confirmed by me here: ------ FWIW I can reproduce the issue with current 2.3rc1 and current trunk. Config file as default for 2.3, repositories changed to file in trunk (we still have derby as default in trunk). I connect to remote manager, create an user. Connect to smtp server and send a message to that user. The XXX.Repository.FileStreamStore file is stuck there, in the spool. If I restart James it got cleaned by the cleaning procedure in AvalonMailRepository. This seems to be a bug. Every file that is spooled remain there until a restart. This is diskspace leak. I tried manually calling from all the places the ContainerUtil.dispose(mail) and set mail to null to be sure that the remove were called and I can see that remove is called twice on that file but it is not removed. It seems that a stream is still opened when we try to remove it and it's not removed. I've not investigated more on this. I only use filerepository in a small production server that I rarely check. Noel, Vincenzo, can you check what does it happen in the long term? Maybe this is a test for Postage... spool folder should increase it size in a linear way if this bug is there. ------ This could be platform specific: I'm able to reproduce it under windows. This would also make sense because in unix os you can remove opened files and they are really removed when the file is closed while under windows an opened file cannot be deleted. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]