May 2009 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBREM-1138) JBREM-1127 - ClassCastExceptions arising from Unmarsharller/Classloader caching in MicroRemoteClientInvoker

by Galder Zamarreño (JIRA)

JBREM-1127 - ClassCastExceptions arising from Unmarsharller/Classloader caching in MicroRemoteClientInvoker ----------------------------------------------------------------------------------------------------------- Key: JBREM-1138 URL: https://jira.jboss.org/jira/browse/JBREM-1138 Project: JBoss Remoting Issue Type: Support Patch Security Level: Public (Everyone can see) Reporter: Galder Zamarreño Assignee: Galder Zamarreño Port JBREM-1127 to a one-off patch so that classloading issues are avoided with paralell isolated EAR invocations using different versions of same class. -- 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

14 years, 1 month

2
3
0 / 0

[JBoss JIRA] Created: (JBREM-1054) Annotation to automatically return new transporters types

by David Lloyd (JIRA)

Annotation to automatically return new transporters types --------------------------------------------------------- Key: JBREM-1054 URL: https://jira.jboss.org/jira/browse/JBREM-1054 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Components: r3 api Reporter: David Lloyd Priority: Optional Fix For: 3.1.0.Beta1 It would be cool if a transporter interface (or an implementing class of that interface) could have methods which sport an annotation that indicates that the return value of that method, if it is an interface, should be automatically wrapped into a transporter (if invoked via a transporter). This way, complex remote object structures can be easily created and used. Also handy would be a simple way of notating such methods when the interface and implementation are already existent. -- 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

14 years, 1 month

3
14
0 / 0

[JBoss JIRA] Created: (JBREM-857) transporterclient not thread-safe for failover

by craig bordelon (JIRA)

transporterclient not thread-safe for failover ---------------------------------------------- Key: JBREM-857 URL: http://jira.jboss.com/jira/browse/JBREM-857 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Components: transporter Affects Versions: 1.4.6.GA Environment: solaris 10 and java 5 Reporter: craig bordelon Fix For: 2.2.2.GA_CP02 the jboss 1.4.1 transporterclient used by multithreaded program was giving strange results on a clustered server when failing over so i found lack of synchronization in the code. I made these changes and seems to be helping. changes to TransporterClient.java. I would like this fixed in the 2.x and 3.x versions (hello developers). I think i know how to fix the 2.x version of this code too as it has some new stuff but is likewise broken. (developers send me an email to bord(a)iscp.telcordia.com if you need it. thx Craig) @@ -93,11 +93,12 @@ /** * Disconnects the remoting client */ - private void disconnect() + private synchronized void disconnect() { if(remotingClient != null) { remotingClient.disconnect(); + remotingClient = null; } } @@ -232,14 +233,18 @@ do { + Client rcl = null; + synchronized(this) { rcl = remotingClient; } + if (rcl == null) throw new CannotConnectException("Client has been dis connected."); try { failOver = false; - response = remotingClient.invoke(request); + response = rcl.invoke(request); } catch(CannotConnectException cnc) { - failOver = findAlternativeTarget(); + failOver = findAlternativeTarget(rcl); + if (log.isDebugEnabled()) log.error("on CannotConnectException failO ver is "+failOver+" for "+rcl.getInvoker().getLocator()); if(!failOver) { throw cnc; @@ -264,7 +269,7 @@ * * @return */ - private boolean findAlternativeTarget() + private boolean findAlternativeTarget(Client rcl) { boolean failover = false; @@ -287,12 +292,19 @@ { // finally found server with target handler InvokerLocator newLocator = data.getInvokerLocator(); - if(!remotingClient.getInvoker().getLocator().equals(new Locator)) + if(!rcl.getInvoker().getLocator().equals(newLocator)) { try { - remotingClient = new Client(newLocator); - remotingClient.connect(); + synchronized(this) { + if (rcl == remotingClient) { + disconnect(); + remotingClient = new Client(newLocator); + } + //otherwise have to assume some other thread + //has meanwhile changed it + //including even disconnecting + } return true; } catch(Exception e) @@ -300,6 +312,8 @@ log.warn("Problem connecting to newly found alter nate target.", e); } } + else if (log.isDebugEnabled()) + log.error(rcl.getInvoker().getLocator()+" == "+newLoc ator); } } } @@ -333,4 +347,4 @@ } -- 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

3
3
0 / 0

[JBoss JIRA] Created: (JBREM-906) NoSuchObjectException on Server Restart Using RMI Transport & Unified Invoker

by John Reynolds (JIRA)

