Bug 981544 - PeriodicRotatingFileHandler does not roll the File on 12AM but 12PM
PeriodicRotatingFileHandler does not roll the File on 12AM but 12PM
Status: CLOSED CURRENTRELEASE
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Logging (Show other bugs)
6.1.0
Unspecified Unspecified
unspecified Severity high
: ER7
: EAP 6.1.1
Assigned To: James Perkins
:
Depends On:
Blocks: 975555 987125 1067555
  Show dependency treegraph
 
Reported: 2013-07-05 02:26 EDT by Takayoshi Kimura
Modified: 2014-02-20 11:11 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
A bug was found in previous versions of Red Hat JBoss Enterprise Application Platform 6 that caused the LogManager to not rotate the log file the day after a restart. The bug presented if the server was restarted in the 'PM' hour range. It was caused by the LogManager not correctly handling half-day periods. This bug has been resolved with an update to the LogManager version.
Story Points: ---
Clone Of:
: 1067555 (view as bug list)
Environment:
Last Closed: 2013-09-16 16:24:41 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
JBoss Issue Tracker LOGMGR-68 Major Resolved periodic-rotating-file-handler not rotating 2018-03-08 23:54 EST

  None (edit)
Comment 1 Takayoshi Kimura 2013-07-05 02:30:08 EDT
If the base time (boot time) is pm, the next rolling time will be set to 12pm because it doesn't clear AM_PM before setting 0 to HOUR.
Comment 2 Kyle Lape 2013-07-05 14:03:02 EDT
I actually asked James about this issue a couple of days ago.  I developed a patch similar to Takayoshi's:

index 406ff7d..28deb97 100644
--- a/src/main/java/org/jboss/logmanager/handlers/PeriodicRotatingFileHandler.java
+++ b/src/main/java/org/jboss/logmanager/handlers/PeriodicRotatingFileHandler.java
@@ -214,6 +214,7 @@ public class PeriodicRotatingFileHandler extends FileHandler {
                 calendar.clear(Calendar.DAY_OF_WEEK_IN_MONTH);
             case DAY:
                 calendar.set(Calendar.HOUR_OF_DAY, 0);
+                calendar.set(Calendar.AM_PM, 0);
             case HALF_DAY:
                 calendar.set(Calendar.HOUR, 0);
             case HOUR:

And James's response:

I started looking at this briefly, but didn't dig into it yet. I was trying to get a test case to break it, but I haven't yet. I'll have a look soon at that though. It could be as simple as that for sure. In fact, my gut is telling me that's exactly what it is.
Comment 3 JBoss JIRA Server 2013-07-05 18:41:06 EDT
Paul V <pvs.1.email@gmail.com> made a comment on jira LOGMGR-68

This will not fix the problem. The set methods of Calendar do not recalculate its time. My previous comment has a fix for this problem.

From the java doc for Calendar

Getting and Setting Calendar Field Values

The calendar field values can be set by calling the set methods. Any field values set in a Calendar will not be interpreted until it needs to calculate its time value (milliseconds from the Epoch) or values of the calendar fields. Calling the get, getTimeInMillis, getTime, add and roll involves such calculation.
Comment 4 JBoss JIRA Server 2013-07-06 00:14:43 EDT
Takayoshi Kimura <tkimura@redhat.com> made a comment on jira LOGMGR-68

Thanks Paul, you're right. HOUR should not be set other than the HALF_DAY case. Updated the pull req.

Also I'm wondering if we can change the calcNextRollover method to protected or package private for unit testing.
Comment 5 JBoss JIRA Server 2013-07-09 18:53:01 EDT
Kyle Lape <kyle.lape@redhat.com> made a comment on jira LOGMGR-68

I've talked with [~jamezp] about this case, and we worked through this issue.  He suggested a fix that included pieces from both proposed solutions.  I had also created some more tests and fixed another issue regarding the {{WEEK}} period.  I submitted a new PR: https://github.com/jboss-logging/jboss-logmanager/pull/32
Comment 6 JBoss JIRA Server 2013-07-10 10:28:40 EDT
Bertrand Donnet <bertrand.donnet@gmail.com> made a comment on jira LOGMGR-68

We also noticed this problem when migrating from JBoss EAP 6.0.1 to 6.1.0, which means LogManager from 1.3.2 to 1.4.0

Thanks for the feedback and we will wait for the fix.
Comment 8 JBoss JIRA Server 2013-07-22 12:49:56 EDT
James Perkins <jperkins@redhat.com> made a comment on jira LOGMGR-68

Pull request merged
Comment 9 Kyle Lape 2013-07-22 14:11:47 EDT
Setting the EAP 6.1.1 flag since this has already been committed for the logmanager release for 6.1.1.
Comment 10 Petr Kremensky 2013-08-26 09:42:41 EDT
This was fixed with new version of log manager (BZ975555). PeriodicRotatingFileHandler now roll the File on 12AM even if its base time (boot time) is pm. 

Verified with EAP 6.1.1 ER7
Comment 11 Scott Mumford 2013-08-30 01:24:41 EDT
Added a draft release note.

Setting NEEDINFO flag to request technical verification from assignee, however, at this late stage, a verification from anyone involved in the resolution of this issue will be sufficient.

If the note above is inaccurate, please reset the 'requires_doc_text' flag to '?' and leave comment with corrections.
Comment 12 James Perkins 2013-08-30 11:37:00 EDT
I think that doc text is fine. I didn't work on the problem, but from my understanding you've explained it well.

Note You need to log in before you can comment on or make changes to this bug.