[
https://issues.apache.org/jira/browse/SOLR-17667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17928175#comment-17928175
]
Houston Putman commented on SOLR-17667:
---------------------------------------
Note, I added a small commit to make debug logging a lot less verbose, because
it looks like the errors stem from the Solr node taking over 10 seconds to come
online. Probably GC pressure, and the only reason I can come up with is the
LogListener. Hopefully adding the "debug(LBSolrClient)", and thus vastly
reducing the amount of logs that the LogListener is churning through, will help
in this regard.
The actual zombie server logic only made it to branch_9x, not branch_9_8.
> Simplify and cleanup zombie server logic in LBSolrClient
> --------------------------------------------------------
>
> Key: SOLR-17667
> URL: https://issues.apache.org/jira/browse/SOLR-17667
> Project: Solr
> Issue Type: Improvement
> Components: SolrJ
> Reporter: Houston Putman
> Assignee: Houston Putman
> Priority: Major
> Labels: pull-request-available
> Fix For: 9.9
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Currently the Zombie server logic is quite complex, a list of alive servers
> and a list of zombie servers. When moving servers between these lists, things
> can get lost. Additionally, the logic is different when using a request that
> contains a list of URLS. So zombies can be dropped always in some case, not
> being added back to the alive list.
> It would be easier to have a list of allServers for a client, and a map of
> zombieServers. If the server in allServers is not in the zombieServers map,
> it can be considered alive.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
