Create a new log file only if the default one is open
Dear list, I’d like to set up logback so that it always records the log to the file out.log, except when a process is already busy writing to out.log when my program start. (I expect such a process will simply be another instance of my program; when multiple instances run in parallel, I want to have multiple log files, one per instance.) I know that logback can be asked to create uniquely named files ( http://logback.qos.ch/manual/appenders.html#uniquelyNamed), but I do not want that: most of the time, only one instance of my program is running, in which case, it is fine to replace the log file, using the default name (out.log), instead of creating a new one at each run. I’d like to deviate from the default name only when the default one is busy. It is possible to detect (at least under Linux, but, I suppose, in other OSes as well) that a process has a file open, so this seems feasible, at least in principle; and it seems like a natural requirement for programs designed to allow parallel instances. I am surprised I didn’t see anything related to this in the logback manual. Is there a reason not to want what I want? I realize that a race condition could happen, in principle: if someone creates a second instance of my program immediately after the first one, the second one could decide to use out.log because that file is not yet open by the first one, ending up with both processes logging to the same file. I am ready to live with that risk. This question was also asked on SO ( https://stackoverflow.com/q/64184299), to no avail. -- Olivier
Guten Tag Olivier Cailloux, am Samstag, 10. Oktober 2020 um 15:57 schrieben Sie:
It is possible to detect (at least under Linux, but, I suppose, in other OSes as well) that a process has a file open, so this seems feasible, at least in principle; and it seems like a natural requirement for programs designed to allow parallel instances. I am surprised I didn’t see anything related to this in the logback manual. Is there a reason not to want what I want?
Many users most likely simply prefer to have one known schema of log file names, like a static name in your case, the current month and year etc. Many apps supporting concurrency in general, which is not only multiple processes, but threads as well, use Nested Diagnostic Context instead to provide IDs/names of processes or threads WITHIN one and the same log file. Many tools processing those log files are prepared to support that and allow e.g. filtering based on that additional data. Sometimes it's even necessary to log that way to see e.g. when multiple instances block each other using their log timestmap or something like that. So while you should be able to implement an appender doing what you like yourself, from my experience most people simply prefer to do it differently and therefore there might simply be no built-in solution available yet. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail: Thorsten.Schoening@AM-SoFT.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...........05151- 9468- 55 Fax...............05151- 9468- 88 Mobil..............0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Le samedi 10 octobre 2020 à 17:47 +0200, Thorsten Schöning a écrit :
Guten Tag Olivier Cailloux, am Samstag, 10. Oktober 2020 um 15:57 schrieben Sie:
It is possible to detect (at least under Linux, but, I suppose, in other OSes as well) that a process has a file open, so this seems feasible, at least in principle; and it seems like a natural requirement for programs designed to allow parallel instances. I am surprised I didn’t see anything related to this in the logback manual. Is there a reason not to want what I want?
Many users most likely simply prefer to have one known schema of log file names, like a static name in your case, the current month and year etc. Many apps supporting concurrency in general, which is not only multiple processes, but threads as well, use Nested Diagnostic Context instead to provide IDs/names of processes or threads WITHIN one and the same log file. Many tools processing those log files are prepared to support that and allow e.g. filtering based on that additional data. Sometimes it's even necessary to log that way to see e.g. when multiple instances block each other using their log timestmap or something like that.
So while you should be able to implement an appender doing what you like yourself, from my experience most people simply prefer to do it differently and therefore there might simply be no built-in solution available yet.
Thanks for the reference to MDC, which I had overlooked. So all my instances could log to the same file, each with a different context, which indeed permits to retrieve from the log file the subset of logging statements relevant to a given instance. Fine. One remaining problem I see with this setup is that I then need to enable “prudent” mode, as multiple instances will log to the same file (http://logback.qos.ch/manual/appenders.html#prudent). This may have a non-negligible impact on performance, which does not happen with the solution I was initially considering. Also, except by programming a custom solution, this prudent mode need to be always enabled, including in the cases where only one instance logs to the file, thereby tripling the cost of logging, for nothing. As I understand it, MDC is rather appropriate for multi-threaded applications running all with the same FileAppender instance, which therefore does not need to use prudent mode, and for which it might be important, as you observe, to know the order of logging statements coming from the multiple threads. It seems less appropriate for my case of single-threaded, multiple instances of the same application. Please, anyone, correct me if I am wrong. Not that tripling the cost of logging (which is initially very small) matters much in my specific case, but I am still surprised that a better solution (similar, for example, to the one I proposed) is not supported “out of the box” and mentioned in the manual. I am considering posting a feature request about this to https://jira.qos.ch/projects/LOGBACK/, please anyone tell me if this is a bad idea.
Mit freundlichen Grüßen,
Thorsten Schöning
Thank you for your reply. -- Olivier
participants (2)
-
Olivier Cailloux -
Thorsten Schöning