Mailing-List: contact users-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@activemq.apache.org
Received-SPF: pass (athena.apache.org: domain of chirino@gmail.com designates
 209.85.216.50 as permitted sender)
MIME-Version: 1.0
Sender: chirino@gmail.com
In-Reply-To: <1386605680874-4675294.post@n4.nabble.com>
References: <1386605680874-4675294.post@n4.nabble.com>
Date: Wed, 19 Feb 2014 20:57:23 -0500
Message-ID: 
 <CAGZ-RDLk6i1v8sz1dhWmMhQpVTGJfzNS-trWduaDAM4N4ovSMQ@mail.gmail.com>
Subject: Re: Any way to protect from corruption being replicated in LevelDB?
From: Hiram Chirino <hiram@hiramchirino.com>
To: users <users@activemq.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Dec 9, 2013 at 11:14 AM, pwalker <pwalker@navinet.net> wrote:
> Having a quick look it doesn't seem like ReadOptions are used for this
> function so no verifyChecksums flag is passed in right?
>

Yep.. perhaps we should.

> Was hoping that on initialization of the masterLevelDBClient we would be
> able to validate the datastore at that point and if it was invalid fall
> over?

It might be impractical to check for all corruption at startup since
that might significantly delay the startup process.

> Is that the expected behavior of those parameters or is it completely
> distinct from the replication process as they are used in the non-replicated
> leveldb adapter as well?

The replication bits added to leveldb replicate files at the block
level and don't really check the integrity of the files it's
transferring.

Perhaps if we do detect consistency problem with a master we should
just stop replication and mark it's data files as being inconsistent
so that it does not try to become a master in the future.  That still
would require that one of the slaves data files be consistent to be
able to recover from the failure.


-- 
Hiram Chirino
Engineering | Red Hat, Inc.
hchirino@redhat.com | fusesource.com | redhat.com
skype: hiramchirino | twitter: @hiramchirino