Re: VmPipeConnector Initialisation order

["이희승 (Trustin Lee)" <tr...@gmail.com>]

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/