[
https://issues.apache.org/jira/browse/SOLR-1044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12678987#action_12678987
]
Yonik Seeley commented on SOLR-1044:
------------------------------------
bq. An HTTP connection can be re-used only after the request-response is
complete. meanwhile, If there is another request to be fired to the same server
from the same client , a new connection will have to be created.
But the system quickly reaches steady state, right? That new connection will
be persistent and hang around for a while to be reused again when needed.
For a high-fanout distributed search, a more important part might actually be
message parsing (independent of transport used). I think we've done a decent
job with the binary protocol for both CPU and network bandwidth... the actual
requests themselves (hitting the lucene index, doing faceting and highlighting,
retrieving stored fields) should hopefully be the bottleneck.
> Use Hadoop RPC for inter Solr communication
> -------------------------------------------
>
> Key: SOLR-1044
> URL: https://issues.apache.org/jira/browse/SOLR-1044
> Project: Solr
> Issue Type: New Feature
> Components: search
> Reporter: Noble Paul
>
> Solr uses http for distributed search . We can make it a whole lot faster if
> we use an RPC mechanism which is more lightweight/efficient.
> Hadoop RPC looks like a good candidate for this.
> The implementation should just have one protocol. It should follow the Solr's
> idiom of making remote calls . A uri + params +[optional stream(s)] . The
> response can be a stream of bytes.
> To make this work we must make the SolrServer implementation pluggable in
> distributed search. Users should be able to choose between the current
> CommonshttpSolrServer, or a HadoopRpcSolrServer .
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
