[
https://issues.apache.org/jira/browse/SOLR-1044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12678587#action_12678587
]
Yonik Seeley commented on SOLR-1044:
------------------------------------
We're using persistent HTTP connections, so socket creation overhead should not
be much of an issue.
As far as NIO - servlet containers often have NIO connectors (I guess so idle
persistent connections don't take up a thread to listen on them). That handles
the receive-side. On the sender-side, NIO shouldn't matter... all of our
clients need a thread to keep the request context anyway - we really have no
way of using NIO there.
There could be an issue surrounding the number of TCP connections in a large
cluster (that's an orthogonal issue to NIO), but modern OSs seem to handle high
numbers of connections efficiently.... do switches? Or perhaps the real limit
has to do with exhausting port numbers (65536)?
> 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.
