I started with implementation of Option-1. As I understood the idea is to block all puts(put them in the queue) until all members are upgraded. After that it will process all queued events.
I tried with Dan's proposal to check on start of LuceneEventListener.process() if all members are upgraded, also changed test to verify lucene indexes only after all members are upgraded, but got the same error with incompatibilities between lucene versions. Changes are visible on https://github.com/apache/geode/pull/4198. Please add comments and suggestions. BR, Mario ________________________________ Šalje: Xiaojian Zhou <gz...@pivotal.io> Poslano: 7. studenog 2019. 18:27 Prima: geode <dev@geode.apache.org> Predmet: Re: Lucene upgrade Oh, I misunderstood option-1 and option-2. What I vote is Jason's option-1. On Thu, Nov 7, 2019 at 9:19 AM Jason Huynh <jhu...@pivotal.io> wrote: > Gester, I don't think we need to write in the old format, we just need the > new format not to be written while old members can potentially read the > lucene files. Option 1 can be very similar to Dan's snippet of code. > > I think Option 2 is going to leave a lot of people unhappy when they get > stuck with what Mario is experiencing right now and all we can say is "you > should have read the doc". Not to say Option 2 isn't valid and it's > definitely the least amount of work to do, I still vote option 1. > > On Wed, Nov 6, 2019 at 5:16 PM Xiaojian Zhou <gz...@pivotal.io> wrote: > > > Usually re-creating region and index are expensive and customers are > > reluctant to do it, according to my memory. > > > > We do have an offline reindex scripts or steps (written by Barry?). If > that > > could be an option, they can try that offline tool. > > > > I saw from Mario's email, he said: "I didn't found a way to write lucene > in > > older format. They only support > > reading old format indexes with newer version by using lucene-backward- > > codec." > > > > That's why I think option-1 is not feasible. > > > > Option-2 will cause the queue to be filled. But usually customer will > hold > > on, silence or reduce their business throughput when > > doing rolling upgrade. I wonder if it's a reasonable assumption. > > > > Overall, after compared all the 3 options, I still think option-2 is the > > best bet. > > > > Regards > > Gester > > > > > > On Wed, Nov 6, 2019 at 3:38 PM Jacob Barrett <jbarr...@pivotal.io> > wrote: > > > > > > > > > > > > On Nov 6, 2019, at 3:36 PM, Jason Huynh <jhu...@pivotal.io> wrote: > > > > > > > > Jake - there is a side effect to this in that the user would have to > > > > reimport all their data into the user defined region too. Client > apps > > > > would also have to know which of the regions to put into.. also, I > may > > be > > > > misunderstanding this suggestion, completely. In either case, I'll > > > support > > > > whoever implements the changes :-P > > > > > > Ah… there isn’t a way to re-index the existing data. Eh… just a > thought. > > > > > > -Jake > > > > > > > > >
