[
https://issues.apache.org/jira/browse/SOLR-1044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12679061#action_12679061
]
Noble Paul commented on SOLR-1044:
----------------------------------
bq.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.
the system reaches a steady state where the no:of connections would be slightly
greater than the maximum no:of parallel requests. whereas a system using a
message based RPC will still have only a single connection between 2 Solrs.
bq.For a high-fanout distributed search, a more important part might actually
be message parsing (independent of transport used)
As Solr move towards other applications such as mapreduce/mahout where the
operations do not involve disk IO and where the payload is small there can be a
problem.
My tests with hadoop RPC showed it outperforming tomcat when I used a small
payload (5 bytes)
> 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.
