[jboss-jira] [JBoss JIRA] (AS7-4860) Client InitialContext only works on 127.0.0.1 due to 5 second delay in server on other addresses
Remmelt van der Werff (JIRA)
jira-events at lists.jboss.org
Tue May 22 05:06:20 EDT 2012
[ https://issues.jboss.org/browse/AS7-4860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
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 at 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 at 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
> Client InitialContext only works on 127.0.0.1 due to 5 second delay in server on other addresses
> ------------------------------------------------------------------------------------------------
>
> Key: AS7-4860
> URL: https://issues.jboss.org/browse/AS7-4860
> Project: Application Server 7
> Issue Type: Bug
> Components: Naming, Remoting
> Affects Versions: 7.1.1.Final, 7.2.0.Alpha1
> Environment: Ubuntu 12.04LTS 64bit
> Reporter: Remmelt van der Werff
> Assignee: John Bailey
> Attachments: client-127.0.0.1.log, client-127.0.0.2.log, server-127.0.0.1.log, server-127.0.0.2.log
>
>
> 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 at 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
--
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
More information about the jboss-jira
mailing list