[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, 6 months
[JBoss JIRA] Created: (JBREM-929) Secure remote classloading
by David Lloyd (JIRA)
Secure remote classloading
--------------------------
Key: JBREM-929
URL: http://jira.jboss.com/jira/browse/JBREM-929
Project: JBoss Remoting
Issue Type: Task
Security Level: Public (Everyone can see)
Reporter: David Lloyd
Fix For: 3.0.0-M3
Remote classloading should be allowed only if either (a) a security manager is installed (and thus the security manager would create the policy) or (b) a specific option is enabled (which would be disabled by default) to allow it.
Also, the remote classloader needs to be able to work with the standard security manager policy - which is to say, that classes loaded from a remote service need to have a unique codeBase URL so that administrators can grant permission to remote classes based on the service from whence they came.
--
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, 9 months
[JBoss JIRA] Created: (JBREM-947) ConnectionValidator hangs when server dies
by Tim Fox (JIRA)
ConnectionValidator hangs when server dies
------------------------------------------
Key: JBREM-947
URL: http://jira.jboss.com/jira/browse/JBREM-947
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Tim Fox
Fix For: 2.2.2.SP7
If the connection between client and server is pulled (pull the real cable) or the entire server suddenly dies, then the connection won't be closed from the server (unlike a kill -9 of the server where the OS will terminate that processses connections), so the client making the write() or read() on the socket won't receive an exception.
In the eyes of TCP the connection is still alive and the read/write will block until the socket timeout is reached.
Typically the socket timeout will be much higher than the desired failure detection time (the validation interval), but currently failure will never be detected in this situation before the socket timeout time.
Remoting should not be dependent on the socket timeout for failure detection, the connetion validation and socket timeout should be possible to be configured separately.
E.g. you might want to configure a socket timeout of 60 seconds, but a connection validation frequency (ping) of 5 seconds. Currently this is not possible.
The current implementation gives inconsistent behaviour depending on how the server died - i.e. whether the process died (e.g. kill -9) or the cable was pulled or the entire server disappeared.
--
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
15 years, 1 month
[JBoss JIRA] Created: (JBREM-949) CLONE [JBREM-947] - ConnectionValidator hangs when server dies
by Ron Sigal (JIRA)
CLONE [JBREM-947] - ConnectionValidator hangs when server dies
--------------------------------------------------------------
Key: JBREM-949
URL: http://jira.jboss.com/jira/browse/JBREM-949
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 2.2.2.SP7
Reporter: Tim Fox
Assigned To: Ron Sigal
Fix For: 2.4.0.GA
If the connection between client and server is pulled (pull the real cable) or the entire server suddenly dies, then the connection won't be closed from the server (unlike a kill -9 of the server where the OS will terminate that processses connections), so the client making the write() or read() on the socket won't receive an exception.
In the eyes of TCP the connection is still alive and the read/write will block until the socket timeout is reached.
Typically the socket timeout will be much higher than the desired failure detection time (the validation interval), but currently failure will never be detected in this situation before the socket timeout time.
Remoting should not be dependent on the socket timeout for failure detection, the connetion validation and socket timeout should be possible to be configured separately.
E.g. you might want to configure a socket timeout of 60 seconds, but a connection validation frequency (ping) of 5 seconds. Currently this is not possible.
The current implementation gives inconsistent behaviour depending on how the server died - i.e. whether the process died (e.g. kill -9) or the cable was pulled or the entire server disappeared.
--
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
15 years, 1 month
[JBoss JIRA] Created: (JBREM-992) Can't restart a Connector that uses SocketServerInvoker
by Brian Stansberry (JIRA)
Can't restart a Connector that uses SocketServerInvoker
-------------------------------------------------------
Key: JBREM-992
URL: http://jira.jboss.com/jira/browse/JBREM-992
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 2.4.0.GA (Pinto)
Reporter: Brian Stansberry
Priority: Minor
You can't take a Connector that uses SocketServerInvoker through a restart, i.e. these lifecycle steps:
create/start/stop/start.
You have to do a full transition to destroy and back through create.
This is because SocketServerInvoker sets its maxPoolSize field to 0 as part of its cleanup work in stop(). If you then call start() you get a failure due to 0 being an invalid value for maxPoolSize:
2008-06-04 12:33:00,382 DEBUG [org.jboss.invocation.unified.server.UnifiedInvokerHA] (RMI TCP Connec
tion(31)-127.0.0.1) Starting failed jboss:service=invoker,type=unifiedha,partitionName=RestartPartit
ion
java.lang.IllegalArgumentException: Illegal cache capacities
at org.jboss.util.LRUCachePolicy.<init>(LRUCachePolicy.java:77)
at org.jboss.remoting.transport.socket.LRUPool.<init>(LRUPool.java:44)
at org.jboss.remoting.transport.socket.SocketServerInvoker.start(SocketServerInvoker.java:231)
at org.jboss.invocation.unified.server.UnifiedInvoker.startService(UnifiedInvoker.java:140)
at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:376)
at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:322)
at sun.reflect.GeneratedMethodAccessor65.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
--
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
15 years, 11 months
[JBoss JIRA] Created: (JBREM-1000) CLONE [JBREM-962] - Remote classloading does not work with Isolated EARs
by Ron Sigal (JIRA)
CLONE [JBREM-962] - Remote classloading does not work with Isolated EARs
------------------------------------------------------------------------
Key: JBREM-1000
URL: http://jira.jboss.com/jira/browse/JBREM-1000
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 2.2.2.SP4
Environment: EAP4.3
Reporter: Magesh Kumar B
Assigned To: Ron Sigal
Fix For: 2.2.2.SP8
When user has enabled isolation in a ear file containing an EJB3 jar file, the implementation classes are not serialized and a ClassNotFoundException is thrown. I have attached a sample called HelloEJB3.zip that contains all files needed for deploying this test case. Using EAP4.3 do "ant deploy" and then do "ant test".
When the jboss-app.xml is removed the application client works fine. This fails in the isolated mode with the below exception:
Caused by: java.lang.ClassNotFoundException: org.jboss.ejb3.user.UserImpl
at org.jboss.remoting.serialization.ClassLoaderUtility.loadClass(ClassLoaderUtility.java:82)
at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:76)
at java.lang.ClassLoader.loadClassInternal(Unknown Source)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Unknown Source)
at org.jboss.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:174)
at java.io.ObjectInputStream.readNonProxyDesc(Unknown Source)
at java.io.ObjectInputStream.readClassDesc(Unknown Source)
at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source)
at java.io.ObjectInputStream.readObject0(Unknown Source)
at java.io.ObjectInputStream.readObject(Unknown Source)
at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:122)
at java.io.ObjectInputStream.readExternalData(Unknown Source)
at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source)
at java.io.ObjectInputStream.readObject0(Unknown Source)
at java.io.ObjectInputStream.defaultReadFields(Unknown Source)
at java.io.ObjectInputStream.readSerialData(Unknown Source)
at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source)
at java.io.ObjectInputStream.readObject0(Unknown Source)
at java.io.ObjectInputStream.readObject(Unknown Source)
at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:239)
at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:133)
at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:120)
at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:919)
at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:613)
at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:122)
at org.jboss.remoting.Client.invoke(Client.java:1634)
at org.jboss.remoting.Client.invoke(Client.java:548)
at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:62)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:53)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:74)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.stateless.StatelessRemoteProxy.invoke(StatelessRemoteProxy.java:107)
--
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
16 years, 4 months