You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by Jack Park <ja...@topicquests.org> on 2013/11/03 21:04:00 UTC

Cloud issue as an issue with SolrJ?

I now have a single ZK running standalone on 2121. On the same CPU, I
have three nodes.

I used a curl to send over two documents, one each to two of the three
nodes in the cloud.  According to a web query, they are both there.

My solrconfig.xml file has a custom update response processor chain
defined thus:

<updateRequestProcessorChain name="harvest" default="true">
      <processor class="solr.RunUpdateProcessorFactory"/>
      <processor
class="org.apache.solr.update.TopicQuestsHarvestProcessFactory">
        <str name="inputField">hello</str>
      </processor>
      <processor class="solr.LogUpdateProcessorFactory"/>
    </updateRequestProcessorChain>

where the added process intercepts a SolrDocument after it is
processed and sends it out as a JSON object to TCP socket listeners.

The instance of SolrJ I have implemented looks like this:

     LBHttpSolrServer sv = new LBHttpSolrServer(solrurla,solrurlb,solrurlc);
    sv.getHttpClient().getParams().setParameter("update.chain",
"update"); // "merge");
       CloudSolrServer server = new CloudSolrServer(zkurl,sv);
    server.setDefaultCollection("collection1");

where the commented-out code would call my "merge" update chain.

In curl tests, /solr/merge?commit=true ... got a jetty error
/solr/merge not found.
When I changed that to /solr/update?commit=true... the document got
indexed. Thus, commenting out "merge" in favor of "update".

In any case (merge, update, or no update.chain setting at all), the
SolrJ implementation fails, typically at a zookeeper.out nio exception
"socket closed by peer".

Rewriting my implementation to this:
       CloudSolrServer server = new CloudSolrServer(zkurl);
       server.setDefaultCollection("collection1");
makes no change in behavior.

Where is the error thrown?

The code to build a doc is this (which reflects my field definitions):

    SolrInputDocument doc = new SolrInputDocument();
       doc.addField( "locator", "doc"+i);
       doc.addField( "label", "document " + i);
       doc.addField( "details", "This is document " + i);
       server.add(doc);

The error is thrown at server.add(doc)

Many thanks in advance for any observations or suggestions.

Cheers
Jack

Re: Cloud issue as an issue with SolrJ?

Posted by Erick Erickson <er...@gmail.com>.
Thanks for closing this off!

Erick


On Sun, Nov 3, 2013 at 8:24 PM, Jack Park <ja...@topicquests.org> wrote:

> Issue resolved, with great thanks to Tim Casey.
> The issue was based on my own poor understanding of the mechanics of
> ZooKeeper. The "host" setting in solr.xml must find the correct value
> and not default to localhost. Simply hard-wiring host to the network
> address of the computer made everything work.
>
>
> On Sun, Nov 3, 2013 at 12:04 PM, Jack Park <ja...@topicquests.org>
> wrote:
> > I now have a single ZK running standalone on 2121. On the same CPU, I
> > have three nodes.
> >
> > I used a curl to send over two documents, one each to two of the three
> > nodes in the cloud.  According to a web query, they are both there.
> >
> > My solrconfig.xml file has a custom update response processor chain
> > defined thus:
> >
> > <updateRequestProcessorChain name="harvest" default="true">
> >       <processor class="solr.RunUpdateProcessorFactory"/>
> >       <processor
> > class="org.apache.solr.update.TopicQuestsHarvestProcessFactory">
> >         <str name="inputField">hello</str>
> >       </processor>
> >       <processor class="solr.LogUpdateProcessorFactory"/>
> >     </updateRequestProcessorChain>
> >
> > where the added process intercepts a SolrDocument after it is
> > processed and sends it out as a JSON object to TCP socket listeners.
> >
> > The instance of SolrJ I have implemented looks like this:
> >
> >      LBHttpSolrServer sv = new
> LBHttpSolrServer(solrurla,solrurlb,solrurlc);
> >     sv.getHttpClient().getParams().setParameter("update.chain",
> > "update"); // "merge");
> >        CloudSolrServer server = new CloudSolrServer(zkurl,sv);
> >     server.setDefaultCollection("collection1");
> >
> > where the commented-out code would call my "merge" update chain.
> >
> > In curl tests, /solr/merge?commit=true ... got a jetty error
> > /solr/merge not found.
> > When I changed that to /solr/update?commit=true... the document got
> > indexed. Thus, commenting out "merge" in favor of "update".
> >
> > In any case (merge, update, or no update.chain setting at all), the
> > SolrJ implementation fails, typically at a zookeeper.out nio exception
> > "socket closed by peer".
> >
> > Rewriting my implementation to this:
> >        CloudSolrServer server = new CloudSolrServer(zkurl);
> >        server.setDefaultCollection("collection1");
> > makes no change in behavior.
> >
> > Where is the error thrown?
> >
> > The code to build a doc is this (which reflects my field definitions):
> >
> >     SolrInputDocument doc = new SolrInputDocument();
> >        doc.addField( "locator", "doc"+i);
> >        doc.addField( "label", "document " + i);
> >        doc.addField( "details", "This is document " + i);
> >        server.add(doc);
> >
> > The error is thrown at server.add(doc)
> >
> > Many thanks in advance for any observations or suggestions.
> >
> > Cheers
> > Jack
>

