Hmm...this is very strange - there is nothing interesting in any of the logs?
In clusterstate.json, all of the shards have an active state?
There are quite a few of us doing exactly this setup recently, so there must be
something we are missing here...
Any info you can offer might help.
- Mark
On Feb 28, 2012, at 1:00 PM, Matthew Parker wrote:
> Mark,
>
> I got the codebase from the 2/26/2012, and I got the same inconsistent
> results.
>
> I have solr running on four ports 8081-8084
>
> 8081 and 8082 are the leaders for shard 1, and shard 2, respectively
>
> 8083 - is assigned to shard 1
> 8084 - is assigned to shard 2
>
> queries come in and sometime it seems the windows from 8081 and 8083 move
> responding to the query but there are no results.
>
> if the queries run on 8081/8082 or 8081/8084 then results come back ok.
>
> The query is nothing more than: q=*:*
>
> Regards,
>
> Matt
>
>
> On Mon, Feb 27, 2012 at 9:26 PM, Matthew Parker <
> mpar...@apogeeintegration.com> wrote:
>
>> I'll have to check on the commit situation. We have been pushing data from
>> SharePoint the last week or so. Would that somehow block the documents
>> moving between the solr instances?
>>
>> I'll try another version tomorrow. Thanks for the suggestions.
>>
>> On Mon, Feb 27, 2012 at 5:34 PM, Mark Miller <markrmil...@gmail.com>wrote:
>>
>>> Hmmm...all of that looks pretty normal...
>>>
>>> Did a commit somehow fail on the other machine? When you view the stats
>>> for the update handler, are there a lot of pending adds for on of the
>>> nodes? Do the commit counts match across nodes?
>>>
>>> You can also query an individual node with distrib=false to check that.
>>>
>>> If you build is a month old, I'd honestly recommend you try upgrading as
>>> well.
>>>
>>> - Mark
>>>
>>> On Feb 27, 2012, at 3:34 PM, Matthew Parker wrote:
>>>
>>>> Here is most of the cluster state:
>>>>
>>>> Connected to Zookeeper
>>>> localhost:2181, localhost: 2182, localhost:2183
>>>>
>>>> /(v=0 children=7) ""
>>>> /CONFIGS(v=0, children=1)
>>>> /CONFIGURATION(v=0 children=25)
>>>> <<<<< all the configuration files, velocity info, xslt, etc.
>>>>>>>>
>>>> /NODE_STATES(v=0 children=4)
>>>> MACHINE1:8083_SOLR (v=121)"[{"shard_id":"shard1",
>>>> "state":"active","core":"","collection":"collection1","node_name:"..."
>>>> MACHINE1:8082_SOLR (v=101)"[{"shard_id":"shard2",
>>>> "state":"active","core":"","collection":"collection1","node_name:"..."
>>>> MACHINE1:8081_SOLR (v=92)"[{"shard_id":"shard1",
>>>> "state":"active","core":"","collection":"collection1","node_name:"..."
>>>> MACHINE1:8084_SOLR (v=73)"[{"shard_id":"shard2",
>>>> "state":"active","core":"","collection":"collection1","node_name:"..."
>>>> /ZOOKEEPER (v-0 children=1)
>>>> QUOTA(v=0)
>>>>
>>>>
>>> /CLUSTERSTATE.JSON(V=272)"{"collection1":{"shard1":{MACHINE1:8081_solr_":{shard_id":"shard1","leader":"true","..."
>>>> /LIVE_NODES (v=0 children=4)
>>>> MACHINE1:8083_SOLR(ephemeral v=0)
>>>> MACHINE1:8082_SOLR(ephemeral v=0)
>>>> MACHINE1:8081_SOLR(ephemeral v=0)
>>>> MACHINE1:8084_SOLR(ephemeral v=0)
>>>> /COLLECTIONS (v=1 children=1)
>>>> COLLECTION1(v=0 children=2)"{"configName":"configuration1"}"
>>>> LEADER_ELECT(v=0 children=2)
>>>> SHARD1(V=0 children=1)
>>>> ELECTION(v=0 children=2)
>>>>
>>>> 87186203314552835-MACHINE1:8081_SOLR_-N_0000000096(ephemeral v=0)
>>>>
>>>> 87186203314552836-MACHINE1:8083_SOLR_-N_0000000084(ephemeral v=0)
>>>> SHARD2(v=0 children=1)
>>>> ELECTION(v=0 children=2)
>>>>
>>>> 231301391392833539-MACHINE1:8084_SOLR_-N_0000000085(ephemeral v=0)
>>>>
>>>> 159243797356740611-MACHINE1:8082_SOLR_-N_0000000084(ephemeral v=0)
>>>> LEADERS (v=0 children=2)
>>>> SHARD1 (ephemeral
>>>> v=0)"{"core":"","node_name":"MACHINE1:8081_solr","base_url":"
>>>> http://MACHINE1:8081/solr"}";
>>>> SHARD2 (ephemeral
>>>> v=0)"{"core":"","node_name":"MACHINE1:8082_solr","base_url":"
>>>> http://MACHINE1:8082/solr"}";
>>>> /OVERSEER_ELECT (v=0 children=2)
>>>> ELECTION (v=0 children=4)
>>>> 231301391392833539-MACHINE1:8084_SOLR_-N_0000000251(ephemeral
>>> v=0)
>>>> 87186203314552835-MACHINE1:8081_SOLR_-N_0000000248(ephemeral
>>> v=0)
>>>> 159243797356740611-MACHINE1:8082_SOLR_-N_0000000250(ephemeral
>>> v=0)
>>>> 87186203314552836-MACHINE1:8083_SOLR_-N_0000000249(ephemeral
>>> v=0)
>>>> LEADER (emphemeral
>>>> v=0)"{"id":"87186203314552835-MACHINE1:8081_solr-n_000000248"}"
>>>>
>>>>
>>>>
>>>> On Mon, Feb 27, 2012 at 2:47 PM, Mark Miller <markrmil...@gmail.com>
>>> wrote:
>>>>
>>>>>
>>>>> On Feb 27, 2012, at 2:22 PM, Matthew Parker wrote:
>>>>>
>>>>>> Thanks for your reply Mark.
>>>>>>
>>>>>> I believe the build was towards the begining of the month. The
>>>>>> solr.spec.version is 4.0.0.2012.01.10.38.09
>>>>>>
>>>>>> I cannot access the clusterstate.json contents. I clicked on it a
>>> couple
>>>>> of
>>>>>> times, but nothing happens. Is that stored on disk somewhere?
>>>>>
>>>>> Are you using the new admin UI? That has recently been updated to work
>>>>> better with cloud - it had some troubles not too long ago. If you are,
>>> you
>>>>> should trying using the old admin UI's zookeeper page - that should
>>> show
>>>>> the cluster state.
>>>>>
>>>>> That being said, there has been a lot of bug fixes over the past month
>>> -
>>>>> so you may just want to update to a recent version.
>>>>>
>>>>>>
>>>>>> I configured a custom request handler to calculate an unique document
>>> id
>>>>>> based on the file's url.
>>>>>>
>>>>>> On Mon, Feb 27, 2012 at 1:13 PM, Mark Miller <markrmil...@gmail.com>
>>>>> wrote:
>>>>>>
>>>>>>> Hey Matt - is your build recent?
>>>>>>>
>>>>>>> Can you visit the cloud/zookeeper page in the admin and send the
>>>>> contents
>>>>>>> of the clusterstate.json node?
>>>>>>>
>>>>>>> Are you using a custom index chain or anything out of the ordinary?
>>>>>>>
>>>>>>>
>>>>>>> - Mark
>>>>>>>
>>>>>>> On Feb 27, 2012, at 12:26 PM, Matthew Parker wrote:
>>>>>>>
>>>>>>>> TWIMC:
>>>>>>>>
>>>>>>>> Environment
>>>>>>>> =========
>>>>>>>> Apache SOLR rev-1236154
>>>>>>>> Apache Zookeeper 3.3.4
>>>>>>>> Windows 7
>>>>>>>> JDK 1.6.0_23.b05
>>>>>>>>
>>>>>>>> I have built a SOLR Cloud instance with 4 nodes using the embeded
>>> Jetty
>>>>>>>> servers.
>>>>>>>>
>>>>>>>> I created a 3 node zookeeper ensemble to manage the solr
>>> configuration
>>>>>>> data.
>>>>>>>>
>>>>>>>> All the instances run on one server so I've had to move ports around
>>>>> for
>>>>>>>> the various applications.
>>>>>>>>
>>>>>>>> I start the 3 zookeeper nodes.
>>>>>>>>
>>>>>>>> I started the first instance of solr cloud with the parameter to
>>> have
>>>>> two
>>>>>>>> shards.
>>>>>>>>
>>>>>>>> The start the remaining 3 solr nodes.
>>>>>>>>
>>>>>>>> The system comes up fine. No errors thrown.
>>>>>>>>
>>>>>>>> I can view the solr cloud console and I can see the SOLR
>>> configuration
>>>>>>>> files managed by ZooKeeper.
>>>>>>>>
>>>>>>>> I published data into the SOLR Cloud instances from SharePoint using
>>>>>>> Apache
>>>>>>>> Manifold 0.4-incubating. Manifold is setup to publish the data into
>>>>>>>> collection1, which is the only collection defined in the cluster.
>>>>>>>>
>>>>>>>> When I query the data from collection1 as per the solr wiki, the
>>>>> results
>>>>>>>> are inconsistent. Sometimes all the results are there, other times
>>>>>>> nothing
>>>>>>>> comes back at all.
>>>>>>>>
>>>>>>>> It seems to be having an issue auto replicating the data across the
>>>>>>> cloud.
>>>>>>>>
>>>>>>>> Is there some specific setting I might have missed? Based upon what
>>> I
>>>>>>> read,
>>>>>>>> I thought that SOLR cloud would take care of distributing and
>>>>> replicating
>>>>>>>> the data automatically. Do you have to tell it what shard to publish
>>>>> the
>>>>>>>> data into as well?
>>>>>>>>
>>>>>>>> Any help would be appreciated.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Matt
>>>>>>>>
>>>>>>>> ------------------------------
>>>>>>>> This e-mail and any files transmitted with it may be proprietary.
>>>>>>> Please note that any views or opinions presented in this e-mail are
>>>>> solely
>>>>>>> those of the author and do not necessarily represent those of Apogee
>>>>>>> Integration.
>>>>>>>
>>>>>>> - Mark Miller
>>>>>>> lucidimagination.com
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Matt
>>>>>>
>>>>>> ------------------------------
>>>>>> This e-mail and any files transmitted with it may be proprietary.
>>>>> Please note that any views or opinions presented in this e-mail are
>>> solely
>>>>> those of the author and do not necessarily represent those of Apogee
>>>>> Integration.
>>>>>
>>>>> - Mark Miller
>>>>> lucidimagination.com
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> ------------------------------
>>>> This e-mail and any files transmitted with it may be proprietary.
>>> Please note that any views or opinions presented in this e-mail are solely
>>> those of the author and do not necessarily represent those of Apogee
>>> Integration.
>>>
>>> - Mark Miller
>>> lucidimagination.com
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
> ------------------------------
> This e-mail and any files transmitted with it may be proprietary. Please
> note that any views or opinions presented in this e-mail are solely those of
> the author and do not necessarily represent those of Apogee Integration.
- Mark Miller
lucidimagination.com
