Skip to content

Closing client when Proxyconnection is disconnected - #1821

Merged
sijie merged 4 commits into
apache:masterfrom
jai1:closeConnection_oss
Jun 22, 2018
Merged

Closing client when Proxyconnection is disconnected#1821
sijie merged 4 commits into
apache:masterfrom
jai1:closeConnection_oss

Conversation

@jai1

@jai1 jai1 commented May 21, 2018

Copy link
Copy Markdown
Contributor

Currently, client.close() is not called when ProxyConnection becomes inactive which leads to leaking unused connections.

Since the ConnectionPool used in proxy uses the same event worker group as the Proxy service we can't close the event workgroup when we close the client, hence overriding the close() function in ProxyConnectionPool to just close the connections and not the event worker group.

@jai1 jai1 added this to the 2.1.0-incubating milestone May 21, 2018
@jai1 jai1 self-assigned this May 21, 2018

@sijie sijie left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

a simple unit test might be great.

@@ -0,0 +1,40 @@
package org.apache.pulsar.proxy.server;

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is no license header.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch - I will fix it

@massakam

Copy link
Copy Markdown
Contributor


if (client != null) {
client.close();
}

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand why we want to close the entire client at this point.

When this connection gets closed, we want its paired connection to be closed as well. This should already done at line 140 here above.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The client connection Pool is used by lookupProxyHandler and not the directProxyHandler.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But the client is shared across all the ProxyConnection instances

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We changed the logic to have one client per ProxyConnection
#1707

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Uhm, that doesn't sound a good option to me

@jai1

jai1 commented May 23, 2018

Copy link
Copy Markdown
Contributor Author

retest this please

2 similar comments
@jai1

jai1 commented Jun 1, 2018

Copy link
Copy Markdown
Contributor Author

retest this please

@jai1

jai1 commented Jun 1, 2018

Copy link
Copy Markdown
Contributor Author

retest this please

@merlimat

merlimat commented Jun 1, 2018

Copy link
Copy Markdown
Contributor

@jai1 there are many resources that are created per-client, I don't think it's a working approach to have 1 client instance per proxy connection.

@jai1

jai1 commented Jun 1, 2018

Copy link
Copy Markdown
Contributor Author

I understand the resource aspect of it and agree that instead of having one client we can extract the connectionPool part out of the client and use one connection pool per proxy connection

But we still need one connection pool per proxy connection since the broker authenticates the client and the proxy if forwardAuthorizationCredentials is set to true and then the connection remains open throughout the lifetime of the proxy connection.

So if Client A and Client B connect to Proxy we need one connection pool for A (since its A's credentials are authorized during handleConnect) and one connection pool for B.

If we are in agreement let me know and I will start the work of having one connection pool instead of one client per proxy connection.

@merlimat

merlimat commented Jun 1, 2018

Copy link
Copy Markdown
Contributor

But we still need one connection pool per proxy connection since the broker authenticates the client and the proxy if forwardAuthorizationCredentials is set to true and then the connection remains open throughout the lifetime of the proxy connection.

I think the term "connection pool" is actually misleading. Proxy uses a 1-1 connections matching between (client -> proxy) and (proxy -> broker). No pooling is required, but rather just opening new connection each time.

@jai1

jai1 commented Jun 1, 2018

Copy link
Copy Markdown
Contributor Author

Ohk - now I understand the confusion

The connection pool is used for lookups and getPartitionMetaData only once the broker discovery is done we use the 1 to 1 connection as you said.

@sijie

sijie commented Jun 18, 2018

Copy link
Copy Markdown
Member

@jai1 @merlimat what is the conclusion here? are we going to include this for 2.1?

@jai1

jai1 commented Jun 18, 2018

Copy link
Copy Markdown
Contributor Author

If this is blocking the release then we can defer it to the next one, else I will fix the tests and rebase the PR by Wednesday

@sijie

sijie commented Jun 18, 2018

Copy link
Copy Markdown
Member

@jai1 great! Wednesday is good.

@jai1

jai1 commented Jun 21, 2018

Copy link
Copy Markdown
Contributor Author

@sijie - Can you review this PR so that we can merge it

@sijie

sijie commented Jun 21, 2018

Copy link
Copy Markdown
Member

@jai1 still looks good to me.

@merlimat can you review this? since you have some comments there.

@merlimat

Copy link
Copy Markdown
Contributor

We can merge this now, though we should try to revisit the changes in #1707 for 2.2

@merlimat merlimat left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

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

Successfully merging this pull request may close these issues.

4 participants