The operational and config stores use the same code base. The only difference is the configuration - operational is not persisted by default.
On Wed, Jan 11, 2017 at 1:31 AM, Sela, Guy <guy.s...@hpe.com> wrote: > But operational needs to be transferred to the followers in the cluster. > > It uses a different mechanism? > > > > *From:* Tom Pantelis [mailto:tompante...@gmail.com] > *Sent:* Wednesday, January 11, 2017 1:06 AM > *To:* Sela, Guy <guy.s...@hpe.com> > *Cc:* Robert Varga <n...@hq.sk>; controller-dev@lists.opendaylight.org; > odl netvirt dev <netvirt-...@lists.opendaylight.org> > *Subject:* Re: [controller-dev] [mdsal-dev] Netvirt Scale tests: > OutOfMemory from datastore > > > > operational won't snapshot if not persisted or replicated. > > > > Can you open a bug for tracking? > > > > On Tue, Jan 10, 2017 at 4:12 PM, Sela, Guy <guy.s...@hpe.com> wrote: > > Do the snapshot happen only to the configuration data store or to the > operational as well? > > -----Original Message----- > From: Robert Varga [mailto:n...@hq.sk] > Sent: Tuesday, January 10, 2017 10:21 PM > To: Tom Pantelis <tompante...@gmail.com>; Sela, Guy <guy.s...@hpe.com> > > Cc: controller-dev@lists.opendaylight.org; odl netvirt dev < > netvirt-...@lists.opendaylight.org> > Subject: Re: [controller-dev] [mdsal-dev] Netvirt Scale tests: OutOfMemory > from datastore > > On 01/10/2017 08:16 PM, Tom Pantelis wrote: > > Since the length field of an array is an int, it's constrained to > > Integer.MAX_VALUE (~2G). To handle snapshots larger than 2G we'll have > > to chuck it into multiple byte[]. > > That could get funky on the reassembly side of things. If we go that > route, we may as well switch to something more friendly, like > java.nio.ByteBuffer(), too. > > Guy, just out of curiosity: how much duplication is in your data set? > > Regards, > Robert > > >
_______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
