Re: Index documents in async way

[Gus Heck]

This is interesting, though it opens a few of cans of worms IMHO.

   1. Currently we now guarantee that if solr sends you an OK response the
   document WILL eventually become searchable without further action.
   Maintaining that guarantee becomes impossible if we haven't verified that
   the data is formatted correctly (i.e. dates are in ISO format, etc).
   This may be an acceptable cost for those opting for async indexing but it
   may be very hard for some folks to swallow if it became the only option
   however.
   2. In the case of errors we need to hold the error message indefinitely
   for later discovery by the client, this needs to not accumulate forever.
   Thus:
  1. We have a timed cleanup, leasing or some other self limiting
  pattern... possibly by indexing the failures in a TRA with autodelete so
  that clients can efficiently find the status of the particular
document(s)
  they sent, obviouysly there's at least an asyc id involved, probably the
  uniqueKey (where available) and timestamps for recieved, and processed as
  well.
  2. We log more simply with a sequential id and let clients keep track
  of what they have seen... This can lead us down the path of re-inventing
  kafka, or making kafka a required dependency.
  3. We provide a push oriented connection (websocket? HTTP2?) that
  clients that care about failures can listen to and store nothing. A less
  appetizing variant is to publish errors to a message bus.
   3. If we have more than one thread picking up the submitted documents
   and writing them, we need a state machine that identifies in-progress
   documents to prevent multiple pickups and resets processing to new on
   startup to ensure we don't index the same document twice and don't lose
   things that were in-flight on power loss.
   4. Backpressure/throttling. If we're losing ground continuously on the
   submissions because indexing is heavier than accepting documents, we may
   fill up the disk. Of course the index itself can do that, but need to think
   about if this makes it worse.

A big plus to this however is that batches with errors could optionally
just omit the (one or two?) errored document(s) and publish the error for
each errored document rather than failing the whole batch, meaning that the
indexing infrastructure submitting in batches doesn't have to leave several
hundred docs unprocessed, or alternately do a slow doc at a time resubmit
to weed out the offenders.

Certainly the involvement of kafka sounds interesting. If one persists to
an externally addressable location like a kafka queue one might leave the
option for the write-on-receipt queue to be different from the
read-to-actually-index queue and put a pipeline behind solr instead of
infront of it... possibly atomic updates could then be given identical
processing as initial indexing

On Sat, Oct 10, 2020 at 12:41 AM David Smiley  wrote:

>
>
> On Thu, Oct 8, 2020 at 10:21 AM Cao Mạnh Đạt  wrote:
>
>> Hi guys,
>>
>> First of all it seems that I used the term async a lot recently :D.
>> Recently I have been thinking a lot about changing the current indexing
>> model of Solr from sync way like currently (user submit an update request
>> waiting for response). What about changing it to async model, where nodes
>> will only persist the update into tlog then return immediately much like
>> what tlog is doing now. Then we have a dedicated executor which reads from
>> tlog to do indexing (producer consumer model with tlog acting like the
>> queue).
>>
>
> The biggest problem I have with this is that the client doesn't know about
> indexing problems without awkward callbacks later to see if something went
> wrong.  Even simple stuff like a schema problem (e.g. undefined field).
> It's a useful *option*, any way.
>
>
>>
>> I do see several big benefits of this approach
>>
>>- We can batching updates in a single call, right now we do not use
>>writer.add(documents) api from lucene, by batching updates this gonna 
>> boost
>>the performance of indexing
>>
>> I'm a bit skeptical that would boost indexing performance.  Please
> understand the intent of that API is about transactionality (atomic add)
> and ensuring all docs go in the same segment.  Solr *does* use that API for
> nested / parent-child documents, and because it has to.  If that API were
> to get called for normal docs, I could see the configured indexing buffer
> RAM or doc limit could be exceeded substantially.  Perhaps not a big deal.
> You could test your performance theory on a hacked Solr without much
> modifications, I think?  Just buffer then send in bulk.
>
>>
>>- One common problems with Solr now is we have lot of threads doing
>>indexing so that can ends up with many small segments. Using this model we
>>can have bigger segments so less merge cost
>>
>> This is app/use-case dependent of course.  If you observe the segment
> count to be high, I think it's more 

Re: 8.7 Release

[Adrien Grand]

This sounds good to me, thank you!

On Tue, Oct 13, 2020 at 6:06 PM Atri Sharma  wrote:

> I will start the first build candidate on upcoming Monday. This is my
> first release so fingers crossed :)
>
> On Tue, Oct 13, 2020 at 7:01 PM Adrien Grand  wrote:
> >
> > Thanks Atri. Do you know when you will start the first build candidate
> as well? We had been doing some planning around Ishan's initial suggestion
> of cutting the branch on September 20th, so as this is getting delayed I'm
> trying to get a sense of whether the release would likely be out in the
> next two weeks.
> >
> > On Tue, Oct 13, 2020 at 12:10 PM Atri Sharma  wrote:
> >>
> >> Adrien,
> >>
> >> Sorry for the delay in response.
> >>
> >> I will cut the branch this Friday morning (IST).
> >>
> >> Atri
> >>
> >> On Tue, 13 Oct 2020 at 05:43, Houston Putman 
> wrote:
> >>>
> >>> Adrien, I plan on merging SOLR-14907 to master and 8x tomorrow. If you
> would mind waiting to cut 8.7 until then, I would appreciate it.
> >>>
> >>> - Houston
> >>>
> >>> On Mon, Oct 12, 2020 at 4:59 AM Adrien Grand 
> wrote:
> 
>  Shall we move forward with 8.7 now that 8.6.3 is out?
> 
>  On Tue, Sep 22, 2020 at 9:32 PM Atri Sharma  wrote:
> >
> > I plan to cut the branch on 30th September.
> >
> > On Wed, 23 Sep 2020 at 00:51, Cassandra Targett <
> casstarg...@gmail.com> wrote:
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> Atri,
> >>
> >>
> >>
> >>
> >>
> >> Just so I understand your plans, when you say you are planning to
> start the process at the end of this month, you mean you intend to create
> the branch around Oct 1? No pressure, I ask only because Ishan’s original
> mail mentioned cutting the branch this week and I just wanted to have a
> clearer sense of your timeline.
> >>
> >>
> >>
> >>
> >>
> >> Thanks,
> >>
> >>
> >> Cassandra
> >>
> >>
> >>
> >>
> >> On Sep 15, 2020, 11:53 PM -0500, Atri Sharma ,
> wrote:
> >>
> >>
> >>
> >>
> >> I was planning to start the process end of this month.
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> On Wed, 16 Sep 2020 at 04:07, Gus Heck  wrote:
> >>
> >>
> >>>
> >>>
> >>> Unless it somehow got lost in a spam filter somewhere, I don't
> think we have set a target date for the release yet? (roadmap says autumn
> 2020 which technically doesn't begin until the solstice on the 21st :) )
> >>>
> >>>
> >>>
> >>>
> >>> Hoping that I might still get the Advanced Query parser in first,
> but that's a much bigger prospect than these two tickets.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> -Gus
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> On Tue, Sep 15, 2020 at 5:29 PM Erik Hatcher <
> erik.hatc...@gmail.com> wrote:
> >>>
> >>>
> 
> 
>  Unless there are objections, I'm gonna get
> https://issues.apache.org/jira/browse/SOLR-14799 into 8.7 as well.
> 
> 
> 
> 
>  Erik
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>  On Sep 14, 2020, at 10:06 AM, Christine Poerschke (BLOOMBERG/
> LONDON)  wrote:
> 
> 
> 
> 
> 
> 
> 
> 
> 
>  With a view towards including it in the release, I'd appreciate
> input on the
> 
> 
> 
> 
>  https://issues.apache.org/jira/browse/SOLR-14828
> 
> 
> 
> 
> 
>  solrj logging tweak if anyone has a moment?
> 
> 
> 
> 
>  Thanks,
> 
> 
>  Christine
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>  From: dev@lucene.apache.org At: 08/20/20 22:48:39
> 
> 
>  To: dev@lucene.apache.org
> 
> 
>  Subject: Re: 8.7 Release
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>  Also, we should try to respect the stuff we have put on the
> roadmap (Which includes me getting a patch up for SIP-9 much sooner rather
> than even a little later!)
> 
> 
> 
> 
> 
> 
> 
>  On Thu, Aug 20, 2020 at 5:18 PM Adrien Grand 
> wrote:
> 
> 
> >
> >
> > Thanks for the explanation Ishan.
> >
> >
> >
> >
> >
> >
> >
> > On Thu, Aug 20, 2020 at 10:33 PM Ishan Chattopadhyaya <
> ichattopadhy...@gmail.com> wrote:
> >
> 

Re: 8.7 Release

[Atri Sharma]

I will start the first build candidate on upcoming Monday. This is my
first release so fingers crossed :)

