[
https://issues.apache.org/jira/browse/DIRMINA-1147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18139247#comment-18139247
]
Emmanuel Lécharny commented on DIRMINA-1147:
--------------------------------------------
So the main idea is that we use a queue to store data to be written, regardless
of the Socket status. The thread writing in this queue does not really care if
the socket is ready or not...
At the end, when the thread comes back to the execution through the filters, it
checks if there is some ways to write into the socket *if* the selector says
there is room in it (ie OP_WRITE is et). If so, we can switch the OP_WRITE bit
to false, read the queue, put the message in a writing queue, and write down
the socket as much data as possible. When the socket is full, we set the
OP_WRITE bit to true, and wait for the socket to tell is there is more room.
I'm wondering if it wouldn't be a better idea to get rid of the
currentWriteRequest, simply by not polling the queue, but peeking it instead.
We can poll (and remove) the fully processed message when it's fully written.
Now, if we have an executor filter in between, things are starting to be way
more complex, as many threads processing one single session can write in the
queue. Still, one single thread will process the outgoing messages.
We probably need some tests that demonstrate the issue we have at this point.
> Concurrency problem on write interest
> -------------------------------------
>
> Key: DIRMINA-1147
> URL: https://issues.apache.org/jira/browse/DIRMINA-1147
> Project: MINA
> Issue Type: Bug
> Components: Transport
> Affects Versions: 2.1.4
> Environment: AdoptJDK 11
> Reporter: Jonathan Valliere
> Assignee: Jonathan Valliere
> Priority: Critical
> Fix For: 2.2.11
>
>
> *THIS IS A MAJOR ISSUE; I've seen it dozens of times today occurring during
> an event write and the concurrent send/write from another thread.*
> Write interest is not concurrent and full of issues relating to the
> synchronization between the backlog queue and the atomic flag write interest.
> It is possible to check for a queue to be not full, and add to the queue
> whereas the queue is emptied and write interest is disabled before the
> additional item is added to the queue.
> What happens is 2-3 atomic operations occur and cannot/do not check to see
> whether the state changed between the time of assertion and subsequent action.
> The scheduledFlush queue also suffers from the same concurrency problem.
> Events may be added to the queue after the scheduledFlush operation has
> removed it from the scheduledFlush queue and after queue is empited causing
> items to be added to the backlog but not trigger the scheduledFlush queue or
> interest.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
