[JBoss JIRA] Created: (JGRP-346) Connection objects are removed from the ConnectionTable, but remain active on the system and eventually consume available system resources.
by Stuart Jensen (JIRA)
Connection objects are removed from the ConnectionTable, but remain active on the system and eventually consume available system resources.
-------------------------------------------------------------------------------------------------------------------------------------------
Key: JGRP-346
URL: http://jira.jboss.com/jira/browse/JGRP-346
Project: JGroups
Issue Type: Bug
Affects Versions: 2.3 SP1
Environment: SUSE Linux 9
Reporter: Stuart Jensen
Assigned To: Bela Ban
To duplicate the issue:
1) Create a four member cluster using the following configuration: (two member clusters exhibit the problem as well, just not as exaggerated)
TCP(start_port=7801):
TCPPING(initial_hosts=<ip addresses go here>;port_range=3;timeout=3500;num_initial_members=3;up_thread=true;down_thread=true):
MERGE2(min_interval=5000;max_interval=10000):
FD(shun=true;timeout=2500;max_tries=5;up_thread=true;down_thread=true):
VERIFY_SUSPECT(timeout=2000;down_thread=false;up_thread=false):
pbcast.NAKACK(down_thread=true;up_thread=true;gc_lag=100;retransmit_timeout=3000):
pbcast.STABLE(desired_avg_gossip=20000;down_thread=false;up_thread=false):
pbcast.GMS(join_timeout=5000;join_retry_timeout=3500;shun=true;print_local_addr=true;down_thread=true;up_thread=true)
2) I was running JGroups in a Tomcat servlet application. Start up the cluster. To determine the number of threads on Linux I executed the following commands:
ps -ef | grep tomcat
echo "" > catalina.out
kill -QUIT <pid from ps command above>
grep ".Sender \[" catalina.out | wc -l
You get the process id of Tomcat using the ps command. Then clear the content of the catalina.out file. The kill command causes the threads to be printed into the catalina.out file. Then the grep searches for and counts all of the "ConnectionTable.Connnection.Sender" threads that are currently active on the system.
3) Pick one of the cluster member boxes and pull the network cable out of the box such that all communication with the other three members is terminated.
4) After one or two minutes, replace the network cable.
5) Repeat the steps to determine the number of threads currently active on the system.
6) Repeat steps 3 through 5, each time watching the number of threads. Each iteration will cause more and more threads to be orphaned on the system. It seems to grow exponentially, after about 4 iterations we have around 300-400 Sender threads. The Receiver threads will be orphaned also in similar numbers.
After investigating the issue, I came up with the following "fix" which cleared the problem up.
In the file ConnectionTable.java there is a method called retainAll(). It appears that this method is called by the TCP protocol when a view change occurs. This method removes Connnections from the "Connection Pool" (member variable conns) but does not destroy them. We initially thought the reaper thread may clean them up, but since the Connection objects are actually removed from the Connection Pool, the reaper does not help the situation. As we watched our connections we noticed that the Connections orphaned by this routine were the ones filling up the system's set of threads. So, we added code to call destroy() on all of the Connection objects that retainAll() removes from the Connection Pool. The "diff" is provided below. Note that we did our change in the JGroups 2.3 SP1 file ConnectionTable.java. Scott Marlow did this diff for me, the same change, but applied to the BasicConnectionTable from the 2.4 source set.
Index: BasicConnectionTable.java
===================================================================
RCS file: /cvsroot/javagroups/JGroups/src/org/jgroups/blocks/BasicConnectionTable.java,v
retrieving revision 1.8
diff -r1.8 BasicConnectionTable.java
22,26c22
< import java.util.Map;
< import java.util.Iterator;
< import java.util.HashMap;
< import java.util.Vector;
< import java.util.Collection;
---
> import java.util.*;
263c259,289
< conns.keySet().retainAll(c);
---
> // conns.keySet().retainAll(c);
> ArrayList alConnsToDestroy = new ArrayList();
> synchronized(conns)
> {
> HashMap copy=new HashMap(conns);
> conns.keySet().retainAll(c);
> Set ks = copy.keySet();
> Iterator iter = ks.iterator();
> while (iter.hasNext())
> {
> Object oKey = iter.next();
> if (null == conns.get(oKey))
> { // This connection NOT in the resultant connection set
> Connection conn = (Connection)copy.get(oKey);
> if (null != conn)
> { // Destroy this connection
> alConnsToDestroy.add(conn);
> }
> }
> }
> }
> // All of the connections that were not retained must be destroyed
> // so that their resources are cleaned up.
> for (int a=0; a<alConnsToDestroy.size(); a++)
> {
> Connection conn = (Connection)alConnsToDestroy.get(a);
> if(log.isTraceEnabled())
> log.trace("Destroy this orphaned connection: " + conn);
> conn.destroy();
> }
>
--
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
12 years, 2 months
[JBoss JIRA] Created: (JBREM-552) cannot init cause of ClassCastException
by John Mazzitelli (JIRA)
cannot init cause of ClassCastException
---------------------------------------
Key: JBREM-552
URL: http://jira.jboss.com/jira/browse/JBREM-552
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 2.0.0.Beta2 (Boon)
Reporter: John Mazzitelli
Assigned To: Tom Elrod
Priority: Minor
Fix For: 2.0.0.CR1 (Boon)
I'm in a catch clause within InvokerRegistry and I'm getting a weird exception thrown:
java.lang.IllegalStateException: Can't overwrite cause
at java.lang.Throwable.initCause(Throwable.java:320)
at org.jboss.remoting.InvokerRegistry.loadClientInvoker(InvokerRegistry.java:447)
at org.jboss.remoting.InvokerRegistry.createClientInvoker(InvokerRegistry.java:324)
at org.jboss.remoting.Client.connect(Client.java:385)
at org.jboss.on.communications.command.client.JBossRemotingRemoteCommunicator.getRemotingClient(JBossRemotingRemoteCommunicator.java:470)
at org.jboss.on.communications.command.client.JBossRemotingRemoteCommunicator.send(JBossRemotingRemoteCommunicator.java:430)
at org.jboss.on.communications.command.client.AbstractCommandClient.invoke(AbstractCommandClient.java:167)
at org.jboss.on.communications.command.client.ClientCommandSender.send(ClientCommandSender.java:820)
at org.jboss.on.communications.command.client.ServerPollingThread.run(ServerPollingThread.java:102)
Look at line 447 and you'll see it is trying to init the cause of a ClassNotFoundException. Running in a debugger, the newly constructed exception created on 446 has a null cause. Looking then at Throwable.initCause and you'll see a null cause causes this IllegalStateException to be thrown. The cause needs to be "this", not null (I don't know why, seems like it should also look for null, but whatever - that's the way the JDK is written).
The fix is simple - use the constructor that takes a throwable as its second parameter. Not sure why initCause it being used, as opposed to this constructor.
e.g.:
new ClassNotFoundException("Can not invoke loadClientInvokerClass method on " + transportFactoryClass, e);
(notice the ", e" parameter).
There are three other instances where initCause is called on ClassNotFoundException that also need to be fixed. See the other catch clauses in here.
--
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
12 years, 10 months
[JBoss JIRA] Created: (JBREM-591) Make asynchronous calls using Transporter
by vivek v (JIRA)
Make asynchronous calls using Transporter
-----------------------------------------
Key: JBREM-591
URL: http://jira.jboss.com/jira/browse/JBREM-591
Project: JBoss Remoting
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: transporter
Reporter: vivek v
Assigned To: Tom Elrod
This came out of the user forum question,
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=89224
Currently, there is a mechanism to do asynchronous calls and callbacks using InvocationHandler. As more and more people are using POJOs (via Transporter) for remoting it would be great if we can have the same features (both asynchronous calls and callbacks) available for the Transporter.
Couple of use cases can be,
Asynchronous Call
-----------------------------
1) Client makes a simple method call (using POJO) on server
2) Server gets the request and returns immediately to the Client. Now Client is free to do its own stuff without waiting or polling for the result.
3) Server starts processing the request
4) When the response is ready Server sends the response to the Client.
Callbacks
--------------------
1) An alert happens on the server side
2) Server should be able to send the alert to the Client without Client requesting for it.
--
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
12 years, 11 months
[JBoss JIRA] Created: (JBREM-585) there is the need to add a callback listener for ssl stream invocation
by Michael Voss (JIRA)
there is the need to add a callback listener for ssl stream invocation
----------------------------------------------------------------------
Key: JBREM-585
URL: http://jira.jboss.com/jira/browse/JBREM-585
Project: JBoss Remoting
Issue Type: Task
Security Level: Public (Everyone can see)
Components: stream
Affects Versions: 2.0.0.CR1 (Boon)
Reporter: Michael Voss
Assigned To: Tom Elrod
Fix For: 2.0.0.GA (Boon)
If want to use existing ssl connector for stream invocation (using Client.invoke(InputStream,Object,Connector) ) the client has to add a callback listener to run the the invocation properly
I think stream invocation should also work without the need to add a callback listener
if no listener is added the following exception is thrown:
by stream sender:
org.jboss.remoting.ConnectionFailedException: Connection has been shutdown: javax.net.ssl.SSLProtocolException: Illegal client handshake msg, 1
at org.jboss.remoting.transport.multiplex.MultiplexClientInvoker.handleConnect(MultiplexClientInvoker.java:111)
at org.jboss.remoting.MicroRemoteClientInvoker.connect(MicroRemoteClientInvoker.java:252)
at org.jboss.remoting.Client.connect(Client.java:391)
at org.jboss.remoting.Client.connect(Client.java:383)
at org.jboss.remoting.stream.StreamHandler.<init>(StreamHandler.java:77)
at org.jboss.remoting.ServerInvoker.getStreamHandler(ServerInvoker.java:1253)
at org.jboss.remoting.ServerInvoker.handleInternalInvocation(ServerInvoker.java:1225)
at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:983)
at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:848)
at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:447)
at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:520)
at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:257)
at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:163)
at org.jboss.remoting.Client.invoke(Client.java:612)
at org.jboss.remoting.Client.invoke(Client.java:604)
at org.jboss.remoting.Client.invoke(Client.java:1211)
by stream receiver:
javax.net.ssl.SSLException: Connection has been shutdown: javax.net.ssl.SSLProto
colException: Illegal client handshake msg, 1
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.checkEOF(Unknown Source)
at com.sun.net.ssl.internal.ssl.AppInputStream.read(Unknown Source)
at java.io.BufferedInputStream.fill(Unknown Source)
at java.io.BufferedInputStream.read1(Unknown Source)
at java.io.BufferedInputStream.read(Unknown Source)
at org.jboss.remoting.transport.multiplex.InputMultiplexor$SingleGroupIn
putThread.completeHeader(InputMultiplexor.java:608)
at org.jboss.remoting.transport.multiplex.InputMultiplexor$SingleGroupIn
putThread.doRun(InputMultiplexor.java:540)
at org.jboss.remoting.transport.multiplex.utility.StoppableThread.run(St
oppableThread.java:54)
Caused by: javax.net.ssl.SSLProtocolException: Illegal client handshake msg, 1
at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(Unknown
Source)
at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Unknown Source)
at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Unknown Source
)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(Unknown Source)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(Un
known Source)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.writeRecord(Unknown Source
)
at com.sun.net.ssl.internal.ssl.AppOutputStream.write(Unknown Source)
at java.io.OutputStream.write(Unknown Source)
at org.jboss.remoting.transport.multiplex.OutputMultiplexor$OutputThread
.encode(OutputMultiplexor.java:580)
at org.jboss.remoting.transport.multiplex.OutputMultiplexor$OutputThread
.doRun(OutputMultiplexor.java:452)
... 1 more
--
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
12 years, 11 months
[JBoss JIRA] Created: (JBCLUSTER-140) Examine need for a distributed service registry outside the AS
by Brian Stansberry (JIRA)
Examine need for a distributed service registry outside the AS
--------------------------------------------------------------
Key: JBCLUSTER-140
URL: http://jira.jboss.com/jira/browse/JBCLUSTER-140
Project: JBoss Clustering
Issue Type: Sub-task
Security Level: Public (Everyone can see)
Reporter: Brian Stansberry
Assigned To: Brian Stansberry
Fix For: Q3Y6
Is something like DRM needed outside the AS? If it is, do we want to use the JBoss Cache based version (creates JBC dependency.)
DRM is used in two ways:
1) To maintain a distributed registry of remote invocation targets.
2) To maintain a distributed registry of services, which is done by having the service register a meaningless token under its key rather than a target. This is used by HASingleton.
Need to examine whether this kind of thing is needed by Messaging, or whether simple listening for view changes is sufficient. Listening for view changes could be sufficient if each group member knew how to create a Remoting InvokerLocator for the other members based on the JGroups Address. But, this presupposes use of consistent ports across the cluster, and that the IP address used by JGroups is the one that Messaging traffic should 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
13 years, 3 months