Hi dev team,
Recently, a commit was pushed to develop which upgraded the Lucene
version used in Apache Geode to 7.1.0. These new Lucene indexes are
not compatible with the previous versions hence it breaks the rolling
upgrade contract. We are no longer able to execute Lucene queries when
there
Would it be possible to allow an operator to choose which version of Lucene to
use? Such that if they are prepared for the issues you describe, they could
still go ahead and upgrade to 7.10. Or are there breaking API changes which
would make that hard/impossible to accommodate in our code base?
> On Sep 27, 2021, at 11:48 AM, nabarun nag wrote:
>
> Recently, a commit was pushed to develop which upgraded the Lucene
> version used in Apache Geode to 7.1.0. These new Lucene indexes are
> not compatible with the previous versions hence it breaks the rolling
> upgrade contract. We are no
Does anyone have more context on why lucene queries won't work during the
rolling upgrade? I can see what added a line to the documentation and changed
the tests not to do queries, but I'm not sure why we needed to do that.
-Dan
From: nabarun nag
Sent: Monday,
In simple words, if Lucene indexes were created by a new version (7.1.0), then
replicated to others that are still in the older version, they won't understand
the index, and the event processors start throwing exceptions.
This can be simply seen by just re-enabling the query execution in the
Might I propose something here.
There is currently a significant amount of work going into completing
Geode-8705, which is the Classloader isolation. We are currently targeting to
getting this release in Geode 1.16.
My proposal is, that we use the capability that Patrick demo’d at the
The solution for preventing the query executions to occur in the mixed version
mode also caused some problems where the query function executions get
repeatedly executed and that results in stack overflow.
From: Nabarun Nag
Sent: Monday, September 27, 2021
