[JBoss JIRA] (JBREM-1322) Cannot set up serverBindAddress for secondarySocket in bisocket transport
by Igor Kostromin (JIRA)
[ https://issues.jboss.org/browse/JBREM-1322?page=com.atlassian.jira.plugin... ]
Igor Kostromin commented on JBREM-1322:
---------------------------------------
My mistake - the option allows set IP address will be useless here, it should be setting like "Ignore received secondary address, use address from original URI".
> Cannot set up serverBindAddress for secondarySocket in bisocket transport
> -------------------------------------------------------------------------
>
> Key: JBREM-1322
> URL: https://issues.jboss.org/browse/JBREM-1322
> Project: JBoss Remoting
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: transport
> Affects Versions: 2.5.4.SP4
> Reporter: Igor Kostromin
> Assignee: Ron Sigal
> Fix For: 2.5.4.SP5
>
>
> Using IS_CALLBACK_SERVER = true.
> In BisocketClientInvoker.java:355
> InvokerLocator getSecondaryLocator() throws Throwable {
> ...
> 355: Object o = invoke(r);
> ...
> }
> It retrieves host from server, but if you want to use original client invoker host, you cannot do this (it is necessary if server is behind translating firewall). If you want to do this, you have to patch this code manually to
> Object o = invoke(r);
> // DZ: patch to use original server address for creating secondary connection
> // instead of address retrieved from server (because server will return jboss bind address
> // that can be local address, inaccessible from client)
> InvokerLocator patchedLocator = new InvokerLocator( (( InvokerLocator ) o).getOriginalURI().replace(
> (( InvokerLocator ) o).getHost(), this.getLocator().getHost() )
> );
> log.debug("secondary locator: " + o);
> log.debug("patched secondary locator: " + patchedLocator);
> return patchedLocator;
> and rebuild jboss-remoting project.
> For ports there are settings SECONDARY_BIND_PORT, SECONDARY_CONNECT_PORT allowing to set up them as you want. For address there is no one to do this.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 4 months
[JBoss JIRA] (JBREM-1322) Cannot set up serverBindAddress for secondarySocket in bisocket transport
by Ron Sigal (JIRA)
[ https://issues.jboss.org/browse/JBREM-1322?page=com.atlassian.jira.plugin... ]
Ron Sigal updated JBREM-1322:
-----------------------------
Fix Version/s: 2.5.4.SP5
Assignee: Ron Sigal
> Cannot set up serverBindAddress for secondarySocket in bisocket transport
> -------------------------------------------------------------------------
>
> Key: JBREM-1322
> URL: https://issues.jboss.org/browse/JBREM-1322
> Project: JBoss Remoting
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: transport
> Affects Versions: 2.5.4.SP4
> Reporter: Igor Kostromin
> Assignee: Ron Sigal
> Fix For: 2.5.4.SP5
>
>
> Using IS_CALLBACK_SERVER = true.
> In BisocketClientInvoker.java:355
> InvokerLocator getSecondaryLocator() throws Throwable {
> ...
> 355: Object o = invoke(r);
> ...
> }
> It retrieves host from server, but if you want to use original client invoker host, you cannot do this (it is necessary if server is behind translating firewall). If you want to do this, you have to patch this code manually to
> Object o = invoke(r);
> // DZ: patch to use original server address for creating secondary connection
> // instead of address retrieved from server (because server will return jboss bind address
> // that can be local address, inaccessible from client)
> InvokerLocator patchedLocator = new InvokerLocator( (( InvokerLocator ) o).getOriginalURI().replace(
> (( InvokerLocator ) o).getHost(), this.getLocator().getHost() )
> );
> log.debug("secondary locator: " + o);
> log.debug("patched secondary locator: " + patchedLocator);
> return patchedLocator;
> and rebuild jboss-remoting project.
> For ports there are settings SECONDARY_BIND_PORT, SECONDARY_CONNECT_PORT allowing to set up them as you want. For address there is no one to do this.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 4 months
[JBoss JIRA] (JBREM-1322) Cannot set up serverBindAddress for secondarySocket in bisocket transport
by Igor Kostromin (JIRA)
[ https://issues.jboss.org/browse/JBREM-1322?page=com.atlassian.jira.plugin... ]
Igor Kostromin updated JBREM-1322:
----------------------------------
Description:
Using IS_CALLBACK_SERVER = true.
In BisocketClientInvoker.java:355
InvokerLocator getSecondaryLocator() throws Throwable {
...
355: Object o = invoke(r);
...
}
It retrieves host from server, but if you want to use original client invoker host, you cannot do this (it is necessary if server is behind translating firewall). If you want to do this, you have to patch this code manually to
Object o = invoke(r);
// DZ: patch to use original server address for creating secondary connection
// instead of address retrieved from server (because server will return jboss bind address
// that can be local address, inaccessible from client)
InvokerLocator patchedLocator = new InvokerLocator( (( InvokerLocator ) o).getOriginalURI().replace(
(( InvokerLocator ) o).getHost(), this.getLocator().getHost() )
);
log.debug("secondary locator: " + o);
log.debug("patched secondary locator: " + patchedLocator);
return patchedLocator;
and rebuild jboss-remoting project.
For ports there are settings SECONDARY_BIND_PORT, SECONDARY_CONNECT_PORT allowing to set up them as you want. For address there is no one to do this.
was:
Using IS_CALLBACK_SERVER = true.
In BisocketServerInvoker.java:355
String host = newLocator.getHost();
int port = newLocator.getPort();
It retrieves host from server, but if you want to use original client invoker host, you cannot do this (it is necessary if server is behind translating firewall). If you want to do this, you have to patch this code manually to
String host = clientInvoker.getLocator().getHost();
int port = newLocator.getPort();
and rebuild jboss-remoting project.
For ports there are settings SECONDARY_BIND_PORT, SECONDARY_CONNECT_PORT allowing to set up them as you want. For address there is no one to do this.
> Cannot set up serverBindAddress for secondarySocket in bisocket transport
> -------------------------------------------------------------------------
>
> Key: JBREM-1322
> URL: https://issues.jboss.org/browse/JBREM-1322
> Project: JBoss Remoting
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: transport
> Affects Versions: 2.5.4.SP4
> Reporter: Igor Kostromin
>
> Using IS_CALLBACK_SERVER = true.
> In BisocketClientInvoker.java:355
> InvokerLocator getSecondaryLocator() throws Throwable {
> ...
> 355: Object o = invoke(r);
> ...
> }
> It retrieves host from server, but if you want to use original client invoker host, you cannot do this (it is necessary if server is behind translating firewall). If you want to do this, you have to patch this code manually to
> Object o = invoke(r);
> // DZ: patch to use original server address for creating secondary connection
> // instead of address retrieved from server (because server will return jboss bind address
> // that can be local address, inaccessible from client)
> InvokerLocator patchedLocator = new InvokerLocator( (( InvokerLocator ) o).getOriginalURI().replace(
> (( InvokerLocator ) o).getHost(), this.getLocator().getHost() )
> );
> log.debug("secondary locator: " + o);
> log.debug("patched secondary locator: " + patchedLocator);
> return patchedLocator;
> and rebuild jboss-remoting project.
> For ports there are settings SECONDARY_BIND_PORT, SECONDARY_CONNECT_PORT allowing to set up them as you want. For address there is no one to do this.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 4 months
[JBoss JIRA] (JBREM-1322) Cannot set up serverBindAddress for secondarySocket in bisocket transport
by Igor Kostromin (JIRA)
Igor Kostromin created JBREM-1322:
-------------------------------------
Summary: Cannot set up serverBindAddress for secondarySocket in bisocket transport
Key: JBREM-1322
URL: https://issues.jboss.org/browse/JBREM-1322
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: transport
Affects Versions: 2.5.4.SP4
Reporter: Igor Kostromin
Using IS_CALLBACK_SERVER = true.
In BisocketServerInvoker.java:355
String host = newLocator.getHost();
int port = newLocator.getPort();
It retrieves host from server, but if you want to use original client invoker host, you cannot do this (it is necessary if server is behind translating firewall). If you want to do this, you have to patch this code manually to
String host = clientInvoker.getLocator().getHost();
int port = newLocator.getPort();
and rebuild jboss-remoting project.
For ports there are settings SECONDARY_BIND_PORT, SECONDARY_CONNECT_PORT allowing to set up them as you want. For address there is no one to do this.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 4 months
[JBoss JIRA] (JBREM-1321) Null pointer when deploying repeatedly via arquillian - EAP 6.1
by John Ament (JIRA)
John Ament created JBREM-1321:
---------------------------------
Summary: Null pointer when deploying repeatedly via arquillian - EAP 6.1
Key: JBREM-1321
URL: https://issues.jboss.org/browse/JBREM-1321
Project: JBoss Remoting
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Reporter: John Ament
I am seeing a NullPointerException consistently after a while for tests running. This is the stack trace. This is in EAP 6.1
2013-06-19 10:06:55,035 [Remoting "management-client" read-1] ERROR org.xnio.listener - A channel event listener threw an exception
java.lang.NullPointerException
at org.jboss.remoting3.remote.IntIndexHashMap.resize(IntIndexHashMap.java:461)
at org.jboss.remoting3.remote.IntIndexHashMap.doPut(IntIndexHashMap.java:406)
at org.jboss.remoting3.remote.IntIndexHashMap.putIfAbsent(IntIndexHashMap.java:154)
at org.jboss.remoting3.remote.RemoteConnectionChannel.handleMessageData(RemoteConnectionChannel.java:424)
at org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:234)
at org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:45)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189)
at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189)
at org.xnio.ssl.JsseConnectedSslStreamChannel.handleReadable(JsseConnectedSslStreamChannel.java:180)
at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
at org.xnio.nio.NioHandle.run(NioHandle.java:90)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:184)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 4 months