You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I searched in the issues and found nothing similar.
Motivation
Pulsar-shell would attempt to load the NAR files every time a new custom/extention command is invoked (see PIP-201 for context regarding Pulsar Admin CLI Extensions).
This works fine with caveats:
Multiple NAR loading seems redundant. It is fair to expect the user to restart the shell session if the underlying NAR is updated.
It has some interesting consequences when the the extensions command has a runtime dependency on a class that is available on the parent class loader.
For example, I ran into a scenario where the extension/custom command has a dependency on netty-common - the command would load on the NAR class loader, but the netty dependency will load on the parent class loader (the admin's AppClassLoader). Between shell commands invocations, the classes in the NAR class loader are recycled, but the netty classes are not. This lead to any "static" state to appear as "leaking" when the CLI is invoked for the second time.
Solution
Implementing "singleton" custom command bootstrapping (the NAR class loader and other necessary initialization) would do, at least in theory.
Alternatives
Switch the order by which class loader work (child then parent) although this seems unnecessarily complex.
Anything else?
No response
Are you willing to submit a PR?
I'm willing to submit a PR!
The text was updated successfully, but these errors were encountered:
aymkhalil
added
the
type/enhancement
The enhancements for the existing features or docs. e.g. reduce memory usage of the delayed messages
label
Apr 10, 2023
Search before asking
Motivation
Pulsar-shell would attempt to load the NAR files every time a new custom/extention command is invoked (see PIP-201 for context regarding Pulsar Admin CLI Extensions).
This works fine with caveats:
For example, I ran into a scenario where the extension/custom command has a dependency on
netty-common
- the command would load on the NAR class loader, but the netty dependency will load on the parent class loader (the admin's AppClassLoader). Between shell commands invocations, the classes in the NAR class loader are recycled, but the netty classes are not. This lead to any "static" state to appear as "leaking" when the CLI is invoked for the second time.Solution
Implementing "singleton" custom command bootstrapping (the NAR class loader and other necessary initialization) would do, at least in theory.
Alternatives
Switch the order by which class loader work (child then parent) although this seems unnecessarily complex.
Anything else?
No response
Are you willing to submit a PR?
The text was updated successfully, but these errors were encountered: