Have a trace option of do not display return code 0 entries

[colinpaicemq]

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like
A clear and concise description of what you want to happen.

If I turn on ZSS trace I get lots of entries like

BPXCLO for failed connect returnValue 0 returnCode 0 reasonCode 0
BPXSEL (extended) maxSoc=0x400 returnValue 0x0 returnCode 0x0 reasonCode 0x0

It would be good to have an option eg -1 which says do not report rc=0 rs=0 , but only those which had an error/problem

My trace file has thousands of entries - and it hasn't finished starting.

I've got lots of
JWK request to https://10.1.1.2:7554/gateway/api/v1/auth/keys/public/current

It would be nice if it produced this messages once( unless it can change)

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Willingness to help
If you are willing to help with feedback on the implementation or with the actual implementation,
please state your willingness to assist in the created issue. We will take it into account when figuring what to work on.

Additional context
Add any other context or screenshots about the feature request here.

[balhar-jakub]

@JoeNemo @Martin-Zeithaml Can you please transfer this issue to the zss repository as this is request to change logging in there?

[JoeNemo]

I am not sure that turning off info messages when tracing is turned on is a desirable behavior. If there are some that are truly flooding the log with duplicates (thousands per second/minute/whatever) that should be a bug, but when tracing, it's supposed to be verbose so problems can be diagnosed at customer sites.

[colinpaicemq]

I had trace turned on, and was running a reasonable workload for an hour or two. When the problem occurred, there was a lot of data to go through, an I could not find the problem. I also think that the trace did not have a time stamp, so it made it double hard to find which entry was important amongst the thousands of "OK" trace entries.

If this was a config option eg -1 then this is up to the user to decide to do it. I havent measured the cost of running with trace, but running with trace on for a day to capture one problem would be very expensive- and may cause the whole system to slow down.
You could have -4 for return code 8 or higher, and -8 for return code 8 or higher