Yeah, I'm working through some of it where I have time. I plan to have a Jira up this weekend. I'm wondering, though, if we shouldn't consider a spike for switching to log4j2 in 2.X because I saw a lot of complaints about logback being inconsistent in honoring its settings.
On Fri, Jul 7, 2023 at 10:19 PM Joe Witt <[email protected]> wrote: > Hmmmm. Interesting. Can you capture these bits of fun in a jira? > > Thanks > > On Fri, Jul 7, 2023 at 7:17 PM Mike Thomsen <[email protected]> > wrote: > >> After doing some research, it appears that <maxFileSize/> is a wonky >> setting WRT how well it's honored by logback. I let a GenerateFlowFile > >> LogAttribute flow run for a long time, and it just kept filling up. When I >> added <totalSizeCap/> that appeared to force expected behavior on total log >> size. We might want to add the following: >> >> <cleanHistoryOnStart>true</cleanHistoryOnStart> >> <totalSizeCap>50GB</totalSizeCap> >> >> On Fri, Jul 7, 2023 at 11:33 AM Michael Moser <[email protected]> wrote: >> >>> Hi Mike, >>> >>> You aren't alone in experiencing this. I think logback uses a pattern >>> matcher on filename to discover files to delete. If "something" happens >>> which causes a gap in the date pattern, then the matcher will then fail to >>> pick up and delete files on the other side of that gap. >>> >>> Regards, >>> -- Mike M >>> >>> >>> On Thu, Jul 6, 2023 at 10:28 AM Mike Thomsen <[email protected]> >>> wrote: >>> >>>> We are using the stock configuration, and have noticed that we have a >>>> lot of nifi-app* logs that are well beyond the historic data cap of 30 days >>>> in logback.xml; some of those logs go back to April. We also have a bunch >>>> of 0 byte nifi-user logs and some of the other logs are 0 bytes as well. It >>>> looks like logback is rotating based on time, but isn't cleaning up. Is >>>> this expected behavior or a problem with the configuration? >>>> >>>> Thanks, >>>> >>>> Mike >>>> >>>
