[stellation-res] Timing: The Problem

[Dave Shields <shields@xxxxxxxxxxxxxx>]

Apologies in advance for the long note, but I think it raises a
problem that must be addressed. If you are interested in working on
the solution, please respond to the thread

  Timing: The Solution

which I will start shortly.

Your timely responses to my request to "Could someone please run this
program on Windows" showed we do indeed have a problem with time,
namely Java's File.lastModified() method does not always work as one
would expect

The problem is not urgent, in that Eclipse does it right, as do the
other reported systems, except for IBM's JDK 1.3 on Linux RedHat 7.1
(the version I am using), and at least one version of Windows (Rodolfo
Araya can provide the details).

However, the problem is real. For example, Jonathan Gossage reported
that his company has encountered several-second variations in clock
time on various Unix systems. I originally ran into this problem when
I noted failures on some regression tests, only to discover that two
versions of a file that had changed were deemed to be the same since
they were changed in the 'same' second.

We could address this solely by an addition to the documentation.
For example,

  If you are using Version 1.3 of IBM's JVM on RedHat 7.1, then
  after every checkin or checkout, please say the following phrase
  to yourself

      I wish IBM would fix the bug in File.lastModified

  and make *sure* you take at least one second to do so.

But -- eager programmers all -- we probably want to change the code.

Now I could do it myself, but I think it best that I don't. Here's
why.

There is a more urgent problem -- this project will only succeed in
the long run if we can get more non-IBM people involved -- and I see
this file modification time problem as a good opportunity to do this,
as we have a problem that is not urgent, provides a good introduction
to the workspace code, and raises some interesting challenges.

In brief, I'm going to leave it to the community to sort this out.

I've just checked in a first cut in changes to the workspace -- involving
the classes Files, Checkin, Checkout, Configure, Files, Project, and
Svc -- that do the following:

1) add a new option 'svc-check-wait' that can be used to wait for the
clock to catch up after a checkin or checkout

2) add a new command 'svc configure client' that runs a variant of the
Time program I posted yesterday to determine is the 'svc-check-wait'
option is needed and installs an appropriate value in the current
.svcrc file.

3) add a a test in the computeSignature() loop in Project so that, if
'svc-check-wait' has been specified with a value starting with '-',
then file modification time will be ignored, and *all* artifacts will
have their signature computed. This provides a starting point for
investigating the performance issues. Is is really important to get
the time right, or should we just compute all signatures all the time?

I will post a followup note with the diff output showing my recent
changes. If you read the code, you will learn how to add a new
command, a new option, and how to affect execution of one of the most
critical loops of the workspace (signature computation). I expect
anyone working through this will find  bugs, or  ways to improve the
system, or both. Doing it right may involve changing guide, tutorial,
unit tests (which raises a problem in itself, as this problem only
shows up on some operating systems), and so forth.

Though in rough form, the code works in that, if I run the standard
tests with the IBM 1.3 JVM on Linux, they fail, and now pass only 
if I first do
      svc config system
to set an appropriate wait value.

The rest is up to you. I'm asking Florin and Ringo to coordinate any
source commits. I'll try to stay out of this as much as possible,
except to answer any queries about the workspace code.

thanks,
dave

-- 
Dave Shields, IBM Research, shields@xxxxxxxxxxxxxx.