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

Logging - set default value for quarkus.log.file.rotation.max-file-size #25072

Merged
merged 1 commit into from
Apr 26, 2022

Conversation

mkouba
Copy link
Contributor

@mkouba mkouba commented Apr 21, 2022

  • also change the default value for
    quarkus.log.file.rotation.max-backup-index

The current behavior is a bit misleading. The docs say that quarkus.log.file.rotation.max-file-size has the default value 10 which is not correct, because no default value is set and so no rotation happens (and the log file is growing and growing..) unless you set the quarkus.log.file.rotation.file-suffix, but then the default value from the org.jboss.logmanager.handlers.PeriodicSizeRotatingFileHandler is taken which is 0xa0000, i.e. approx. 650KB (it's actually a bug, because the comment is clear that it should be 0xa00000). Therefore, we set the default max-file-size to 10M, so the file size is always limited.

We also change the default value for max-backup-index from 1 to 5 which is IMO a more reasonable default.

@mkouba
Copy link
Contributor Author

mkouba commented Apr 21, 2022

CC @dmlloyd

@machi1990
Copy link
Member

This supersedes #24267, correct?
/cc @gsmet

@mkouba
Copy link
Contributor Author

mkouba commented Apr 21, 2022

This supersedes #24267, correct? /cc @gsmet

I didn't know about this one but I think that the change in the LoggingSetupRecorder is needed as well.

@quarkus-bot

This comment has been minimized.

@geoand
Copy link
Contributor

geoand commented Apr 22, 2022

The test failures are related to the change

@mkouba mkouba force-pushed the logging-max-file-size branch from 339ced5 to f462ff0 Compare April 22, 2022 08:01
@mkouba
Copy link
Contributor Author

mkouba commented Apr 22, 2022

The test is fixed.

@geoand geoand added the triage/waiting-for-ci Ready to merge when CI successfully finishes label Apr 22, 2022
@mkouba
Copy link
Contributor Author

mkouba commented Apr 22, 2022

I wonder if we should consider this a breaking change in the sense that we drop the support of org.jboss.logmanager.handlers.FileHandler which just appends messages to a file (i.e. limits are filesystem-specific). Such a handler IMO does not make a lot of sense in practice.

@quarkus-bot

This comment has been minimized.

@mkouba
Copy link
Contributor Author

mkouba commented Apr 22, 2022

@michalszynkiewicz is it (#25072 (comment)) a known flaky test?

@gsmet
Copy link
Member

gsmet commented Apr 22, 2022

Please let me think a bit about it before merging. I’ll have a look on Monday.

@gsmet gsmet removed the triage/waiting-for-ci Ready to merge when CI successfully finishes label Apr 22, 2022
@michalszynkiewicz
Copy link
Member

@michalszynkiewicz is it (#25072 (comment)) a known flaky test?

Not known to me

@gsmet
Copy link
Member

gsmet commented Apr 25, 2022

So my main problem with this is:

  • what happens when you want to set fileSuffix and not rotate on size?
  • in this case, you usually want one log per day and keep 5 days for instance

My guess is that with this patch, it won't work anymore and things will get broken (and you can't even fix it given the value for the file size is not optional anymore).

@mkouba
Copy link
Contributor Author

mkouba commented Apr 25, 2022

So my main problem with this is:

* what happens when you want to set `fileSuffix` and not rotate on size?

* in this case, you usually want one log per day and keep 5 days for instance

My guess is that with this patch, it won't work anymore and things will get broken (and you can't even fix it given the value for the file size is not optional anymore).

In theory, you can set the max-file-size to a value that is not likely to be reached, e.g. 2T. We could switch back to Optional but in that case you'd have to supply the empty config value anyway, i.e. something like quarkus.log.file.rotation.max-file-size=.

However, this would not work even now - see my comment: if you set file-suffix and not the max-file-size then the default value (~ 650KB) is used (note that rotate-on-boot is true by default).

In any case, I think that the current behavior is wrong and the unlimited file handler is not a reasonable default.

CC @gsmet

- also change the default value for
quarkus.log.file.rotation.max-backup-index
@mkouba mkouba force-pushed the logging-max-file-size branch from f462ff0 to 4bd700a Compare April 26, 2022 11:06
@mkouba mkouba added the triage/waiting-for-ci Ready to merge when CI successfully finishes label Apr 26, 2022
@gsmet gsmet merged commit be8e31a into quarkusio:main Apr 26, 2022
@quarkus-bot quarkus-bot bot added this to the 2.9 - main milestone Apr 26, 2022
@quarkus-bot quarkus-bot bot removed the triage/waiting-for-ci Ready to merge when CI successfully finishes label Apr 26, 2022
@dmlloyd
Copy link
Member

dmlloyd commented Apr 27, 2022

I think I have a config type somewhere which is a type-or-enum which would allow a size to be specified or a keyword like "unlimited". I would personally prefer this over special values.

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.

6 participants