Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cleanup Permament TCP Connection #125

Open
tbocek opened this issue Jan 25, 2016 · 0 comments
Open

Cleanup Permament TCP Connection #125

tbocek opened this issue Jan 25, 2016 · 0 comments

Comments

@tbocek
Copy link
Member

tbocek commented Jan 25, 2016

On Further Investigation, we found that in Reservation class,
WaitReservationPermanent method, all threads are waiting at
semaphorePermanentTCP.acquire(permitsPermanentTCP);

The size of the queue private final BlockingQueue queue = new
LinkedBlockingQueue(); have reached to 4000 around.

This seems that release on the semaphore is never called. The permanent
TCP does not release the permits when the channel is closed.

However, the peer is able to receive the requests and even reply to them.

Relay uses the permanent connection, is it something to do with them. We
are using multiple manual relays and connect with them ?

You need to try to close the PeerConnection manually.

Any idea why request are not getting timed out and semaphore are not
releasing?

Most likely, closing the TCP connection does not release the semaphore.
I just created a testcase in TestConnection

Attaching the threaddump, if that can help. From my understanding thread
tagged with name "pool-2-thread-1" is the culprit and deadlocked.

When you create the permanent connection, you need to add something like
this:

peerConnection.closeFuture().addListener(new
BaseFutureAdapter<FutureDone>() {
@OverRide
public void operationComplete(FutureDone future) throws Exception {
peerConnection.close();
}
});

I remember that I thought about releasing automatically the semaphore,
but decided against it. The idea of a PeerConnection is that it should
not matter if it is currently connected to a TCP channel or not. If it
is connect, then PeerConnection should use this connection, if not, then
PeerConnection creates a new connection. If you don't need the
connection anymore, then you call close, and the semaphore is released.

However, this is error prone, and I'll need to change this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant