2008-01-25 (금), 12:34 -0800, hborders 쓰시길:
>
> Trustin Lee wrote:
> >
> > If you take a look into the VmPipeFilterChain, there's a queue for such a
> > case:
> >
> > ...
> >
> > So, I think it will work fine without causing a dead lock or
> > messageReceived event to be fired before sessionOpened is fired. Does
> > it make sense?
> >
>
> In a VmPipe, I've run into some problems with sessionCreated not completing
> before sessionOpened and messageReceived are called. I thought that mina
> guaranteed that sessionCreated would be completed before sessionOpened and
> messageReceived. I think this stems from the following code in
> ExecutorFilter:
>
> public void sessionCreated(NextFilter nextFilter, IoSession session) {
> nextFilter.sessionCreated(session);
> }
>
> All other event handlers run the nextFilter a separate thread thusly:
>
> public void sessionOpened(NextFilter nextFilter, IoSession session) {
> fireEvent(nextFilter, session, EventType.OPENED, null);
> }
>
>
> The issue appears if the VmPipeConnector writes a message while the
> VmPipeAcceptor's IoHandler is still envoking sessionCreated.
>
> The program below illustrates the problem. It outputs a String with events
> appended in the order they finish. We would expect it to print
> "sessionCreated, sessionOpened, messageReceived, ", but it prints
> "sessionOpened, messageReceived, sessionCreated, ".
>
> public class VmPipeSessionCreatedTimingBug {
> public static void main(String[] args) throws Exception {
> final Semaphore semaphore = new Semaphore(0);
> final StringBuffer stringBuffer = new StringBuffer();
> VmPipeAcceptor vmPipeAcceptor = new VmPipeAcceptor();
> final VmPipeAddress vmPipeAddress = new VmPipeAddress(12345);
> vmPipeAcceptor.bind(vmPipeAddress, new IoHandlerAdapter() {
> @Override
> public void sessionCreated(IoSession session) throws
> Exception {
> // pretend we are doing some time-consuming
> work. For
> // performance reasons, you would never want to
> do time
> // consuming work in sessionCreated.
> // However, this increases the likelihood of
> the timing bug.
> Thread.sleep(5000);
> stringBuffer.append("sessionCreated, ");
> }
>
> @Override
> public void sessionOpened(IoSession session) throws
> Exception {
> Thread.sleep(1000);
> stringBuffer.append("sessionOpened, ");
> }
>
> @Override
> public void messageReceived(IoSession session, Object
> message)
> throws Exception {
> stringBuffer.append("messageReceived, ");
> semaphore.release();
> }
> });
>
> final VmPipeConnector vmPipeConnector = new VmPipeConnector();
> ConnectFuture connectFuture =
> vmPipeConnector.connect(vmPipeAddress,
> new IoHandlerAdapter() {
> @Override
> public void sessionOpened(IoSession
> session)
> throws Exception {
>
> session.write(ByteBuffer.wrap(new byte[1]));
> }
> });
>
> semaphore.tryAcquire(5, TimeUnit.SECONDS);
> connectFuture.getSession().close();
> vmPipeAcceptor.unbindAll();
>
> System.out.println(stringBuffer);
> }
> }Thanks for the detailed report. I succeeded to reproduce the problem, and you can track this issue here: https://issues.apache.org/jira/browse/DIRMINA-543 -- 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
