2. It seems like you suggest that the shipping thread will continously
check to see whether the timeout has expired. Generally, such
busy-waits should be avoided. I think you should introduce a timer
or something so that the thread can be suspended until it is time
to ship log records.
I have introduced the time concept to overcome the limitation imposed by
DaemonFactory.
The DaemonFactory would call performWork (i.e.) ship log records at its own
convinience. As i understand it we cannot configure DaemonFactory to transmit
at our mentioned time interval.
So, When performWork is called entirely depends on how good DaemonFactory is
feeling :-)
We do not want this to happen, because what if this is too soon for us or what
if it
is too late.
Hence we introduce a transmit interval variable that calculates the difference
between the
last call and the current call of performWork or rather
shipALogChunk(forceFlush also)
If I understand you correctly, this time interval will only be helpful
in the "too soon" case, not the "too late" case.
When I wrote version 2 of the proof of concept patches (see DERBY-2872),
I used a Daemon to read log records at the slave side. I basically had:
performWork {
if (messageWaitingForProcess) processMessage();
}
The waiting interval between each time performWork was called was way
too high for this usage (in the order of 3-10 seconds). This interval is
probably too high for the log shipper as well, so my guess is that
you'll need something similar to an eternal loop with a wait(millis)
somewhere in this package.
--
Jørgen Løland
