You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by "Anton Sitnikov (JIRA)" <ji...@apache.org> on 2012/10/12 13:01:02 UTC

[jira] [Created] (DIRMINA-912) Different instances of OrderedThreadPoolExecutor may use same task queue

Anton Sitnikov created DIRMINA-912:
--------------------------------------

             Summary: 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


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.

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));

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.:

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));

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DIRMINA-912) Different instances of OrderedThreadPoolExecutor may use same task queue

Posted by "Anton Sitnikov (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/DIRMINA-912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anton Sitnikov updated DIRMINA-912:
-----------------------------------

       Priority: Minor  (was: Major)
    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.

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));

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.:

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));

  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.

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));

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.:

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));

    
> 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
>
> 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.
> 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));
> 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.:
> 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));

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira