Re: Community over Code Apache Solr Hackathon

[Alessandro Benedetti]

I'll be there!
Cheers

On Fri, 6 Oct 2023, 21:52 Ishan Chattopadhyaya, 
wrote:

> Sounds great, looking forward to the zookeeper quorum experiments! Sooner
> we get that to work, the closer we get to axing the standalone mode. All
> the best..
>
> On Sat, 7 Oct, 2023, 1:19 am Eric Pugh, 
> wrote:
>
> > Folks headed to Halifax….   Jason and I have talked about hacking
> together
> > on Solr during the conference.   Well, Good News!  I’ve got us a room,
> > thanks to Brian Proffitt's help, to use on Sunday (the day after the
> Search
> > Track).  When you check the conference schedule you should see it show
> up.
> >
> > Room 107 on Sunday from 10:25-18:30.
> >
> > Jason G and I are planning on spiking out what it would take to fire up a
> > Solr cloud node with the role “zookeeper” and see if we can build a
> quorum
> > ;-).   Other things that would be interesting is to show folks who aren’t
> > deep in Solr code how to build Solr, how to write tests.If we are
> super
> > energetic, maybe I can talk folks like Jeff Zemerick from OpenNLP
> community
> > to work with us in loading models into Solr via ONNX ;-).  So basically,
> > anything anyone wants to work on ;-).
> >
> > So please come join us in Room 107 on Sunday!
> >
> > Eric
> > ___
> > Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 |
> > http://www.opensourceconnections.com <
> > http://www.opensourceconnections.com/> | My Free/Busy <
> > http://tinyurl.com/eric-cal>
> > Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <
> >
> https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw
> >
> >
> > This e-mail and all contents, including attachments, is considered to be
> > Company Confidential unless explicitly stated otherwise, regardless of
> > whether attachments are marked as such.
> >
> >
>

Re: Issue with marking replicas down at startup

[Mark Miller]

Yeah, it’s not going to fix that updates can come in too early if you just
delay when the replica publishes active. It’s still going to show up active
when it’s not. That gets rectified if you end up replicating the index,
it’s when you peer sync that it can be a persistent problem. And in both
cases, you can end up with a window of incorrect queries.

The most straightforward way to handle it is to use the cluster state
rather than the cores from the core container when publishing down (where
it doesn’t currently use the downnode command) and when waiting to see the
state.