[JBoss JIRA] Created: (JBREM-1144) Extend connection identity to server side
by Ron Sigal (JIRA)
Extend connection identity to server side
-----------------------------------------
Key: JBREM-1144
URL: https://jira.jboss.org/jira/browse/JBREM-1144
Project: JBoss Remoting
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Affects Versions: 2.2.3, 2.5.1 (Flounder)
Reporter: Ron Sigal
Assignee: Ron Sigal
Fix For: 2.5.2 (Flounder), 2.2.3.SP1
In JBREM-1128 "Introduce connection identity concept" and JBREM-1132 "CLONE [JBREM-1128] - Introduce connection identity concept", the server was equipped to recognized when a client had been replaced by another client. In other words, clients were assigned an identity. This concept should be extended to the server side, so that ConnectionValidator can detect that a server has been replaced.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 10 months
[JBoss JIRA] Created: (JBREM-1226) Sockets created by bisocket secondary ServerSocket should be configured properly
by Ron Sigal (JIRA)
Sockets created by bisocket secondary ServerSocket should be configured properly
--------------------------------------------------------------------------------
Key: JBREM-1226
URL: https://jira.jboss.org/browse/JBREM-1226
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 2.2.3.SP2, 2.5.2.SP3 (Flounder)
Reporter: Ron Sigal
Assignee: Ron Sigal
Fix For: 2.2.3.SP3, 2.5.2.SP4 (Flounder)
Sockets created by org.jboss.remoting.transport.socket.SocketServerInvoker are configured by
protected void configureSocket(Socket s) throws SocketException
{
s.setReuseAddress(getReuseAddress());
if (keepAliveSet) s.setKeepAlive(keepAlive);
if (oOBInlineSet) s.setOOBInline(oOBInline);
if (receiveBufferSize > -1) s.setReceiveBufferSize(receiveBufferSize);
if (sendBufferSize > -1) s.setSendBufferSize(sendBufferSize);
if (soLingerSet &&
soLingerDuration > 0) s.setSoLinger(soLinger, soLingerDuration);
if (trafficClass > -1) s.setTrafficClass(trafficClass);
}
but configureSocket() is not called for sockets created by org.jboss.remoting.transport.bisocket.BisocketServerInvoker.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 11 months
[JBoss JIRA] Created: (JBREM-1227) Fix deadlock between MicroRemoteClientInvoker and RemotingClassLoader
by Ron Sigal (JIRA)
Fix deadlock between MicroRemoteClientInvoker and RemotingClassLoader
---------------------------------------------------------------------
Key: JBREM-1227
URL: https://jira.jboss.org/browse/JBREM-1227
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 2.5.2.SP3 (Flounder)
Reporter: Ron Sigal
Assignee: Ron Sigal
Fix For: 2.5.2.SP4 (Flounder)
The following deadlock can occur:
1. Thread T1 reads a response with an object whose class is not available locally, so it uses its org.jboss.remoting.loading.RemotingClassLoader to try to download the class
a. java.lang.ClassLoader.loadClassInternal() acquires a lock on itself (an instance of RemotingClassLoader)
b. RemotingClassLoader uses its copy of an org.jboss.remoting.loading.ClassByteClassLoader to try to download the class
c. ClassByteClassLoader calls org.jboss.remoting.MicroRemoteClientInvoker.invoke(), which tries to synchronize on MicroRemoteClientInvoker.class as it sets up an UnMarshaller with a ClassLoader
2. Thread T2 attempts to make an invocation
a. MicroRemoteClientInvoker.invoke() acquires a lock on MicroRemoteClientInvoker.class
b. MicroRemoteClientInvoker.invoke() calls the synchronized method RemotingClassLoader.setUserClassLoader(), which tries to acquire a lock on the RemotingClassLoader
Deadlock.
The only two synchronized methods in RemotingClassLoader are setUserClassLoader() and unsetUserClassLoader(), which are both called from MicroRemoteClientInvoker.invoke(). The call to setUserClassLoader() is already done while the MicroRemoteClientInvoker.class lock is held. If the call to unsetUserClassLoader() is made with the same lock, then setUserClassLoader() and unsetClassLoader() don't have to be synchronized. That will eliminate the deadlock because step 2b is removed.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 11 months
[JBoss JIRA] Created: (JBREM-981) CLONE [JBREM-980] - ServerInvokerServlet should retrieve ServletServerInvoker based on updated InvokerLocator
by Ron Sigal (JIRA)
CLONE [JBREM-980] - ServerInvokerServlet should retrieve ServletServerInvoker based on updated InvokerLocator
-------------------------------------------------------------------------------------------------------------
Key: JBREM-981
URL: http://jira.jboss.com/jira/browse/JBREM-981
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 2.4.0.CR2
Reporter: Ron Sigal
Assigned To: Ron Sigal
Fix For: 2.4.0.GA
>From Galder:
Consider
<servlet>
<servlet-name>Ejb3ServerInvokerServlet</servlet-name>
<description>The ServerInvokerServlet receives requests via HTTP
protocol from within a web container and passes it onto the
ServletServerInvoker for processing.
</description>
<servlet-class>org.jboss.remoting.transport.servlet.web.ServerInvokerServlet</servlet-class>
<init-param>
<param-name>locatorUrl</param-name>
<param-value>servlet://${jboss.bind.address}:8080/unified-invoker/Ejb3ServerInvokerServlet</param-value>
<description>The servlet server invoker</description>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
Now, let's say you bind to 0.0.0.0. You'll get an exception like this:
13:39:26,856 ERROR [ContainerBase] Servlet /unified-invoker threw load() exception
javax.servlet.ServletException: Can not find servlet server invoker with same locator as specified (servlet://0.0.0.0:8080/unified-invoker/Ejb3ServerInvokerServlet)
at org.jboss.remoting.transport.servlet.web.ServerInvokerServlet.getInvokerFromInvokerUrl(ServerInvokerServlet.java:198)
at org.jboss.remoting.transport.servlet.web.ServerInvokerServlet.init(ServerInvokerServlet.java:66)
The problem arises from the fact that Remoting is trying to compare:
servlet://0.0.0.0:8080/unified-invoker/Ejb3ServerInvokerServlet
with
servlet://localhost.localdomain:8080/unified-invoker/Ejb3ServerInvokerServlet
So either, ServerInvokerServlet should call ServerInvoker.validateLocator() with locatorUrl, take the return of that and compare that with the list of locators.
Or validateLocator() is modified to have the real original host passed to the InvokerLocator constructor, rather than the transformed or newHost.
--
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
14 years, 5 months
[JBoss JIRA] Created: (JBREM-1229) Display recreated InvokerLocator when bind address is 0.0.0.0
by Ron Sigal (JIRA)
Display recreated InvokerLocator when bind address is 0.0.0.0
-------------------------------------------------------------
Key: JBREM-1229
URL: https://jira.jboss.org/browse/JBREM-1229
Project: JBoss Remoting
Issue Type: Task
Security Level: Public (Everyone can see)
Affects Versions: 2.5.2.SP3 (Flounder), 2.2.3.SP2
Reporter: Ron Sigal
Assignee: Ron Sigal
Priority: Minor
Fix For: 2.2.3.SP3, 2.5.2.SP4 (Flounder)
Occasionally, the character "_" is used in hostnames, which is illegal, according to http://www.ietf.org/rfc/rfc952.txt. The java.net.URI parser gets confused, and the detectable phenomenon is the replacement of the port with -1.
When 0.0.0.0 is given as the bind address, org.jboss.remoting.ServerInvoker calls org.jboss.Remoting.InvokerLocator.validateLocator() to create an InvokerLocator with a host accessible over a network. By default, the host name is used, which leads to the problem described above.
If the system property InvokerLocator.BIND_BY_HOST (actual value "remoting.bind_by_host"), the host address will be used instead, which would work around the problem.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 5 months