November 2011 - jboss-remoting-issues

[JBoss JIRA] (JBREM-318) add remoting based chat sample

by Ron Sigal (Closed) (JIRA)

[ https://issues.jboss.org/browse/JBREM-318?page=com.atlassian.jira.plugin.... ] Ron Sigal closed JBREM-318. --------------------------- Resolution: Done > add remoting based chat sample > ------------------------------ > > Key: JBREM-318 > URL: https://issues.jboss.org/browse/JBREM-318 > Project: JBoss Remoting > Issue Type: Task > Security Level: Public(Everyone can see) > Components: general > Affects Versions: 1.4.0 final > Reporter: Tom Elrod > Assignee: Ron Sigal > Priority: Optional > Fix For: 2.5.3.Beta (Flounder) > > > Add a simple chat application using remoting for the communication layer to the remoting samples. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBREM-1300) Create or preview Data Source does not work without network connection when accessing EDS server on localhost

by Ron Sigal (Closed) (JIRA)

[ https://issues.jboss.org/browse/JBREM-1300?page=com.atlassian.jira.plugin... ] Ron Sigal closed JBREM-1300. ---------------------------- Resolution: Done Jason made the following comment on the support case: {quote} Hello, Ron Sigal has done some investigation, and come up with this explaination. JBoss remoting is the thing making the connection, by setting up a org.jboss.remoting.stream.StreamServer, which creates a ServerSocket. This ServerSocket is bound to the address returned by InetAddress.getLocalHost() by default. On my machine that was the ethernet interface, eth0, which I disconnected prior to attempting to make a connection to the TEIID server. If there is no network connectivity on this interface, when an attempt to make a connection is made, we get the error in question. We can force StreamServer to create a ServerSocket on a different interface, eg, localhost, by setting the system property "remoting.stream.host", to "localhost". To do that, add the following line to the end of $EDS_HOME/bin/run.conf. JAVA_OPTS="$JAVA_OPTS -Dremoting.stream.host=localhost" Please test your VM environment using this setting, and let us know the result. Regards, Jason {quote} The support case is now closed > Create or preview Data Source does not work without network connection when accessing EDS server on localhost > ------------------------------------------------------------------------------------------------------------- > > Key: JBREM-1300 > URL: https://issues.jboss.org/browse/JBREM-1300 > Project: JBoss Remoting > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 2.5.3.SP1 > Environment: Fedora 15 > JBoss Developer Studio (JBDS) 4 > Enterprise Data Services (EDS) 5.1.0 > Reporter: Jason Shepherd > Assignee: Ron Sigal > Fix For: 2.5.4.SP4 > > > When trying to create a preview a datasource using the Teiid designer, an error dialogue is shown, and the EDS server.log shows an error containing this message. This only happens when there is no network connectivity on the machine, for example the network cable is unplugged. > [IOException]Can not find a free port for use -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] Created: (JBREM-1169) Bisocket connection won't be closed if pulling out the ethernet cable between client and server. The failure detection code won't close the failure connection, as a result, the subsequent requests will hang after connection account exceeds the threshold

by mingjun jiang (JIRA)

Bisocket connection won't be closed if pulling out the ethernet cable between client and server. The failure detection code won't close the failure connection, as a result, the subsequent requests will hang after connection account exceeds the threshold ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Key: JBREM-1169 URL: https://jira.jboss.org/jira/browse/JBREM-1169 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Components: detection Affects Versions: 2.2.3.SP1 Environment: OS: Windows Server 2003. JBoss App Server 4.2.3.GA, JBoss Messaging 1.4.5 GA, JBoss Remoting 2.2.3 SP1 Reporter: mingjun jiang We are using JBoss App Server 4.2.3.GA, JBoss Messaging 1.4.5 GA and JBoss Remoting 2.2.3 SP1. In our application, there are a lot of Message listeners running on the client side, these message listeners will receive messages from queue/topic deployed in JBoss Messaging Configuration: We created our own JMS Connection factory which uses the default remoting connector. As you know, the default remoting connector is configured to use the bisocket transport. We didn't change the default value of the remoting connector During we run our application, we open the JBoss web console to monitor the value of currentClientPoolSize under "Jboss.remoting" JMX MBean. How to reproduce this issue: 1. Run 5 message listeners in the client side to receive messages from JBoss Messaging, then we observe the value of currentClientPoolSize is 10 2. After processing several messages, we manually pull out the ethernet cable. The value of currentClientPoolSize is still 10. 3. We run another 5 message listeners in client side, then the value of currentClientPoolSize will become 20 4. After we do the same operations above several times, the value of currentClientPoolSize will increase continuously. Once the value of currentClientPoolSize is equal to the MaxPoolSize, then the subsequent incoming client requests will hang, and we will encounter the following exception in server side 2009-10-20 18:08:09,655 ERROR [org.jboss.remoting.transport.socket.ServerThread] Worker thread initialization failure java.net.SocketException: Connection reset at java.net.SocketInputStream.read(SocketInputStream.java:168) at java.io.BufferedInputStream.fill(BufferedInputStream.java:218) at java.io.BufferedInputStream.read(BufferedInputStream.java:235) at java.io.FilterInputStream.read(FilterInputStream.java:66) at org.jboss.remoting.transport.socket.ServerThread.readVersion(ServerThread.java:859) at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:545) at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:406) at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:173) Conclusion: JBoss Messaging won't close the failure connections if they are caused by manually pulling out ethernet cable. As a result, the value of currentClientPoolSize will increase continuously and finally the new client requests will hang Note: If we killed the process of message listener in client side, then the value of currentClientPoolSize will decrease to 0 immediately, it seems that the server could detect the failure connection and perform the corresponding resource releasing. -- 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

12 years, 5 months

4
5
0 / 0

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

by Ron Sigal (Resolved) (JIRA)

[ https://issues.jboss.org/browse/JBREM-1138?page=com.atlassian.jira.plugin... ] Ron Sigal resolved JBREM-1138. ------------------------------ Resolution: Done > JBREM-1127 - ClassCastExceptions arising from Unmarsharller/Classloader caching in MicroRemoteClientInvoker > ----------------------------------------------------------------------------------------------------------- > > Key: JBREM-1138 > URL: https://issues.jboss.org/browse/JBREM-1138 > Project: JBoss Remoting > Issue Type: Support Patch > Security Level: Public(Everyone can see) > Affects Versions: 2.2.2.SP11 > 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, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
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

12 years, 5 months

3
14
0 / 0

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

by Ron Sigal (Closed) (JIRA)

[ https://issues.jboss.org/browse/JBREM-906?page=com.atlassian.jira.plugin.... ] Ron Sigal closed JBREM-906. --------------------------- Resolution: Won't Fix > NoSuchObjectException on Server Restart Using RMI Transport & Unified Invoker > ----------------------------------------------------------------------------- > > Key: JBREM-906 > URL: https://issues.jboss.org/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, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

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

by Ron Sigal (Closed) (JIRA)

[ https://issues.jboss.org/browse/JBREM-857?page=com.atlassian.jira.plugin.... ] Ron Sigal closed JBREM-857. --------------------------- Resolution: Won't Fix > transporterclient not thread-safe for failover > ---------------------------------------------- > > Key: JBREM-857 > URL: https://issues.jboss.org/browse/JBREM-857 > Project: JBoss Remoting > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: transporter > Affects Versions: 1.4.6.GA, 2.2.2.SP2, 2.4.0.Beta1 (Pinto) > Environment: solaris 10 and java 5 > Reporter: craig bordelon > Fix For: 2.5.3.Beta (Flounder) > > Original Estimate: 1 day > Remaining Estimate: 1 day > > 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, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

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

by Ron Sigal (Closed) (JIRA)

[ https://issues.jboss.org/browse/JBREM-808?page=com.atlassian.jira.plugin.... ] Ron Sigal closed JBREM-808. --------------------------- Resolution: Rejected > Remove dependencies on ObjectNameFactory from JBoss JMX > ------------------------------------------------------- > > Key: JBREM-808 > URL: https://issues.jboss.org/browse/JBREM-808 > Project: JBoss Remoting > Issue Type: Task > Security Level: Public(Everyone can see) > Affects Versions: 2.2.2.SP1, 2.4.0.Beta1 (Pinto) > Reporter: julien1 > Fix For: 2.5.3.Beta (Flounder) > > > 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, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

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

by Ron Sigal (Closed) (JIRA)

[ https://issues.jboss.org/browse/JBREM-802?page=com.atlassian.jira.plugin.... ] Ron Sigal closed JBREM-802. --------------------------- Resolution: Rejected > TransporterHandler should not use Class.forName > ----------------------------------------------- > > Key: JBREM-802 > URL: https://issues.jboss.org/browse/JBREM-802 > Project: JBoss Remoting > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: transporter > Affects Versions: 2.2.2.GA, 2.4.0.Beta1 (Pinto) > Reporter: julien1 > Fix For: 2.5.3.Beta (Flounder) > > > 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, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

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

by Ron Sigal (Closed) (JIRA)

[ https://issues.jboss.org/browse/JBREM-762?page=com.atlassian.jira.plugin.... ] Ron Sigal closed JBREM-762. --------------------------- Resolution: Out of Date > Deadlock bug in socket invoker > ------------------------------ > > Key: JBREM-762 > URL: https://issues.jboss.org/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, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

jboss-remoting-issues November 2011