[
https://issues.apache.org/jira/browse/JAMES-3477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17255467#comment-17255467
]
ASF GitHub Bot commented on JAMES-3477:
---------------------------------------
jeantil commented on pull request #282:
URL: https://github.com/apache/james-project/pull/282#issuecomment-751631891
> Both pipelines will work on different email copies now no?
In the event that there are 2 different MimeMessageWrapper instances, are we
certain that DeferredOutputStream will have finished copying the underlying
file ?
I was worried that the file storing the email data for t1 might be deleted
before the file storing the data for t2 is completely written ending up in a
MimeMessageWrapper instance in t2 that's backed by a corrupted file.
I read through more code and it looks like DeferredOutputStream does make a
defensive copy (I was misled by the `deferred` in the name) so 2 different
instances would have 2 complete files as soon as instance creation returns.
That leaves the `synchronized` flag on
`MimeMessageInputStreamSource#getInputStream` which suggests concurrent access
may occur there with the possible outcome I mentionned. If you are certain that
concurrent access may no longer occur on `MimeMessageInputStreamSource` I
suggest dropping the misleading `synchronized`. I assume that the
synchronization was added to avoid/fix a `ConcurrentModificationException` on
the `List<InputStream> streams`. The `synchronized` is actually a lie since a
`ConcurrentModificationException` could still be triggererd by threads calling
`getInputStream` and dispose concurrently
on a side note: `List<InputStream> streams` the ordering property of lists
doesn't seem to have any importance in the implementation, a `Set` would be
more appropriate.
I guess we will have to wait and see if shared access to MimeMessageWrapper
instances occurs or not.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
> MimeMessageCopyOnWriteProxy is not thread safe
> ----------------------------------------------
>
> Key: JAMES-3477
> URL: https://issues.apache.org/jira/browse/JAMES-3477
> Project: James Server
> Issue Type: Wish
> Reporter: Benoit Tellier
> Priority: Major
>
> https://www.mail-archive.com/[email protected]/msg69221.html
> &
> https://github.com/jeantil/james-project/commit/c0354ea21c5b0a8f6d46e9919f7db0d97db9eb23
> proves there is a concurrency issue in MimeMessageCopyOnWriteProxy class that
> we need to investigate.
> It causes our test suite to be flacky.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
