Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Track configuration initialization state for using loggers #44619

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

zakkak
Copy link
Contributor

@zakkak zakkak commented Nov 21, 2024

Tracks configuration initialization state in a boolean to determine if loggers are ready to be used. Useful when we need to log an error due to an early failure.

Closes #42084

This comment has been minimized.

@zakkak
Copy link
Contributor Author

zakkak commented Nov 22, 2024

This seems to result in the process freezing after printing the exception... Converting to draft for now.

@zakkak zakkak marked this pull request as draft November 22, 2024 15:10
@zakkak
Copy link
Contributor Author

zakkak commented Nov 22, 2024

This seems to result in the process freezing after printing the exception... Converting to draft for now.

False alarm, it only freezes if we pass -XX:MissingRegistrationReportingMode=Exit, which is unrelated to this PR.

However, while looking at this I noticed that there is also com.oracle.svm.core.jdk.resources.MissingResourceRegistrationError that we need to catch, but it's not public API.

@zakkak zakkak changed the title Catch MissingReflectionRegistrationErrors during start up Track configuration initialization state for using loggers Nov 22, 2024
@zakkak
Copy link
Contributor Author

zakkak commented Nov 22, 2024

@radcortez how do you find this idea?

@dmlloyd
Copy link
Member

dmlloyd commented Nov 22, 2024

It's been a while since I looked at how the early boot works with native image generation, but are we using the delayed handler in this case?

@zakkak
Copy link
Contributor Author

zakkak commented Nov 22, 2024

It's been a while since I looked at how the early boot works with native image generation, but are we using the delayed handler in this case?

I don't really know, but a quick search led me to

// an exception was thrown before logging was actually setup, we simply dump everything to the console
// we don't do this for dev mode, as on startup failure dev mode sets up its own logging
if (launchMode.getLaunchMode() != LaunchMode.DEVELOPMENT) {
ResultHandle delayedHandler = cb
.readStaticField(
FieldDescriptor.of(InitialConfigurator.class, "DELAYED_HANDLER", QuarkusDelayedHandler.class));
ResultHandle isActivated = cb.invokeVirtualMethod(
ofMethod(QuarkusDelayedHandler.class, "isActivated", boolean.class),
delayedHandler);
BytecodeCreator isActivatedFalse = cb.ifNonZero(isActivated).falseBranch();
ResultHandle handlersArray = isActivatedFalse.newArray(Handler.class, 1);
isActivatedFalse.writeArrayValue(handlersArray, 0,
isActivatedFalse.newInstance(ofConstructor(ConsoleHandler.class)));
isActivatedFalse.invokeVirtualMethod(
ofMethod(QuarkusDelayedHandler.class, "setHandlers", Handler[].class, Handler[].class),
delayedHandler, handlersArray);
isActivatedFalse.breakScope();
}
which indicates that you are right.

@dmlloyd
Copy link
Member

dmlloyd commented Nov 22, 2024

Maybe what we want is a way to dump out the delayed handler queue in the event of error. I know we're able to do that at run time at least, so it should be possible to do so at build time as well?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Quarkus exits without showing thrown exception when using -H:ThrowMissingRegistrationErrors=
2 participants