Skip to content

Fix Pulsar Proxy to re-use authentication instance - #12245

Merged
eolivelli merged 3 commits into
apache:masterfrom
streamnative:proxy_reuse_auth
Oct 7, 2021
Merged

Fix Pulsar Proxy to re-use authentication instance#12245
eolivelli merged 3 commits into
apache:masterfrom
streamnative:proxy_reuse_auth

Conversation

@addisonj

Copy link
Copy Markdown
Contributor

Currently, the Pulsar Proxy creates a new PulsarClientImpl with a new
instance of the client authentication plugin.

For certain client auth implementations, this can cause issues. For
example, if a client plugin needs to generate a token and then cache and
re-use it (which is very common with typical Pulsar client usage) this
pattern breaks, because the client auth plugin is tied to the
lifecycle of the connection and not the more "singleton" usage of the
Pulsar client.

Arguably, we should instead figure out how to re-use the entire Pulsar
client, but that likely has more complexity, instead this "quick fix"
will get one of the most obvious cases solved.

@addisonj
addisonj requested a review from merlimat September 30, 2021 01:52
@merlimat merlimat added this to the 2.9.0 milestone Sep 30, 2021
@merlimat merlimat added type/enhancement The enhancements for the existing features or docs. e.g. reduce memory usage of the delayed messages release/2.8.2 labels Sep 30, 2021

@eolivelli eolivelli 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.

very well
can you add a unit test ?

@Anonymitaet

Copy link
Copy Markdown
Member

Thanks for your contribution. For this PR, do we need to update docs?

(The PR template contains info about doc, which helps others know more about the changes. Can you provide doc-related info in this and future PR descriptions? Thanks)

@eolivelli eolivelli modified the milestones: 2.9.0, 2.10.0 Oct 6, 2021
Currently, the Pulsar Proxy creates a new PulsarClientImpl with a new
instance of the client authentication plugin.

For certain client auth implementations, this can cause issues. For
example, if a client plugin needs to generate a token and then cache and
re-use it (which is very common with typical Pulsar client usage) this
pattern breaks, because the client auth plugin is tied to the
lifecycle of the connection and not the more "singleton" usage of the
Pulsar client.

Arguably, we should instead figure out how to re-use the entire Pulsar
client, but that likely has more complexity, instead this "quick fix"
will get one of the most obvious cases solved.
It isn't clear why this test was doing timeouts... it doesn't really
seem to be testing anything as the auth token was not being refreshed
and it appears the test was expected to pass (it almost looks like they
were expected to fail?)

This allows us to make this test faster and more reliable, as the
timeouts don't really seem to be adding anything
@addisonj
addisonj requested a review from eolivelli October 7, 2021 06:06
@addisonj

addisonj commented Oct 7, 2021

Copy link
Copy Markdown
Contributor Author

