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