NoSuchObjectException on Server Restart Using RMI Transport & Unified Invoker ----------------------------------------------------------------------------- Key: JBREM-906 URL: http://jira.jboss.com/jira/browse/JBREM-906 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Components: unifiedinvoker Affects Versions: 2.2.2.GA Environment: Server Running Windows XP or Redhat - Swing Client on Windows XP Reporter: John Reynolds Using a Swing client to connect to the JBoss server, configured with RMI Transport Connector and Unified Invoker, I receive the following StackTrace when, after successfully connecting to the server and executing a few EJB transactions, I shut the server down and then bring it back up. Upon attempting to do any further invocations, it appears cached information is causing the client to fail. ------------- (rmi.RMIClientInvoker 272 ) java.rmi.NoSuchObjectException: no such object in table galaxy.framework.model.domain.services.util.SLCommunicationException: Error making invocation in RMI client invoker. at galaxy.framework.model.domain.services.util.ServiceLocator.authenticateUser(ServiceLocator.java:738) at galaxy.framework.model.domain.services.util.ServiceLocator.initializeWithLDAP(ServiceLocator.java:435) at galaxy.application.view.swing.presentation.util.ClientConnectionManager$1.run(ClientConnectionManager.java:51) Caused by: org.jboss.remoting.CannotConnectException: Error making invocation in RMI client invoker. at org.jboss.remoting.transport.rmi.RMIClientInvoker.transport(RMIClientInvoker.java:273) at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:122) at org.jboss.remoting.Client.invoke(Client.java:1550) at org.jboss.remoting.Client.invoke(Client.java:530) at org.jboss.invocation.unified.interfaces.UnifiedInvokerProxy.invoke(UnifiedInvokerProxy.java:183) at org.jboss.invocation.InvokerInterceptor.invokeInvoker(InvokerInterceptor.java:365) at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:197) at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:61) at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:70) at org.jboss.proxy.ejb.StatelessSessionInterceptor.invoke(StatelessSessionInterceptor.java:112) at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:100) at $Proxy1.authenticateSwingUserWithLDAP(Unknown Source) at galaxy.framework.model.domain.services.util.ServiceLocator.authenticateUser(ServiceLocator.java:725) ... 2 more Caused by: java.rmi.NoSuchObjectException: no such object in table at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247) at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223) at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:126) at org.jboss.remoting.transport.rmi.RMIServerInvoker_Stub.transport(Unknown Source) at org.jboss.remoting.transport.rmi.RMIClientInvoker.transport(RMIClientInvoker.java:238) ... 14 more ------------ Seems potentially similar to this issue fixed in 4.0.5 in non-remoting-RMI code: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=116027 -- 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

2
1
0 / 0

[JBoss JIRA] Created: (JBREM-802) TransporterHandler should not use Class.forName

by Julien Viet (JIRA)

TransporterHandler should not use Class.forName ----------------------------------------------- Key: JBREM-802 URL: http://jira.jboss.com/jira/browse/JBREM-802 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Components: transporter Affects Versions: 2.2.1.GA, 2.2.0.SP4 Reporter: Julien Viet line: classSig[x] = Class.forName(sig[x]); should probably be replaced by classSig[x] = targetPOJO.getClass().getClassLoader().loadClass(sig[x]); to provide a correct class lookup -- 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

4
4
0 / 0

[JBoss JIRA] Created: (JBREM-808) Remove dependencies on ObjectNameFactory from JBoss JMX

by Julien Viet (JIRA)

Remove dependencies on ObjectNameFactory from JBoss JMX ------------------------------------------------------- Key: JBREM-808 URL: http://jira.jboss.com/jira/browse/JBREM-808 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Reporter: Julien Viet It happens when my POJO has not been bound on the transporter server, it looks like the transporter client is trying to do some fail over. This make JBoss Remoting depends on the JBoss JMX implementation. That makes JBoss Remoting more difficult to embed and reuse. I think that the ObjectNameFactory class could be easily ported to JBoss Remoting without any harm done. However perhaps JBoss Remoting has more dependencies on JBoss JMX that I don't know that would prevent to remove such dependency. [junit_] Exception in thread "main" java.lang.NoClassDefFoundError: org/jboss/mx/util/ObjectNameFactory [junit_] at org.jboss.remoting.transporter.InternalTransporterServices.<clinit>(InternalTransporterServices.java:41) [junit_] at org.jboss.remoting.transporter.TransporterClient.findAlternativeTarget(TransporterClient.java:330) [junit_] at org.jboss.remoting.transporter.TransporterClient.invoke(TransporterClient.java:301) [junit_] at $Proxy0.getInfo(Unknown Source) [junit_] at org.jboss.portal.test.framework.driver.remote.RemoteTestDriverClient.getInfo(RemoteTestDriverClient.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

14 years, 1 month

3
3
0 / 0

[JBoss JIRA] Created: (JBREM-762) Deadlock bug in socket invoker

by Tim McCune (JIRA)

Deadlock bug in socket invoker ------------------------------ Key: JBREM-762 URL: http://jira.jboss.com/jira/browse/JBREM-762 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Components: transport Affects Versions: 1.4.6.GA Environment: JBoss 4.0.4 EJB 3.0-rc9-patch1 JDK 1.6.0 Reporter: Tim McCune There is a potential thread leak in ServerThread.java that causes ServerThreads to stick around, but to disappear from the thread pool as the accept() thread(s) see it. Eventually, when the # of leaked threads reaches the MaxPoolSize, the system ends up deadlocked and will not accept any more incoming socket connections. I have described the problem in great detail in a forum post and in support case 00016786. I have patched the code, and so far it seems to be working fine and to have fixed the problem. This is what I patched: In ServerThread.java, I wrapped the contents of wakeup() inside of a try/catch, block, with the following code in the catch block: } catch (Exception e) { synchronized (clientpool) { synchronized (threadpool) { clientpool.remove(this); threadpool.add(this); Thread.interrupted(); } } throw e; } This makes sure that the thread is put back into the threadpool when an exception occurs in the createServerSocket() method (this method is doing socket I/O in 1.4.6, and in our case, this socket connection was timing out.). -- 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

