[
https://issues.apache.org/jira/browse/FLUME-936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189710#comment-13189710
]
Juhani Connolly commented on FLUME-936:
---------------------------------------
The unit test recreates the following order;
t1: begin transaction
t1: put
t2: begin transaction
t2: put
t1: rollback transaction <- Problem happens here as undoPut gets called, and
removes the queue entry placed and stamped by t2
t2: commit transaction <- As things are right now, this is actually
committing the Event that was supposed to have been rolled back
t1+t2: close transaction
Overall it seems pretty hairy. One solution I can think of is to keep
uncommitted entries in the thread-separate transaction items rather than
keeping them in a shared queue
> MemoryChannel is not thread safe
> --------------------------------
>
> Key: FLUME-936
> URL: https://issues.apache.org/jira/browse/FLUME-936
> Project: Flume
> Issue Type: Bug
> Components: Channel
> Affects Versions: NG alpha 2
> Reporter: Juhani Connolly
> Fix For: v1.1.0
>
> Attachments: FLUME-936-unittest.patch
>
>
> The memory channel isn't thread safe as a couple of parallel transactions can
> commit/rollback each others entries if called in the wrong order.
> I'm attaching a unit test I made that demonstrates it using a cyclicbarrier
> to force the event order that causes the precondition to fail.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
