FISH-642 Workaround fix for OpenMQ blowing away logging on cluster instances. #5043
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Workaround fix for OpenMQ blowing away logging on cluster instances.
lprimak
approved these changes
Dec 10, 2020
|
jenkins test |
|
I've made an alternative fix for this (see link above). |
|
jenkins test please |
|
Closing to not hide focus from better fix. I shan't delete the branch though just in case |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
This is a part-fix / workaround.
Application logging breaks for clustered instances (as in Shoal/GMS clustered instances) due to OpenMQ blowing away logging configuration.
The cause of OpenMQ blowing it away is due to it running into an exception when starting the clustered broker, specifically that a loopback address is being used. Rather than exiting out at this point however, OpenMQ attempts to fallover to a non-clustered broker. This logic is currently flawed however due to the fact that the Broker which is being started gets "exited" before continuing to start using a non-clustered mbus - the broker doesn't exit due to being started in-process, and attempts to carry on despite having all configuration nulled, unsurprisingly running into NPEs (which you don't see because a side-effect of nulling the configuration is that it also blows away the logging configuration).
It should be pointed out that this flaw in OpenMQ exists regardless of this workaround / part-fix - the OpenMQ broker won't start regardless, but with this change you at least get told it hasn't started. This change doesn't cause OpenMQ to print quite the same exception that it would normally however (if it could actually print the exception). It still gets the same NPEs caused by throwing away all configuration, but in a slightly different place, causing it to not get wrapped in a nicer "Illegal Loopback Address Used" message.
Important Info
Blockers
payara/Payara_PatchedProjects#349
Testing
New tests
None
Testing Performed
Started cluster instances on Windows and Linux and deployed test application, hitting endpoint http://localhost:28080/ticket1567-logging/hello and checking logs to see if messages are printed out.
As noted above, clustered instances on Linux with a "default" networking setup will get errors related to OpenMQ not starting.
Documentation
None