Hi Trustin, Thanks for looking into this. I was able to resolve the issue at hand and I hope that my feedback helps others.
I'm running on OS X version 10.5 (Leopard, the latest release). After I got the feeling from you that it might be something other than MINA because you were able to run things with another program, I tried to run one of the examples from trunk. It failed at the same place where it was supposed to bind.. That was when I started suspecting Leopard running with the Java 1.5 release (If you're not aware, apple pulled back and uninstalled java 6 from apple computers that upgraded to the latest OS X, hurting the feelings of all java developers who had already moved to java 6). All is well now. I was able to get a java 6 port from http://landonf.bikemonkey.org/code/macosx and once I recompiled all the mina sources against it, as well as my program, the acceptor bound successfully. With all this said, the port from the link above is not officially supported by anyone, but at least people can move on on OS X Leopard (10.5) until Apple releases something usable. Once again, thanks for the great support.. I love MINA! -Ussama Trustin Lee wrote: > > It seems like the acceptor thread died unexpectedly while the main > thread waits for bind completion notification. I tried to reproduce > the problem with minimal code, but my attempt ended up with failure. > Could you please provide source code that I can execute by myself? > > Thanks, > Trustin > > On Nov 24, 2007 10:50 PM, ubaggili <[EMAIL PROTECTED]> wrote: >> >> Here the source code.. I'm running on java 1.5. You I've commented out >> the >> old NioSocketAcceptor binding within it: >> >> public static void main(String[] args) throws IOException { >> >> IoHandlerChain chain = new IoHandlerChain(); >> ChainedIoHandler cih = new ChainedIoHandler(chain); >> >> ChainedDemuxingIoHandler messageHandler = new >> ChainedDemuxingIoHandler(); >> >> // add the AgiRequest Message Handler >> messageHandler.addMessageHandler(AgiRequest.class, new >> AgiRequestMessageHandler()); >> messageHandler.addMessageHandler(AgiCommandResponse.class, new >> AgiCommandResponseMessageHandler()); >> >> chain.addLast("DemuxingIoHandler", messageHandler); >> chain.addLast("AgiProtocolIoHandler", new >> AgiProtocolIoHandler()); >> >> // SocketAcceptor acceptor = new NioSocketAcceptor(5, new >> NewThreadExecutor()); //<--- old invocation >> SocketAcceptor acceptor = new NioSocketAcceptor(5); >> >> acceptor.setReuseAddress(true); >> acceptor.getFilterChain().addLast("protocol", new >> ProtocolCodecFilter(new AgiCodecFactory())); >> // acceptor.getFilterChain().addLast("TestFilter", new >> TestFilter()); >> acceptor.getFilterChain().addLast("logger", new LoggingFilter()); >> >> acceptor.getFilterChain().addLast("executor", new >> ExecutorFilter(Executors.newCachedThreadPool())); >> acceptor.getSessionConfig().setIdleTime(IdleStatus.BOTH_IDLE, >> 10); >> acceptor.setLocalAddress(new InetSocketAddress(4573)); >> acceptor.setHandler(cih); >> >> acceptor.bind(); >> >> System.out.println("server is listenig on port " + 4573); >> } >> >> >> within acceptor.bind(), I've stepped through the execution to see where >> things hang, and it was line 150 of the AbstractPollingIoAcceptor class >> --> >> request.awaitUninterruptibly(); >> >> stack for that is: >> org.apache.mina.transport.socket.nio.NioSocketAcceptor(org.apache.mina.common.AbstractPollingIoAcceptor<T,H>).bind0() >> line: 150 >> >> >> Full Thread dump: >> >> Full thread dump Java HotSpot(TM) Client VM (1.5.0_13-119 mixed mode, >> sharing): >> >> "Low Memory Detector" daemon prio=5 tid=0x01008ed0 nid=0x806a00 runnable >> [0x00000000..0x00000000] >> >> "CompilerThread0" daemon prio=9 tid=0x010084a0 nid=0x805c00 waiting on >> condition [0x00000000..0xb0b077d8] >> >> "Signal Dispatcher" daemon prio=9 tid=0x01008040 nid=0x809a00 waiting on >> condition [0x00000000..0x00000000] >> >> "Finalizer" daemon prio=8 tid=0x01007870 nid=0x818200 in Object.wait() >> [0xb0a05000..0xb0a05d90] >> at java.lang.Object.wait(Native Method) >> - waiting on <0x25a7cd30> (a java.lang.ref.ReferenceQueue$Lock) >> at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116) >> - locked <0x25a7cd30> (a java.lang.ref.ReferenceQueue$Lock) >> at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132) >> at >> java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159) >> >> "Reference Handler" daemon prio=10 tid=0x01007490 nid=0x816a00 in >> Object.wait() [0xb0984000..0xb0984d90] >> at java.lang.Object.wait(Native Method) >> - waiting on <0x25a7cdb0> (a java.lang.ref.Reference$Lock) >> at java.lang.Object.wait(Object.java:474) >> at >> java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116) >> - locked <0x25a7cdb0> (a java.lang.ref.Reference$Lock) >> >> "main" prio=5 tid=0x01001350 nid=0xb0801000 in Object.wait() >> [0xb07ff000..0xb0800148] >> at java.lang.Object.wait(Native Method) >> - waiting on <0x2558da90> (a >> org.apache.mina.common.AbstractIoService$ServiceOperationFuture) >> at >> org.apache.mina.common.DefaultIoFuture.awaitUninterruptibly(DefaultIoFuture.java:96) >> - locked <0x2558da90> (a >> org.apache.mina.common.AbstractIoService$ServiceOperationFuture) >> at >> org.apache.mina.common.AbstractPollingIoAcceptor.bind0(AbstractPollingIoAcceptor.java:150) >> at >> org.apache.mina.common.AbstractIoAcceptor.bind(AbstractIoAcceptor.java:146) >> - locked <0x25610638> (a java.lang.Object) >> at >> com.xentelco.asterisk.agi.server.XenServer.main(XenServer.java:62) >> >> "VM Thread" prio=9 tid=0x01006be0 nid=0x815c00 runnable >> >> "VM Periodic Task Thread" prio=9 tid=0x01009a30 nid=0x807800 waiting on >> condition >> >> "Exception Catcher Thread" prio=10 tid=0x010015a0 nid=0x80b000 runnable >> >> Thanks in advance, >> Ussama >> >> >> >> Trustin Lee wrote: >> > >> > Could you please provide the full thread dump of the moment when your >> > server hangs? Any source code would be appreciated. >> > >> > HTH, >> > Trustin >> > >> > On Nov 24, 2007 1:04 PM, ubaggili <[EMAIL PROTECTED]> wrote: >> >> >> >> Hey Guys, >> >> >> >> It's great to see that you're actively working on mina 2.0. I love it! >> >> >> >> I recently updated my mina 2.0 tree and for some reason, my >> >> NioSocketAcceptor cannot bind anymore. I did take note of the change >> in >> >> constructor signature. However, I need some direction.. My >> application >> >> hangs when trying to bind. Also, it seems that the NewThreadExecutor >> >> class >> >> no longer exists? What did this change to? Where should I be >> looking? >> >> >> >> Thanks, >> >> Ussama >> >> -- >> >> View this message in context: >> >> >> http://www.nabble.com/Binding-issues-with-NioSocketAcceptor---mina-2.0-tf4864844s16868.html#a13921865 >> >> Sent from the Apache MINA Support Forum mailing list archive at >> >> Nabble.com. >> >> >> >> >> > >> > >> > >> > -- >> > what we call human nature is actually human habit >> > -- >> > http://gleamynode.net/ >> > -- >> > PGP Key ID: 0x0255ECA6 >> > >> > >> >> -- >> View this message in context: >> http://www.nabble.com/Binding-issues-with-NioSocketAcceptor---mina-2.0-tf4864844s16868.html#a13924887 >> >> Sent from the Apache MINA Support Forum mailing list archive at >> Nabble.com. >> >> > > > > -- > what we call human nature is actually human habit > -- > http://gleamynode.net/ > -- > PGP Key ID: 0x0255ECA6 > > -- View this message in context: http://www.nabble.com/Binding-issues-with-NioSocketAcceptor---mina-2.0-tf4864844s16868.html#a13931570 Sent from the Apache MINA Support Forum mailing list archive at Nabble.com.
