June 2008 - jboss-remoting-issues

[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-1004) Run manual servlet unit tests

by Ron Sigal (JIRA)

Run manual servlet unit tests ----------------------------- Key: JBREM-1004 URL: http://jira.jboss.com/jira/browse/JBREM-1004 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-1002) Allow ServerThread to keep running after SocketTImeoutException, part 2

by Ron Sigal (JIRA)

Allow ServerThread to keep running after SocketTImeoutException, part 2 ----------------------------------------------------------------------- Key: JBREM-1002 URL: http://jira.jboss.com/jira/browse/JBREM-1002 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.2.2.SP7 Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.2.2.SP8 In response to JBREM-945 "Allow ServerThread to keep running after SocketTImeoutException", org.jboss.remoting.transport.socket.ServerThread was changed so that after experiencing a SocketTimeoutException, it would go on to wait for the next invocation. It turns out not to always be a good idea to continue after a SocketTimeoutException. In particular, once a java.io.ObjectInputStream throws a SocketTimeoutException, all subsequent reads will throw an EOFException. In this case it would be better immediately to close the ServerThread's socket and inform the client side that the connection is not usable. On the other hand, an org.jboss.serial.io.JBossObjectInputStream works as expected; i.e., it will continue to function after a SocketTimeoutException. In this case it is appropriate to keep the ServerThread in use. -- 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
2
0 / 0

[JBoss JIRA] Created: (JBREM-1003) Verify IPv6 addresses are handled correctly, part 2

by Ron Sigal (JIRA)

Verify IPv6 addresses are handled correctly, part 2 --------------------------------------------------- Key: JBREM-1003 URL: http://jira.jboss.com/jira/browse/JBREM-1003 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.2.2.SP7 Reporter: Ron Sigal Assigned To: Ron Sigal Priority: Minor Fix For: 2.2.2.SP8 org.jboss.remoting.InvokerLocator doesn't handle zones properly in IPv6 addresses because of the "%" character in the <address>%<zone_id> format. -- 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
2
0 / 0

[JBoss JIRA] Reopened: (JBREM-902) InvocationRequest need SSLSession for certificates and principal in sslsocket transport

by ya xiang (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-902?page=all ] ya xiang reopened JBREM-902: ---------------------------- indeed, the handshakelistener style process not fit some case. especial future in NIO transports case. As I before mentioned, we can search the ssl session id by client address, this function provided by http://jira.jboss.com/jira/browse/JBREM-758 But in Pojo case, maybe you don't want to pass the arguments to implementation, like this: void doService(ClientAddress, otherBizArguments), BTW, ICE use this style. most equivent to void doSevice(RequestPayload, otherBizArguments); OK, In pojo: we just do it like this: void doService(BizArguments); so if need client credientals, we must handle it at invoker class and and find seesionid and then put it to threadlocal. so I advice, just do it and server thread, put ssl session to threadlocal, and set it defualt as default behaviour, (jbossAS use it too). OK, if someone not need it, just config it like CLIENT_ADDRESS configing. > InvocationRequest need SSLSession for certificates and principal in sslsocket transport > --------------------------------------------------------------------------------------- > > Key: JBREM-902 > URL: http://jira.jboss.com/jira/browse/JBREM-902 > Project: JBoss Remoting > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: security > Reporter: ya xiang > > In a SSL context, there is a real need for check principal and certificates. > There are ways to do this, but current jboss remoting not provide it, just provider socket remote address as sessionId. seems not enough. -- 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
0
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

[JBoss JIRA] Created: (JBREM-995) Apply unit test timing fixes

by Ron Sigal (JIRA)

Apply unit test timing fixes ---------------------------- Key: JBREM-995 URL: http://jira.jboss.com/jira/browse/JBREM-995 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.2.2.SP7 Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.2.2.SP8 Some unit tests fail occasionally because of timing constraints, and many of these have been fixed on the 2.x branch. These fixes should be copied to the 2.2 branch. -- 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-1001) Update Remoting Guide

by Ron Sigal (JIRA)

Update Remoting Guide --------------------- Key: JBREM-1001 URL: http://jira.jboss.com/jira/browse/JBREM-1001 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-954) InterruptException should not be rethrown as CannotConnectionException

by Galder Zamarreno (JIRA)

InterruptException should not be rethrown as CannotConnectionException ---------------------------------------------------------------------- Key: JBREM-954 URL: http://jira.jboss.com/jira/browse/JBREM-954 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Components: transport Reporter: Galder Zamarreno Fix For: 2.2.2.SP4 Let's say you have a Swing GUI application that calls an EJB remotely and the client code is waiting to get entry to client side pool (controlled by clientMaxPoolSize). While waiting, the user decides to cancel the operation by interrupting the thread. In that case, the Remoting code does not make a difference between an InterruptedException and any other Exception: MicroSocketClientInvoker.java: protected SocketWrapper getConnection(Marshaller marshaller, UnMarshaller unmarshaller, int timeAllowed) throws Exception { long start = System.currentTimeMillis(); long timeToWait = (timeAllowed > 0) ? timeAllowed : 30000; boolean timedout = !semaphore.attempt(timeToWait); Any Exception thrown from getConnection() is treated as a CannotConnectException try { socketWrapper = getConnection(marshaller, unmarshaller, timeLeft); } catch (Exception e) { // if (bailOut) // return null; semaphore.release(); if (trace) log.trace(this + " released semaphore: " + semaphore.permits()); throw new CannotConnectException( "Can not get connection to server. Problem establishing " + "socket connection for " + locator, e); } The EJB3 layer wraps this in CannotConnectException in a RuntimeException like: throw new RuntimeException("cluster invocation failed, last exception was: ", lastException); This is misleading on the Remoting side. Semantically, the fact that the thread attempting to connect is interrupted shouldn't be translated into a CannotConnectException. Please find attached a test case I've created. -- 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
22
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

jboss-remoting-issues June 2008