Re: Cloud issue as an issue with SolrJ?

Posted by Jack Park <ja...@topicquests.org>.
Issue resolved, with great thanks to Tim Casey.
The issue was based on my own poor understanding of the mechanics of
ZooKeeper. The "host" setting in solr.xml must find the correct value
and not default to localhost. Simply hard-wiring host to the network
address of the computer made everything work.


On Sun, Nov 3, 2013 at 12:04 PM, Jack Park <ja...@topicquests.org> wrote:
> I now have a single ZK running standalone on 2121. On the same CPU, I
> have three nodes.
>
> I used a curl to send over two documents, one each to two of the three
> nodes in the cloud.  According to a web query, they are both there.
>
> My solrconfig.xml file has a custom update response processor chain
> defined thus:
>
> <updateRequestProcessorChain name="harvest" default="true">
>       <processor class="solr.RunUpdateProcessorFactory"/>
>       <processor
> class="org.apache.solr.update.TopicQuestsHarvestProcessFactory">
>         <str name="inputField">hello</str>
>       </processor>
>       <processor class="solr.LogUpdateProcessorFactory"/>
>     </updateRequestProcessorChain>
>
> where the added process intercepts a SolrDocument after it is
> processed and sends it out as a JSON object to TCP socket listeners.
>
> The instance of SolrJ I have implemented looks like this:
>
>      LBHttpSolrServer sv = new LBHttpSolrServer(solrurla,solrurlb,solrurlc);
>     sv.getHttpClient().getParams().setParameter("update.chain",
> "update"); // "merge");
>        CloudSolrServer server = new CloudSolrServer(zkurl,sv);
>     server.setDefaultCollection("collection1");
>
> where the commented-out code would call my "merge" update chain.
>
> In curl tests, /solr/merge?commit=true ... got a jetty error
> /solr/merge not found.
> When I changed that to /solr/update?commit=true... the document got
> indexed. Thus, commenting out "merge" in favor of "update".
>
> In any case (merge, update, or no update.chain setting at all), the
> SolrJ implementation fails, typically at a zookeeper.out nio exception
> "socket closed by peer".
>
> Rewriting my implementation to this:
>        CloudSolrServer server = new CloudSolrServer(zkurl);
>        server.setDefaultCollection("collection1");
> makes no change in behavior.
>
> Where is the error thrown?
>
> The code to build a doc is this (which reflects my field definitions):
>
>     SolrInputDocument doc = new SolrInputDocument();
>        doc.addField( "locator", "doc"+i);
>        doc.addField( "label", "document " + i);
>        doc.addField( "details", "This is document " + i);
>        server.add(doc);
>
> The error is thrown at server.add(doc)
>
> Many thanks in advance for any observations or suggestions.
>
> Cheers
> Jack