mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Edouard De Oliveira (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (DIRMINA-714) Packet sequence is unordered in multi thread.
Date Thu, 18 Jun 2009 23:26:07 GMT

    [ https://issues.apache.org/jira/browse/DIRMINA-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12721548#action_12721548
] 

Edouard De Oliveira edited comment on DIRMINA-714 at 6/18/09 4:25 PM:
----------------------------------------------------------------------

After some hours of debugging, i think the concurrency problem is located in the executor
filters that need to be place before and after the codec . they must be interested on the
IoEventType.WRITE using the right constructor which strangely is not the case by default.

I first thought that an Executor before the codec will be enough but it seems not and i'm
not totally sure why 

As long as the IoBuffer or object message isn't queued in the OrderedThreadPool you could
fall in the following situation :

Thread A gets a sequence number and then ctx is switched somewhere before write event is queued
by the executor filter
Thread B gets seq+1 and runs till event is queued 

this will result in a wrong sequence

finally combining the two executor filters with adding a synchronization on the session when
writing the packet should definetely solve the problem :
synchronized (session) {
....
seq = generateSeq();
....
session.write(buf);
...
}

The OrderedThreadPoolExecutor needs many conditions to do it's job correctly so maybe the
solution to this issue is just a complete doco to avoid misunderstandings until the 3.0 branch
which should bring a new chain that should allow ordering events more 
efficiently.

WDYT ?

      was (Author: ted_kods):
    After some hours of debugging, i think the concurrency problem is located in the executor
filters that need to be place before and after the codec . they must be interested on the
IoEventType.WRITE using the right constructor which strangely is not the case by default.

I first thought that an Executor before the codec will be enough but it seems not and i'm
not totally sure why 

As long as the IoBuffer or object message isn't queued in the OrderedThreadPool you could
fall in the following situation :

Thread A gets a sequence number and then ctx is switched somewhere before write event is queued
by the executor filter
Thread B gets seq+1 and runs till event is queued 

this will result in a wrong sequence

finally adding a synchronization on the session when writing the packet should definetely
solve the problem :
synchronized (session) {
....
seq = generateSeq();
....
session.write(buf);
...
}

The OrderedThreadPoolExecutor needs many conditions to do it's job correctly so maybe the
solution to this issue is just a complete doco to avoid misunderstandings until the 3.0 branch
which should bring a new chain that should allow ordering events more 
efficiently.

WDYT ?
  
> Packet sequence is unordered in multi thread.
> ---------------------------------------------
>
>                 Key: DIRMINA-714
>                 URL: https://issues.apache.org/jira/browse/DIRMINA-714
>             Project: MINA
>          Issue Type: Bug
>          Components: Filter
>    Affects Versions: 2.0.0-M5
>         Environment: xp
>            Reporter: ncanis2
>            Assignee: Edouard De Oliveira
>             Fix For: 2.0.0-M7
>
>         Attachments: mina_m6_seq_test_src.zip, org.zip
>
>
> Hi.
> Packet sequence is unordered.
> = Server & Client = 
> chain.addLast("codec", new ProtocolCodecFilter(rcf));
> chain.addLast("executor", getExecuteFilter());    => OrderedThreadPoolExecutor c =
new OrderedThreadPoolExecutor(20,100);
> If server send 1,2,3,4,5,6 , client receive 1,2,3,4,6  from server.
> Clients : 100.
> where I am wrong? 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message