[
https://issues.apache.org/jira/browse/DIRMINA-845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13072871#comment-13072871
]
Ilya Ivanov edited comment on DIRMINA-845 at 7/29/11 4:19 PM:
--------------------------------------------------------------
Let suppose we have 3 session (3 rtmp connections) 1, 2 and 3. Session 1
receives video frame and re-sends it to session 3, session 2 receives another
video frame and re-send it to session 3 too. All sessions have different
io-processor threads.
Note video frame represented as sequence of several messages in MINA terms
(chunks). Frame is sent further when it received completely. When sending it is
splitted on chunks again.
So, two incoming frames processed by different threads will concurrently pass
through session 3 filter chain chunk by chunk. Exactly chunking leads to issue
above. Flushing may break chunks order.
Let frame F1 chunked as F1A, F1B and F2 as F2A, F2B. They might be written to
ProtocolEncoderOutput in such order F1A, F2A, F2B, F1B for example. It's ok
that chunks of different frames are mixed, but important that B chunk follows
after A for each frame. When flush runs concurrently the above sequence might
be written to next filter as F1A, F2B, F2A, F1B - wrong: F2B precedes F2A!
I'm not sure this is right using of MINA or not but such implementation I saw
in red5...
http://code.google.com/p/red5/source/browse/java/server/trunk/src/org/red5/server/net/rtmp/codec/RTMPMinaProtocolEncoder.java
lines 50 and 70
I tried to eliminate entire connection lock and replace it on per-channel lock
(RTMP itself allows this). Also I add chunking which didn't present in original
code.
was (Author: ilya.a.ivanov):
Let suppose we have 3 session (3 rtmp connections) 1, 2 and 3. Session 1
receives video frame and re-sends it to session 3, session 2 receives another
video frame and re-send it to session 3 too. All sessions have different
io-processor threads.
Note video frame represented as sequence of several messages in MINA terms
(chunks) and frame is sent further when it received completely. When sending it
is splitted on chunks again.
So, two incoming frames processed by different threads will concurrently pass
through session 3 filter chain chunk by chunk. Exactly chunking leads to issue
above. Flushing may break chunks order.
I'm not sure this is right using of MINA or not but such implementation I saw
in red5...
http://code.google.com/p/red5/source/browse/java/server/trunk/src/org/red5/server/net/rtmp/codec/RTMPMinaProtocolEncoder.java
lines 50 and 70
I tried to eliminate entire connection lock and replace it on per-channel lock
(RTMP itself allows this). Also I add chunking which didn't present in original
code.
> ProtocolEncoderOutputImpl isn't thread-safe
> -------------------------------------------
>
> Key: DIRMINA-845
> URL: https://issues.apache.org/jira/browse/DIRMINA-845
> Project: MINA
> Issue Type: Bug
> Components: Filter
> Affects Versions: 2.0.4
> Reporter: Ilya Ivanov
>
> ProtocolEncoderOutputImpl uses ConcurrentLinkedQueue and at first look it
> seems to be thread-safe. But really concurrent execution of flush method
> isn't thread-safe (and write-mergeAll also).
> E.g. in RTMP several channels multiplexed in single connection. According
> protocol specification it's possible to write to different channels
> concurrently. But it doesn't work with MINA.
> I've synchronized channel writing, but it doesn't prevent concurrent run of
> flushing (in 2.0.4 it's done directly in ProtocolCodecFilter.filterWrite, but
> ProtocolEncoderOutputImpl.flush has the same problem).
> Here the fragment of flushing code:
> while (!bufferQueue.isEmpty()) {
> Object encodedMessage = bufferQueue.poll();
>
> if (encodedMessage == null) {
> break;
> }
> // Flush only when the buffer has remaining.
> if (!(encodedMessage instanceof IoBuffer) || ((IoBuffer)
> encodedMessage).hasRemaining()) {
> SocketAddress destination = writeRequest.getDestination();
> WriteRequest encodedWriteRequest = new
> EncodedWriteRequest(encodedMessage, null, destination);
> nextFilter.filterWrite(session, encodedWriteRequest);
> }
> }
> Suppose original packets sequence is A, B, ...
> Concurrent run of flushing may proceed as following:
> thread-1: Object encodedMessage = bufferQueue.poll(); // gets A packet
> thread-2: Object encodedMessage = bufferQueue.poll(); // gets B packet
> ...
> thread-2: nextFilter.filterWrite(...); // writes B packet
> thread-1: nextFilter.filterWrite(...); // writes A packet
> so, resulting sequence will B, A
> It's quite confusing result especially when documentation doesn't contain any
> explanation about such behavior.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
