[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[Pki-devel] [pki-devel][PATCH] 0031-Ticket-572-CRL-scheduler-adds-extra-CRL-generation-a.patch



Patch addresses the issue with least amount of change, isolated to the specific problem case.

The case is when we have a daily schedule that spans only one day. When the last member of the 
daily schedule fires, the system thinks the next update should be at midnight the following morning
instead of the first entry of the schedule for the next day.

From c9f38196352a8fa2611e87bc38dccac16a83a1a8 Mon Sep 17 00:00:00 2001
From: Jack Magne <jmagne localhost localdomain>
Date: Tue, 5 May 2015 14:19:58 -0700
Subject: [PATCH] Ticket #572 - CRL scheduler adds extra CRL generation at
 midnight for daily schedules.

Addresses the complaint of this ticket. Tested to work in a few basic cases. The minor code change
was designed to only affect the specific scenario when we have a daily scedule that spans only one day.

More Info:

How to duplicate and test:

    Perform a manual crl generate from the agent interface because the code to be tested relies heavily upon the "lastUpdate" which will appear in the logs. Do this to have a nice launching off point.

    Go to the ca's pkiconsole and select : Certificate Manager -> CRL Issuing Points -> MasterCRL.
    Check "updateCRL at: " and give a schedule such as : 15:03, 15:10 .. This gives us a chance to watch the two regularly scheduled updates happen.

    When the first event triggers, have a look at the CA's "debug" log and note the following or similar entry:

[CRLIssuingPoint-MasterCRL]: findNextUpdate: Wed May 06 15:10:00 PDT 2015 delay: 86301873

    Wait for the 15:00 even to happen. When that triggers at the end of that cycle, we should see one more similar entry.

[CRLIssuingPoint-MasterCRL]: findNextUpdate: Wed May 06 15:03 PDT 2015 delay: 86301873

That is the correct behavior after the fix. We want the next update to be at the first entry of the daily schedule , but tomorrow. The current bug would print out this value as something like:

    Wed May 06 00:00:00 or similar to indicate midnight. This is not what we want.
---
 base/ca/src/com/netscape/ca/CRLIssuingPoint.java | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/base/ca/src/com/netscape/ca/CRLIssuingPoint.java b/base/ca/src/com/netscape/ca/CRLIssuingPoint.java
index 2700bef..fe230e9 100644
--- a/base/ca/src/com/netscape/ca/CRLIssuingPoint.java
+++ b/base/ca/src/com/netscape/ca/CRLIssuingPoint.java
@@ -242,7 +242,7 @@ public class CRLIssuingPoint implements ICRLIssuingPoint, Runnable {
      /**
       * next update as this update extension
       */
-    private long mNextAsThisUpdateExtension; 
+    private long mNextAsThisUpdateExtension;
 
     /**
      * Boolean flag controlling whether CRLv2 extensions are to be
@@ -707,7 +707,7 @@ public class CRLIssuingPoint implements ICRLIssuingPoint, Runnable {
         // get next update grace period
         mNextUpdateGracePeriod = MINUTE * config.getInteger(Constants.PR_GRACE_PERIOD, 0);
 
-        // get next update as this update extension 
+        // get next update as this update extension
         mNextAsThisUpdateExtension = MINUTE * config.getInteger(Constants.PR_NEXT_AS_THIS_EXTENSION, 0);
 
         // Get V2 or V1 CRL
@@ -1653,7 +1653,7 @@ public class CRLIssuingPoint implements ICRLIssuingPoint, Runnable {
                     int j = i - mDailyUpdates.elementAt(mCurrentDay).size();
                     int nDays = 1;
                     long t = 0;
-                    if (mDailyUpdates.size() > 1) {
+                    if (mDailyUpdates.size() >= 1) {
                         while (nDays <= mDailyUpdates.size()) {
                             int nextDay = (mCurrentDay + nDays) % mDailyUpdates.size();
                             if (j < mDailyUpdates.elementAt(nextDay).size()) {
-- 
2.1.0


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]