Hi,

I agree with the FileStoreCorruptException idea. The change helps clarify
the problem (missing segment) and will not affect any existing code.

best,
alex



On Tue, Sep 9, 2014 at 2:25 PM, Martin Böttcher <
[email protected]> wrote:

> Hi,
>
> I'm working on the TarMK failover package and trying to make it more
> robust and reliable. I noticed that there are still some situations in
> which the current implementation will run into persistent problems. It's
> not obvious what the "right" strategy is so let me paint the picture quite
> quickly:
>
> If you have a slave and corrupt the local tar files (eg. kill the process
> during a sync/write operation) it can happen that the next sync with the
> master tries to update the informations and
>
> 1) nothing happens because the head segment is unchanged and locally
> present
> 2) a new head segment is received and only the new head segment will be
> stored
> 3) during a "compareAgainstBaseState"-call an exception is thrown because
> a segment can't be read locally (see attached stacktrace). As soon as you
> enter this state you're stuck.
>
> The problem is that the FileStore has its own immutable Tracker which is
> used for reading segments. The SegmentTracker of the FailoverStore will not
> be used if segments are read from the existing store. Due to the fact that
> a quite "generic" IllegalStateException is thrown the handling is
> difficult. A minimal inversive approach could be:
>
> * add a FileStoreCorruptException (extending
> java.lang.IllegalStateException) and pass the SegmentId to the exception
> * catch this exception in the SegmentLoaderHandler and refetch the segment
> from the master and persist it
>
> This recovers from the error.
>
> Any comments?
>
> Regards
> Martin
>
>
>
>
>

Reply via email to