Add guard task to ensure log messages are dropped when the process isn't a Quarkus application

[geoand]

Fixes: #14295

This solution really sucks but I couldn't come up with anything better that

1. Had no penalty for a prod run
2. Worked properly for prod, dev and test mode

[geoand]

The JDK 11 test failure is completely unrelated:

Error:    ConnectionPoolsClosedTest.connectionsFromOtherThreadsGetClosed:35 COM01003: Internal error: Assertion failure: Expected boolean value to be false
[INFO] 
Error:  Tests run: 2, Failures: 1, Errors: 0, Skipped: 0

It looks like there is some kind of race condition in the test

[gsmet]

/cc @Sanne for the test failure above ^

[Sanne]

hum thanks yes I can see a possible race. I'll open a different issue:

• ConnectionPoolsClosedTest is racy #14392

If this happens again while I haven't fixed it, feel free to disable the test.

[dmlloyd]

Apologies, but: I think using a timer is a monumentally bad idea. Let's try to find some other approach - even examining the stack trace would be a better idea IMO.

[dmlloyd]

Apologies, but: I think using a timer is a monumentally bad idea. Let's try to find some other approach - even examining the stack trace would be a better idea IMO.

[geoand]

I absolutely agree it's bad :).

If you think the stacktrace approach is better, then I'm all for it. I thought of it myself, but I didn't go through with it because I thought the performance penalty would be high...
Are you sure you want me to go ahead with it?

[dmlloyd]

I absolutely agree it's bad :).

If you think the stacktrace approach is better, then I'm all for it. I thought of it myself, but I didn't go through with it because I thought the performance penalty would be high...
Are you sure you want me to go ahead with it?

I don't think it would be terrible. The main challenge is that the stack is not necessarily predictable; you'd have to do some experimentation to see.

[geoand]

I absolutely agree it's bad :).
If you think the stacktrace approach is better, then I'm all for it. I thought of it myself, but I didn't go through with it because I thought the performance penalty would be high...
Are you sure you want me to go ahead with it?

I don't think it would be terrible. The main challenge is that the stack is not necessarily predictable; you'd have to do some experimentation to see.

OK, I'll check

[geoand]

Another thing about the stack based approach, is that I am not sure that we'll be able to tell a Quarkus application is being run by examining the stack.

I am thinking about the case of tests where maven surefire launches a test jar and our logging is started very very early. In that case I think even when getHandlersOf there is a good chance that Quarkus bootstrapping will not have been started yet.

[geoand]

I also wanted to note that generating an InitialConfigurator won't work because again that class is engaged before Quarkus is even bootstraped in the case of tests

[Sanne]

I've probably missed something, but why do we worry about "non-Quarkus applications" at all?

[geoand]

I've probably missed something, but why do we worry about "non-Quarkus applications" at all?

The problem is that merely the presence of Quarkus on the test classpath, leads to non Quarkus tests causing OOM errors because log messages get queued and never released

[stuartwdouglas]

I don't know if there is any good automatic solution to this. Can't we just tell the user to specify -Djava.util.logging.manager=java.util.logging.LogManager and be done with it?

[geoand]

Yeah... The complexity of an acceptable solution outweighs the usefulness of addressing the issue.