2
1
0 / 0

[JBoss JIRA] Created: (JBREM-646) dynamic loading of new keystores during runtime is not possible when using Transporters (beaming POJOs)

by Claudia Richter (JIRA)

dynamic loading of new keystores during runtime is not possible when using Transporters (beaming POJOs) ------------------------------------------------------------------------------------------------------- Key: JBREM-646 URL: http://jira.jboss.com/jira/browse/JBREM-646 Project: JBoss Remoting Issue Type: Patch Security Level: Public (Everyone can see) Components: transporter Environment: ?? Reporter: Claudia Richter Assigned To: Tom Elrod when running a Transporter Server and a Transporter Client, using SSL connection, the Transporter Server does not recognise changes within its Truststore, if this is updated. Means, if the Client is not trusted when starting the Server, it will not be trusted for future request until the Server is restarted. It would be better to have a Server that is able to recognise Truststore changes. This feature is already implemented for other transports (no Transporters) as described in issue http://jira.jboss.com/jira/browse/JBREM-427. -- 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

4
7
0 / 0

[JBoss JIRA] Created: (JBREM-652) allow passing of config map when creating transporter client

by Tom Elrod (JIRA)

allow passing of config map when creating transporter client ------------------------------------------------------------ Key: JBREM-652 URL: http://jira.jboss.com/jira/browse/JBREM-652 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Components: transporter Affects Versions: 2.2.0.Alpha4 Reporter: Tom Elrod Assigned To: Tom Elrod Fix For: 2.2.0.Beta1 (Bluto) Currently the transporter client can only be created using invoker locator for configuration. Need to add to the api so can pass config map which gets passed to the remoting client that is created so can customize things such as ssl config. For example, would be need to be able to something like is done in org.jboss.test.remoting.transport.socket.ssl.custom.InvokerClientTest with a transporter client. -- 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

3
4
0 / 0

[JBoss JIRA] Created: (JBREM-738) ServerThread/invoker still executing invocation after its related TransportServer was stopped

by craig bordelon (JIRA)

ServerThread/invoker still executing invocation after its related TransportServer was stopped --------------------------------------------------------------------------------------------- Key: JBREM-738 URL: http://jira.jboss.com/jira/browse/JBREM-738 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Components: transporter Affects Versions: 2.2.0.Beta1 (Bluto) Environment: java 1.5 on solaris but doubt its specific to this one. Reporter: craig bordelon Assigned To: Tom Elrod get an exception on the third iteration of a transporter client to a transporter server where the client code is doing the same invoke each time. This should not happen as the first two iterations give correct result. The exception is thrown from the server side as apparently the jboss remoting internals are confused -- stating that a ServerInvoker is not in "started state". Exception is java.lang.reflect.UndeclaredThrowableException at $Proxy4.toString(Unknown Source) at java.lang.String.valueOf(String.java:2615) at java.lang.StringBuilder.append(StringBuilder.java:116) at proxy.Client.testClientCall(Client.java:38) at proxy.Client.main(Client.java:115) Caused by: org.jboss.remoting.ServerInvoker$InvalidStateException: Can not proc ess invocation request since is not in started state. at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:751) at org.jboss.remoting.transport.socket.ServerThread.processInvocation(S erverThread.java:568) at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread. java:390) at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.ja va:164) at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClient Invoker.java:163) at org.jboss.remoting.Client.invoke(Client.java:1548) at org.jboss.remoting.Client.invoke(Client.java:534) at org.jboss.remoting.Client.invoke(Client.java:522) at org.jboss.remoting.transporter.TransporterClient.invoke(TransporterC lient.java:297) to reproduce this (one way at least): run the transporter sample modified for the Client to execute the the makeClientCall multiple times. Now to get past the obvious first issue (socket in use) add new code for customerProcessor.releaseCustomer(processedCustomer.getCustomerId() in the Client just before the TransporterClient.destroyTransporterClient(customerProcessor); Implement this method in the CustomerProcessorImpl to use the id to locate (eg hash get()) the related ICustomer TransporterClient and destroy it and to the TransporterServer to stop it. This theoretically frees up the Customer "server" allowing for the next iteration by the Client. note that the processCustomer() implemenation is modified to store the TransporterClient and TransporterServer that are created here. ------------ I dug into the code a bit and what i gathered is that a ServerThread is trying to do processInvocation using a SocketServerInvoker that was already "stopped". I think the ServerThread itself should not be executing as the TransporterServer it should be involved with was already stopped. I posted to the jboss forum on issues i was having trying to make the transporter sample run from the client multiple times. See issue by "bord" on 4/17/2007 -- 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

3
3
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira May 2009