Warn against usage of plugin-provided classes in Hazelcast #74
Comments
|
igniterealtime/openfire-monitoring-plugin#156 (comment) suggests that a similar issue exists with executable tasks. Lets put in place a similar warning for those. |
guusdk
changed the title
guusdk
added a commit
to guusdk/openfire-hazelcast-plugin
that referenced
this issue
Nov 17, 2021
…ses in clustered caches/tasks When an instance of a class that is loaded by a PluginClassLoader is used in a Cache or Task, reloading the plugin (and thus replacing the PluginClassLoader) can cause ClassCastExceptions. This commit detects this usage, and logs warnings. A throttle has been applied to the amount of duplicate warnings logged, to prevent the logs from being flooded with the same message.
guusdk
added a commit
to guusdk/openfire-hazelcast-plugin
that referenced
this issue
Dec 7, 2021
When a clustered tasks is executed (particularly when that task returns a value), class loading issues can occur when the task is defined in a plugin. The classes that are used by the task might not be accessible by the (context class loader of the) thread that executes the task. When a task is executed that is defined in a plugin, the context class loader of the thread should be switched to the plugin class loader during the execution of the task to work around this issue. Be aware of igniterealtime#74: Using Tasks defined in a plugin causes issues (particularly when reloading that plugin). That problem remains, even with the improvement suggested here. fixes igniterealtime#79
This was referenced Dec 7, 2021
guusdk
added a commit
to guusdk/openfire-hazelcast-plugin
that referenced
this issue
Nov 5, 2024
When a clustered tasks is executed (particularly when that task returns a value), class loading issues can occur when the task is defined in a plugin. The classes that are used by the task might not be accessible by the (context class loader of the) thread that executes the task. When a task is executed that is defined in a plugin, the context class loader of the thread should be switched to the plugin class loader during the execution of the task to work around this issue. Be aware of igniterealtime#74: Using Tasks defined in a plugin causes issues (particularly when reloading that plugin). That problem remains, even with the improvement suggested here. fixes igniterealtime#79
guusdk
added a commit
that referenced
this issue
Nov 5, 2024
When a clustered tasks is executed (particularly when that task returns a value), class loading issues can occur when the task is defined in a plugin. The classes that are used by the task might not be accessible by the (context class loader of the) thread that executes the task. When a task is executed that is defined in a plugin, the context class loader of the thread should be switched to the plugin class loader during the execution of the task to work around this issue. Be aware of #74: Using Tasks defined in a plugin causes issues (particularly when reloading that plugin). That problem remains, even with the improvement suggested here. fixes #79
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
See igniterealtime/openfire-monitoring-plugin#155 This links eventually to guusdk/openfire-pushnotification-plugin@48b408c
Caching custom instances has ClassLoader problems when reloading plugins in a cluster.
Raise a warning every time we see (the first?) instance of a class loaded by a PluginClassLoader being added to a cache.
Ideally, if there's a reflection or something we can go at boot time, that'd be better.
If there's something we can add as a deprecation, or a plugin compile-time warning, better still.
(Separate tickets required to fix this in our plugins)
This issue was previously known as https://igniterealtime.atlassian.net/browse/OF-2238
The text was updated successfully, but these errors were encountered: