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 <[EMAIL PROTECTED]> 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/
signature.asc
Description: This is a digitally signed message part
