It's on our roadmap:
https://cwiki.apache.org/confluence/display/SOLR/Roadmap
and I created an "umbrella" JIRA issue with most issues I could think of,
some minor or tangential/complementary:
https://issues.apache.org/jira/browse/SOLR-17605
I could create a SIP but it feels redundant. Maybe a SIP
The current implementation removes non live nodes from the set of
nodes to connect to. Getting the live nodes requires connecting to a
specific node in the cluster that is therefore live when that happens.
Worst case, if there is a single node up in the cluster, the client
ends with a single node i
Hi!
I'm all for (eventually) nudging folks towards HttpCSP. It's a "Good
Thing", conceptually, to hide ZK!
But it sounds like there are still some significant (if few) downsides
to using HttpCSP (the "all live nodes disappear" case being the
biggest, to my mind). IMO we should close the more sig
On Thu, Oct 24, 2024 at 9:07 AM Jason Gerlowski
wrote:
> Hi!
>
> I'm all for (eventually) nudging folks towards HttpCSP. It's a "Good
> Thing", conceptually, to hide ZK!
>
> But it sounds like there are still some significant (if few) downsides
> to using HttpCSP (the "all live nodes disappear"
I strongly believe that we need to get ZooKeeper out of our clients (that
use CloudSolrClient), and use Solr URLs (HTTP) for the cluster state
instead. I'm arguing to make this strategic direction clear, and we're
already going in the right direction. Realistically, I don't think
solrj-zookeeper