Test has been added (via re-using existing test which wasn't very logical)

@addisonj

addisonj commented Oct 7, 2021

Copy link
Copy Markdown
Contributor Author

/pulsarbot run-failure-checks

@eolivelli
eolivelli merged commit 6b93a16 into apache:master Oct 7, 2021
@codelipenghui
codelipenghui deleted the proxy_reuse_auth branch October 8, 2021 00:37
eolivelli pushed a commit that referenced this pull request Oct 8, 2021
* Fix Pulsar Proxy to re-use authentication instance

Currently, the Pulsar Proxy creates a new PulsarClientImpl with a new
instance of the client authentication plugin.

For certain client auth implementations, this can cause issues. For
example, if a client plugin needs to generate a token and then cache and
re-use it (which is very common with typical Pulsar client usage) this
pattern breaks, because the client auth plugin is tied to the
lifecycle of the connection and not the more "singleton" usage of the
Pulsar client.

Arguably, we should instead figure out how to re-use the entire Pulsar
client, but that likely has more complexity, instead this "quick fix"
will get one of the most obvious cases solved.

* add test for ensuring all same auth instance

* Simplify ProxyAuthTest

It isn't clear why this test was doing timeouts... it doesn't really
seem to be testing anything as the auth token was not being refreshed
and it appears the test was expected to pass (it almost looks like they
were expected to fail?)

This allows us to make this test faster and more reliable, as the
timeouts don't really seem to be adding anything
@codelipenghui codelipenghui added the cherry-picked/branch-2.8 Archived: 2.8 is end of life label Oct 11, 2021
codelipenghui pushed a commit that referenced this pull request Oct 11, 2021
* Fix Pulsar Proxy to re-use authentication instance

Currently, the Pulsar Proxy creates a new PulsarClientImpl with a new
instance of the client authentication plugin.

For certain client auth implementations, this can cause issues. For
example, if a client plugin needs to generate a token and then cache and
re-use it (which is very common with typical Pulsar client usage) this
pattern breaks, because the client auth plugin is tied to the
lifecycle of the connection and not the more "singleton" usage of the
Pulsar client.

Arguably, we should instead figure out how to re-use the entire Pulsar
client, but that likely has more complexity, instead this "quick fix"
will get one of the most obvious cases solved.

* add test for ensuring all same auth instance

* Simplify ProxyAuthTest

It isn't clear why this test was doing timeouts... it doesn't really
seem to be testing anything as the auth token was not being refreshed
and it appears the test was expected to pass (it almost looks like they
were expected to fail?)

This allows us to make this test faster and more reliable, as the
timeouts don't really seem to be adding anything

(cherry picked from commit 6b93a16)
nicoloboschi pushed a commit to datastax/pulsar that referenced this pull request Oct 27, 2021
* Fix Pulsar Proxy to re-use authentication instance

Currently, the Pulsar Proxy creates a new PulsarClientImpl with a new
instance of the client authentication plugin.

For certain client auth implementations, this can cause issues. For
example, if a client plugin needs to generate a token and then cache and
re-use it (which is very common with typical Pulsar client usage) this
pattern breaks, because the client auth plugin is tied to the
lifecycle of the connection and not the more "singleton" usage of the
Pulsar client.

Arguably, we should instead figure out how to re-use the entire Pulsar
client, but that likely has more complexity, instead this "quick fix"
will get one of the most obvious cases solved.

* add test for ensuring all same auth instance

* Simplify ProxyAuthTest

It isn't clear why this test was doing timeouts... it doesn't really
seem to be testing anything as the auth token was not being refreshed
and it appears the test was expected to pass (it almost looks like they
were expected to fail?)

This allows us to make this test faster and more reliable, as the
timeouts don't really seem to be adding anything

(cherry picked from commit 6b93a16)
(cherry picked from commit ef27532)
bharanic-dev pushed a commit to bharanic-dev/pulsar that referenced this pull request Mar 18, 2022
* Fix Pulsar Proxy to re-use authentication instance

Currently, the Pulsar Proxy creates a new PulsarClientImpl with a new
instance of the client authentication plugin.

For certain client auth implementations, this can cause issues. For
example, if a client plugin needs to generate a token and then cache and
re-use it (which is very common with typical Pulsar client usage) this
pattern breaks, because the client auth plugin is tied to the
lifecycle of the connection and not the more "singleton" usage of the
Pulsar client.

Arguably, we should instead figure out how to re-use the entire Pulsar
client, but that likely has more complexity, instead this "quick fix"
will get one of the most obvious cases solved.

* add test for ensuring all same auth instance

* Simplify ProxyAuthTest

It isn't clear why this test was doing timeouts... it doesn't really
seem to be testing anything as the auth token was not being refreshed
and it appears the test was expected to pass (it almost looks like they
were expected to fail?)

This allows us to make this test faster and more reliable, as the
timeouts don't really seem to be adding anything
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

cherry-picked/branch-2.8 Archived: 2.8 is end of life release/2.8.2 type/enhancement The enhancements for the existing features or docs. e.g. reduce memory usage of the delayed messages

Projects

None yet

Development

Successfully merging this pull request may close these issues.

9 participants