[ https://issues.jboss.org/browse/AS7-4860?page=com.atlassian.jira.plugin.s... ] Remmelt van der Werff updated AS7-4860: --------------------------------------- Description: I am in the process of migrating from jboss 5 to 7 and I am having problems accessing jms through jndi, which I think is related to a bug. The lookup works fine when the client accesses the server on 127.0.0.1. On any other address bound to the loopback device (eg 127.0.0.2) the getting of the initial context fails with the "Operation failed with status WAITING" error. The server was started with -b 0.0.0.0. Looking at the logs I notice the following. The client waits max 5 seconds for a response from the server before issueing the WAITING error. In case of 127.0.0.1 no problem, but with 127.0.0.2 the server does "something" that takes up exactly 5 seconds. 10:02:16,565 TRACE [org.xnio.channels.framed] (Remoting "server17" read-1) Created new framed message channel around TCP socket channel (NIO) <5f55b990>, receive buffer Pooled wrapper around java.nio.HeapByteBuffer[pos=0 lim=8196 cap=8196], transmit buffer Pooled wrapper around java.nio.HeapByteBuffer[pos=0 lim=8196 cap=8196] 10:02:21,573 TRACE [org.xnio.listener] (Remoting "server17" read-1) Setting channel listener to org.jboss.remoting3.remote.RemoteConnection$RemoteWriteListener@54038f36 This 5 seconds delay in the server breaks the 5 second timeout in the client. In the client log you can see the initial handshake coming in right after the error message (which gets terminated because the connections was already closed by the client). Problem occurs with both 7.1.1.Final as with jboss-as-7.2.0.Alpha1-SNAPSHOT was: I am in the process of migrating from jboss 5 to 7 and I am having problems accessing jms through jndi, which I think is related to a bug. The lookup works fine when the client accesses the server on 127.0.0.1. On any other address bound to the loopback device (eg 127.0.0.2) the getting of the initial context fails with the "Operation failed with status WAITING" error. The server was started with -b 0.0.0.0. Looking at the logs I notice the following. The client waits max 5 seconds for a response from the server before issueing the WAITING error. In case of 127.0.0.1 no problem, but with 127.0.0.2 the server does "something" that takes up exactly 5 seconds. 10:02:16,565 TRACE [org.xnio.channels.framed] (Remoting "server17" read-1) Created new framed message channel around TCP socket channel (NIO) <5f55b990>, receive buffer Pooled wrapper around java.nio.HeapByteBuffer[pos=0 lim=8196 cap=8196], transmit buffer Pooled wrapper around java.nio.HeapByteBuffer[pos=0 lim=8196 cap=8196] 10:02:21,573 TRACE [org.xnio.listener] (Remoting "server17" read-1) Setting channel listener to org.jboss.remoting3.remote.RemoteConnection$RemoteWriteListener@54038f36 This 5 seconds delay in the server breaks the 5 second timeout in the client. In the client log you can see the initial handshake comming in right after the error message (which gets terminated because the connections was already closed by the client). Problem occurs with both 7.1.1.Final as with jboss-as-7.2.0.Alpha1-SNAPSHOT -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-4860?page=com.atlassian.jira.plugin.s... ] jaikiran pai commented on AS7-4860: ----------------------------------- I don't know what that 5 second delay is, but the remote-naming project does allow overriding the default 5 second timeout value. All you have to do is pass the jboss.naming.client.connect.timeout property value while creating the InitialContext: {code} Properties props = new Properties(); // timeout is in milli. seconds. Here we configure a 10 second timeout props.put("jboss.naming.client.connect.timeout", "10000"); Context context = new InitialContext(props); {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-4860?page=com.atlassian.jira.plugin.s... ] Remmelt van der Werff commented on AS7-4860: -------------------------------------------- Thanks Jaikiran. Setting the timeout to 10 seconds in the client was successful as a workaround. The client hangs for 5 seconds and then continues. {code} 14:03:36,466 TRACE [selector] Beginning select on sun.nio.ch.EPollSelectorImpl@811e50c 14:03:41,529 TRACE [selector] Selected on sun.nio.ch.EPollSelectorImpl@811e50c {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira