[ http://issues.apache.org/jira/browse/JAMES-584?page=all ]
Stefano Bagnara reopened JAMES-584:
-----------------------------------
Iwasa Kazmi found another way to reproduce this issue:
----
I inserted Redirect mailet in the "transport" processor.
(see config.xml.diff)
It duplicates a message for local-user before the RemoteDelivery runs.
Then I sent a mail to the external server via james.
FileStreamStore file in the spool was not deleted.
----
> 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
> Assigned To: Stefano Bagnara
> Fix For: 2.3.0rc2
>
>
> 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]
