You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Erick Erickson (Created) (JIRA)" <ji...@apache.org> on 2012/04/19 01:10:41 UTC
[jira] [Created] (SOLR-3376) SolrCloud: Specifying shardId not
working correctly, although the failures are inconsistent.
SolrCloud: Specifying shardId not working correctly, although the failures are inconsistent.
--------------------------------------------------------------------------------------------
Key: SOLR-3376
URL: https://issues.apache.org/jira/browse/SOLR-3376
Project: Solr
Issue Type: Bug
Components: SolrCloud
Affects Versions: 4.0
Reporter: Erick Erickson
I'm seeing some odd results when specifying "shardId" parameter. I'm trying the 4-node, 2-shard example from the Wiki and specifying shardIds like this:
dir shardId start order runnng ZK port
example 1 1 y 8983
example2 2 2 y 7574
example3 1 3 y 8900
example4 2 4 y 7500
And I'm waiting a bit between starting various examples to let ZK settle down.
Once all of them are started, I was looking at http://localhost:8983/solr/#/~cloud?view=graph to check out what that looks like (pretty cool IMO, especially since I didn't have to do it). The problem was that shard 2 only reported a single instance, while shard1 showed the two instances I was expecting. I'm running with 3 embedded ZK instances, just for yucks. Interestingly the node that didn't show up was the only node that was NOT running ZK.
When I removed all the "shardId" parameters, nuked zoo_data from all directories and just started them up (with numShards=2 on the bootstrap ZK node), all 4 nodes showed up just fine.
When starting with shardId specified and trying to go straight to the admin interface on the node that wasn't showing up, I'd get odd errors like "This interface requires that you activate the admin request handlers, add the following configuration to your solrconfig.xml:". I also couldn't search directly on that machine, "http://localhost:7574/solr/select?q=*:*" returns a 404 error.
Command starting server that's giving me trouble: java -Xmx1G -Djetty.port=7500 -DzkHost=localhost:9983,localhost:8574,localhost:9900 -DshardId=2 -jar start.jar
Command for one that works fine: java -Xmx1G -Djetty.port=8900 -DzkRun -DzkHost=localhost:9983,localhost:8574,localhost:9900 -DshardId=1 -jar start.jar
Sami Siren and he reports similar issues via e-mail conversation. Sami says that ZK 3.5 apparently (without exhaustive tests) fixed the problem for him, but when I tried ZK 3.5 I saw the same issue. Of course with all the recent stuff with Ivy, I may have screwed up when/where the JARs were.
So then I went back to ZK 3.4 and couldn't reproduce the problem. Which seems highly suspicious to me. It was failing every time before with 3.4, so it sounds like gremlins.
And then I re-did the stuff with ZK 3.5 and it works fine there too now. Siiiiggggh. Mostly this is a placeholder to insure we try this, I guarantee that sys admins will want to assign specific machines to specific shards, so this'll get used.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
[jira] [Commented] (SOLR-3376) SolrCloud: Specifying shardId not
working correctly, although the failures are inconsistent.
Posted by "Robert Muir (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-3376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13457908#comment-13457908 ]
Robert Muir commented on SOLR-3376:
-----------------------------------
Is this still a problem now that zookeeper has been upgraded?
> SolrCloud: Specifying shardId not working correctly, although the failures are inconsistent.
> --------------------------------------------------------------------------------------------
>
> Key: SOLR-3376
> URL: https://issues.apache.org/jira/browse/SOLR-3376
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
> Reporter: Erick Erickson
> Assignee: Sami Siren
> Fix For: 4.0
>
>
> I'm seeing some odd results when specifying "shardId" parameter. I'm trying the 4-node, 2-shard example from the Wiki and specifying shardIds like this:
> dir shardId start order runnng ZK port
> example 1 1 y 8983
> example2 2 2 y 7574
> example3 1 3 y 8900
> example4 2 4 y 7500
> And I'm waiting a bit between starting various examples to let ZK settle down.
> Once all of them are started, I was looking at http://localhost:8983/solr/#/~cloud?view=graph to check out what that looks like (pretty cool IMO, especially since I didn't have to do it). The problem was that shard 2 only reported a single instance, while shard1 showed the two instances I was expecting. I'm running with 3 embedded ZK instances, just for yucks. Interestingly the node that didn't show up was the only node that was NOT running ZK.
> When I removed all the "shardId" parameters, nuked zoo_data from all directories and just started them up (with numShards=2 on the bootstrap ZK node), all 4 nodes showed up just fine.
> When starting with shardId specified and trying to go straight to the admin interface on the node that wasn't showing up, I'd get odd errors like "This interface requires that you activate the admin request handlers, add the following configuration to your solrconfig.xml:". I also couldn't search directly on that machine, "http://localhost:7574/solr/select?q=*:*" returns a 404 error.
> Command starting server that's giving me trouble: java -Xmx1G -Djetty.port=7500 -DzkHost=localhost:9983,localhost:8574,localhost:9900 -DshardId=2 -jar start.jar
> Command for one that works fine: java -Xmx1G -Djetty.port=8900 -DzkRun -DzkHost=localhost:9983,localhost:8574,localhost:9900 -DshardId=1 -jar start.jar
> Sami Siren and he reports similar issues via e-mail conversation. Sami says that ZK 3.3.5 apparently (without exhaustive tests) fixed the problem for him, but when I tried ZK 3.3.5 I saw the same issue. Of course with all the recent stuff with Ivy, I may have screwed up when/where the JARs were.
> So then I went back to ZK 3.3.4 and couldn't reproduce the problem. Which seems highly suspicious to me. It was failing every time before with 3.3.4, so it sounds like gremlins.
> And then I tried ZK 3.3.5 again (changed the ivy.xml in solrj, blew away the ZK 3.3.4, rebuilt, removed zoo_data, recopied example to three other directories) and it works fine there too now. Siiiiggggh. Mostly this is a placeholder to insure we try this, I guarantee that sys admins will want to assign specific machines to specific shards, so this'll get used.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
[jira] [Updated] (SOLR-3376) SolrCloud: Specifying shardId not
working correctly, although the failures are inconsistent.
Posted by "Erick Erickson (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-3376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Erick Erickson updated SOLR-3376:
---------------------------------
Description:
I'm seeing some odd results when specifying "shardId" parameter. I'm trying the 4-node, 2-shard example from the Wiki and specifying shardIds like this:
dir shardId start order runnng ZK port
example 1 1 y 8983
example2 2 2 y 7574
example3 1 3 y 8900
example4 2 4 y 7500
And I'm waiting a bit between starting various examples to let ZK settle down.
Once all of them are started, I was looking at http://localhost:8983/solr/#/~cloud?view=graph to check out what that looks like (pretty cool IMO, especially since I didn't have to do it). The problem was that shard 2 only reported a single instance, while shard1 showed the two instances I was expecting. I'm running with 3 embedded ZK instances, just for yucks. Interestingly the node that didn't show up was the only node that was NOT running ZK.
When I removed all the "shardId" parameters, nuked zoo_data from all directories and just started them up (with numShards=2 on the bootstrap ZK node), all 4 nodes showed up just fine.
When starting with shardId specified and trying to go straight to the admin interface on the node that wasn't showing up, I'd get odd errors like "This interface requires that you activate the admin request handlers, add the following configuration to your solrconfig.xml:". I also couldn't search directly on that machine, "http://localhost:7574/solr/select?q=*:*" returns a 404 error.
Command starting server that's giving me trouble: java -Xmx1G -Djetty.port=7500 -DzkHost=localhost:9983,localhost:8574,localhost:9900 -DshardId=2 -jar start.jar
Command for one that works fine: java -Xmx1G -Djetty.port=8900 -DzkRun -DzkHost=localhost:9983,localhost:8574,localhost:9900 -DshardId=1 -jar start.jar
Sami Siren and he reports similar issues via e-mail conversation. Sami says that ZK 3.3.5 apparently (without exhaustive tests) fixed the problem for him, but when I tried ZK 3.3.5 I saw the same issue. Of course with all the recent stuff with Ivy, I may have screwed up when/where the JARs were.
So then I went back to ZK 3.3.4 and couldn't reproduce the problem. Which seems highly suspicious to me. It was failing every time before with 3.3.4, so it sounds like gremlins.
And then I tried ZK 3.3.5 again (changed the ivy.xml in solrj, blew away the ZK 3.3.4, rebuilt, removed zoo_data, recopied example to three other directories) and it works fine there too now. Siiiiggggh. Mostly this is a placeholder to insure we try this, I guarantee that sys admins will want to assign specific machines to specific shards, so this'll get used.
was:
I'm seeing some odd results when specifying "shardId" parameter. I'm trying the 4-node, 2-shard example from the Wiki and specifying shardIds like this:
{{{
dir shardId start order runnng ZK port
example 1 1 y 8983
example2 2 2 y 7574
example3 1 3 y 8900
example4 2 4 y 7500
}}}
And I'm waiting a bit between starting various examples to let ZK settle down.
Once all of them are started, I was looking at http://localhost:8983/solr/#/~cloud?view=graph to check out what that looks like (pretty cool IMO, especially since I didn't have to do it). The problem was that shard 2 only reported a single instance, while shard1 showed the two instances I was expecting. I'm running with 3 embedded ZK instances, just for yucks. Interestingly the node that didn't show up was the only node that was NOT running ZK.
When I removed all the "shardId" parameters, nuked zoo_data from all directories and just started them up (with numShards=2 on the bootstrap ZK node), all 4 nodes showed up just fine.
When starting with shardId specified and trying to go straight to the admin interface on the node that wasn't showing up, I'd get odd errors like "This interface requires that you activate the admin request handlers, add the following configuration to your solrconfig.xml:". I also couldn't search directly on that machine, "http://localhost:7574/solr/select?q=*:*" returns a 404 error.
Command starting server that's giving me trouble: java -Xmx1G -Djetty.port=7500 -DzkHost=localhost:9983,localhost:8574,localhost:9900 -DshardId=2 -jar start.jar
Command for one that works fine: java -Xmx1G -Djetty.port=8900 -DzkRun -DzkHost=localhost:9983,localhost:8574,localhost:9900 -DshardId=1 -jar start.jar
Sami Siren and he reports similar issues via e-mail conversation. Sami says that ZK 3.3.5 apparently (without exhaustive tests) fixed the problem for him, but when I tried ZK 3.3.5 I saw the same issue. Of course with all the recent stuff with Ivy, I may have screwed up when/where the JARs were.
So then I went back to ZK 3.3.4 and couldn't reproduce the problem. Which seems highly suspicious to me. It was failing every time before with 3.3.4, so it sounds like gremlins.
And then I tried ZK 3.3.5 again (changed the ivy.xml in solrj, blew away the ZK 3.3.4, rebuilt, removed zoo_data, recopied example to three other directories) and it works fine there too now. Siiiiggggh. Mostly this is a placeholder to insure we try this, I guarantee that sys admins will want to assign specific machines to specific shards, so this'll get used.
> SolrCloud: Specifying shardId not working correctly, although the failures are inconsistent.
> --------------------------------------------------------------------------------------------
>
> Key: SOLR-3376
> URL: https://issues.apache.org/jira/browse/SOLR-3376
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
> Affects Versions: 4.0
> Reporter: Erick Erickson
>
> I'm seeing some odd results when specifying "shardId" parameter. I'm trying the 4-node, 2-shard example from the Wiki and specifying shardIds like this:
> dir shardId start order runnng ZK port
> example 1 1 y 8983
> example2 2 2 y 7574
> example3 1 3 y 8900
> example4 2 4 y 7500
> And I'm waiting a bit between starting various examples to let ZK settle down.
> Once all of them are started, I was looking at http://localhost:8983/solr/#/~cloud?view=graph to check out what that looks like (pretty cool IMO, especially since I didn't have to do it). The problem was that shard 2 only reported a single instance, while shard1 showed the two instances I was expecting. I'm running with 3 embedded ZK instances, just for yucks. Interestingly the node that didn't show up was the only node that was NOT running ZK.
> When I removed all the "shardId" parameters, nuked zoo_data from all directories and just started them up (with numShards=2 on the bootstrap ZK node), all 4 nodes showed up just fine.
> When starting with shardId specified and trying to go straight to the admin interface on the node that wasn't showing up, I'd get odd errors like "This interface requires that you activate the admin request handlers, add the following configuration to your solrconfig.xml:". I also couldn't search directly on that machine, "http://localhost:7574/solr/select?q=*:*" returns a 404 error.
> Command starting server that's giving me trouble: java -Xmx1G -Djetty.port=7500 -DzkHost=localhost:9983,localhost:8574,localhost:9900 -DshardId=2 -jar start.jar
> Command for one that works fine: java -Xmx1G -Djetty.port=8900 -DzkRun -DzkHost=localhost:9983,localhost:8574,localhost:9900 -DshardId=1 -jar start.jar
> Sami Siren and he reports similar issues via e-mail conversation. Sami says that ZK 3.3.5 apparently (without exhaustive tests) fixed the problem for him, but when I tried ZK 3.3.5 I saw the same issue. Of course with all the recent stuff with Ivy, I may have screwed up when/where the JARs were.
> So then I went back to ZK 3.3.4 and couldn't reproduce the problem. Which seems highly suspicious to me. It was failing every time before with 3.3.4, so it sounds like gremlins.
> And then I tried ZK 3.3.5 again (changed the ivy.xml in solrj, blew away the ZK 3.3.4, rebuilt, removed zoo_data, recopied example to three other directories) and it works fine there too now. Siiiiggggh. Mostly this is a placeholder to insure we try this, I guarantee that sys admins will want to assign specific machines to specific shards, so this'll get used.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
[jira] [Assigned] (SOLR-3376) SolrCloud: Specifying shardId not
working correctly, although the failures are inconsistent.
Posted by "Hoss Man (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-3376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Hoss Man reassigned SOLR-3376:
------------------------------
Assignee: Sami Siren
Assigning to Sami to triage since Erick mentioned that Sami had confirmed he could reproduce this at one point, and then fixed it by upgrading ZK.
Sami: please update with comments or resolve if you know that this is no longer an issue.
> SolrCloud: Specifying shardId not working correctly, although the failures are inconsistent.
> --------------------------------------------------------------------------------------------
>
> Key: SOLR-3376
> URL: https://issues.apache.org/jira/browse/SOLR-3376
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
> Reporter: Erick Erickson
> Assignee: Sami Siren
> Fix For: 4.0
>
>
> I'm seeing some odd results when specifying "shardId" parameter. I'm trying the 4-node, 2-shard example from the Wiki and specifying shardIds like this:
> dir shardId start order runnng ZK port
> example 1 1 y 8983
> example2 2 2 y 7574
> example3 1 3 y 8900
> example4 2 4 y 7500
> And I'm waiting a bit between starting various examples to let ZK settle down.
> Once all of them are started, I was looking at http://localhost:8983/solr/#/~cloud?view=graph to check out what that looks like (pretty cool IMO, especially since I didn't have to do it). The problem was that shard 2 only reported a single instance, while shard1 showed the two instances I was expecting. I'm running with 3 embedded ZK instances, just for yucks. Interestingly the node that didn't show up was the only node that was NOT running ZK.
> When I removed all the "shardId" parameters, nuked zoo_data from all directories and just started them up (with numShards=2 on the bootstrap ZK node), all 4 nodes showed up just fine.
> When starting with shardId specified and trying to go straight to the admin interface on the node that wasn't showing up, I'd get odd errors like "This interface requires that you activate the admin request handlers, add the following configuration to your solrconfig.xml:". I also couldn't search directly on that machine, "http://localhost:7574/solr/select?q=*:*" returns a 404 error.
> Command starting server that's giving me trouble: java -Xmx1G -Djetty.port=7500 -DzkHost=localhost:9983,localhost:8574,localhost:9900 -DshardId=2 -jar start.jar
> Command for one that works fine: java -Xmx1G -Djetty.port=8900 -DzkRun -DzkHost=localhost:9983,localhost:8574,localhost:9900 -DshardId=1 -jar start.jar
> Sami Siren and he reports similar issues via e-mail conversation. Sami says that ZK 3.3.5 apparently (without exhaustive tests) fixed the problem for him, but when I tried ZK 3.3.5 I saw the same issue. Of course with all the recent stuff with Ivy, I may have screwed up when/where the JARs were.
> So then I went back to ZK 3.3.4 and couldn't reproduce the problem. Which seems highly suspicious to me. It was failing every time before with 3.3.4, so it sounds like gremlins.
> And then I tried ZK 3.3.5 again (changed the ivy.xml in solrj, blew away the ZK 3.3.4, rebuilt, removed zoo_data, recopied example to three other directories) and it works fine there too now. Siiiiggggh. Mostly this is a placeholder to insure we try this, I guarantee that sys admins will want to assign specific machines to specific shards, so this'll get used.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
[jira] [Updated] (SOLR-3376) SolrCloud: Specifying shardId not
working correctly, although the failures are inconsistent.
Posted by "Mark Miller (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-3376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mark Miller updated SOLR-3376:
------------------------------
Affects Version/s: (was: 4.0)
Fix Version/s: 4.0
> SolrCloud: Specifying shardId not working correctly, although the failures are inconsistent.
> --------------------------------------------------------------------------------------------
>
> Key: SOLR-3376
> URL: https://issues.apache.org/jira/browse/SOLR-3376
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
> Reporter: Erick Erickson
> Fix For: 4.0
>
>
> I'm seeing some odd results when specifying "shardId" parameter. I'm trying the 4-node, 2-shard example from the Wiki and specifying shardIds like this:
> dir shardId start order runnng ZK port
> example 1 1 y 8983
> example2 2 2 y 7574
> example3 1 3 y 8900
> example4 2 4 y 7500
> And I'm waiting a bit between starting various examples to let ZK settle down.
> Once all of them are started, I was looking at http://localhost:8983/solr/#/~cloud?view=graph to check out what that looks like (pretty cool IMO, especially since I didn't have to do it). The problem was that shard 2 only reported a single instance, while shard1 showed the two instances I was expecting. I'm running with 3 embedded ZK instances, just for yucks. Interestingly the node that didn't show up was the only node that was NOT running ZK.
> When I removed all the "shardId" parameters, nuked zoo_data from all directories and just started them up (with numShards=2 on the bootstrap ZK node), all 4 nodes showed up just fine.
> When starting with shardId specified and trying to go straight to the admin interface on the node that wasn't showing up, I'd get odd errors like "This interface requires that you activate the admin request handlers, add the following configuration to your solrconfig.xml:". I also couldn't search directly on that machine, "http://localhost:7574/solr/select?q=*:*" returns a 404 error.
> Command starting server that's giving me trouble: java -Xmx1G -Djetty.port=7500 -DzkHost=localhost:9983,localhost:8574,localhost:9900 -DshardId=2 -jar start.jar
> Command for one that works fine: java -Xmx1G -Djetty.port=8900 -DzkRun -DzkHost=localhost:9983,localhost:8574,localhost:9900 -DshardId=1 -jar start.jar
> Sami Siren and he reports similar issues via e-mail conversation. Sami says that ZK 3.3.5 apparently (without exhaustive tests) fixed the problem for him, but when I tried ZK 3.3.5 I saw the same issue. Of course with all the recent stuff with Ivy, I may have screwed up when/where the JARs were.
> So then I went back to ZK 3.3.4 and couldn't reproduce the problem. Which seems highly suspicious to me. It was failing every time before with 3.3.4, so it sounds like gremlins.
> And then I tried ZK 3.3.5 again (changed the ivy.xml in solrj, blew away the ZK 3.3.4, rebuilt, removed zoo_data, recopied example to three other directories) and it works fine there too now. Siiiiggggh. Mostly this is a placeholder to insure we try this, I guarantee that sys admins will want to assign specific machines to specific shards, so this'll get used.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
[jira] [Updated] (SOLR-3376) SolrCloud: Specifying shardId not
working correctly, although the failures are inconsistent.
Posted by "Erick Erickson (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-3376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Erick Erickson updated SOLR-3376:
---------------------------------
Description:
I'm seeing some odd results when specifying "shardId" parameter. I'm trying the 4-node, 2-shard example from the Wiki and specifying shardIds like this:
dir shardId start order runnng ZK port
example 1 1 y 8983
example2 2 2 y 7574
example3 1 3 y 8900
example4 2 4 y 7500
And I'm waiting a bit between starting various examples to let ZK settle down.
Once all of them are started, I was looking at http://localhost:8983/solr/#/~cloud?view=graph to check out what that looks like (pretty cool IMO, especially since I didn't have to do it). The problem was that shard 2 only reported a single instance, while shard1 showed the two instances I was expecting. I'm running with 3 embedded ZK instances, just for yucks. Interestingly the node that didn't show up was the only node that was NOT running ZK.
When I removed all the "shardId" parameters, nuked zoo_data from all directories and just started them up (with numShards=2 on the bootstrap ZK node), all 4 nodes showed up just fine.
When starting with shardId specified and trying to go straight to the admin interface on the node that wasn't showing up, I'd get odd errors like "This interface requires that you activate the admin request handlers, add the following configuration to your solrconfig.xml:". I also couldn't search directly on that machine, "http://localhost:7574/solr/select?q=*:*" returns a 404 error.
Command starting server that's giving me trouble: java -Xmx1G -Djetty.port=7500 -DzkHost=localhost:9983,localhost:8574,localhost:9900 -DshardId=2 -jar start.jar
Command for one that works fine: java -Xmx1G -Djetty.port=8900 -DzkRun -DzkHost=localhost:9983,localhost:8574,localhost:9900 -DshardId=1 -jar start.jar
Sami Siren and he reports similar issues via e-mail conversation. Sami says that ZK 3.3.5 apparently (without exhaustive tests) fixed the problem for him, but when I tried ZK 3.3.5 I saw the same issue. Of course with all the recent stuff with Ivy, I may have screwed up when/where the JARs were.
So then I went back to ZK 3.3.4 and couldn't reproduce the problem. Which seems highly suspicious to me. It was failing every time before with 3.3.4, so it sounds like gremlins.
And then I tried ZK 3.3.5 again (changed the ivy.xml in solrj, blew away the ZK 3.3.4, rebuilt, removed zoo_data, recopied example to three other directories) and it works fine there too now. Siiiiggggh. Mostly this is a placeholder to insure we try this, I guarantee that sys admins will want to assign specific machines to specific shards, so this'll get used.
was:
I'm seeing some odd results when specifying "shardId" parameter. I'm trying the 4-node, 2-shard example from the Wiki and specifying shardIds like this:
dir shardId start order runnng ZK port
example 1 1 y 8983
example2 2 2 y 7574
example3 1 3 y 8900
example4 2 4 y 7500
And I'm waiting a bit between starting various examples to let ZK settle down.
Once all of them are started, I was looking at http://localhost:8983/solr/#/~cloud?view=graph to check out what that looks like (pretty cool IMO, especially since I didn't have to do it). The problem was that shard 2 only reported a single instance, while shard1 showed the two instances I was expecting. I'm running with 3 embedded ZK instances, just for yucks. Interestingly the node that didn't show up was the only node that was NOT running ZK.
When I removed all the "shardId" parameters, nuked zoo_data from all directories and just started them up (with numShards=2 on the bootstrap ZK node), all 4 nodes showed up just fine.
When starting with shardId specified and trying to go straight to the admin interface on the node that wasn't showing up, I'd get odd errors like "This interface requires that you activate the admin request handlers, add the following configuration to your solrconfig.xml:". I also couldn't search directly on that machine, "http://localhost:7574/solr/select?q=*:*" returns a 404 error.
Command starting server that's giving me trouble: java -Xmx1G -Djetty.port=7500 -DzkHost=localhost:9983,localhost:8574,localhost:9900 -DshardId=2 -jar start.jar
Command for one that works fine: java -Xmx1G -Djetty.port=8900 -DzkRun -DzkHost=localhost:9983,localhost:8574,localhost:9900 -DshardId=1 -jar start.jar
Sami Siren and he reports similar issues via e-mail conversation. Sami says that ZK 3.5 apparently (without exhaustive tests) fixed the problem for him, but when I tried ZK 3.5 I saw the same issue. Of course with all the recent stuff with Ivy, I may have screwed up when/where the JARs were.
So then I went back to ZK 3.4 and couldn't reproduce the problem. Which seems highly suspicious to me. It was failing every time before with 3.4, so it sounds like gremlins.
And then I re-did the stuff with ZK 3.5 and it works fine there too now. Siiiiggggh. Mostly this is a placeholder to insure we try this, I guarantee that sys admins will want to assign specific machines to specific shards, so this'll get used.
> SolrCloud: Specifying shardId not working correctly, although the failures are inconsistent.
> --------------------------------------------------------------------------------------------
>
> Key: SOLR-3376
> URL: https://issues.apache.org/jira/browse/SOLR-3376
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
> Affects Versions: 4.0
> Reporter: Erick Erickson
>
> I'm seeing some odd results when specifying "shardId" parameter. I'm trying the 4-node, 2-shard example from the Wiki and specifying shardIds like this:
> dir shardId start order runnng ZK port
> example 1 1 y 8983
> example2 2 2 y 7574
> example3 1 3 y 8900
> example4 2 4 y 7500
> And I'm waiting a bit between starting various examples to let ZK settle down.
> Once all of them are started, I was looking at http://localhost:8983/solr/#/~cloud?view=graph to check out what that looks like (pretty cool IMO, especially since I didn't have to do it). The problem was that shard 2 only reported a single instance, while shard1 showed the two instances I was expecting. I'm running with 3 embedded ZK instances, just for yucks. Interestingly the node that didn't show up was the only node that was NOT running ZK.
> When I removed all the "shardId" parameters, nuked zoo_data from all directories and just started them up (with numShards=2 on the bootstrap ZK node), all 4 nodes showed up just fine.
> When starting with shardId specified and trying to go straight to the admin interface on the node that wasn't showing up, I'd get odd errors like "This interface requires that you activate the admin request handlers, add the following configuration to your solrconfig.xml:". I also couldn't search directly on that machine, "http://localhost:7574/solr/select?q=*:*" returns a 404 error.
> Command starting server that's giving me trouble: java -Xmx1G -Djetty.port=7500 -DzkHost=localhost:9983,localhost:8574,localhost:9900 -DshardId=2 -jar start.jar
> Command for one that works fine: java -Xmx1G -Djetty.port=8900 -DzkRun -DzkHost=localhost:9983,localhost:8574,localhost:9900 -DshardId=1 -jar start.jar
> Sami Siren and he reports similar issues via e-mail conversation. Sami says that ZK 3.3.5 apparently (without exhaustive tests) fixed the problem for him, but when I tried ZK 3.3.5 I saw the same issue. Of course with all the recent stuff with Ivy, I may have screwed up when/where the JARs were.
> So then I went back to ZK 3.3.4 and couldn't reproduce the problem. Which seems highly suspicious to me. It was failing every time before with 3.3.4, so it sounds like gremlins.
> And then I tried ZK 3.3.5 again (changed the ivy.xml in solrj, blew away the ZK 3.3.4, rebuilt, removed zoo_data, recopied example to three other directories) and it works fine there too now. Siiiiggggh. Mostly this is a placeholder to insure we try this, I guarantee that sys admins will want to assign specific machines to specific shards, so this'll get used.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
[jira] [Resolved] (SOLR-3376) SolrCloud: Specifying shardId not
working correctly, although the failures are inconsistent.
Posted by "Erick Erickson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-3376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Erick Erickson resolved SOLR-3376.
----------------------------------
Resolution: Fixed
I can't make this happen, closing.
> SolrCloud: Specifying shardId not working correctly, although the failures are inconsistent.
> --------------------------------------------------------------------------------------------
>
> Key: SOLR-3376
> URL: https://issues.apache.org/jira/browse/SOLR-3376
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
> Reporter: Erick Erickson
> Assignee: Sami Siren
> Fix For: 4.0
>
>
> I'm seeing some odd results when specifying "shardId" parameter. I'm trying the 4-node, 2-shard example from the Wiki and specifying shardIds like this:
> dir shardId start order runnng ZK port
> example 1 1 y 8983
> example2 2 2 y 7574
> example3 1 3 y 8900
> example4 2 4 y 7500
> And I'm waiting a bit between starting various examples to let ZK settle down.
> Once all of them are started, I was looking at http://localhost:8983/solr/#/~cloud?view=graph to check out what that looks like (pretty cool IMO, especially since I didn't have to do it). The problem was that shard 2 only reported a single instance, while shard1 showed the two instances I was expecting. I'm running with 3 embedded ZK instances, just for yucks. Interestingly the node that didn't show up was the only node that was NOT running ZK.
> When I removed all the "shardId" parameters, nuked zoo_data from all directories and just started them up (with numShards=2 on the bootstrap ZK node), all 4 nodes showed up just fine.
> When starting with shardId specified and trying to go straight to the admin interface on the node that wasn't showing up, I'd get odd errors like "This interface requires that you activate the admin request handlers, add the following configuration to your solrconfig.xml:". I also couldn't search directly on that machine, "http://localhost:7574/solr/select?q=*:*" returns a 404 error.
> Command starting server that's giving me trouble: java -Xmx1G -Djetty.port=7500 -DzkHost=localhost:9983,localhost:8574,localhost:9900 -DshardId=2 -jar start.jar
> Command for one that works fine: java -Xmx1G -Djetty.port=8900 -DzkRun -DzkHost=localhost:9983,localhost:8574,localhost:9900 -DshardId=1 -jar start.jar
> Sami Siren and he reports similar issues via e-mail conversation. Sami says that ZK 3.3.5 apparently (without exhaustive tests) fixed the problem for him, but when I tried ZK 3.3.5 I saw the same issue. Of course with all the recent stuff with Ivy, I may have screwed up when/where the JARs were.
> So then I went back to ZK 3.3.4 and couldn't reproduce the problem. Which seems highly suspicious to me. It was failing every time before with 3.3.4, so it sounds like gremlins.
> And then I tried ZK 3.3.5 again (changed the ivy.xml in solrj, blew away the ZK 3.3.4, rebuilt, removed zoo_data, recopied example to three other directories) and it works fine there too now. Siiiiggggh. Mostly this is a placeholder to insure we try this, I guarantee that sys admins will want to assign specific machines to specific shards, so this'll get used.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
[jira] [Commented] (SOLR-3376) SolrCloud: Specifying shardId not
working correctly, although the failures are inconsistent.
Posted by "Sami Siren (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-3376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13458487#comment-13458487 ]
Sami Siren commented on SOLR-3376:
----------------------------------
I started a small cluster with preassigned ids a few times in a row and did not see anything strange. So I guess unless Erick chimes in it's safe to close this one.
> SolrCloud: Specifying shardId not working correctly, although the failures are inconsistent.
> --------------------------------------------------------------------------------------------
>
> Key: SOLR-3376
> URL: https://issues.apache.org/jira/browse/SOLR-3376
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
> Reporter: Erick Erickson
> Assignee: Sami Siren
> Fix For: 4.0
>
>
> I'm seeing some odd results when specifying "shardId" parameter. I'm trying the 4-node, 2-shard example from the Wiki and specifying shardIds like this:
> dir shardId start order runnng ZK port
> example 1 1 y 8983
> example2 2 2 y 7574
> example3 1 3 y 8900
> example4 2 4 y 7500
> And I'm waiting a bit between starting various examples to let ZK settle down.
> Once all of them are started, I was looking at http://localhost:8983/solr/#/~cloud?view=graph to check out what that looks like (pretty cool IMO, especially since I didn't have to do it). The problem was that shard 2 only reported a single instance, while shard1 showed the two instances I was expecting. I'm running with 3 embedded ZK instances, just for yucks. Interestingly the node that didn't show up was the only node that was NOT running ZK.
> When I removed all the "shardId" parameters, nuked zoo_data from all directories and just started them up (with numShards=2 on the bootstrap ZK node), all 4 nodes showed up just fine.
> When starting with shardId specified and trying to go straight to the admin interface on the node that wasn't showing up, I'd get odd errors like "This interface requires that you activate the admin request handlers, add the following configuration to your solrconfig.xml:". I also couldn't search directly on that machine, "http://localhost:7574/solr/select?q=*:*" returns a 404 error.
> Command starting server that's giving me trouble: java -Xmx1G -Djetty.port=7500 -DzkHost=localhost:9983,localhost:8574,localhost:9900 -DshardId=2 -jar start.jar
> Command for one that works fine: java -Xmx1G -Djetty.port=8900 -DzkRun -DzkHost=localhost:9983,localhost:8574,localhost:9900 -DshardId=1 -jar start.jar
> Sami Siren and he reports similar issues via e-mail conversation. Sami says that ZK 3.3.5 apparently (without exhaustive tests) fixed the problem for him, but when I tried ZK 3.3.5 I saw the same issue. Of course with all the recent stuff with Ivy, I may have screwed up when/where the JARs were.
> So then I went back to ZK 3.3.4 and couldn't reproduce the problem. Which seems highly suspicious to me. It was failing every time before with 3.3.4, so it sounds like gremlins.
> And then I tried ZK 3.3.5 again (changed the ivy.xml in solrj, blew away the ZK 3.3.4, rebuilt, removed zoo_data, recopied example to three other directories) and it works fine there too now. Siiiiggggh. Mostly this is a placeholder to insure we try this, I guarantee that sys admins will want to assign specific machines to specific shards, so this'll get used.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
[jira] [Updated] (SOLR-3376) SolrCloud: Specifying shardId not
working correctly, although the failures are inconsistent.
Posted by "Erick Erickson (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-3376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Erick Erickson updated SOLR-3376:
---------------------------------
Description:
I'm seeing some odd results when specifying "shardId" parameter. I'm trying the 4-node, 2-shard example from the Wiki and specifying shardIds like this:
{{{
dir shardId start order runnng ZK port
example 1 1 y 8983
example2 2 2 y 7574
example3 1 3 y 8900
example4 2 4 y 7500
}}}
And I'm waiting a bit between starting various examples to let ZK settle down.
Once all of them are started, I was looking at http://localhost:8983/solr/#/~cloud?view=graph to check out what that looks like (pretty cool IMO, especially since I didn't have to do it). The problem was that shard 2 only reported a single instance, while shard1 showed the two instances I was expecting. I'm running with 3 embedded ZK instances, just for yucks. Interestingly the node that didn't show up was the only node that was NOT running ZK.
When I removed all the "shardId" parameters, nuked zoo_data from all directories and just started them up (with numShards=2 on the bootstrap ZK node), all 4 nodes showed up just fine.
When starting with shardId specified and trying to go straight to the admin interface on the node that wasn't showing up, I'd get odd errors like "This interface requires that you activate the admin request handlers, add the following configuration to your solrconfig.xml:". I also couldn't search directly on that machine, "http://localhost:7574/solr/select?q=*:*" returns a 404 error.
Command starting server that's giving me trouble: java -Xmx1G -Djetty.port=7500 -DzkHost=localhost:9983,localhost:8574,localhost:9900 -DshardId=2 -jar start.jar
Command for one that works fine: java -Xmx1G -Djetty.port=8900 -DzkRun -DzkHost=localhost:9983,localhost:8574,localhost:9900 -DshardId=1 -jar start.jar
Sami Siren and he reports similar issues via e-mail conversation. Sami says that ZK 3.3.5 apparently (without exhaustive tests) fixed the problem for him, but when I tried ZK 3.3.5 I saw the same issue. Of course with all the recent stuff with Ivy, I may have screwed up when/where the JARs were.
So then I went back to ZK 3.3.4 and couldn't reproduce the problem. Which seems highly suspicious to me. It was failing every time before with 3.3.4, so it sounds like gremlins.
And then I tried ZK 3.3.5 again (changed the ivy.xml in solrj, blew away the ZK 3.3.4, rebuilt, removed zoo_data, recopied example to three other directories) and it works fine there too now. Siiiiggggh. Mostly this is a placeholder to insure we try this, I guarantee that sys admins will want to assign specific machines to specific shards, so this'll get used.
was:
I'm seeing some odd results when specifying "shardId" parameter. I'm trying the 4-node, 2-shard example from the Wiki and specifying shardIds like this:
dir shardId start order runnng ZK port
example 1 1 y 8983
example2 2 2 y 7574
example3 1 3 y 8900
example4 2 4 y 7500
And I'm waiting a bit between starting various examples to let ZK settle down.
Once all of them are started, I was looking at http://localhost:8983/solr/#/~cloud?view=graph to check out what that looks like (pretty cool IMO, especially since I didn't have to do it). The problem was that shard 2 only reported a single instance, while shard1 showed the two instances I was expecting. I'm running with 3 embedded ZK instances, just for yucks. Interestingly the node that didn't show up was the only node that was NOT running ZK.
When I removed all the "shardId" parameters, nuked zoo_data from all directories and just started them up (with numShards=2 on the bootstrap ZK node), all 4 nodes showed up just fine.
When starting with shardId specified and trying to go straight to the admin interface on the node that wasn't showing up, I'd get odd errors like "This interface requires that you activate the admin request handlers, add the following configuration to your solrconfig.xml:". I also couldn't search directly on that machine, "http://localhost:7574/solr/select?q=*:*" returns a 404 error.
Command starting server that's giving me trouble: java -Xmx1G -Djetty.port=7500 -DzkHost=localhost:9983,localhost:8574,localhost:9900 -DshardId=2 -jar start.jar
Command for one that works fine: java -Xmx1G -Djetty.port=8900 -DzkRun -DzkHost=localhost:9983,localhost:8574,localhost:9900 -DshardId=1 -jar start.jar
Sami Siren and he reports similar issues via e-mail conversation. Sami says that ZK 3.3.5 apparently (without exhaustive tests) fixed the problem for him, but when I tried ZK 3.3.5 I saw the same issue. Of course with all the recent stuff with Ivy, I may have screwed up when/where the JARs were.
So then I went back to ZK 3.3.4 and couldn't reproduce the problem. Which seems highly suspicious to me. It was failing every time before with 3.3.4, so it sounds like gremlins.
And then I tried ZK 3.3.5 again (changed the ivy.xml in solrj, blew away the ZK 3.3.4, rebuilt, removed zoo_data, recopied example to three other directories) and it works fine there too now. Siiiiggggh. Mostly this is a placeholder to insure we try this, I guarantee that sys admins will want to assign specific machines to specific shards, so this'll get used.
> SolrCloud: Specifying shardId not working correctly, although the failures are inconsistent.
> --------------------------------------------------------------------------------------------
>
> Key: SOLR-3376
> URL: https://issues.apache.org/jira/browse/SOLR-3376
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
> Affects Versions: 4.0
> Reporter: Erick Erickson
>
> I'm seeing some odd results when specifying "shardId" parameter. I'm trying the 4-node, 2-shard example from the Wiki and specifying shardIds like this:
> {{{
> dir shardId start order runnng ZK port
> example 1 1 y 8983
> example2 2 2 y 7574
> example3 1 3 y 8900
> example4 2 4 y 7500
> }}}
> And I'm waiting a bit between starting various examples to let ZK settle down.
> Once all of them are started, I was looking at http://localhost:8983/solr/#/~cloud?view=graph to check out what that looks like (pretty cool IMO, especially since I didn't have to do it). The problem was that shard 2 only reported a single instance, while shard1 showed the two instances I was expecting. I'm running with 3 embedded ZK instances, just for yucks. Interestingly the node that didn't show up was the only node that was NOT running ZK.
> When I removed all the "shardId" parameters, nuked zoo_data from all directories and just started them up (with numShards=2 on the bootstrap ZK node), all 4 nodes showed up just fine.
> When starting with shardId specified and trying to go straight to the admin interface on the node that wasn't showing up, I'd get odd errors like "This interface requires that you activate the admin request handlers, add the following configuration to your solrconfig.xml:". I also couldn't search directly on that machine, "http://localhost:7574/solr/select?q=*:*" returns a 404 error.
> Command starting server that's giving me trouble: java -Xmx1G -Djetty.port=7500 -DzkHost=localhost:9983,localhost:8574,localhost:9900 -DshardId=2 -jar start.jar
> Command for one that works fine: java -Xmx1G -Djetty.port=8900 -DzkRun -DzkHost=localhost:9983,localhost:8574,localhost:9900 -DshardId=1 -jar start.jar
> Sami Siren and he reports similar issues via e-mail conversation. Sami says that ZK 3.3.5 apparently (without exhaustive tests) fixed the problem for him, but when I tried ZK 3.3.5 I saw the same issue. Of course with all the recent stuff with Ivy, I may have screwed up when/where the JARs were.
> So then I went back to ZK 3.3.4 and couldn't reproduce the problem. Which seems highly suspicious to me. It was failing every time before with 3.3.4, so it sounds like gremlins.
> And then I tried ZK 3.3.5 again (changed the ivy.xml in solrj, blew away the ZK 3.3.4, rebuilt, removed zoo_data, recopied example to three other directories) and it works fine there too now. Siiiiggggh. Mostly this is a placeholder to insure we try this, I guarantee that sys admins will want to assign specific machines to specific shards, so this'll get used.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org