[
https://issues.apache.org/jira/browse/SOLR-12642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16587444#comment-16587444
]
Shawn Heisey commented on SOLR-12642:
-------------------------------------
If it won't destroy error reporting, I'm all for multiple threads.
[~shalinmangar] I would expect http/2 to be at least as fast, and have the
potential to be faster, in situations where it can effectively use one TCP
connection for many requests. If it is slower, we probably did something
wrong. But your point is still valid -- we need to try some different
approaches and see what works best.
Keepalive is possible with http 1.1, but still requires multiple connections
for simultaneous work. I do not know if HttpSolrClient is making use of
keepalive.
> SolrCmdDistributor should send updates in batch when use Http2SolrClient?
> -------------------------------------------------------------------------
>
> Key: SOLR-12642
> URL: https://issues.apache.org/jira/browse/SOLR-12642
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Cao Manh Dat
> Priority: Major
>
> In the past, batch updates are sent in a single stream from the leader, the
> replica will create a single thread to parse all the updates. For the
> simplicity of {{SOLR-12605}}, the leader is now sending individual updates to
> replicas, therefore they are now parsing updates in different threads which
> increase the usage of memory and CPU.
> In the past, this is an unacceptable approach, because, for every update, we
> must create different connections to replicas. But with the support of
> HTTP/2, all updates will be sent in a single connection from leader to a
> replica. Therefore the cost is not as high as it used to be.
> On the other hand, sending individual updates will improve the indexing
> performance and better error-handling for failures of a single update in a
> batch.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
