[ http://jira.jboss.com/jira/browse/JBESB-1378?page=comments#action_12389970 ] Pavel Kadlec commented on JBESB-1378: ------------------------------------- JBossRemotingGatewayListener does not disconnect properly on undeploy only when using Apache APR. I tested it on Fedora 8 using APR 1.2.11. When I disable APR, everything is OK. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBESB-1378?page=all ] Mark Little reassigned JBESB-1378: ---------------------------------- Assignee: Daniel Bevenius (was: Tom Cunningham) Daniel, could you take a look at this one? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBESB-1378?page=comments#action_12393641 ] Daniel Bevenius commented on JBESB-1378: ---------------------------------------- I've verified that this issue occurs when using Apache APR on Linux. The problem seems to be that org.apache.tomcat.util.net.AprEndpoint$Acceptor's run method is blocking on accept: public void run() { log.info( "Aceptor.run..."); // Loop until we receive a shutdown command while (running) { // Loop if endpoint is paused while (paused) { try { Thread.sleep(1000); } catch (InterruptedException e) { // Ignore } } try { // Allocate a new worker thread // Accept the next incoming connection from the server socket // Hand this socket off to an appropriate processor log.info( "Aceptor.run.accept serverSock : " + serverSock + ", port : " + port); getWorkerThread().assign(Socket.accept(serverSock), true); } catch (Throwable t) { log.error(sm.getString("endpoint.accept.fail"), t); } // The processor will recycle itself when it finishes } log.info( "Aceptor.run...done"); } After 'ant-undeploy' the following netstat call produces: #netstat -na | grep 8765 tcp 0 0 127.0.0.1:8765 0.0.0.0:* LISTEN Now, telneting like this: telnet localhost 8765 will exit the accept block and the check "if (running) will make the method exit, and the quickstart can be redeployed as the port is now free. I'll post to the jbossweb forum and see if they can help us out. There might be a way to make the accept call no-blocking or there might be a way to force the method to exit which might be what "The processor will recycle itself when it finishes" is indicating. I've been trying to play around with various settings for the AprEndpoint class but without success. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBESB-1378?page=comments#action_12395148 ] Daniel Bevenius commented on JBESB-1378: ---------------------------------------- I havn't gotten any response on the thread I created yet... I can create a jira for this in the JBossWeb project perhaps? Any thoughts on how we should proceed? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBESB-1378?page=comments#action_12396117 ] Daniel Bevenius commented on JBESB-1378: ---------------------------------------- Thanks for the feedback! I've checked and JBossRemotingGatewayListener calls stopJBRServer() which calls the Connector's stop() method.. This will in the end invoke AprEndpoints stop() method which calls unlockAccept(). But this does not seem to unlock the socked accept method. I'll see if I can write a test case for this and submit it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBESB-1378?page=comments#action_12396144 ] Daniel Bevenius commented on JBESB-1378: ---------------------------------------- I can get this to work if I write something to the socket like this: protected void unlockAccept() { java.net.Socket s = null; try { // Need to create a connection to unlock the accept(); if (address == null) { s = new java.net.Socket("127.0.0.1", port); } else { s = new java.net.Socket(address, port); // setting soLinger to a small value will help shutdown the // connection quicker s.setSoLinger(true, 0); } s.getOutputStream().write("bogus".getBytes()); } catch(Exception e) { ... } But not otherwise :( -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBESB-1378?page=comments#action_12396545 ] Daniel Bevenius commented on JBESB-1378: ---------------------------------------- Thanks for your feedback Remy. Do you think I should create a JIRA for this issue in JBossWeb so it can be tracked ? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBESB-1378?page=comments#action_12396848 ] Mark Little commented on JBESB-1378: ------------------------------------ Daniel, on second thoughts just leave it as is for now. I'll move this to Unassigned until we decide what to do. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBESB-1378?page=all ] Remy Maucherat reassigned JBESB-1378: ------------------------------------- Assignee: Remy Maucherat -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBESB-1378?page=all ] Kevin Conner updated JBESB-1378: -------------------------------- Fix Version/s: 4.4 (was: 4.3) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBESB-1378?page=all ] Mark Little updated JBESB-1378: ------------------------------- Fix Version/s: (was: 4.4) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBESB-1378?page=all ] Mark Little reassigned JBESB-1378: ---------------------------------- Assignee: (was: Mark Little) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira