directory-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Peter <jmr...@iki.fi>
Subject Re: [ApacheDS] is it safe to use apacheDS M20 with Mavibot?
Date Fri, 02 Oct 2015 00:28:09 GMT
Hi,

thanks Pierre, Kiran and Emmanuel for your responses and  information on
this topic.

"when a write occurs, no read can be done"
Emmanuel are you saying that if Mavibot is used then a read operation would
fail if a write is currently in progress?

With JDBM and apacheDS M19 we have seen situations where a read doesn't
return an entry and then when that entry is attempted to be added we get an
error.

Also we have seen situations where a read doesn't find an entry and a user
can't login due to that. After some time it starts working again (not quite
sure is this a client or server side issue though).

Best regards,
John Peter

On Thu, Oct 1, 2015 at 5:40 PM, Emmanuel Lécharny <elecharny@gmail.com>
wrote:

> Le 01/10/15 14:45, John Peter a écrit :
> > Hi,
> >
> > we are planning to upgrade to apacheDS M20 and tried using Mavibot with
> it
> > in our test environment. So far it seems to work.
> >
> > I have seen emails around Mavibot still having issues.
> >
> > Is it safe to use Mavibot already in production or what issues should we
> > expect to see with it if we do use it?
> >
> > On the other hand JDBM has its issues also so we are just wondering does
> > Mavibot still have more or less issues?
>
> I'll give you a few insights about what's missing in Mavibot :
>
> - cross-B-tree transaction support
>
> This feature is absolutely critical to have a server that does not
> randomely sent back errors when doing a search while some updates are
> occuring. At this point, tjis is a rare event, because the server is
> kind of protected against such situation, but that comes with a price :
> when a write occurs, no read can be done.
>
> So, no, I don't think it's safe, but it wll be soon : we have spent some
> time yesterday with Kiran reviewing the implementation of this last
> feature, and we a re confident that this is teh way we want to implement
> it.
>
> So please, keep watching, the code might be committed soon.
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message