On Tue, Oct 13, 2020 at 7:01 PM Adrien Grand  wrote:
>
> Thanks Atri. Do you know when you will start the first build candidate as 
> well? We had been doing some planning around Ishan's initial suggestion of 
> cutting the branch on September 20th, so as this is getting delayed I'm 
> trying to get a sense of whether the release would likely be out in the next 
> two weeks.
>
> On Tue, Oct 13, 2020 at 12:10 PM Atri Sharma  wrote:
>>
>> Adrien,
>>
>> Sorry for the delay in response.
>>
>> I will cut the branch this Friday morning (IST).
>>
>> Atri
>>
>> On Tue, 13 Oct 2020 at 05:43, Houston Putman  wrote:
>>>
>>> Adrien, I plan on merging SOLR-14907 to master and 8x tomorrow. If you 
>>> would mind waiting to cut 8.7 until then, I would appreciate it.
>>>
>>> - Houston
>>>
>>> On Mon, Oct 12, 2020 at 4:59 AM Adrien Grand  wrote:

 Shall we move forward with 8.7 now that 8.6.3 is out?

 On Tue, Sep 22, 2020 at 9:32 PM Atri Sharma  wrote:
>
> I plan to cut the branch on 30th September.
>
> On Wed, 23 Sep 2020 at 00:51, Cassandra Targett  
> wrote:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Atri,
>>
>>
>>
>>
>>
>> Just so I understand your plans, when you say you are planning to start 
>> the process at the end of this month, you mean you intend to create the 
>> branch around Oct 1? No pressure, I ask only because Ishan’s original 
>> mail mentioned cutting the branch this week and I just wanted to have a 
>> clearer sense of your timeline.
>>
>>
>>
>>
>>
>> Thanks,
>>
>>
>> Cassandra
>>
>>
>>
>>
>> On Sep 15, 2020, 11:53 PM -0500, Atri Sharma , wrote:
>>
>>
>>
>>
>> I was planning to start the process end of this month.
>>
>>
>>
>>
>>
>>
>>
>> On Wed, 16 Sep 2020 at 04:07, Gus Heck  wrote:
>>
>>
>>>
>>>
>>> Unless it somehow got lost in a spam filter somewhere, I don't think we 
>>> have set a target date for the release yet? (roadmap says autumn 2020 
>>> which technically doesn't begin until the solstice on the 21st :) )
>>>
>>>
>>>
>>>
>>> Hoping that I might still get the Advanced Query parser in first, but 
>>> that's a much bigger prospect than these two tickets.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> -Gus
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Sep 15, 2020 at 5:29 PM Erik Hatcher  
>>> wrote:
>>>
>>>


 Unless there are objections, I'm gonna get 
 https://issues.apache.org/jira/browse/SOLR-14799 into 8.7 as well.




 Erik










 On Sep 14, 2020, at 10:06 AM, Christine Poerschke (BLOOMBERG/ LONDON) 
  wrote:









 With a view towards including it in the release, I'd appreciate input 
 on the




 https://issues.apache.org/jira/browse/SOLR-14828





 solrj logging tweak if anyone has a moment?




 Thanks,


 Christine











 From: dev@lucene.apache.org At: 08/20/20 22:48:39


 To: dev@lucene.apache.org


 Subject: Re: 8.7 Release











 Also, we should try to respect the stuff we have put on the roadmap 
 (Which includes me getting a patch up for SIP-9 much sooner rather 
 than even a little later!)







 On Thu, Aug 20, 2020 at 5:18 PM Adrien Grand  wrote:


>
>
> Thanks for the explanation Ishan.
>
>
>
>
>
>
>
> On Thu, Aug 20, 2020 at 10:33 PM Ishan Chattopadhyaya 
>  wrote:
>
>
>>
>>
>>
>>
>> Hi Adrien,
>>
>>
>> I think I am mainly concerned about getting the configuration and 
>> modularity of this right before we release: 
>> https://issues.apache.org/jira/browse/SOLR-14588.
>>
>>
>> If we aren't able to resolve it, we should revert that feature.
>>
>>
>>
>>
>>
>> There may be some other 

Re: 8.7 Release

[Adrien Grand]

Thanks Atri. Do you know when you will start the first build candidate as
well? We had been doing some planning around Ishan's initial suggestion of
cutting the branch on September 20th, so as this is getting delayed I'm
trying to get a sense of whether the release would likely be out in the
next two weeks.

On Tue, Oct 13, 2020 at 12:10 PM Atri Sharma  wrote:

> Adrien,
>
> Sorry for the delay in response.
>
> I will cut the branch this Friday morning (IST).
>
> Atri
>
> On Tue, 13 Oct 2020 at 05:43, Houston Putman 
> wrote:
>
>> Adrien, I plan on merging SOLR-14907
>>  to master and 8x
>> tomorrow. If you would mind waiting to cut 8.7 until then, I would
>> appreciate it.
>>
>> - Houston
>>
>> On Mon, Oct 12, 2020 at 4:59 AM Adrien Grand  wrote:
>>
>>> Shall we move forward with 8.7 now that 8.6.3 is out?
>>>
>>> On Tue, Sep 22, 2020 at 9:32 PM Atri Sharma  wrote:
>>>
 I plan to cut the branch on 30th September.

 On Wed, 23 Sep 2020 at 00:51, Cassandra Targett 
 wrote:

>
>
>
>
>
>
>
>
>
>
>
>
> Atri,
>
>
>
>
>
> Just so I understand your plans, when you say you are planning to
> start the process at the end of this month, you mean you intend to create
> the branch around Oct 1? No pressure, I ask only because Ishan’s original
> mail mentioned cutting the branch this week and I just wanted to have a
> clearer sense of your timeline.
>
>
>
>
>
> Thanks,
>
>
> Cassandra
>
>
>
>
> On Sep 15, 2020, 11:53 PM -0500, Atri Sharma , wrote:
>
>
>
>
> I was planning to start the process end of this month.
>
>
>
>
>
>
>
> On Wed, 16 Sep 2020 at 04:07, Gus Heck  wrote:
>
>
>
>>
>> Unless it somehow got lost in a spam filter somewhere, I don't think
>> we have set a target date for the release yet? (roadmap says autumn 2020
>> which technically doesn't begin until the solstice on the 21st :) )
>>
>>
>>
>>
>> Hoping that I might still get the Advanced Query parser in first, but
>> that's a much bigger prospect than these two tickets.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> -Gus
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Tue, Sep 15, 2020 at 5:29 PM Erik Hatcher 
>> wrote:
>>
>>
>>
>>>
>>> Unless there are objections, I'm gonna get
>>> https://issues.apache.org/jira/browse/SOLR-14799 into 8.7 as well.
>>>
>>>
>>>
>>>
>>> Erik
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Sep 14, 2020, at 10:06 AM, Christine Poerschke (BLOOMBERG/
>>> LONDON)  wrote:
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> With a view towards including it in the release, I'd appreciate
>>> input on the
>>>
>>>
>>>
>>>
>>> https://issues.apache.org/jira/browse/SOLR-14828
>>>
>>>
>>>
>>>
>>>
>>> solrj logging tweak if anyone has a moment?
>>>
>>>
>>>
>>>
>>> Thanks,
>>>
>>>
>>> Christine
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> From: dev@lucene.apache.org At: 08/20/20 22:48:39
>>>
>>>
>>> To: dev@lucene.apache.org
>>>
>>>
>>> Subject: Re: 8.7 Release
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Also, we should try to respect the stuff we have put on the roadmap
>>> (Which includes me getting a patch up for SIP-9 much sooner rather than
>>> even a little later!)
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Aug 20, 2020 at 5:18 PM Adrien Grand 
>>> wrote:
>>>
>>>
>>>

 Thanks for the explanation Ishan.







 On Thu, Aug 20, 2020 at 10:33 PM Ishan Chattopadhyaya <
 ichattopadhy...@gmail.com> wrote:



>
>
>
> Hi Adrien,
>
>
> I think I am mainly concerned about getting the configuration and
> modularity of this right before we release:
> https://issues.apache.org/jira/browse/SOLR-14588.
>
>
> If we aren't able to resolve it, we should revert that feature.
>
>
>
>
>
> There may be some other performance issues that may have been
> marked as blockers just to infuse a sense of urgency among those that 
> need
> to fix it. But, I wouldn't consider them something that actually 
> holds up a
> release.
>
>
> Regards,
>
>
> Ishan
>
>
>

Re: [jira] [Commented] (SOLR-14923) Indexing performance is unacceptable when child documents are involved

[Thomas Wöckinger]

On Tue, Oct 13, 2020 at 2:43 PM David Smiley (Jira)  wrote:

>
> [
> https://issues.apache.org/jira/browse/SOLR-14923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17213093#comment-17213093
> ]
>
> David Smiley commented on SOLR-14923:
> -
>
> I am responsible for this bug, along with [~moshebla], the contributor of
> SOLR-12638.  Perhaps the single most bit of code I've regretted committing
> on behalf of another are the few lines of code you have found Thomas.  I
> expressed my reservations at the time:
>
>
> https://issues.apache.org/jira/browse/SOLR-12638?focusedCommentId=16872898=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16872898
>
> bq. What gnaws at me is that this "UpdateLog.openRealtimeSearcher" is
> being called optimistically on a new doc because mbeee some future
> atomic update will need to see it. And not just any type of atomic update;
> one that is directly to a nested child doc (something I consider highly
> experimental). It's as if we're optimizing for making that future atomic
> update faster by doing work in advance that will, I think, very rarely
> actually be used. It's a tragedy, if I'm understanding this right.
>
> There's a bit of conversation before in the issue about it as well.  It's
> difficult for me to say at the moment what the fix is because that's fairly
> complex low-level Solr code that I think few people understand well.
> Nonetheless I'll look into it further this week.
>

I was writing an additional comment at the moment you commented on the
issue, an additional performance test shows that moving out the
openNewSearcher code from the synchronized block results in nearly the same
performance boost.
But removing this critical code section, if not needed, would be better, as
there are no side effects on the UpdateLog


>
> > Indexing performance is unacceptable when child documents are involved
> > --
> >
> > Key: SOLR-14923
> > URL: https://issues.apache.org/jira/browse/SOLR-14923
> > Project: Solr
> >  Issue Type: Bug
> >  Security Level: Public(Default Security Level. Issues are Public)
> >  Components: update, UpdateRequestProcessors
> >Affects Versions: master (9.0), 8.3, 8.4, 8.5, 8.6
> >Reporter: Thomas Wöckinger
> >Priority: Critical
> >  Labels: performance
> >
> > Parallel indexing does not make sense at moment when child documents are
> used.
> > The org.apache.solr.update.processor.DistributedUpdateProcessor checks
> at the end of the method doVersionAdd if Ulog caches should be refreshed.
> > This check will return true if any child document is included in the
> AddUpdateCommand.
> > If so ulog.openRealtimeSearcher(); is called, this call is very
> expensive, and executed in a synchronized block of the UpdateLog instance,
> therefore all other operations on the UpdateLog are blocked too.
> > Because every important UpdateLog method (add, delete, ...) is done
> using a synchronized block almost each operation is blocked.
> > This reduces multi threaded index update to a single thread behavior.
> > The described behavior is not depending on any option of the
> UpdateRequest, so it does not make any difference if 'waitFlush',
> 'waitSearcher' or 'softCommit'  is true or false.
> > The described behavior makes the usage of ChildDocuments useless,
> because the performance is unacceptable.
> >
> >
>
>
>
> --
> This message was sent by Atlassian Jira
> (v8.3.4#803005)
>
> -
> To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
> For additional commands, e-mail: issues-h...@lucene.apache.org
>
>

Re: 8.7 Release

[Atri Sharma]

Adrien,

Sorry for the delay in response.

I will cut the branch this Friday morning (IST).

Atri

On Tue, 13 Oct 2020 at 05:43, Houston Putman 
wrote:

> Adrien, I plan on merging SOLR-14907
>  to master and 8x
> tomorrow. If you would mind waiting to cut 8.7 until then, I would
> appreciate it.
>
> - Houston
>
> On Mon, Oct 12, 2020 at 4:59 AM Adrien Grand  wrote:
>
>> Shall we move forward with 8.7 now that 8.6.3 is out?
>>
>> On Tue, Sep 22, 2020 at 9:32 PM Atri Sharma  wrote:
>>
>>> I plan to cut the branch on 30th September.
>>>
>>> On Wed, 23 Sep 2020 at 00:51, Cassandra Targett 
>>> wrote:
>>>












 Atri,





 Just so I understand your plans, when you say you are planning to start
 the process at the end of this month, you mean you intend to create the
 branch around Oct 1? No pressure, I ask only because Ishan’s original mail
 mentioned cutting the branch this week and I just wanted to have a clearer
 sense of your timeline.





 Thanks,


 Cassandra




 On Sep 15, 2020, 11:53 PM -0500, Atri Sharma , wrote:




 I was planning to start the process end of this month.







 On Wed, 16 Sep 2020 at 04:07, Gus Heck  wrote:



>
> Unless it somehow got lost in a spam filter somewhere, I don't think
> we have set a target date for the release yet? (roadmap says autumn 2020
> which technically doesn't begin until the solstice on the 21st :) )
>
>
>
>
> Hoping that I might still get the Advanced Query parser in first, but
> that's a much bigger prospect than these two tickets.
>
>
>
>
>
>
>
>
>
> -Gus
>
>
>
>
>
>
>
>
>
> On Tue, Sep 15, 2020 at 5:29 PM Erik Hatcher 
> wrote:
>
>
>
>>
>> Unless there are objections, I'm gonna get
>> https://issues.apache.org/jira/browse/SOLR-14799 into 8.7 as well.
>>
>>
>>
>>
>> Erik
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Sep 14, 2020, at 10:06 AM, Christine Poerschke (BLOOMBERG/ LONDON)
>>  wrote:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> With a view towards including it in the release, I'd appreciate input
>> on the
>>
>>
>>
>>
>> https://issues.apache.org/jira/browse/SOLR-14828
>>
>>
>>
>>
>>
>> solrj logging tweak if anyone has a moment?
>>
>>
>>
>>
>> Thanks,
>>
>>
>> Christine
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> From: dev@lucene.apache.org At: 08/20/20 22:48:39
>>
>>
>> To: dev@lucene.apache.org
>>
>>
>> Subject: Re: 8.7 Release
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Also, we should try to respect the stuff we have put on the roadmap
>> (Which includes me getting a patch up for SIP-9 much sooner rather than
>> even a little later!)
>>
>>
>>
>>
>>
>>
>>
>> On Thu, Aug 20, 2020 at 5:18 PM Adrien Grand 
>> wrote:
>>
>>
>>
>>>
>>> Thanks for the explanation Ishan.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Aug 20, 2020 at 10:33 PM Ishan Chattopadhyaya <
>>> ichattopadhy...@gmail.com> wrote:
>>>
>>>
>>>



 Hi Adrien,


 I think I am mainly concerned about getting the configuration and
 modularity of this right before we release:
 https://issues.apache.org/jira/browse/SOLR-14588.


 If we aren't able to resolve it, we should revert that feature.





 There may be some other performance issues that may have been
 marked as blockers just to infuse a sense of urgency among those that 
 need
 to fix it. But, I wouldn't consider them something that actually holds 
 up a
 release.


 Regards,


 Ishan









 On Fri, Aug 21, 2020 at 1:56 AM Adrien Grand 
 wrote:



>
> Noble, I'm curious what blockers you have in mind. I just checked
> JIRA, and while I see a number of 9.0 blockers, I'm not counting many 
> 8.7
> blockers?
>
>
>
>
>
>
>
> On Thu, Aug 20, 2020 at 11:13 AM Noble Paul 
> wrote:
>
>
> There are a lot of blockers for 8.7. It's good to plan in advance
>>
>>
>>