On Sep 18, 2009, at 1:09 AM, rajan chandi wrote:
We are planning to use the external Solr on tomcat for scalability
reasons.
We thought that EmbeddedSolrServer uses HTTP too to talk with Ruby and
vise-versa as in acts_as_solr ruby plugin.
EmbeddedSolrServer is a way to run Solr as an API (like Lucene) rather
than with any web container involved at all. In other words, only
Java can use EmbeddedSolrServer (which means JRuby works great).
The acts_as_solr plugin uses the solr-ruby library to communicate with
Solr. Under solr-ruby, it's HTTP with ruby (wt=ruby) formatted
responses for searches, and documents being indexed get converted to
Solr's XML format and POSTed to the Solr URL used to open the
Solr::Connection
Erik
If Ruby is not using the HTTP to talk EmbeddedSolrServer, what is it
using?
Thanks and Regards
Rajan Chandi
On Thu, Sep 17, 2009 at 9:44 PM, Erik Hatcher
<erik.hatc...@gmail.com>wrote:
On Sep 17, 2009, at 11:40 AM, Ian Connor wrote:
Is there any support for connection pooling or a more optimized data
exchange format?
The solr-ruby library (as do other Solr + Ruby libraries) use the
ruby
response format and eval it. solr-ruby supports keeping the HTTP
connection
alive too.
We are looking at any further ways to optimize the solr
queries so we can possibly make more of them in the one request.
The JSON like format seems pretty tight but I understand when the
distributed search takes place it uses a binary protocol instead
of text.
I
wanted to know if that was available or could be available via the
ruby
library.
Is it possible to host a local shard and skip HTTP between ruby
and solr?
If you use JRuby you can do some fancy stuff, like use the javabin
update
and response formats so no XML is involved, and you could also use
Solr's
EmbeddedSolrServer to avoid HTTP. However, in practice rarely is
HTTP the
bottleneck and actually offers a lot of advantages, such as easy
commodity
load balancing and caching.
But JRuby + Solr is a very beautiful way to go!
If you're using MRI Ruby, though, you don't really have any options
other
than to go over HTTP. You could use json or ruby formatted
responses - I'd
be curious to see some performance numbers comparing those two.
Erik
