ScheduledReporter.start() starts with undesired delay

[sofax]

ScheduledReporter.start() incorrectly uses the interval size for the start delay, too:

    public void start(long period, TimeUnit unit) {
        executor.scheduleAtFixedRate(new Runnable() {
            @Override
            public void run() {
                try {
                    report();
                } catch (RuntimeException ex) {
                    LOG.error("RuntimeException thrown from {}#report. Exception was suppressed.", ScheduledReporter.this.getClass().getSimpleName(), ex);
                }
            }
        }, period, period, unit);
    }

This is a serious problem when the interval is sufficiently big. I suggest to add an alternative version of ScheduledReporter.start() to fix the bug without affecting code that relies on this behavior:

    public void start(long period, long initialDelay, TimeUnit unit) {
        executor.scheduleAtFixedRate(new Runnable() {
            @Override
            public void run() {
                try {
                    report();
                } catch (RuntimeException ex) {
                    LOG.error("RuntimeException thrown from {}#report. Exception was suppressed.", ScheduledReporter.this.getClass().getSimpleName(), ex);
                }
            }
        }, initialDelay, period, unit);
    }

[arteam]

Hello @sofax,

Sorry to get back to you late. I like your pull request, could you please rebase it against the 3.2-development branch? Due changes from another pull requests (respectively #1018), it now has merge conflicts and can't be merged. Thank you.

[arteam]

Thanks for actualizing your changes! I've added a couple of comments regarding the implementation.

[arteam]

I think it would be better to change the order of parameters, so initialDelay comes first, to maintain the same order as in the scheduleAtFixedRate method.

[sofax]

Agreed. :)

[arteam]

I think we could avoid duplication and implement the method as:

synchronized public void start(long initialDelay, long period, TimeUnit unit) {
        if (this.scheduledFuture != null) {
            throw new IllegalArgumentException("Reporter already started");
        }
        this.scheduledFuture = executor.scheduleAtFixedRate(new Runnable() {
           @Override
           public void run() {
               try {
                   report();
               } catch (RuntimeException ex) {
                   LOG.error("RuntimeException thrown from {}#report. Exception was suppressed.", ScheduledReporter.this.getClass().getSimpleName(), ex);
               }
           }
       }, initialDelay, period, unit);
   }

as then make the start(long period, TimeUnit unit) method to delegate to it as

start(period, period, unit)

[sofax]

Again, agreed.

The lines

        if (this.scheduledFuture != null) {
            throw new IllegalArgumentException("Reporter already started");
        }

are new, but they do look reasonable to me.

[arteam]

It seems to me as an unrelated change. Could you please revert it?

[sofax]

Sorry, already working on it - it got pushed too soon.

[sofax]

This change has been reverted.

[arteam]

Could you add a simple unit test to ScheduledReporterTest? A simple test which verifies that the scheduler wakes up with a correct initial delay. Very similar to the pollsPeriodically test.

[sofax]

Will do. All those tests are a little bit unreliable though, as the executor services rely on the system time instead of using a dedicated (mockable) clock.

[sofax]

Actually, instead of waiting for the reporter to actually do its work, it would be much better to just verify that the method scheduleAtFixedRate() was called with the correct arguments. There is no need to test the executor itself, as that's a collaborator that has already been tested elsewhere.

[arteam]

Actually, instead of waiting for the reporter to actually do its work, it would be much better to just verify that the method scheduleAtFixedRate() was called with the correct arguments. There is no need to test the executor itself, as that's a collaborator that has already been tested elsewhere.

Agrred. This would work, too.

[sofax]

Also, the tests are not isolated. The collaborators (mocks) should be initialized per test method, not per class.

[sofax]

Gnnhhh ... my IDE is configured to replace ".*" imports with the explicit ones - but I did NOT want to push those changes, as they were not necessary for the fix.

[sofax]

Test cases have been added.

[arteam]

Gnnhhh ... my IDE is configured to replace ".*" imports with the explicit ones - but I did NOT want to push those changes, as they were not necessary for the fix.

I think expanding star imports is a good change, we can leave it.

[arteam]

Thank you for your contribution!