You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by Matt Mehalso <me...@gmail.com> on 2008/03/11 19:11:53 UTC
executor filter chain behavior
All -
We are having some strange behavior with our MINA 1.0.9-based server during
load test. I may be misinterpreting the purpose of an executor in the
filter chain - please let me know if I have an incorrect understanding of
its usage.
Our server is a pretty simple asynchronous request/response server where
multiple requests may come in all at once and be answered in any order.
We have an Executor filter set up at the end of our filter chain to process
requests concurrently. However, when under load, our server is processing
all requests in order, in the same thread. For example, please see the log
below:
[SocketAcceptorIoProcessor-0.0] INFO - [/127.0.0.1:2824] RECEIVED:
n0002..<omitted for readability>
[SocketAcceptorIoProcessor-0.0] INFO - [/127.0.0.1:2824] RECEIVED:
n0003..<omitted>
[SocketAcceptorIoProcessor-0.0] INFO - [/127.0.0.1:2824] RECEIVED:
n0004..<omitted>
[SocketAcceptorIoProcessor-0.0] INFO - [/127.0.0.1:2824] RECEIVED:
n0005..<omitted>
[pool-4-thread-1] INFO - [/127.0.0.1:2824] WRITE: 0001E24
...<SENT's omitted for readability>
[pool-4-thread-1] INFO - [/127.0.0.1:2824] WRITE: 000232nA
[pool-4-thread-1] INFO - [/127.0.0.1:2824] WRITE: 000332nA
[pool-4-thread-1] INFO - [/127.0.0.1:2824] WRITE: 000432nA
[pool-4-thread-1] INFO - [/127.0.0.1:2824] WRITE: 000532nA
It was my understanding that simultaneous requests like this would spawn
five different threads (currently all executed in order, in
pool-4-thread-1). Am I wrong? If so, is there a way to have these processed
concurrently, as we are facing some performance issues?
Our filter chain is set up as follows:
filterChainBuilder = acceptorConfig.getFilterChain();
filterChainBuilder.addLast("codec", new ProtocolCodecFilter(new
TcCodecFactory()));
filterChainBuilder.addLast("logger", new LoggingFilter());
filterChainBuilder.addLast("threadPool", new ExecutorFilter(
Executors.newCachedThreadPool()));
Thanks in advance! I greatly appreciate everyone's help.
-Matt
Re: executor filter chain behavior
Posted by "이희승 (Trustin Lee)" <tr...@gmail.com>.
You can still implement your own ExecutorFilter with MINA 1.x. It sould
be pretty easy. Another option is to use byte code manipulation tool
such as retrotranslator.
2008-03-11 (화), 15:04 -0400, Matt Mehalso 쓰시길:
> I see now that this is the expected behavior in Mina 1.x. We can't use Mina
> 2.0/UnorderedExecutorFilter as we cannot use Java 1.5 in our environment.
> Has anyone published a custom version of an unordered ExecutorFilter for
> Java 1.4? Otherwise I guess we'll just write our own.
>
> Thanks,
>
> Matt
>
> On Tue, Mar 11, 2008 at 2:11 PM, Matt Mehalso <me...@gmail.com> wrote:
>
> > All -
> >
> > We are having some strange behavior with our MINA 1.0.9-based server
> > during load test. I may be misinterpreting the purpose of an executor in
> > the filter chain - please let me know if I have an incorrect understanding
> > of its usage.
> >
> > Our server is a pretty simple asynchronous request/response server where
> > multiple requests may come in all at once and be answered in any order.
> >
> > We have an Executor filter set up at the end of our filter chain to
> > process requests concurrently. However, when under load, our server is
> > processing all requests in order, in the same thread. For example, please
> > see the log below:
> >
> > [SocketAcceptorIoProcessor-0.0] INFO - [/127.0.0.1:2824] RECEIVED:
> > n0002..<omitted for readability>
> > [SocketAcceptorIoProcessor-0.0] INFO - [/127.0.0.1:2824] RECEIVED:
> > n0003..<omitted>
> > [SocketAcceptorIoProcessor-0.0] INFO - [/127.0.0.1:2824] RECEIVED:
> > n0004..<omitted>
> > [SocketAcceptorIoProcessor-0.0] INFO - [/127.0.0.1:2824] RECEIVED:
> > n0005..<omitted>
> >
> > [pool-4-thread-1] INFO - [/127.0.0.1:2824] WRITE: 0001E24
> > ...<SENT's omitted for readability>
> > [pool-4-thread-1] INFO - [/127.0.0.1:2824] WRITE: 000232nA
> > [pool-4-thread-1] INFO - [/127.0.0.1:2824] WRITE: 000332nA
> > [pool-4-thread-1] INFO - [/127.0.0.1:2824] WRITE: 000432nA
> > [pool-4-thread-1] INFO - [/127.0.0.1:2824] WRITE: 000532nA
> >
> > It was my understanding that simultaneous requests like this would spawn
> > five different threads (currently all executed in order, in
> > pool-4-thread-1). Am I wrong? If so, is there a way to have these processed
> > concurrently, as we are facing some performance issues?
> >
> > Our filter chain is set up as follows:
> >
> > filterChainBuilder = acceptorConfig.getFilterChain();
> > filterChainBuilder.addLast("codec", new ProtocolCodecFilter(new
> > TcCodecFactory()));
> > filterChainBuilder.addLast("logger", new LoggingFilter());
> > filterChainBuilder.addLast("threadPool", new ExecutorFilter(
> > Executors.newCachedThreadPool()));
> >
> > Thanks in advance! I greatly appreciate everyone's help.
> >
> > -Matt
> >
> >
--
Trustin Lee - Principal Software Engineer, JBoss, Red Hat
--
what we call human nature is actually human habit
--
http://gleamynode.net/
Re: executor filter chain behavior
Posted by Matt Mehalso <me...@gmail.com>.
I see now that this is the expected behavior in Mina 1.x. We can't use Mina
2.0/UnorderedExecutorFilter as we cannot use Java 1.5 in our environment.
Has anyone published a custom version of an unordered ExecutorFilter for
Java 1.4? Otherwise I guess we'll just write our own.
Thanks,
Matt
On Tue, Mar 11, 2008 at 2:11 PM, Matt Mehalso <me...@gmail.com> wrote:
> All -
>
> We are having some strange behavior with our MINA 1.0.9-based server
> during load test. I may be misinterpreting the purpose of an executor in
> the filter chain - please let me know if I have an incorrect understanding
> of its usage.
>
> Our server is a pretty simple asynchronous request/response server where
> multiple requests may come in all at once and be answered in any order.
>
> We have an Executor filter set up at the end of our filter chain to
> process requests concurrently. However, when under load, our server is
> processing all requests in order, in the same thread. For example, please
> see the log below:
>
> [SocketAcceptorIoProcessor-0.0] INFO - [/127.0.0.1:2824] RECEIVED:
> n0002..<omitted for readability>
> [SocketAcceptorIoProcessor-0.0] INFO - [/127.0.0.1:2824] RECEIVED:
> n0003..<omitted>
> [SocketAcceptorIoProcessor-0.0] INFO - [/127.0.0.1:2824] RECEIVED:
> n0004..<omitted>
> [SocketAcceptorIoProcessor-0.0] INFO - [/127.0.0.1:2824] RECEIVED:
> n0005..<omitted>
>
> [pool-4-thread-1] INFO - [/127.0.0.1:2824] WRITE: 0001E24
> ...<SENT's omitted for readability>
> [pool-4-thread-1] INFO - [/127.0.0.1:2824] WRITE: 000232nA
> [pool-4-thread-1] INFO - [/127.0.0.1:2824] WRITE: 000332nA
> [pool-4-thread-1] INFO - [/127.0.0.1:2824] WRITE: 000432nA
> [pool-4-thread-1] INFO - [/127.0.0.1:2824] WRITE: 000532nA
>
> It was my understanding that simultaneous requests like this would spawn
> five different threads (currently all executed in order, in
> pool-4-thread-1). Am I wrong? If so, is there a way to have these processed
> concurrently, as we are facing some performance issues?
>
> Our filter chain is set up as follows:
>
> filterChainBuilder = acceptorConfig.getFilterChain();
> filterChainBuilder.addLast("codec", new ProtocolCodecFilter(new
> TcCodecFactory()));
> filterChainBuilder.addLast("logger", new LoggingFilter());
> filterChainBuilder.addLast("threadPool", new ExecutorFilter(
> Executors.newCachedThreadPool()));
>
> Thanks in advance! I greatly appreciate everyone's help.
>
> -Matt
>
>