[JBoss JIRA] (JBREM-1326) Socket read timeout is not set on Control Thread/Socket
by Ron Sigal (JIRA)
[ https://issues.jboss.org/browse/JBREM-1326?page=com.atlassian.jira.plugin... ]
Ron Sigal closed JBREM-1326.
----------------------------
Resolution: Out of Date
> Socket read timeout is not set on Control Thread/Socket
> -------------------------------------------------------
>
> Key: JBREM-1326
> URL: https://issues.jboss.org/browse/JBREM-1326
> Project: JBoss Remoting
> Issue Type: Bug
> Environment: JBoss EAP 5
> Reporter: Doug Grove
> Assignee: Ron Sigal
>
> It is possible for an unhandled exception to be thrown from the EJB container that causes orphaned control threads to accumulate:
> "control: Socket[addr=127.0.0.1,port=45892,localport=51040]" daemon prio=3 tid=0x056c2800 nid=0x2002 runnable [0x5ba4f000]
> java.lang.Thread.State: RUNNABLE
> java.net.SocketInputStream.socketRead0(Native Method)
> java.net.SocketInputStream.read(SocketInputStream.java:129)
> java.net.SocketInputStream.read(SocketInputStream.java:182)
> java.io.FilterInputStream.read(FilterInputStream.java:66)
> The socket read blocks indefinitely as there is no timeout.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 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 closed JBREM-1322.
----------------------------
Resolution: Out of Date
> 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
> Components: transport
> Affects Versions: 2.5.4.SP4
> Reporter: Igor Kostromin
> Assignee: Ron Sigal
>
> 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 was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months
[JBoss JIRA] (JBREM-1289) CLONE [JBREM-1288] - StreamServer for in-jvm connection should create a LocalServerInvoker
by Ron Sigal (JIRA)
[ https://issues.jboss.org/browse/JBREM-1289?page=com.atlassian.jira.plugin... ]
Ron Sigal closed JBREM-1289.
----------------------------
Resolution: Out of Date
> CLONE [JBREM-1288] - StreamServer for in-jvm connection should create a LocalServerInvoker
> ------------------------------------------------------------------------------------------
>
> Key: JBREM-1289
> URL: https://issues.jboss.org/browse/JBREM-1289
> Project: JBoss Remoting
> Issue Type: Bug
> Affects Versions: 2.2.4
> Reporter: Ron Sigal
> Assignee: Ron Sigal
> Fix For: 2.2.4.SP1
>
>
> When the org.jboss.remoting.Client method
> public Object invoke(InputStream inputStream, Object param) throws Throwable;
> or one of its variants is called, it calls new StreamServer(inputStream), which creates an org.jboss.remoting.transport.Connector to serve the contents of the InputStream. To determine the transport to be used, StreamServer looks for a system property "remoting.stream.transport", and, if it doesn't exist, it uses "socket" by default. However, if the InputStream is being sent to a server in the same JVM, the "local" transport should be used.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months