April 2008 - jboss-remoting-issues

[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, 1 month

1
3
0 / 0

[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

14 years, 5 months

3
9
0 / 0

[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

14 years, 5 months

2
5
0 / 0

[JBoss JIRA] Created: (JBREM-963) Work out a mechanism to handle protocol message ordering issues across multiple channels

by David Lloyd (JIRA)

Work out a mechanism to handle protocol message ordering issues across multiple channels ---------------------------------------------------------------------------------------- Key: JBREM-963 URL: http://jira.jboss.com/jira/browse/JBREM-963 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Reporter: David Lloyd Fix For: 3.0.0-M3 When dealing with a protocol using multiple channels (HTTP for example, and possibly a future multi-channel JRPP variant), sending two messages on two different channels can cause ordering issues if the second message sent arrives first. For example, sending a context open on channel A, and a request on channel B, may cause the request to be received before the context open message, resulting in the request being rejected with a "no such context" error. Another example is that stream messages must be handled sequentially. There are several possible solutions, including but not limited to: * for any message B that must come after A, always send A and B on the same channel (problem: HTTP channels are transient, so this won't work for HTTP) (problem: this could load up one channel while leaving other channels empty, even if load-balancing is used) * don't send B until after A is acknowledged (problem: acknowledging A might not be possible within the underlying protocol, like if A is sent in an HTTP reply, requiring a separate ACK message, which can lead to performance problems) * if a message comes in seemingly unsolicited (like a request on a nonexistant context) or out of sequence (like in a stream), queue the message for some fixed amount of time to see if the context open message arrives (problem: could be a source of DoS on the server; also this is a duplication of what protocols like TCP already do, which means that all the same problems must be in effect re-solved) Starting a forum thread to discuss the topic. -- 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, 8 months

1
3
0 / 0

[JBoss JIRA] Created: (JBREM-961) Context closing handshake is broken

by David Lloyd (JIRA)

Context closing handshake is broken ----------------------------------- Key: JBREM-961 URL: http://jira.jboss.com/jira/browse/JBREM-961 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Reporter: David Lloyd Fix For: 3.0.0-M3 Guess I just half-finished it. It needs to be rethought/fixed. See ContextClient.handlerClosing(boolean). -- 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, 9 months

1
2
0 / 0

[JBoss JIRA] Created: (JBREM-941) SRP SASL integrity/confidentiality protection is failing

by David Lloyd (JIRA)

SRP SASL integrity/confidentiality protection is failing -------------------------------------------------------- Key: JBREM-941 URL: http://jira.jboss.com/jira/browse/JBREM-941 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Reporter: David Lloyd Fix For: 3.0.0-M3 See JrppConnection.java (getSaslProperties) - enable the commented-out line and watch SRP blow up. -- 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, 9 months

1
3
0 / 0

[JBoss JIRA] Created: (JBREM-948) Release 2.2.0.SP8

by Ron Sigal (JIRA)

Release 2.2.0.SP8 ----------------- Key: JBREM-948 URL: http://jira.jboss.com/jira/browse/JBREM-948 Project: JBoss Remoting Issue Type: Release Security Level: Public (Everyone can see) Reporter: Ron Sigal -- 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, 10 months

1
3
0 / 0

[JBoss JIRA] Created: (JBREM-957) faulty logging: ...transport.http.ssl.HTTPSClientInvoker.createSocketFactory logs an error when there is no error

by Larry Talley (JIRA)

faulty logging: ...transport.http.ssl.HTTPSClientInvoker.createSocketFactory logs an error when there is no error ----------------------------------------------------------------------------------------------------------------- Key: JBREM-957 URL: http://jira.jboss.com/jira/browse/JBREM-957 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Environment: 2.2.0.GA as included in JBoss-4.2.2.GA Reporter: Larry Talley When used in client mode ...transport.http.ssl.HTTPSClientInvoker.createSocketFactory(HTTPSClientInvoker.java:140) logs an error, but then proceeds to work fine (because sf already has a valid value due to line 129). The misreported error spews misleading information in the log. I suggest that line 144 shouldn't be at ERROR level if the IOException isn't always an error. -- 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, 10 months

2
6
0 / 0

[JBoss JIRA] Created: (JBREM-950) Assure version compatibility with earlier versions of Remoting

by Ron Sigal (JIRA)

Assure version compatibility with earlier versions of Remoting -------------------------------------------------------------- Key: JBREM-950 URL: http://jira.jboss.com/jira/browse/JBREM-950 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.2.2.SP8 -- 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, 10 months

1
1
0 / 0

[JBoss JIRA] Created: (JBREM-962) Remote classloading does not work with Isolated EARs

by Magesh Kumar B (JIRA)

Remote classloading does not work with Isolated EARs ---------------------------------------------------- Key: JBREM-962 URL: http://jira.jboss.com/jira/browse/JBREM-962 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 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

15 years, 10 months

2
10
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

jboss-remoting-issues April 2008