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.
I had a couple of problems in my code where I pulled up a couple of connections/clients and randomly it happened that in the loop an exception occurred. When it happens the exception always starts like this before the stacktrace:
... which gives not too much info where the exception happened, as the stack trace ends always at
loop_forever
and the interesting part would most of the time be who actually started the thread that caused the exception.The change gives control over how the thread that is created by
loop_start
is named. To not change any API at all I opted for the decoded client id. If not explicitly set, there will be the usual "broker-generated string" as name, but for me that does not give any less information than the mentioned aboveThread-$some_number
. But if you explicitly set theclient_id
(which needs to be unique, so no name clashes possible as far as I can see) the thread will reflect that change, so in the exception it would print: