mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Lecharny (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (DIRMINA-912) Different instances of OrderedThreadPoolExecutor may use same task queue
Date Wed, 10 Sep 2014 07:42:29 GMT

     [ https://issues.apache.org/jira/browse/DIRMINA-912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Emmanuel Lecharny updated DIRMINA-912:
--------------------------------------
    Description: 
If two ExecutionFilter's with default executors are placed in filter chain, for example to
separate inbound and outbound events processing, both ExecutorFilters will use same task queue.
{code}
acceptor.getFilterChain().addLast("inboundExecutor", 
        new ExecutorFilter(IoEventType.MESSAGE_RECEIVED, IoEventType.SESSION_OPENED, IoEventType.SESSION_CLOSED,
IoEventType.MESSAGE_SENT));
acceptor.getFilterChain().addLast("codec", new SomeCodecFilter());
acceptor.getFilterChain().addLast("outboundExecutor",
        new ExecutorFilter(IoEventType.CLOSE, IoEventType.WRITE));
{code}
OrderedThreadPoolExecutor uses TASKS_QUEUE key to get task queue from session attributes.
TASKS_QUEUE behaves such way that different OrderedThreadPoolExecutor's refer to the same
task queue stored in session attributes.

{code}
private final AttributeKey TASKS_QUEUE = new AttributeKey(getClass(), "tasksQueue");
{code}

I'm not sure if it's OrderedThreadPoolExecutor or AttributeKey bug.

As a result only one ExecutorFilter processes task originating from both ExecutorFilters.

Workaround is to inherit Executor classes from OrderedThreadPoolExecutor and pass its instances
to ExecutorFilter constructor, e.g.:
{code}
class InboundExecutor extends OrderedThreadPoolExecutor {
}

class OutboundExecutor extends OrderedThreadPoolExecutor {
}

acceptor.getFilterChain().addLast("inboundExecutor",
        new ExecutorFilter(new InvoundExecutor(), IoEventType.MESSAGE_RECEIVED, IoEventType.SESSION_OPENED,
IoEventType.SESSION_CLOSED, IoEventType.MESSAGE_SENT));
acceptor.getFilterChain().addLast("outboundExecutor",
        new ExecutorFilter(new OuboundExecutor(), IoEventType.CLOSE, IoEventType.WRITE));
{code}

  was:
If two ExecutionFilter's with default executors are placed in filter chain, for example to
separate inbound and outbound events processing, both ExecutorFilters will use same task queue.
{code}
acceptor.getFilterChain().addLast("inboundExecutor", 
        new ExecutorFilter(IoEventType.MESSAGE_RECEIVED, IoEventType.SESSION_OPENED, IoEventType.SESSION_CLOSED,
IoEventType.MESSAGE_SENT));
acceptor.getFilterChain().addLast("codec", new SomeCodecFilter());
acceptor.getFilterChain().addLast("outboundExecutor",
        new ExecutorFilter(IoEventType.CLOSE, IoEventType.WRITE));
{code}
OrderedThreadPoolExecutor uses TASKS_QUEUE key to get task queue from session attributes.
TASKS_QUEUE behaves such way that different OrderedThreadPoolExecutor's refer to the same
task queue stored in session attributes.

private final AttributeKey TASKS_QUEUE = new AttributeKey(getClass(), "tasksQueue");

I'm not sure if it's OrderedThreadPoolExecutor or AttributeKey bug.

As a result only one ExecutorFilter processes task originating from both ExecutorFilters.

Workaround is to inherit Executor classes from OrderedThreadPoolExecutor and pass its instances
to ExecutorFilter constructor, e.g.:
{code}
class InboundExecutor extends OrderedThreadPoolExecutor {
}

class OutboundExecutor extends OrderedThreadPoolExecutor {
}

acceptor.getFilterChain().addLast("inboundExecutor",
        new ExecutorFilter(new InvoundExecutor(), IoEventType.MESSAGE_RECEIVED, IoEventType.SESSION_OPENED,
IoEventType.SESSION_CLOSED, IoEventType.MESSAGE_SENT));
acceptor.getFilterChain().addLast("outboundExecutor",
        new ExecutorFilter(new OuboundExecutor(), IoEventType.CLOSE, IoEventType.WRITE));
{code}


> Different instances of OrderedThreadPoolExecutor may use same task queue
> ------------------------------------------------------------------------
>
>                 Key: DIRMINA-912
>                 URL: https://issues.apache.org/jira/browse/DIRMINA-912
>             Project: MINA
>          Issue Type: Bug
>            Reporter: Anton Sitnikov
>            Priority: Minor
>             Fix For: 2.0.8
>
>
> If two ExecutionFilter's with default executors are placed in filter chain, for example
to separate inbound and outbound events processing, both ExecutorFilters will use same task
queue.
> {code}
> acceptor.getFilterChain().addLast("inboundExecutor", 
>         new ExecutorFilter(IoEventType.MESSAGE_RECEIVED, IoEventType.SESSION_OPENED,
IoEventType.SESSION_CLOSED, IoEventType.MESSAGE_SENT));
> acceptor.getFilterChain().addLast("codec", new SomeCodecFilter());
> acceptor.getFilterChain().addLast("outboundExecutor",
>         new ExecutorFilter(IoEventType.CLOSE, IoEventType.WRITE));
> {code}
> OrderedThreadPoolExecutor uses TASKS_QUEUE key to get task queue from session attributes.
TASKS_QUEUE behaves such way that different OrderedThreadPoolExecutor's refer to the same
task queue stored in session attributes.
> {code}
> private final AttributeKey TASKS_QUEUE = new AttributeKey(getClass(), "tasksQueue");
> {code}
> I'm not sure if it's OrderedThreadPoolExecutor or AttributeKey bug.
> As a result only one ExecutorFilter processes task originating from both ExecutorFilters.
> Workaround is to inherit Executor classes from OrderedThreadPoolExecutor and pass its
instances to ExecutorFilter constructor, e.g.:
> {code}
> class InboundExecutor extends OrderedThreadPoolExecutor {
> }
> class OutboundExecutor extends OrderedThreadPoolExecutor {
> }
> acceptor.getFilterChain().addLast("inboundExecutor",
>         new ExecutorFilter(new InvoundExecutor(), IoEventType.MESSAGE_RECEIVED, IoEventType.SESSION_OPENED,
IoEventType.SESSION_CLOSED, IoEventType.MESSAGE_SENT));
> acceptor.getFilterChain().addLast("outboundExecutor",
>         new ExecutorFilter(new OuboundExecutor(), IoEventType.CLOSE, IoEventType.WRITE));
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message