[jira] [Commented] (SOLR-4192) There is an odd classpath gotchya with ZkCli scripts.
[
https://issues.apache.org/jira/browse/SOLR-4192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13532701#comment-13532701
]
Sami Siren commented on SOLR-4192:
--
I think you are just missing the double quotes from around the classpath (to
prevent shell? from expanding it):
{code}
java -classpath example/solr-webapp/webapp/WEB-INF/lib/*
org.apache.solr.cloud.ZkCLI -cmd bootstrap -zkhost 127.0.0.1:9983 -solrhome
example/solr -runzk 8983
{code}
Should work just fine.
There is an odd classpath gotchya with ZkCli scripts.
-
Key: SOLR-4192
URL: https://issues.apache.org/jira/browse/SOLR-4192
Project: Solr
Issue Type: Bug
Components: SolrCloud
Reporter: Mark Miller
Assignee: Mark Miller
Fix For: 4.1, 5.0
I saw this many months ago while working with a customer, but forgot to
investigate further.
When using a classpath that just points to the webapp libs, you seem to get
an error about not being able to find one of the jars in that folder. If you
also specifically include the one solrj jar it complains about, everything
works. WTF?
Does not work:
{code}java -classpath example/solr-webapp/webapp/WEB-INF/lib/*
org.apache.solr.cloud.ZkCLI -cmd bootstrap -zkhost 127.0.0.1:9983 -solrhome
example/solr -runzk 8983{code}
Works
{code}java -classpath
example/solr-webapp/webapp/WEB-INF/lib/*:example/solr-webapp/webapp/WEB-INF/lib/apache-solr-solrj-5.0-SNAPSHOT.jar
org.apache.solr.cloud.ZkCLI -cmd bootstrap -zkhost 127.0.0.1:9983 -solrhome
example/solr -runzk 8983
{code}
--
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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2816) Versioning
[ https://issues.apache.org/jira/browse/SOLR-2816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13502882#comment-13502882 ] Sami Siren commented on SOLR-2816: -- Seems like this is done. Or is there something left to do? Versioning -- Key: SOLR-2816 URL: https://issues.apache.org/jira/browse/SOLR-2816 Project: Solr Issue Type: Sub-task Components: SolrCloud, update Reporter: Yonik Seeley Fix For: 4.1 Attachments: SOLR-2816.patch Adds and deletes need to be versioned by the leader so that this can be relayed to all replicas for consistency (so an equivalent index can be built). -- 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3854) SolrCloud does not work with https
[ https://issues.apache.org/jira/browse/SOLR-3854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13496294#comment-13496294 ] Sami Siren commented on SOLR-3854: -- I was planning to add some tests too, but got distracted with something else. I'll try to get to this again in near future. SolrCloud does not work with https -- Key: SOLR-3854 URL: https://issues.apache.org/jira/browse/SOLR-3854 Project: Solr Issue Type: Bug Reporter: Sami Siren Assignee: Sami Siren Fix For: 4.1, 5.0 Attachments: SOLR-3854.patch There are a few places in current codebase that assume http is used. This prevents using https when running solr in cloud mode. -- 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-3965) CoreAdminHandler does not do property expansion on values wren creating new core
Sami Siren created SOLR-3965:
Summary: CoreAdminHandler does not do property expansion on
values wren creating new core
Key: SOLR-3965
URL: https://issues.apache.org/jira/browse/SOLR-3965
Project: Solr
Issue Type: Bug
Reporter: Sami Siren
Let's say I have a core definition in my solr.xml like this:
{code}
core name=core instanceDir=cores/core
dataDir=${DataHome}/cores/core/data/
{code}
When I want to add more cores through the coreAdminHandler so that the data
goes under the same base dir I cannot use ${DataHome} but I have to use a
absolute directory instead.
Using property references stores everything correctly in solr.xml but the
actual value used for the data dir of the new core is incorrect (until solr is
restarted).
--
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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3965) CoreAdminHandler does not do property expansion on values wren creating new core
[
https://issues.apache.org/jira/browse/SOLR-3965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sami Siren updated SOLR-3965:
-
Affects Version/s: 4.0
CoreAdminHandler does not do property expansion on values wren creating new
core
--
Key: SOLR-3965
URL: https://issues.apache.org/jira/browse/SOLR-3965
Project: Solr
Issue Type: Bug
Affects Versions: 4.0
Reporter: Sami Siren
Let's say I have a core definition in my solr.xml like this:
{code}
core name=core instanceDir=cores/core
dataDir=${DataHome}/cores/core/data/
{code}
When I want to add more cores through the coreAdminHandler so that the data
goes under the same base dir I cannot use ${DataHome} but I have to use a
absolute directory instead.
Using property references stores everything correctly in solr.xml but the
actual value used for the data dir of the new core is incorrect (until solr
is restarted).
--
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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3854) SolrCloud does not work with https
[ https://issues.apache.org/jira/browse/SOLR-3854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren updated SOLR-3854: - Fix Version/s: (was: 4.0) 4.1 SolrCloud does not work with https -- Key: SOLR-3854 URL: https://issues.apache.org/jira/browse/SOLR-3854 Project: Solr Issue Type: Bug Reporter: Sami Siren Assignee: Sami Siren Fix For: 4.1 Attachments: SOLR-3854.patch There are a few places in current codebase that assume http is used. This prevents using https when running solr in cloud mode. -- 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3861) regresion of SOLR-2008 - updateHandler should be closed before searcherExecutor
[ https://issues.apache.org/jira/browse/SOLR-3861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13459871#comment-13459871 ] Sami Siren commented on SOLR-3861: -- Not sure if this is related but the famous TestReplicationHandler failures seem to throw the mentioned RejectedExecutionException when the test fails. for example here: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Linux/1221/ regresion of SOLR-2008 - updateHandler should be closed before searcherExecutor --- Key: SOLR-3861 URL: https://issues.apache.org/jira/browse/SOLR-3861 Project: Solr Issue Type: Bug Affects Versions: 4.0-ALPHA, 4.0-BETA Reporter: Hoss Man Assignee: Mark Miller Priority: Blocker Fix For: 4.0 SOLR-2008 fixed a possible RejectedExecutionException by ensuring that SolrCore closed the updateHandler before the searcherExecutor. [~markrmil...@gmail.com] re-flipped this logic in r1159378, which is annotated as fixing both SOLR-2654 and SOLR-2654 (dup typo i guess) but it's not clear why - pretty sure this means that the risk of a Rejected exception is back in 4.0-BETA... https://svn.apache.org/viewvc/lucene/dev/trunk/solr/core/src/java/org/apache/solr/core/SolrCore.java?r1=1146905r2=1159378 -- 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3376) SolrCloud: Specifying shardId not working correctly, although the failures are inconsistent.
[ https://issues.apache.org/jira/browse/SOLR-3376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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 orderrunnng ZK port example 1 1 y8983 example22 2 y7574 example31 3 y8900 example42 4 y7500 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. Sh. 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3354) LeaderElectionIntegrationTest
[
https://issues.apache.org/jira/browse/SOLR-3354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458491#comment-13458491
]
Sami Siren commented on SOLR-3354:
--
Dawid are you still seeing this happen? There have been a number of bug fixes
around the areas that might have caused this, the last failure I could find was
from July 23th.
LeaderElectionIntegrationTest
-
Key: SOLR-3354
URL: https://issues.apache.org/jira/browse/SOLR-3354
Project: Solr
Issue Type: Bug
Reporter: Dawid Weiss
Assignee: Sami Siren
Priority: Minor
Labels: not_reproducible
Fix For: 4.1
From my build server.
{noformat}
12-Apr-2012 02:29:21 [junit] Testcase:
testSimpleSliceLeaderElection(org.apache.solr.cloud.LeaderElectionIntegrationTest):
FAILED
12-Apr-2012 02:29:21 [junit] We didn't find a new leader! 7004 was
shutdown, but it's still showing as the leader
12-Apr-2012 02:29:21 [junit] junit.framework.AssertionFailedError: We
didn't find a new leader! 7004 was shutdown, but it's still showing as the
leader
12-Apr-2012 02:29:21 [junit] at
org.junit.Assert.fail(Assert.java:93)
12-Apr-2012 02:29:21 [junit] at
org.apache.solr.cloud.LeaderElectionIntegrationTest.testSimpleSliceLeaderElection(LeaderElectionIntegrationTest.java:174)
12-Apr-2012 02:29:21 [junit] at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
12-Apr-2012 02:29:21 [junit] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
12-Apr-2012 02:29:21 [junit] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
12-Apr-2012 02:29:21 [junit] at
java.lang.reflect.Method.invoke(Method.java:597)
12-Apr-2012 02:29:21 [junit] at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
12-Apr-2012 02:29:21 [junit] at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
12-Apr-2012 02:29:21 [junit] at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
12-Apr-2012 02:29:21 [junit] at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
12-Apr-2012 02:29:21 [junit] at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
12-Apr-2012 02:29:21 [junit] at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
12-Apr-2012 02:29:21 [junit] at
org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:63)
12-Apr-2012 02:29:21 [junit] at
org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:754)
12-Apr-2012 02:29:21 [junit] at
org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:670)
12-Apr-2012 02:29:21 [junit] at
org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:69)
12-Apr-2012 02:29:21 [junit] at
org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:591)
12-Apr-2012 02:29:21 [junit] at
org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:75)
12-Apr-2012 02:29:21 [junit] at
org.apache.lucene.util.LuceneTestCase$SaveThreadAndTestNameRule$1.evaluate(LuceneTestCase.java:642)
12-Apr-2012 02:29:21 [junit] at
org.junit.rules.RunRules.evaluate(RunRules.java:18)
12-Apr-2012 02:29:21 [junit] at
org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
12-Apr-2012 02:29:21 [junit] at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
12-Apr-2012 02:29:21 [junit] at
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:164)
12-Apr-2012 02:29:21 [junit] at
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57)
12-Apr-2012 02:29:21 [junit] at
org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
12-Apr-2012 02:29:21 [junit] at
org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
12-Apr-2012 02:29:21 [junit] at
org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
12-Apr-2012 02:29:21 [junit] at
org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
12-Apr-2012 02:29:21 [junit] at
org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
12-Apr-2012 02:29:21
[jira] [Resolved] (SOLR-3237) OverseerTest failure (non-reproducible)
[
https://issues.apache.org/jira/browse/SOLR-3237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sami Siren resolved SOLR-3237.
--
Resolution: Cannot Reproduce
I haven't seen this occur in a while, there was one failure with the same
method recently but it was not related to this. closing.
OverseerTest failure (non-reproducible)
---
Key: SOLR-3237
URL: https://issues.apache.org/jira/browse/SOLR-3237
Project: Solr
Issue Type: Bug
Reporter: Dawid Weiss
Assignee: Sami Siren
Priority: Minor
Fix For: 4.1
Nighly log harvest. Couldn't reproduce, unfortunately.
{noformat}
build 13-Mar-2012 06:08:43[junit] Testsuite:
org.apache.solr.cloud.OverseerTest
build 13-Mar-2012 06:08:43[junit] Testcase:
testShardLeaderChange(org.apache.solr.cloud.OverseerTest):FAILED
build 13-Mar-2012 06:08:43[junit] Unexpected shard leader
coll:collection1 shard:shard1 expected:core4 but was:null
build 13-Mar-2012 06:08:43[junit]
junit.framework.AssertionFailedError: Unexpected shard leader
coll:collection1 shard:shard1 expected:core4 but was:null
build 13-Mar-2012 06:08:43[junit] at
org.apache.solr.cloud.OverseerTest.verifyShardLeader(OverseerTest.java:549)
build 13-Mar-2012 06:08:43[junit] at
org.apache.solr.cloud.OverseerTest.testShardLeaderChange(OverseerTest.java:711)
build 13-Mar-2012 06:08:43[junit] at
org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:20)
build 13-Mar-2012 06:08:43[junit] at
org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:729)
build 13-Mar-2012 06:08:43[junit] at
org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:645)
build 13-Mar-2012 06:08:43[junit] at
org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22)
build 13-Mar-2012 06:08:43[junit] at
org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:556)
build 13-Mar-2012 06:08:43[junit] at
org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:51)
build 13-Mar-2012 06:08:43[junit] at
org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:618)
build 13-Mar-2012 06:08:43[junit] at
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:164)
build 13-Mar-2012 06:08:43[junit] at
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57)
build 13-Mar-2012 06:08:43[junit] at
org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:20)
build 13-Mar-2012 06:08:43[junit] at
org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:51)
build 13-Mar-2012 06:08:43[junit] at
org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:21)
build 13-Mar-2012 06:08:43[junit] at
org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22)
build 13-Mar-2012 06:08:43[junit]
build 13-Mar-2012 06:08:43[junit]
build 13-Mar-2012 06:08:43[junit] Tests run: 7, Failures: 1, Errors:
0, Time elapsed: 74.666 sec
build 13-Mar-2012 06:08:43[junit]
build 13-Mar-2012 06:08:43[junit] - Standard Error
-
build 13-Mar-2012 06:08:43[junit] NOTE: reproduce with: ant test
-Dtestcase=OverseerTest -Dtestmethod=testShardLeaderChange
-Dtests.seed=48c9960216b3d5d:6c1600de0df53cdd:69c37083161d807d
-Dargs=-Dfile.encoding=UTF-8
build 13-Mar-2012 06:08:43[junit] WARNING: test class left thread
running: Session Sets (4):
build 13-Mar-2012 06:08:43[junit] 0 expire at Mon Mar 12 22:08:45 MST
2012:
build 13-Mar-2012 06:08:43[junit] 0 expire at Mon Mar 12 22:08:48 MST
2012:
build 13-Mar-2012 06:08:43[junit] 0 expire at Mon Mar 12 22:08:51 MST
2012:
build 13-Mar-2012 06:08:43[junit] 0 expire at Mon Mar 12 22:08:54 MST
2012:
build 13-Mar-2012 06:08:43[junit]
build 13-Mar-2012 06:08:43[junit] RESOURCE LEAK: test class left 1
thread(s) running
build 13-Mar-2012 06:08:43[junit] NOTE: test params are:
codec=Lucene40: {}, sim=DefaultSimilarity, locale=zh_TW,
timezone=Mexico/BajaSur
build 13-Mar-2012 06:08:43[junit] NOTE: all tests run in this JVM:
build 13-Mar-2012 06:08:43[junit] [BasicFunctionalityTest,
SolrInfoMBeanTest, SnowballPorterFilterFactoryTest,
[jira] [Resolved] (SOLR-861) SOLRJ Client does not release connections 'nicely' by default
[ https://issues.apache.org/jira/browse/SOLR-861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren resolved SOLR-861. - Resolution: Fixed Fix Version/s: (was: 4.1) 4.0-BETA I have not heard back anything that suggests that the shutdown() does not do it's job. resolving this one as fixed (the work was done in SOLR-2020, SOLR-3532). SOLRJ Client does not release connections 'nicely' by default - Key: SOLR-861 URL: https://issues.apache.org/jira/browse/SOLR-861 Project: Solr Issue Type: Bug Components: clients - java Affects Versions: 1.3 Environment: linux Reporter: Ian Holsman Assignee: Sami Siren Fix For: 4.0-BETA Attachments: SimpleClient.patch as-is the SolrJ Commons HttpServer uses the multi-threaded http connection manager. This manager seems to keep the connection alive for the client and does not close it when the object is dereferenced. When you keep on opening new CommonsHttpSolrServer instances it results in a socket that is stuck in the CLOSE_WAIT state. Eventually this will use up all your available file handles, causing your client to die a painful death. The solution I propose is that it uses a 'Simple' HttpConnectionManager which is set to not reuse connections if you don't specify a HttpClient. -- 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-3854) SolrCloud does not work with https
Sami Siren created SOLR-3854: Summary: SolrCloud does not work with https Key: SOLR-3854 URL: https://issues.apache.org/jira/browse/SOLR-3854 Project: Solr Issue Type: Bug Reporter: Sami Siren Assignee: Sami Siren Fix For: 4.0 There are a few places in current codebase that assume http is used. This prevents using https when running solr in cloud mode. -- 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3854) SolrCloud does not work with https
[ https://issues.apache.org/jira/browse/SOLR-3854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren updated SOLR-3854: - Attachment: SOLR-3854.patch Here's a patch against trunk that allows one to use https too. SolrCloud does not work with https -- Key: SOLR-3854 URL: https://issues.apache.org/jira/browse/SOLR-3854 Project: Solr Issue Type: Bug Reporter: Sami Siren Assignee: Sami Siren Fix For: 4.0 Attachments: SOLR-3854.patch There are a few places in current codebase that assume http is used. This prevents using https when running solr in cloud mode. -- 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3815) add hash range to shard
[ https://issues.apache.org/jira/browse/SOLR-3815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13454748#comment-13454748 ] Sami Siren commented on SOLR-3815: -- Yonik, I was trying to reproduce what you see and applied SOLR-3815_clusterState_immutable.patch. do you mean that with that patch (which modifies the existing state inside the nocommits block) the LeaderElectionIntegrationTest should pass? It fails for me sporadically around 50% of time. wrt. editing the immutable state. I think the problem may be in the shared ZKStateReader which is used by the overseer and rest of the system. Shouldn't the overseer create it's own reader so that it cannot modify the state (which should not be happening in the first place, bug, bug!) that other parts running on that same instance see and use. add hash range to shard --- Key: SOLR-3815 URL: https://issues.apache.org/jira/browse/SOLR-3815 Project: Solr Issue Type: Sub-task Reporter: Yonik Seeley Attachments: SOLR-3815_addrange.patch, SOLR-3815_clusterState_immutable.patch, SOLR-3815.patch -- 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3815) add hash range to shard
[ https://issues.apache.org/jira/browse/SOLR-3815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13454777#comment-13454777 ] Sami Siren commented on SOLR-3815: -- It appears that if I create a new instance of the ZkStateReader in Overseer constructor for overseer to use the test starts to fail 100% of time which seems to suggest the side-effect of editing the existing state is gone. I did not try to look at the actual failure yet since i am not sure if I am looking at the right thing... add hash range to shard --- Key: SOLR-3815 URL: https://issues.apache.org/jira/browse/SOLR-3815 Project: Solr Issue Type: Sub-task Reporter: Yonik Seeley Attachments: SOLR-3815_addrange.patch, SOLR-3815_clusterState_immutable.patch, SOLR-3815.patch -- 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-3789) Cannot use internal compression in replication handler
Sami Siren created SOLR-3789: Summary: Cannot use internal compression in replication handler Key: SOLR-3789 URL: https://issues.apache.org/jira/browse/SOLR-3789 Project: Solr Issue Type: Bug Affects Versions: 4.0-BETA Reporter: Sami Siren Fix For: 4.0 The implementation for internal compression is currently broken. a Wrong parameter value is used to activate the feature in SnapPuller. -- 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3789) Cannot use internal compression in replication handler
[ https://issues.apache.org/jira/browse/SOLR-3789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren updated SOLR-3789: - Attachment: SOLR-3789.patch fix + improvement to the testcase so that it randomly toggles compression between internal/off Cannot use internal compression in replication handler Key: SOLR-3789 URL: https://issues.apache.org/jira/browse/SOLR-3789 Project: Solr Issue Type: Bug Affects Versions: 4.0-BETA Reporter: Sami Siren Fix For: 4.0 Attachments: SOLR-3789.patch The implementation for internal compression is currently broken. a Wrong parameter value is used to activate the feature in SnapPuller. -- 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-3789) Cannot use internal compression in replication handler
[ https://issues.apache.org/jira/browse/SOLR-3789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren resolved SOLR-3789. -- Resolution: Fixed committed. trunk: r1381043 4x: 1381045 Cannot use internal compression in replication handler Key: SOLR-3789 URL: https://issues.apache.org/jira/browse/SOLR-3789 Project: Solr Issue Type: Bug Affects Versions: 4.0-BETA Reporter: Sami Siren Fix For: 4.0 Attachments: SOLR-3789.patch The implementation for internal compression is currently broken. a Wrong parameter value is used to activate the feature in SnapPuller. -- 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4360) Support running the same test suite multiple times in parallel
[
https://issues.apache.org/jira/browse/LUCENE-4360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13448627#comment-13448627
]
Sami Siren commented on LUCENE-4360:
Cool! This is a really nice addition!
Support running the same test suite multiple times in parallel
--
Key: LUCENE-4360
URL: https://issues.apache.org/jira/browse/LUCENE-4360
Project: Lucene - Core
Issue Type: New Feature
Components: general/test
Reporter: Dawid Weiss
Assignee: Dawid Weiss
Priority: Trivial
Fix For: 5.0, 4.0
Attachments: quickhack.patch
The current test execution multiplier or:
{code}
-Dtests.iters=N
{code}
generates multiple tests (method executions) under a test class (suite). All
these tests, however, are bound to a single class so they must run
sequentially and on a single JVM (because of how JUnit works -- nesting of
rules, class hooks, etc.).
Mark pointed out that if somebody has a multi-core CPU then it'd be nice to
be able to run a single suite in parallel, possibly in combination with
tests.iters (so that a single test method is executed X times on Y parallel
JVMs).
This is surprisingly easy with the randomized runner because it currently
accepts duplicate suite names and will load-balance them in a normal way.
So, if one has Y cores (JVMs) then providing a suite name X times will result
in X executions, balanced across Y JVMs.
The only problem is how to multiply suite names. This can be done in a
number of ways, starting from a custom resource collection wrapper and ending
at a built-in code in the runner itself. I think the custom collection
wrapper approach would be interesting, I'll explore this direction.
--
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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3785) Cluster-state inconsistent
[
https://issues.apache.org/jira/browse/SOLR-3785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sami Siren updated SOLR-3785:
-
Attachment: SOLR-3785.patch
Here's a patch that adds watches in Overseer for live nodes. When live nodes
change the cluster state is sanitized and leader flags for shards that live in
nodes other than the ones listed in live nodes are removed.
Cluster-state inconsistent
--
Key: SOLR-3785
URL: https://issues.apache.org/jira/browse/SOLR-3785
Project: Solr
Issue Type: Bug
Components: SolrCloud
Affects Versions: 4.0
Environment: Self-build Solr release built on Apache Solr revision
1355667 from 4.x branch
Reporter: Per Steffensen
Attachments: SOLR-3785.patch
Information in CloudSolrServer.getZkStateReader().getCloudState() (called
cloudState below) seems to be inconsistent.
I have a Solr running the leader of slice sliceName in collection
collectionName - no replica to take over. I shut down this Solr, and I want
to detect that there is now no leader active.
I do e.g.
{code}
ZkNodeProps leader = cloudState.getLeader(indexName, sliceName);
boolean notActive = (leader == null) ||
!leader.containsKey(ZkStateReader.STATE_PROP) ||
!leader.get(ZkStateReader.STATE_PROP).equals(ZkStateReader.ACTIVE);
{code}
This does not work. It seems like changing state of a shard does it not
changed when this Solr goes down.
I do e.g.
{code}
ZkNodeProps leader = cloudState.getLeader(indexName, sliceName);
boolean notActive = (leader == null) ||
!leader.containsKey(ZkStateReader.STATE_PROP) ||
!leader.get(ZkStateReader.STATE_PROP).equals(ZkStateReader.ACTIVE) ||
!leader.containsKey(ZkStateReader.NODE_NAME_PROP) ||
!cloudState.getLiveNodes().contains(leader.get(ZkStateReader.NODE_NAME_PROP))
{code}
Whis works.
It seems like live-nodes of cloudState is updated when Solr goes down, but
that some of the other info available through cloudState is not - e.g.
getLeader().
This might already have already been solved on 4.x branch in a revision later
than 1355667. Then please just tell me - thanks.
Regards, Per Steffensen
--
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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3785) Cluster-state inconsistent
[
https://issues.apache.org/jira/browse/SOLR-3785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13447717#comment-13447717
]
Sami Siren commented on SOLR-3785:
--
bq. The overseer watches /leaders I believe - and publishes results to the
clusterstate.json.
The leader is announced by the new shard leader
(ShardLeaderElectionContextBase). It adds the leader type of even with the
required details into overseer queue. There are no watches related to this in
overseer atm. Looks like we need to add one so that the leader=true can be
cleared by overseer from clusterstate.json when the leader nodes change/go away.
perhaps we could also rearrange the hierarchy slightly so that we could get
away with only 1 watch:
/leaders/collection-name-slice-name
Cluster-state inconsistent
--
Key: SOLR-3785
URL: https://issues.apache.org/jira/browse/SOLR-3785
Project: Solr
Issue Type: Bug
Components: SolrCloud
Affects Versions: 4.0
Environment: Self-build Solr release built on Apache Solr revision
1355667 from 4.x branch
Reporter: Per Steffensen
Information in CloudSolrServer.getZkStateReader().getCloudState() (called
cloudState below) seems to be inconsistent.
I have a Solr running the leader of slice sliceName in collection
collectionName - no replica to take over. I shut down this Solr, and I want
to detect that there is now no leader active.
I do e.g.
{code}
ZkNodeProps leader = cloudState.getLeader(indexName, sliceName);
boolean notActive = (leader == null) ||
!leader.containsKey(ZkStateReader.STATE_PROP) ||
!leader.get(ZkStateReader.STATE_PROP).equals(ZkStateReader.ACTIVE);
{code}
This does not work. It seems like changing state of a shard does it not
changed when this Solr goes down.
I do e.g.
{code}
ZkNodeProps leader = cloudState.getLeader(indexName, sliceName);
boolean notActive = (leader == null) ||
!leader.containsKey(ZkStateReader.STATE_PROP) ||
!leader.get(ZkStateReader.STATE_PROP).equals(ZkStateReader.ACTIVE) ||
!leader.containsKey(ZkStateReader.NODE_NAME_PROP) ||
!cloudState.getLiveNodes().contains(leader.get(ZkStateReader.NODE_NAME_PROP))
{code}
Whis works.
It seems like live-nodes of cloudState is updated when Solr goes down, but
that some of the other info available through cloudState is not - e.g.
getLeader().
This might already have already been solved on 4.x branch in a revision later
than 1355667. Then please just tell me - thanks.
Regards, Per Steffensen
--
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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3768) add some prelim assertions to OverseerTest
[
https://issues.apache.org/jira/browse/SOLR-3768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13444717#comment-13444717
]
Sami Siren commented on SOLR-3768:
--
+1
add some prelim assertions to OverseerTest
--
Key: SOLR-3768
URL: https://issues.apache.org/jira/browse/SOLR-3768
Project: Solr
Issue Type: Test
Reporter: Hoss Man
Attachments: SOLR-3768.patch
There isn't much i understand about OverseerTest, but today while doing a
full test run I got an unreproducible assertion failure from this line...
{noformat}
assertNotNull(could not find counter for shard: + ids[i], ai);
{noformat}
...in which the assertion message indicated that not only was ai null, but
ids[i] was null as well.
Poking arround the test a bit, i think what's happening here is that some of
the preliminary logic in testShardAssignmentBigger has bounded wait loops to
make sure things have happened, but there is no assertion that these
things actually happen if that the loop bound is exhausted - which can lead
to missleading/confusing errors further on in the test.
--
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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-3770) Overseer can lose updates to cluster state
Sami Siren created SOLR-3770: Summary: Overseer can lose updates to cluster state Key: SOLR-3770 URL: https://issues.apache.org/jira/browse/SOLR-3770 Project: Solr Issue Type: Bug Components: SolrCloud Reporter: Sami Siren Assignee: Sami Siren Fix For: 4.0 It seems there's a bug in overseer where it removes a work item from the primary queue before inserting it to the work queue. This can cause messages to be lost if overseer is killed in between removing and adding the message. -- 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3770) Overseer can lose updates to cluster state
[ https://issues.apache.org/jira/browse/SOLR-3770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren updated SOLR-3770: - Attachment: SOLR-3770.patch Trivial patch that should fix the problem. Overseer can lose updates to cluster state -- Key: SOLR-3770 URL: https://issues.apache.org/jira/browse/SOLR-3770 Project: Solr Issue Type: Bug Components: SolrCloud Reporter: Sami Siren Assignee: Sami Siren Fix For: 4.0 Attachments: SOLR-3770.patch It seems there's a bug in overseer where it removes a work item from the primary queue before inserting it to the work queue. This can cause messages to be lost if overseer is killed in between removing and adding the message. -- 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-3770) Overseer can lose updates to cluster state
[ https://issues.apache.org/jira/browse/SOLR-3770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren resolved SOLR-3770. -- Resolution: Fixed I committed this, trunk: r1378892, 4x: r1378895 Overseer can lose updates to cluster state -- Key: SOLR-3770 URL: https://issues.apache.org/jira/browse/SOLR-3770 Project: Solr Issue Type: Bug Components: SolrCloud Reporter: Sami Siren Assignee: Sami Siren Fix For: 4.0 Attachments: SOLR-3770.patch It seems there's a bug in overseer where it removes a work item from the primary queue before inserting it to the work queue. This can cause messages to be lost if overseer is killed in between removing and adding the message. -- 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3731) Disallow null CoreContainer in ZkController constructor
[ https://issues.apache.org/jira/browse/SOLR-3731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13444898#comment-13444898 ] Sami Siren commented on SOLR-3731: -- I changed the wait time to match what is currently in ZkController and the OverseerTest passes now (after fixing SOLR-3770 too) on my superslow vm. Disallow null CoreContainer in ZkController constructor --- Key: SOLR-3731 URL: https://issues.apache.org/jira/browse/SOLR-3731 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Sami Siren Assignee: Sami Siren Priority: Minor Fix For: 4.0 Attachments: SOLR-3731.patch Currently some tests use null CoreContainer when using ZkController directly in tests and ZKController has to deal with this. I'd like to remove this possibility. -- 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3731) Disallow null CoreContainer in ZkController constructor
[ https://issues.apache.org/jira/browse/SOLR-3731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13444196#comment-13444196 ] Sami Siren commented on SOLR-3731: -- bq. i raised the loop to go even longer and still sometimes see it I think. How high did you go? ZkController has retryCount = 120, sleep 500 ms (those were used before switching to use mock) Disallow null CoreContainer in ZkController constructor --- Key: SOLR-3731 URL: https://issues.apache.org/jira/browse/SOLR-3731 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Sami Siren Assignee: Sami Siren Priority: Minor Fix For: 4.0 Attachments: SOLR-3731.patch Currently some tests use null CoreContainer when using ZkController directly in tests and ZKController has to deal with this. I'd like to remove this possibility. -- 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3731) Disallow null CoreContainer in ZkController constructor
[ https://issues.apache.org/jira/browse/SOLR-3731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13444346#comment-13444346 ] Sami Siren commented on SOLR-3731: -- bq. I did 10 full ant test runs on my box (on trunk as of 2 hrs ago) and 5 of them still failed. ok, I think need to look into it then.. what kind of machine you are using to run the tests? how long does the test take (roughly) when it fails vs when it succeeds? Disallow null CoreContainer in ZkController constructor --- Key: SOLR-3731 URL: https://issues.apache.org/jira/browse/SOLR-3731 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Sami Siren Assignee: Sami Siren Priority: Minor Fix For: 4.0 Attachments: SOLR-3731.patch Currently some tests use null CoreContainer when using ZkController directly in tests and ZKController has to deal with this. I'd like to remove this possibility. -- 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Reopened] (SOLR-3731) Disallow null CoreContainer in ZkController constructor
[ https://issues.apache.org/jira/browse/SOLR-3731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren reopened SOLR-3731: -- I ran the tests on a slow vm and I do see the failures now, reopening. Disallow null CoreContainer in ZkController constructor --- Key: SOLR-3731 URL: https://issues.apache.org/jira/browse/SOLR-3731 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Sami Siren Assignee: Sami Siren Priority: Minor Fix For: 4.0 Attachments: SOLR-3731.patch Currently some tests use null CoreContainer when using ZkController directly in tests and ZKController has to deal with this. I'd like to remove this possibility. -- 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3507) Refactor parts of solr doing inter node communication to use shardhandlerfactory/shardhandler
[ https://issues.apache.org/jira/browse/SOLR-3507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren updated SOLR-3507: - Attachment: SOLR-3507.patch new patch updated to latest trunk with cleanups. Refactor parts of solr doing inter node communication to use shardhandlerfactory/shardhandler - Key: SOLR-3507 URL: https://issues.apache.org/jira/browse/SOLR-3507 Project: Solr Issue Type: Improvement Reporter: Sami Siren Assignee: Sami Siren Priority: Minor Attachments: SOLR-3507.patch, SOLR-3507.patch, SOLR-3507.patch Sequal to SOLR-3480, the aim is to change most (all?) parts of solr that need to talk to different nodes to use ShardHandlerFacory from corecontainer. -- 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3731) Disallow null CoreContainer in ZkController constructor
[ https://issues.apache.org/jira/browse/SOLR-3731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13442305#comment-13442305 ] Sami Siren commented on SOLR-3731: -- bq. I'm getting frequent fails now in OverseerTest Likely a timing issue, I increased the sleep time in the loop where the shardid is retrieved. Disallow null CoreContainer in ZkController constructor --- Key: SOLR-3731 URL: https://issues.apache.org/jira/browse/SOLR-3731 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Sami Siren Assignee: Sami Siren Priority: Minor Fix For: 4.0 Attachments: SOLR-3731.patch Currently some tests use null CoreContainer when using ZkController directly in tests and ZKController has to deal with this. I'd like to remove this possibility. -- 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-3731) Disallow null CoreContainer in ZkController constructor
Sami Siren created SOLR-3731: Summary: Disallow null CoreContainer in ZkController constructor Key: SOLR-3731 URL: https://issues.apache.org/jira/browse/SOLR-3731 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Sami Siren Priority: Minor Currently some tests use null CoreContainer when using ZkController directly in tests and ZKController has to deal with this. I'd like to remove this possibility. -- 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3731) Disallow null CoreContainer in ZkController constructor
[ https://issues.apache.org/jira/browse/SOLR-3731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren updated SOLR-3731: - Attachment: SOLR-3731.patch patch that changes the following: -ZkController: throw IAE when CoreContainer is null, remove null logic that applies to tests only -OverseerTest: use mock -ZkControllerTest: remove testCoreUnload (this is tested through BasicDistributedZkTest#testCollectionsApi) other methods seem to continue working if a dummy CoreContainer is used Disallow null CoreContainer in ZkController constructor --- Key: SOLR-3731 URL: https://issues.apache.org/jira/browse/SOLR-3731 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Sami Siren Priority: Minor Attachments: SOLR-3731.patch Currently some tests use null CoreContainer when using ZkController directly in tests and ZKController has to deal with this. I'd like to remove this possibility. -- 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-3649) The javabin update request handler does not seem to be working properly when calling solrj method*HttpSolrServer.deleteById(ListString ids).
[ https://issues.apache.org/jira/browse/SOLR-3649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren resolved SOLR-3649. -- Resolution: Fixed Assignee: Sami Siren trunk: 1372346 4.x: 1372351 The javabin update request handler does not seem to be working properly when calling solrj method*HttpSolrServer.deleteById(ListString ids). -- Key: SOLR-3649 URL: https://issues.apache.org/jira/browse/SOLR-3649 Project: Solr Issue Type: Bug Components: clients - java Reporter: Mark Miller Assignee: Sami Siren Priority: Minor Fix For: 4.0 Attachments: SOLR-3649.patch A single Id gets deleted from the index as opposed to the full list. It appears properly in the logs - shows delete of all Ids sent, although all but one remain in the index. As reported on the mailing list http://lucene.472066.n3.nabble.com/Solr-4-Alpha-SolrJ-Indexing-Issue-tp3995781p3996074.html -- 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-3726) Allow more flexibility in configuring the http clients that Solr uses
Sami Siren created SOLR-3726: Summary: Allow more flexibility in configuring the http clients that Solr uses Key: SOLR-3726 URL: https://issues.apache.org/jira/browse/SOLR-3726 Project: Solr Issue Type: Improvement Components: clients - java Reporter: Sami Siren Assignee: Sami Siren Priority: Minor Fix For: 4.0 The purpose of this issue is to allow customizing the configuration process of the http clients that solr uses internally. -- 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3726) Allow more flexibility in configuring the http clients that Solr uses
[ https://issues.apache.org/jira/browse/SOLR-3726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren updated SOLR-3726: - Attachment: SOLR-3726.patch initial patch with a test Allow more flexibility in configuring the http clients that Solr uses - Key: SOLR-3726 URL: https://issues.apache.org/jira/browse/SOLR-3726 Project: Solr Issue Type: Improvement Components: clients - java Reporter: Sami Siren Assignee: Sami Siren Priority: Minor Fix For: 4.0 Attachments: SOLR-3726.patch The purpose of this issue is to allow customizing the configuration process of the http clients that solr uses internally. -- 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3649) The javabin update request handler does not seem to be working properly when calling solrj method*HttpSolrServer.deleteById(ListString ids).
[ https://issues.apache.org/jira/browse/SOLR-3649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren updated SOLR-3649: - Attachment: SOLR-3649.patch Here's a patch that fixes the test for deleting by multiple ids + a proposed fix. The javabin update request handler does not seem to be working properly when calling solrj method*HttpSolrServer.deleteById(ListString ids). -- Key: SOLR-3649 URL: https://issues.apache.org/jira/browse/SOLR-3649 Project: Solr Issue Type: Bug Components: clients - java Reporter: Mark Miller Priority: Minor Fix For: 4.0, 5.0 Attachments: SOLR-3649.patch A single Id gets deleted from the index as opposed to the full list. It appears properly in the logs - shows delete of all Ids sent, although all but one remain in the index. As reported on the mailing list http://lucene.472066.n3.nabble.com/Solr-4-Alpha-SolrJ-Indexing-Issue-tp3995781p3996074.html -- 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-3558) Change SnapPuller to use Solrj
[ https://issues.apache.org/jira/browse/SOLR-3558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren resolved SOLR-3558. -- Resolution: Fixed Fix Version/s: 4.0 I committed this with some additional cleanups Change SnapPuller to use Solrj -- Key: SOLR-3558 URL: https://issues.apache.org/jira/browse/SOLR-3558 Project: Solr Issue Type: Sub-task Reporter: Sami Siren Assignee: Sami Siren Fix For: 4.0 Attachments: SOLR-3558.patch, SOLR-3558.patch Now it uses http client directly -- 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3507) Refactor parts of solr doing inter node communication to use shardhandlerfactory/shardhandler
[ https://issues.apache.org/jira/browse/SOLR-3507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren updated SOLR-3507: - Attachment: SOLR-3507.patch Still pretty much work in progress, everything in core now uses shardhandler, tests pass. Refactor parts of solr doing inter node communication to use shardhandlerfactory/shardhandler - Key: SOLR-3507 URL: https://issues.apache.org/jira/browse/SOLR-3507 Project: Solr Issue Type: Improvement Reporter: Sami Siren Assignee: Sami Siren Priority: Minor Attachments: SOLR-3507.patch, SOLR-3507.patch Sequal to SOLR-3480, the aim is to change most (all?) parts of solr that need to talk to different nodes to use ShardHandlerFacory from corecontainer. -- 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3558) Change SnapPuller to use Solrj
[ https://issues.apache.org/jira/browse/SOLR-3558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren updated SOLR-3558: - Attachment: SOLR-3558.patch Incremental patch that adds a new junit test for the new piece of functionality in HttpSolrServer Change SnapPuller to use Solrj -- Key: SOLR-3558 URL: https://issues.apache.org/jira/browse/SOLR-3558 Project: Solr Issue Type: Sub-task Reporter: Sami Siren Assignee: Sami Siren Attachments: SOLR-3558.patch, SOLR-3558.patch Now it uses http client directly -- 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3507) Refactor parts of solr doing inter node communication to use shardhandlerfactory/shardhandler
[ https://issues.apache.org/jira/browse/SOLR-3507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13401183#comment-13401183 ] Sami Siren commented on SOLR-3507: -- bq. any chance the work you're doing here could also address/fix the problems in SOLR-3491 Yeah, that's the plan. I believe the current patch already addresses the issues mentioned in SOLR-3491 but I need to double-check before committing this. Refactor parts of solr doing inter node communication to use shardhandlerfactory/shardhandler - Key: SOLR-3507 URL: https://issues.apache.org/jira/browse/SOLR-3507 Project: Solr Issue Type: Improvement Reporter: Sami Siren Assignee: Sami Siren Priority: Minor Attachments: SOLR-3507.patch Sequal to SOLR-3480, the aim is to change most (all?) parts of solr that need to talk to different nodes to use ShardHandlerFacory from corecontainer. -- 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3488) Create a Collections API for SolrCloud
[ https://issues.apache.org/jira/browse/SOLR-3488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13399117#comment-13399117 ] Sami Siren commented on SOLR-3488: -- bq. Yeah - basically, either every n seconds, or when the overseer sees a new node come or go, it looks at each collection, checks its replication factor, and either adds or removes nodes to match it given the nodes that are currently up. So with some lag, whatever you set for the replication will eventually be matched no matter the failures or random state of the cluster when the collection is created or its replication factor changed. That sounds like a good goal. I think we need to have special handling for situation where whole cluster/collection is bounced or some planned maintenance is to be done. Hdfs has this feature called safe mode that is enabled on startup (and can be turned on at any point) and while in that mode replication of blocks is prohibited. When certain percentage of blocks are availabe it moves away from this mode. Something like that might work in solr context also - meaning no shard reorg would happen until certain percentage of the shards are available or solr is specifically told to leave this mode. http://hadoop.apache.org/hdfs/docs/current/hdfs_user_guide.html#Safemode Create a Collections API for SolrCloud -- Key: SOLR-3488 URL: https://issues.apache.org/jira/browse/SOLR-3488 Project: Solr Issue Type: New Feature Components: SolrCloud Reporter: Mark Miller Assignee: Mark Miller Attachments: SOLR-3488.patch, SOLR-3488.patch, SOLR-3488.patch, SOLR-3488_2.patch -- 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3488) Create a Collections API for SolrCloud
[
https://issues.apache.org/jira/browse/SOLR-3488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13397362#comment-13397362
]
Sami Siren commented on SOLR-3488:
--
Mark, nice work.
bq. I'm still somewhat unsure about handing failures though...
IMO Fail fast: at minimum an error should be reported back (the completed queue
Yonik mentions?). It seems that in the latest patch even in case of failure the
job is removed from queue.
bq. I also have not switched to requiring or respecting a replication factor -
I was thinking perhaps specifying nothing or -1 would give you what you have
now? An infinite rep factor? And we would enforce a lower rep factor if
requested?
Sounds good to me.
bq. I'm not sure how replication factor would be enforced though? The Oveerseer
just periodically prunes and adds given what it sees and what the rep factor
is? Is that how failures should be handled? Don't readd to the queue, just let
the periodic job attempt to fix things later?
I would first implement the simplest? case first where if not enough nodes are
available to meet #shards and/or #replication factor: report error to user and
do not try to create the collection. Or did you mean at runtime after the
collection has been created?
I have one question about the patch specifically in the
OverseerCollectionProcessor where you create the collection: why do you need
the collection param?
In context of creating N * R cluster: why don't you just go though live nodes
to find available nodes and perhaps then based on some strategy class create
specific shards (with shardids) to specific nodes? The rest of the overseer
would have to respect that same strategy (instead of the dummy AssignShard that
is now used) so that things would not break when new nodes are attached to the
collection. Perhaps this strategy could also handle things like time based
sharding and whatnot?
bq. it should be easy to merge but I think that it'd be also good to start
committing your patch and improve things on SVN from now on to ease code review
(no patch merging) and concurrent works.
+1 for committing this as is, there are some minor weak spots in the current
patch like checking the input for the collections api requests (unexisitng
params cause OverseerCollectionProcessor to die with NPE), reporting back input
errors etc. put lets just put this in and open more jira issues to cover the
improvement tasks and bugs?
One more thing: I am seeing BasicDistributedZkTest failing (not just
sporadically), nut sure if it is related, with the following error:
{code}
[junit4] ERROR 0.00s J1 | BasicDistributedZkTest (suite)
[junit4] Throwable #1: java.lang.AssertionError: ERROR:
SolrIndexSearcher opens=496 closes=494
[junit4]at
__randomizedtesting.SeedInfo.seed([F1C0A91EB78BAB39]:0)
[junit4]at org.junit.Assert.fail(Assert.java:93)
[junit4]at
org.apache.solr.SolrTestCaseJ4.endTrackingSearchers(SolrTestCaseJ4.java:190)
{code}
Create a Collections API for SolrCloud
--
Key: SOLR-3488
URL: https://issues.apache.org/jira/browse/SOLR-3488
Project: Solr
Issue Type: New Feature
Components: SolrCloud
Reporter: Mark Miller
Assignee: Mark Miller
Attachments: SOLR-3488.patch, SOLR-3488.patch, SOLR-3488.patch,
SOLR-3488_2.patch
--
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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-3558) Change SnapPuller to use Solrj
Sami Siren created SOLR-3558: Summary: Change SnapPuller to use Solrj Key: SOLR-3558 URL: https://issues.apache.org/jira/browse/SOLR-3558 Project: Solr Issue Type: Sub-task Reporter: Sami Siren Assignee: Sami Siren Now it uses http client directly -- 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3558) Change SnapPuller to use Solrj
[ https://issues.apache.org/jira/browse/SOLR-3558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren updated SOLR-3558: - Attachment: SOLR-3558.patch patch that removes direct http client usage from SnapPuller Change SnapPuller to use Solrj -- Key: SOLR-3558 URL: https://issues.apache.org/jira/browse/SOLR-3558 Project: Solr Issue Type: Sub-task Reporter: Sami Siren Assignee: Sami Siren Attachments: SOLR-3558.patch Now it uses http client directly -- 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-3379) Make logging of threadpool configuration report correct values
[ https://issues.apache.org/jira/browse/SOLR-3379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren resolved SOLR-3379. -- Resolution: Fixed I missed this issue completely earlier, sorry about that. I merged my earlier commit from 4.x (1332160) so this is now fixed also in 3.6.1 (1351779). Thanks David for reporting the problem and also providing the fix! Make logging of threadpool configuration report correct values -- Key: SOLR-3379 URL: https://issues.apache.org/jira/browse/SOLR-3379 Project: Solr Issue Type: Improvement Affects Versions: 3.6, 4.0 Reporter: David M. Lyle Assignee: Sami Siren Priority: Minor Fix For: 4.0, 3.6.1 Attachments: SOLR-3379-3x_branch.patch, SOLR-3379-trunk.patch SOLR-3221 allows configuration of the shard handler thread pool. When the thread pool configuration is changed the configuration changed is logged but the value reported is always the socket timeout. This patch will report the value of the configuration item changed. -- 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2054) Remove StAX libraries from trunk (java6)
[
https://issues.apache.org/jira/browse/SOLR-2054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13295573#comment-13295573
]
Sami Siren commented on SOLR-2054:
--
fwiw: when parsing 1m simple update 1 doc xml messages the woodstox
(com.ctc.wstx.sr.ValidatingStreamReader, 13068ms) seems to be roughly 2 times
as fast as the jdk impl
(com.sun.org.apache.xerces.internal.impl.XMLStreamReaderImpl, 21433ms).
I think this all comes down to how significant portion of total ingestion time
is being spent in parsing xml (vs all the rest).
Test code:
{code}
XMLStreamReader parser =
inputFactory.createXMLStreamReader( new StringReader( xml ) );
parser.next(); // read the START document...
//null for the processor is all right here
XMLLoader loader = new XMLLoader();
SolrInputDocument doc = loader.readDoc( parser );
}
{code}
Remove StAX libraries from trunk (java6)
Key: SOLR-2054
URL: https://issues.apache.org/jira/browse/SOLR-2054
Project: Solr
Issue Type: Task
Reporter: Ryan McKinley
Priority: Trivial
Fix For: 4.1
Java 6 includes the StAX libraries, so there is no need to include them
directly
--
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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-3466) org.apache.solr.common.SolrException: org.apache.lucene.queryParser.ParseException: Cannot parse
[
https://issues.apache.org/jira/browse/SOLR-3466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sami Siren resolved SOLR-3466.
--
Resolution: Not A Problem
Closing this as it seems that this is expected behavior.
org.apache.solr.common.SolrException:
org.apache.lucene.queryParser.ParseException: Cannot parse
Key: SOLR-3466
URL: https://issues.apache.org/jira/browse/SOLR-3466
Project: Solr
Issue Type: Test
Components: clients - java
Reporter: phatak.prachi
Priority: Blocker
Labels: newbie
My configuration
fieldType name=textgen class=solr.TextField positionIncrementGap=100
analyzer type=index
tokenizer class=solr.WhitespaceTokenizerFactory/
filter class=solr.StopFilterFactory ignoreCase=true
words=stopwords.txt enablePositionIncrements=true /
filter class=solr.EdgeNGramFilterFactory minGramSize=1
maxGramSize=15 side=front/
filter class=solr.LowerCaseFilterFactory/
filter class=solr.RemoveDuplicatesTokenFilterFactory/
/analyzer
analyzer type=query
tokenizer class=solr.WhitespaceTokenizerFactory /
filter class=solr.SynonymFilterFactory synonyms=synonyms.txt
ignoreCase=true expand=true/
filter class=solr.EdgeNGramFilterFactory minGramSize=1
maxGramSize=15 side=front/
filter class=solr.StopFilterFactory
ignoreCase=true
words=stopwords.txt
enablePositionIncrements=true
/
filter class=solr.WordDelimiterFilterFactory
preserveOriginal=1 generateWordParts=1 generateNumberParts=1
catenateWords=1 catenateNumbers=1 catenateAll=0 splitOnCaseChange=0/
filter class=solr.LowerCaseFilterFactory/
filter class=solr.RemoveDuplicatesTokenFilterFactory/
/analyzer
/fieldType
Data:
Coke Product Softdrink
Coke Product Softdrink
Coke Product Softdrink
Coke() ProductSoftdrink
Pepsi Product Softdrink
Pepsi Product Softdrink
Other Product Soft(drink)
Domestic-Beer Beer-34333
Domestic-Beer Beer-34333
Domestic-Beer Beer
Domestic Beer Beer
Import Beer+9 Beer
Import Beer Beer
Import Beer Beer
T-Shirt Shirt
T-Shirt Shirt
T-Shirt Shirt
T-Shirt Shirt-34333
T-Shirt Shirt
BlouseWomen's-Wear
BlouseWomen's-Wear
Skirt%3 Women's Wear
Skirt Women's Wear
Dress Formal Wear
Whenever I search for Soft(, it gives me the following error and if try to
search 34333, it gives no results
SEVERE: org.apache.solr.common.SolrException:
org.apache.lucene.queryParser.ParseException: Cannot parse
'+DIMENSION:Product^1.0 +( (SKU:soft(*^1.0 DIM_ATTR_ONE:soft(*^1.0 DIM_ATTR_
Was expecting one of:
AND ...
OR ...
NOT ...
+ ...
- ...
( ...
) ...
* ...
^ ...
QUOTED ...
TERM ...
PREFIXTERM ...
WILDTERM ...
[ ...
{ ...
NUMBER ...
at
org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:105)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:173)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1368)
at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:356)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:252)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1212)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:399)
at
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
at
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766)
at
org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:450)
at
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
at
org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
at
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:326)
at
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
at
org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:928)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549)
at
[jira] [Resolved] (SOLR-3543) JavaBinLoader catches (and logs) exceptions and the (solrj)client has no idea that an update failed
[ https://issues.apache.org/jira/browse/SOLR-3543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren resolved SOLR-3543. -- Resolution: Fixed JavaBinLoader catches (and logs) exceptions and the (solrj)client has no idea that an update failed --- Key: SOLR-3543 URL: https://issues.apache.org/jira/browse/SOLR-3543 Project: Solr Issue Type: Bug Components: update Reporter: Sami Siren Fix For: 4.0 Attachments: SOLR-3543.patch When submitting docs to solr with the javabin wire format server responses with 200 ok even when there was an error. The exception is only logged at the server. When using the xml format error is correctly reported back -- 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-3511) Refactor overseer to use a distributed workqueue
[ https://issues.apache.org/jira/browse/SOLR-3511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren resolved SOLR-3511. -- Resolution: Fixed Committed to 4.x too Refactor overseer to use a distributed workqueue -- Key: SOLR-3511 URL: https://issues.apache.org/jira/browse/SOLR-3511 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Sami Siren Assignee: Sami Siren Fix For: 4.0 Attachments: SOLR-3511.patch, SOLR-3511.patch By using a queue overseer becomes a watch free, a lot simpler and probably less buggy too. -- 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-3540) MultiCoreExampleTest and MultiCoreEmbedded test clash with each other
Sami Siren created SOLR-3540:
Summary: MultiCoreExampleTest and MultiCoreEmbedded test clash
with each other
Key: SOLR-3540
URL: https://issues.apache.org/jira/browse/SOLR-3540
Project: Solr
Issue Type: Bug
Affects Versions: 4.0
Reporter: Sami Siren
Assignee: Sami Siren
Priority: Minor
When those two tests are run at same time one of them is going to fail with
error like this:
{code}
java.lang.AssertionError
at __randomizedtesting.SeedInfo.seed([B44AE18D746BCD54:3062FA7EBBB8C061]:0)
at org.apache.solr.update.TransactionLog.init(TransactionLog.java:163)
at org.apache.solr.update.TransactionLog.init(TransactionLog.java:133)
at org.apache.solr.update.UpdateLog.ensureLog(UpdateLog.java:636)
{code}
This is reproducible with:
{code}
ant -Dtests.jvms=14 test
-Dtests.class=org.apache.solr.client.solrj.embedded.*
{code}
Looks like this is because they share the directory
example/multicore/core0/data/
--
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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3540) MultiCoreExampleTest and MultiCoreEmbedded test clash with each other
[
https://issues.apache.org/jira/browse/SOLR-3540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sami Siren updated SOLR-3540:
-
Attachment: SOLR-3540.patch
this patch should fix the issue
MultiCoreExampleTest and MultiCoreEmbedded test clash with each other
-
Key: SOLR-3540
URL: https://issues.apache.org/jira/browse/SOLR-3540
Project: Solr
Issue Type: Bug
Affects Versions: 4.0
Reporter: Sami Siren
Assignee: Sami Siren
Priority: Minor
Attachments: SOLR-3540.patch
When those two tests are run at same time one of them is going to fail with
error like this:
{code}
java.lang.AssertionError
at __randomizedtesting.SeedInfo.seed([B44AE18D746BCD54:3062FA7EBBB8C061]:0)
at org.apache.solr.update.TransactionLog.init(TransactionLog.java:163)
at org.apache.solr.update.TransactionLog.init(TransactionLog.java:133)
at org.apache.solr.update.UpdateLog.ensureLog(UpdateLog.java:636)
{code}
This is reproducible with:
{code}
ant -Dtests.jvms=14 test
-Dtests.class=org.apache.solr.client.solrj.embedded.*
{code}
Looks like this is because they share the directory
example/multicore/core0/data/
--
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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-3541) Not all libs are copied into solrj-lib
[ https://issues.apache.org/jira/browse/SOLR-3541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren resolved SOLR-3541. -- Resolution: Fixed Assignee: Sami Siren Thijs: I just committed the fix. Thanks! Not all libs are copied into solrj-lib -- Key: SOLR-3541 URL: https://issues.apache.org/jira/browse/SOLR-3541 Project: Solr Issue Type: Bug Components: clients - java Affects Versions: 4.0 Reporter: Thijs Vonk Assignee: Sami Siren Fix For: 4.0 Attachments: SOLR-3541-4x.patch, SOLR-3541-trunk.patch The httpclient, httpmine and httpcore jars are missing in solrj-lib. I'll attach a patch -- 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-3543) JavaBinLoader catches (and logs) exceptions and the (solrj)client has no idea that an update failed
Sami Siren created SOLR-3543: Summary: JavaBinLoader catches (and logs) exceptions and the (solrj)client has no idea that an update failed Key: SOLR-3543 URL: https://issues.apache.org/jira/browse/SOLR-3543 Project: Solr Issue Type: Bug Components: update Reporter: Sami Siren Fix For: 4.0 When submitting docs to solr with the javabin wire format server responses with 200 ok even when there was an error. The exception is only logged at the server. When using the xml format error is correctly reported back -- 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3543) JavaBinLoader catches (and logs) exceptions and the (solrj)client has no idea that an update failed
[ https://issues.apache.org/jira/browse/SOLR-3543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren updated SOLR-3543: - Attachment: SOLR-3543.patch here's a patch that adds a test for this and a proposed fix (which is just changing JavaBinLoader to not catchlog the exception) JavaBinLoader catches (and logs) exceptions and the (solrj)client has no idea that an update failed --- Key: SOLR-3543 URL: https://issues.apache.org/jira/browse/SOLR-3543 Project: Solr Issue Type: Bug Components: update Reporter: Sami Siren Fix For: 4.0 Attachments: SOLR-3543.patch When submitting docs to solr with the javabin wire format server responses with 200 ok even when there was an error. The exception is only logged at the server. When using the xml format error is correctly reported back -- 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3532) Promote shutdown method to SolrServer
[ https://issues.apache.org/jira/browse/SOLR-3532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren updated SOLR-3532: - Attachment: SOLR-3532.patch trivial patch Promote shutdown method to SolrServer - Key: SOLR-3532 URL: https://issues.apache.org/jira/browse/SOLR-3532 Project: Solr Issue Type: Improvement Components: clients - java Reporter: Sami Siren Assignee: Sami Siren Priority: Minor Fix For: 4.0 Attachments: SOLR-3532.patch Currently every java client implements shutdown, (LBHttpSolrServer has close). I think it makes sense to promote #shutdown method to SolrServer. -- 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-3532) Promote shutdown method to SolrServer
Sami Siren created SOLR-3532: Summary: Promote shutdown method to SolrServer Key: SOLR-3532 URL: https://issues.apache.org/jira/browse/SOLR-3532 Project: Solr Issue Type: Improvement Components: clients - java Reporter: Sami Siren Assignee: Sami Siren Priority: Minor Fix For: 4.0 Attachments: SOLR-3532.patch Currently every java client implements shutdown, (LBHttpSolrServer has close). I think it makes sense to promote #shutdown method to SolrServer. -- 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-3532) Promote shutdown method to SolrServer
[ https://issues.apache.org/jira/browse/SOLR-3532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren resolved SOLR-3532. -- Resolution: Fixed trunk: r1349127 4.x: r1349129 Promote shutdown method to SolrServer - Key: SOLR-3532 URL: https://issues.apache.org/jira/browse/SOLR-3532 Project: Solr Issue Type: Improvement Components: clients - java Reporter: Sami Siren Assignee: Sami Siren Priority: Minor Fix For: 4.0 Attachments: SOLR-3532.patch Currently every java client implements shutdown, (LBHttpSolrServer has close). I think it makes sense to promote #shutdown method to SolrServer. -- 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-861) SOLRJ Client does not release connections 'nicely' by default
[ https://issues.apache.org/jira/browse/SOLR-861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13291678#comment-13291678 ] Sami Siren commented on SOLR-861: - bq. it's not clear to me if this has already been addressed by the new client in SOLR-2020 - can you please triage for 4.0? I have not done anything specific to address this issue. Since opening this issue a shutdown() method was added in HttpSolrServer that should take care of releasing the resources, if that's not working then there's a bug. SOLRJ Client does not release connections 'nicely' by default - Key: SOLR-861 URL: https://issues.apache.org/jira/browse/SOLR-861 Project: Solr Issue Type: Bug Components: clients - java Affects Versions: 1.3 Environment: linux Reporter: Ian Holsman Assignee: Sami Siren Fix For: 4.0 Attachments: SimpleClient.patch as-is the SolrJ Commons HttpServer uses the multi-threaded http connection manager. This manager seems to keep the connection alive for the client and does not close it when the object is dereferenced. When you keep on opening new CommonsHttpSolrServer instances it results in a socket that is stuck in the CLOSE_WAIT state. Eventually this will use up all your available file handles, causing your client to die a painful death. The solution I propose is that it uses a 'Simple' HttpConnectionManager which is set to not reuse connections if you don't specify a HttpClient. -- 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3511) Refactor overseer to use a distributed workqueue
[ https://issues.apache.org/jira/browse/SOLR-3511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren updated SOLR-3511: - Attachment: SOLR-3511.patch New patch with cleanups and minor improvements Refactor overseer to use a distributed workqueue -- Key: SOLR-3511 URL: https://issues.apache.org/jira/browse/SOLR-3511 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Sami Siren Assignee: Sami Siren Attachments: SOLR-3511.patch, SOLR-3511.patch By using a queue overseer becomes a watch free, a lot simpler and probably less buggy too. -- 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3511) Refactor overseer to use a distributed workqueue
[ https://issues.apache.org/jira/browse/SOLR-3511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13291556#comment-13291556 ] Sami Siren commented on SOLR-3511: -- Committed to trunk, I'll let it bake there for a while before backporting to 4.x Refactor overseer to use a distributed workqueue -- Key: SOLR-3511 URL: https://issues.apache.org/jira/browse/SOLR-3511 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Sami Siren Assignee: Sami Siren Fix For: 4.0 Attachments: SOLR-3511.patch, SOLR-3511.patch By using a queue overseer becomes a watch free, a lot simpler and probably less buggy too. -- 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3511) Refactor overseer to use a distributed workqueue
[ https://issues.apache.org/jira/browse/SOLR-3511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren updated SOLR-3511: - Fix Version/s: 4.0 Refactor overseer to use a distributed workqueue -- Key: SOLR-3511 URL: https://issues.apache.org/jira/browse/SOLR-3511 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Sami Siren Assignee: Sami Siren Fix For: 4.0 Attachments: SOLR-3511.patch, SOLR-3511.patch By using a queue overseer becomes a watch free, a lot simpler and probably less buggy too. -- 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-3511) Refactor overseer to use a distributed workqueue
Sami Siren created SOLR-3511: Summary: Refactor overseer to use a distributed workqueue Key: SOLR-3511 URL: https://issues.apache.org/jira/browse/SOLR-3511 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Sami Siren Assignee: Sami Siren By using a queue overseer becomes a watch free, a lot simpler and probably less buggy too. -- 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3511) Refactor overseer to use a distributed workqueue
[ https://issues.apache.org/jira/browse/SOLR-3511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren updated SOLR-3511: - Attachment: SOLR-3511.patch Work in progress, uses DistributedQueue from zk recipes. All tests pass, lot of cleaning up to do. Refactor overseer to use a distributed workqueue -- Key: SOLR-3511 URL: https://issues.apache.org/jira/browse/SOLR-3511 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Sami Siren Assignee: Sami Siren Attachments: SOLR-3511.patch By using a queue overseer becomes a watch free, a lot simpler and probably less buggy too. -- 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3511) Refactor overseer to use a distributed workqueue
[ https://issues.apache.org/jira/browse/SOLR-3511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13289384#comment-13289384 ] Sami Siren commented on SOLR-3511: -- bq. but should we leverage this for collection creation as well or will that be a separate work queue I think that the same queue could be used easily. The objects that are stored in queue (serialized in json) are currently specific to core state management and leader announcements but it should be easy to make that part + the actual processing commands in overseer more general. Refactor overseer to use a distributed workqueue -- Key: SOLR-3511 URL: https://issues.apache.org/jira/browse/SOLR-3511 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Sami Siren Assignee: Sami Siren Attachments: SOLR-3511.patch By using a queue overseer becomes a watch free, a lot simpler and probably less buggy too. -- 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-3480) Refactor httpclient impl details into a utility class
[ https://issues.apache.org/jira/browse/SOLR-3480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren resolved SOLR-3480. -- Resolution: Fixed Fix Version/s: 4.0 Refactor httpclient impl details into a utility class - Key: SOLR-3480 URL: https://issues.apache.org/jira/browse/SOLR-3480 Project: Solr Issue Type: Improvement Components: clients - java, replication (java), SolrCloud Reporter: Sami Siren Assignee: Sami Siren Priority: Minor Fix For: 4.0 Attachments: SOLR-3480.patch Currently there are multiple classes that deal with the impl details of httpclient when setting timeouts, basic auth details, retry handling, compression etc. I am proposing that we instead move this functionality into a reusable utility class. The ultimate goal is to be able to easily use for example https or basic auth (that can already be used in some parts of solr) throughout solr but that will require some more work. I will submit a patch shortly. -- 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-3507) Refactor parts of solr doing inter node communication to use shardhandlerfactory/shardhandler
Sami Siren created SOLR-3507: Summary: Refactor parts of solr doing inter node communication to use shardhandlerfactory/shardhandler Key: SOLR-3507 URL: https://issues.apache.org/jira/browse/SOLR-3507 Project: Solr Issue Type: Bug Reporter: Sami Siren Assignee: Sami Siren Priority: Minor Sequal to SOLR-3480, the aim is to change most (all?) parts of solr that need to talk to different nodes to use ShardHandlerFacory from corecontainer. -- 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3507) Refactor parts of solr doing inter node communication to use shardhandlerfactory/shardhandler
[ https://issues.apache.org/jira/browse/SOLR-3507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren updated SOLR-3507: - Issue Type: Improvement (was: Bug) Refactor parts of solr doing inter node communication to use shardhandlerfactory/shardhandler - Key: SOLR-3507 URL: https://issues.apache.org/jira/browse/SOLR-3507 Project: Solr Issue Type: Improvement Reporter: Sami Siren Assignee: Sami Siren Priority: Minor Sequal to SOLR-3480, the aim is to change most (all?) parts of solr that need to talk to different nodes to use ShardHandlerFacory from corecontainer. -- 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3507) Refactor parts of solr doing inter node communication to use shardhandlerfactory/shardhandler
[ https://issues.apache.org/jira/browse/SOLR-3507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren updated SOLR-3507: - Attachment: SOLR-3507.patch Initial patch. Move most of httpclient instantiation to httpshardhandlerfactory. Still some more work to do... Refactor parts of solr doing inter node communication to use shardhandlerfactory/shardhandler - Key: SOLR-3507 URL: https://issues.apache.org/jira/browse/SOLR-3507 Project: Solr Issue Type: Improvement Reporter: Sami Siren Assignee: Sami Siren Priority: Minor Attachments: SOLR-3507.patch Sequal to SOLR-3480, the aim is to change most (all?) parts of solr that need to talk to different nodes to use ShardHandlerFacory from corecontainer. -- 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3433) binary field returns differently when do the distribute search
[ https://issues.apache.org/jira/browse/SOLR-3433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13283161#comment-13283161 ] Sami Siren commented on SOLR-3433: -- It seems this has been fixed in trunk: SOLR-3035. Alex, can you please give me some more details on how you tested this and what versions, especially did you see this still happen in trunk. binary field returns differently when do the distribute search -- Key: SOLR-3433 URL: https://issues.apache.org/jira/browse/SOLR-3433 Project: Solr Issue Type: Bug Components: search Affects Versions: 3.5, 3.6, 4.0 Environment: linux, amazon ec2 Reporter: Alex Liu When install multiple nodes (more than one node), the repeated searches through solr returns binary data back differently each time. lst name=responseHeaderint name=status0/intint name=QTime26/intlst name=paramsstr name=qtext_col:woodman/str/lst/lstresult name=response numFound=1 start=0 maxScore=0.13258252docstr name=binary_col[B:[B@714fef9f/str lst name=responseHeaderint name=status0/intint name=QTime11/intlst name=paramsstr name=qtext_col:woodman/str/lst/lstresult name=response numFound=1 start=0 maxScore=0.13258252docstr name=binary_col[B:[B@4be22114/str check this link, some one report the same issue. http://grokbase.com/t/lucene/solr-user/11beyhmxjw/distributed-search-and-binary-fields-w-solr-3-4 it works for a single node, but fails for multiple node. it's something related to distributed search -- 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-3487) XMLResponseParser does not handle named lists in doc fields
Sami Siren created SOLR-3487: Summary: XMLResponseParser does not handle named lists in doc fields Key: SOLR-3487 URL: https://issues.apache.org/jira/browse/SOLR-3487 Project: Solr Issue Type: Bug Reporter: Sami Siren Priority: Minor Fix For: 4.0 For example when one uses xml and specifies fl to contain [explain style=nl] parser currently cannot handle the response. I also noticed that the example tests are not run with xml (that would have caught this earlier). -- 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3487) XMLResponseParser does not handle named lists in doc fields
[ https://issues.apache.org/jira/browse/SOLR-3487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren updated SOLR-3487: - Attachment: SOLR-3487.patch here's a proposed fix. I also added a test class that runs the example tests by using the xml format. will commit shortly unless someone stops me... XMLResponseParser does not handle named lists in doc fields --- Key: SOLR-3487 URL: https://issues.apache.org/jira/browse/SOLR-3487 Project: Solr Issue Type: Bug Reporter: Sami Siren Priority: Minor Fix For: 4.0 Attachments: SOLR-3487.patch For example when one uses xml and specifies fl to contain [explain style=nl] parser currently cannot handle the response. I also noticed that the example tests are not run with xml (that would have caught this earlier). -- 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3487) XMLResponseParser does not handle named lists in doc fields
[ https://issues.apache.org/jira/browse/SOLR-3487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren updated SOLR-3487: - Component/s: clients - java XMLResponseParser does not handle named lists in doc fields --- Key: SOLR-3487 URL: https://issues.apache.org/jira/browse/SOLR-3487 Project: Solr Issue Type: Bug Components: clients - java Reporter: Sami Siren Priority: Minor Fix For: 4.0 Attachments: SOLR-3487.patch For example when one uses xml and specifies fl to contain [explain style=nl] parser currently cannot handle the response. I also noticed that the example tests are not run with xml (that would have caught this earlier). -- 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3433) binary field returns differently when do the distribute search
[ https://issues.apache.org/jira/browse/SOLR-3433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13283191#comment-13283191 ] Sami Siren commented on SOLR-3433: -- From what I understand from SOLR-3035 it was not about single node. I also did some tests with multiple shards and did not see this problem on trunk. Perhaps I am missing something important. Could you provide a test case that demonstrates the problem on trunk? binary field returns differently when do the distribute search -- Key: SOLR-3433 URL: https://issues.apache.org/jira/browse/SOLR-3433 Project: Solr Issue Type: Bug Components: search Affects Versions: 3.5, 3.6, 4.0 Environment: linux, amazon ec2 Reporter: Alex Liu When install multiple nodes (more than one node), the repeated searches through solr returns binary data back differently each time. lst name=responseHeaderint name=status0/intint name=QTime26/intlst name=paramsstr name=qtext_col:woodman/str/lst/lstresult name=response numFound=1 start=0 maxScore=0.13258252docstr name=binary_col[B:[B@714fef9f/str lst name=responseHeaderint name=status0/intint name=QTime11/intlst name=paramsstr name=qtext_col:woodman/str/lst/lstresult name=response numFound=1 start=0 maxScore=0.13258252docstr name=binary_col[B:[B@4be22114/str check this link, some one report the same issue. http://grokbase.com/t/lucene/solr-user/11beyhmxjw/distributed-search-and-binary-fields-w-solr-3-4 it works for a single node, but fails for multiple node. it's something related to distributed search -- 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-3487) XMLResponseParser does not handle named lists in doc fields
[ https://issues.apache.org/jira/browse/SOLR-3487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren resolved SOLR-3487. -- Resolution: Fixed Assignee: Sami Siren XMLResponseParser does not handle named lists in doc fields --- Key: SOLR-3487 URL: https://issues.apache.org/jira/browse/SOLR-3487 Project: Solr Issue Type: Bug Components: clients - java Reporter: Sami Siren Assignee: Sami Siren Priority: Minor Fix For: 4.0 Attachments: SOLR-3487.patch For example when one uses xml and specifies fl to contain [explain style=nl] parser currently cannot handle the response. I also noticed that the example tests are not run with xml (that would have caught this earlier). -- 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3488) Create a Collections API for SolrCloud
[ https://issues.apache.org/jira/browse/SOLR-3488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13283478#comment-13283478 ] Sami Siren commented on SOLR-3488: -- bq. should we instead add a create node to a queue in zookeeper? Make the overseer responsible for checking for any jobs there, completing them (if needed) and then removing the job from the queue? I like this idea, i would also refactor current zkcontroller-overseer communication to use this same technique. Create a Collections API for SolrCloud -- Key: SOLR-3488 URL: https://issues.apache.org/jira/browse/SOLR-3488 Project: Solr Issue Type: New Feature Components: SolrCloud Reporter: Mark Miller Assignee: Mark Miller -- 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-3480) Refactor httpclient impl details into a utility class
Sami Siren created SOLR-3480: Summary: Refactor httpclient impl details into a utility class Key: SOLR-3480 URL: https://issues.apache.org/jira/browse/SOLR-3480 Project: Solr Issue Type: Improvement Components: clients - java, replication (java), SolrCloud Reporter: Sami Siren Assignee: Sami Siren Priority: Minor Currently there are multiple classes that deal with the impl details of httpclient when setting timeouts, basic auth details, retry handling, compression etc. I am proposing that we instead move this functionality into a reusable utility class. The ultimate goal is to be able to easily use for example https or basic auth (that can already be used in some parts of solr) throughout solr but that will require some more work. I will submit a patch shortly. -- 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3480) Refactor httpclient impl details into a utility class
[ https://issues.apache.org/jira/browse/SOLR-3480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren updated SOLR-3480: - Attachment: SOLR-3480.patch Refactor httpclient impl details into a utility class - Key: SOLR-3480 URL: https://issues.apache.org/jira/browse/SOLR-3480 Project: Solr Issue Type: Improvement Components: clients - java, replication (java), SolrCloud Reporter: Sami Siren Assignee: Sami Siren Priority: Minor Attachments: SOLR-3480.patch Currently there are multiple classes that deal with the impl details of httpclient when setting timeouts, basic auth details, retry handling, compression etc. I am proposing that we instead move this functionality into a reusable utility class. The ultimate goal is to be able to easily use for example https or basic auth (that can already be used in some parts of solr) throughout solr but that will require some more work. I will submit a patch shortly. -- 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-3374) HttpClient jar not included in distribution
[ https://issues.apache.org/jira/browse/SOLR-3374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren resolved SOLR-3374. -- Resolution: Fixed HttpClient jar not included in distribution --- Key: SOLR-3374 URL: https://issues.apache.org/jira/browse/SOLR-3374 Project: Solr Issue Type: Improvement Components: clients - java Affects Versions: 3.6 Reporter: Roger Håkansson Assignee: Sami Siren Priority: Minor Fix For: 3.6.1 Attachments: SOLR-3374.patch In 3.6 CommonsHttpSolrServer is deprecated in favor for HttpSolrServer however in the distribution under solrj-lib, non of the required jar files for HttpClient 4.x is included -- 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3374) HttpClient jar not included in distribution
[ https://issues.apache.org/jira/browse/SOLR-3374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren updated SOLR-3374: - Attachment: SOLR-3374.patch here's a patch that adds the related jars into solrj-lib/optional HttpClient jar not included in distribution --- Key: SOLR-3374 URL: https://issues.apache.org/jira/browse/SOLR-3374 Project: Solr Issue Type: Improvement Components: clients - java Affects Versions: 3.6 Reporter: Roger Håkansson Assignee: Sami Siren Priority: Minor Fix For: 3.6.1 Attachments: SOLR-3374.patch In 3.6 CommonsHttpSolrServer is deprecated in favor for HttpSolrServer however in the distribution under solrj-lib, non of the required jar files for HttpClient 4.x is included -- 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-3375) Charset problem using HttpSolrServer instead of CommonsHttpSolrServer
[
https://issues.apache.org/jira/browse/SOLR-3375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sami Siren resolved SOLR-3375.
--
Resolution: Fixed
the fix is now committed to 3.6 branch
Charset problem using HttpSolrServer instead of CommonsHttpSolrServer
-
Key: SOLR-3375
URL: https://issues.apache.org/jira/browse/SOLR-3375
Project: Solr
Issue Type: Bug
Components: clients - java
Affects Versions: 3.6
Reporter: Roger Håkansson
Assignee: Sami Siren
Fix For: 3.6.1
Attachments: SolrTest.java, commonshttpsolrserver-dump.txt,
httpsolrserver-dump.txt
I've written an application which sends PDF files to Solr for indexing, but I
also need to index some meta-data which isn't contained inside the PDF.
I recently upgraded to 3.6.0 and when recompiling my app, I got some
deprecated messages which mainly was to switch from CommonsHttpSolrServer to
HttpSolrServer.
The problem I've noticed since doing this, is that all extra fields which I
add is sent to the Solr server as ASCII only, i.e UTF-8/ISO-8859-1 doesn't
matter, anything above char 127 is sent as '?'. This was not the behaviour of
CommonsHttpSolrServer.
I've tracked it down to a line (271 in 3.6.0) in HttpSolrServer.java which is:
entity.addPart(name, new StringBody(value));
The problem is that StringBody(String text) maps to
StringBody(text, text/plain, null);
and in
StringBody(String text, String mimeType, Charset charset)
we have this piece of code:
if (charset == null) {
charset = Charset.forName(US-ASCII);
}
this.content = text.getBytes(charset.name());
this.charset = charset;
So unless charset is set everything is converted to US-ASCII.
On the other hand, in CommonsHttpSolrServer.java (line 310 in 3.6.0) there is
this line
parts.add(new StringPart(p, v, UTF-8));
which adds everything as UTF-8.
The simple solution would be to change the faulty line in HttpSolrServer.java
to
entity.addPart(name, new StringBody(value,Charset.forName(UTF-8)));
However, this doesn't work either since my tests have shown that neither
Jetty or Tomcat recognizes the strings as UTF-8 but interprets them as 8-bit
(8859-1 I guess).
So changing HttpSolrServer.java to
entity.addPart(name, new StringBody(value,Charset.forName(ISO-8859-1)));
actually gives me the same result as using CommonsHttpSolrServer.
But my investigations have shown that there is a difference in how
Commons-HttpClient and HttpClient-4.x works.
Commons-HttpClient sends all parameters as regular POST parameters but
URLEncoded (/update/extract?param1=valueparam2=value2) while
HttpClient-4.x sends them as multipart/form-data messages and I think that
the problem is that each multipart-message should have its own charset
parameter.
I.e HttpClient-4.x sends
---
--jNljZ3jE1sHG529HrzSjZWYEad-6Wu
Content-Disposition: form-data; name=literal.string_txt
åäö
---
But it should probably send something like this
---
--jNljZ3jE1sHG529HrzSjZWYEad-6Wu
Content-Disposition: form-data; name=literal.string_txt
Content-Type: text/plain; charset=utf-8
åäö
---
--
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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3038) Solrj should use javabin wireformat by default with updaterequests
[ https://issues.apache.org/jira/browse/SOLR-3038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13259402#comment-13259402 ] Sami Siren commented on SOLR-3038: -- bq. Having a java client that reads from an old server and writes to a new server does not seem like a crazy thing to support. Correct. I missed this cross version ability completely... Solrj should use javabin wireformat by default with updaterequests -- Key: SOLR-3038 URL: https://issues.apache.org/jira/browse/SOLR-3038 Project: Solr Issue Type: Improvement Components: clients - java Affects Versions: 4.0 Reporter: Sami Siren Priority: Minor The javabin wire format is faster than xml when feeding Solr - it should become the default. -- 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2540) CommitWithin as an Update Request parameter
[
https://issues.apache.org/jira/browse/SOLR-2540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13105247#comment-13105247
]
Sami Siren commented on SOLR-2540:
--
I get a test failure on Linux/Fedora 14
java -version says:
{code}
java version 1.6.0_24
Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode)
{code}
Console output:
{code}
[junit] 15/09/2011 11:43:16 ص org.apache.solr.SolrTestCaseJ4 assertQ
[junit] SEVERE: REQUEST FAILED: xpath=//*[@numFound='1']
[junit] xml response was: ?xml version=1.0 encoding=UTF-8?
[junit] response
[junit] lst name=responseHeaderint name=status0/intint
name=QTime0/int/lstresult name=response numFound=0
start=0/result
[junit] /response
[junit]
[junit] request was:start=0q=id:oneqt=standardrows=20version=2.2
[junit] 15/09/2011 11:43:16 ص org.apache.solr.common.SolrException log
[junit] SEVERE: REQUEST FAILED:
start=0q=id:oneqt=standardrows=20version=2.2:java.lang.RuntimeException:
REQUEST FAILED: xpath=//*[@numFound='1']
[junit] xml response was: ?xml version=1.0 encoding=UTF-8?
[junit] response
[junit] lst name=responseHeaderint name=status0/intint
name=QTime0/int/lstresult name=response numFound=0
start=0/result
[junit] /response
[junit]
[junit] request was:start=0q=id:oneqt=standardrows=20version=2.2
[junit] at
org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:389)
[junit] at
org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:363)
[junit] at
org.apache.solr.handler.extraction.ExtractingRequestHandlerTest.testCommitWithin(ExtractingRequestHandlerTest.java:306)
[junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[junit] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[junit] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[junit] at java.lang.reflect.Method.invoke(Method.java:597)
[junit] at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
[junit] at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
[junit] at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
[junit] at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
[junit] at org.junit.rules.TestWatchman$1.evaluate(TestWatchman.java:48)
[junit] at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
[junit] at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
[junit] at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76)
[junit] at
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:148)
[junit] at
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:50)
[junit] at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
[junit] at
org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
[junit] at
org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
[junit] at
org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
[junit] at
org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
[junit] at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
[junit] at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
[junit] at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
[junit] at
junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:39)
[junit] at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:420)
[junit] at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:911)
[junit] at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:768)
[junit]
[junit] NOTE: reproduce with: ant test
-Dtestcase=ExtractingRequestHandlerTest -Dtestmethod=testCommitWithin
-Dtests.seed=3746e79385edf73e:c0f1416de85bd9:2704bb4f54230c5d
[junit] 15/09/2011 11:43:17 ص org.apache.solr.common.SolrException log
[junit] SEVERE: auto commit error...:java.lang.RuntimeException:
org.apache.lucene.util.ThreadInterruptedException:
java.lang.InterruptedException: sleep interrupted
[junit] at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1138)
[junit] at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:998)
[junit] at
org.apache.solr.update.DirectUpdateHandler2.commit(DirectUpdateHandler2.java:339)
[junit] at
[jira] [Commented] (SOLR-2493) SolrQueryParser constantly parse luceneMatchVersion in solrconfig. Large performance hit.
[ https://issues.apache.org/jira/browse/SOLR-2493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13028620#comment-13028620 ] Sami Siren commented on SOLR-2493: -- Trunk version of Solr has this same problem too, I just timed comparable difference in req/sec when caching the Version vs the current implementation. SolrQueryParser constantly parse luceneMatchVersion in solrconfig. Large performance hit. - Key: SOLR-2493 URL: https://issues.apache.org/jira/browse/SOLR-2493 Project: Solr Issue Type: Bug Components: search Affects Versions: 3.1 Reporter: Stephane Bailliez Priority: Blocker Labels: core, parser, performance, request, solr I' m putting this as blocker as I think this is a serious issue that should be adressed asap with a release. With the current code this is no way near suitable for production use. For each instance created SolrQueryParser calls getSchema().getSolrConfig().getLuceneVersion(luceneMatchVersion, Version.LUCENE_24) instead of using getSchema().getSolrConfig().luceneMatchVersion This creates a massive performance hit. For each request, there is generally 3 query parsers created and each of them will parse the xml node in config which involve creating an instance of XPath and behind the scene the usual factory finder pattern quicks in within the xml parser and does a loadClass. The stack is typically: at org.mortbay.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:363) at com.sun.org.apache.xml.internal.dtm.ObjectFactory.findProviderClass(ObjectFactory.java:506) at com.sun.org.apache.xml.internal.dtm.ObjectFactory.lookUpFactoryClass(ObjectFactory.java:217) at com.sun.org.apache.xml.internal.dtm.ObjectFactory.createObject(ObjectFactory.java:131) at com.sun.org.apache.xml.internal.dtm.ObjectFactory.createObject(ObjectFactory.java:101) at com.sun.org.apache.xml.internal.dtm.DTMManager.newInstance(DTMManager.java:135) at com.sun.org.apache.xpath.internal.XPathContext.init(XPathContext.java:100) at com.sun.org.apache.xpath.internal.jaxp.XPathImpl.eval(XPathImpl.java:201) at com.sun.org.apache.xpath.internal.jaxp.XPathImpl.evaluate(XPathImpl.java:275) at org.apache.solr.core.Config.getNode(Config.java:230) at org.apache.solr.core.Config.getVal(Config.java:256) at org.apache.solr.core.Config.getLuceneVersion(Config.java:325) at org.apache.solr.search.SolrQueryParser.init(SolrQueryParser.java:76) at org.apache.solr.schema.IndexSchema.getSolrQueryParser(IndexSchema.java:277) With the current 3.1 code, I do barely 250 qps with 16 concurrent users with a near empty index. Switching SolrQueryParser to use getSchema().getSolrConfig().luceneMatchVersion and doing a quick bench test, performance become reasonable beyond 2000 qps. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2481) Add support for commitWithin in DataImportHandler
[ https://issues.apache.org/jira/browse/SOLR-2481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren updated SOLR-2481: - Component/s: contrib - DataImportHandler Add support for commitWithin in DataImportHandler - Key: SOLR-2481 URL: https://issues.apache.org/jira/browse/SOLR-2481 Project: Solr Issue Type: Improvement Components: contrib - DataImportHandler Reporter: Sami Siren Priority: Trivial Attachments: SOLR-2481.patch It looks like DataImportHandler does not support commitWithin. Would be nice if it did. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-2481) Add support for commitWithin in DataImportHandler
Add support for commitWithin in DataImportHandler - Key: SOLR-2481 URL: https://issues.apache.org/jira/browse/SOLR-2481 Project: Solr Issue Type: Improvement Reporter: Sami Siren Priority: Trivial It looks like DataImportHandler does not support commitWithin. Would be nice if it did. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2481) Add support for commitWithin in DataImportHandler
[ https://issues.apache.org/jira/browse/SOLR-2481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren updated SOLR-2481: - Attachment: SOLR-2481.patch initial patch Add support for commitWithin in DataImportHandler - Key: SOLR-2481 URL: https://issues.apache.org/jira/browse/SOLR-2481 Project: Solr Issue Type: Improvement Reporter: Sami Siren Priority: Trivial Attachments: SOLR-2481.patch It looks like DataImportHandler does not support commitWithin. Would be nice if it did. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Created: (SOLR-2353) SpellCheckCollator uses org.mortbay.log.Log for logging
SpellCheckCollator uses org.mortbay.log.Log for logging --- Key: SOLR-2353 URL: https://issues.apache.org/jira/browse/SOLR-2353 Project: Solr Issue Type: Bug Components: spellchecker Reporter: Sami Siren Priority: Trivial SLF4j should be used instead. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Updated: (SOLR-2353) SpellCheckCollator uses org.mortbay.log.Log for logging
[ https://issues.apache.org/jira/browse/SOLR-2353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren updated SOLR-2353: - Attachment: SOLR-2353.patch SpellCheckCollator uses org.mortbay.log.Log for logging --- Key: SOLR-2353 URL: https://issues.apache.org/jira/browse/SOLR-2353 Project: Solr Issue Type: Bug Components: spellchecker Reporter: Sami Siren Priority: Trivial Attachments: SOLR-2353.patch SLF4j should be used instead. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Updated: (SOLR-1881) SearchHandler prevents HTTPS distributed search
[ https://issues.apache.org/jira/browse/SOLR-1881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren updated SOLR-1881: - Attachment: SOLR-1881.patch Here's a patch that let's you configure the url scheme the same way you can configure socket timeout and connection timeout in distributed search. SearchHandler prevents HTTPS distributed search --- Key: SOLR-1881 URL: https://issues.apache.org/jira/browse/SOLR-1881 Project: Solr Issue Type: Improvement Components: search Affects Versions: 1.4 Environment: All Reporter: Rich Cariens Fix For: Next Attachments: SOLR-1881.patch, SOLR-1881.patch Original Estimate: 0.08h Remaining Estimate: 0.08h The SearchHandler component automagically prepends http://; to all distributed searches, preventing HTTPS communication with remote shards/cores. This feels unnecessary and is trivia to fix (I'll attach a two-line patch shortly). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (NUTCH-798) Upgrade to SOLR1.4
[ https://issues.apache.org/jira/browse/NUTCH-798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12843546#action_12843546 ] Sami Siren commented on NUTCH-798: -- +1 Upgrade to SOLR1.4 -- Key: NUTCH-798 URL: https://issues.apache.org/jira/browse/NUTCH-798 Project: Nutch Issue Type: Improvement Components: indexer Reporter: Julien Nioche Fix For: 1.1 in particular SOLR1.4 has a StreamingUpdateSolrServer which would simplify the way we buffer the docs before sending them to the SOLR instance -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TIKA-147) Add Flash parser
[ https://issues.apache.org/jira/browse/TIKA-147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12838740#action_12838740 ] Sami Siren commented on TIKA-147: - I contacted the author of JavaSWF and his response was basically I do not support it anymore. So we have to proceed with the upload by ourselves. Does anybody know about some other library that has a Apache compatible license and that is maintained? Add Flash parser Key: TIKA-147 URL: https://issues.apache.org/jira/browse/TIKA-147 Project: Tika Issue Type: New Feature Components: parser Reporter: Jukka Zitting Assignee: Dave Meikle Priority: Minor Adobe has published the Flash SWF file format specification at http://www.adobe.com/devnet/swf/. Once there's a parser library available for Flash files we should use it to make especially downstream web crawlers like Nutch happy. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (NUTCH-793) search.jsp compile errors
search.jsp compile errors - Key: NUTCH-793 URL: https://issues.apache.org/jira/browse/NUTCH-793 Project: Nutch Issue Type: Bug Components: web gui Reporter: Sami Siren Assignee: Sami Siren Fix For: 1.1 Related to the searcher interface changes recently committed I broke search.jsp which does not currently compile. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (NUTCH-793) search.jsp compile errors
[ https://issues.apache.org/jira/browse/NUTCH-793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren resolved NUTCH-793. -- Resolution: Fixed committed a fix search.jsp compile errors - Key: NUTCH-793 URL: https://issues.apache.org/jira/browse/NUTCH-793 Project: Nutch Issue Type: Bug Components: web gui Reporter: Sami Siren Assignee: Sami Siren Fix For: 1.1 Related to the searcher interface changes recently committed I broke search.jsp which does not currently compile. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (NUTCH-788) search.jsp typo causing searches to fail
[ https://issues.apache.org/jira/browse/NUTCH-788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren resolved NUTCH-788. -- Resolution: Fixed Fix Version/s: 1.1 Assignee: Sami Siren Thanks Sammy for the fix, I did not realize you had spotted this too. It's now fixed in trunk. search.jsp typo causing searches to fail Key: NUTCH-788 URL: https://issues.apache.org/jira/browse/NUTCH-788 Project: Nutch Issue Type: Bug Components: web gui Affects Versions: 1.1 Environment: On trunk Reporter: Sammy Yu Assignee: Sami Siren Fix For: 1.1 Attachments: 0001-Fix-up-servlet.patch Call to initialize the servlet parameter is missing parentheses. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (NUTCH-789) Improvements to Tika parser
[ https://issues.apache.org/jira/browse/NUTCH-789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12833714#action_12833714 ] Sami Siren commented on NUTCH-789: -- It would be really useful to include the improvements in the functionality since that way almost all (-flash ?) parsers would be covered. Improvements to Tika parser --- Key: NUTCH-789 URL: https://issues.apache.org/jira/browse/NUTCH-789 Project: Nutch Issue Type: Improvement Components: fetcher Environment: reported by Sami, in NUTCH-766 Reporter: Chris A. Mattmann Assignee: Chris A. Mattmann Priority: Minor Fix For: 1.1 Attachments: NutchTikaConfig.java, TikaParser.java As reported by Sami in NUTCH-766, Sami has a few improvements he made to the Tika parser. We'll track that progress here. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (NUTCH-790) Some external javadoc links are broken
Some external javadoc links are broken -- Key: NUTCH-790 URL: https://issues.apache.org/jira/browse/NUTCH-790 Project: Nutch Issue Type: Improvement Components: build Reporter: Sami Siren Assignee: Sami Siren Priority: Trivial Nutch javadoc links for lucene and hadoop are broken. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (NUTCH-790) Some external javadoc links are broken
[ https://issues.apache.org/jira/browse/NUTCH-790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren updated NUTCH-790: - Attachment: NUTCH-790.patch proposed patch, fixes links for lucene and hadoop, also updates j2se link to version 1.6 Some external javadoc links are broken -- Key: NUTCH-790 URL: https://issues.apache.org/jira/browse/NUTCH-790 Project: Nutch Issue Type: Improvement Components: build Reporter: Sami Siren Assignee: Sami Siren Priority: Trivial Attachments: NUTCH-790.patch Nutch javadoc links for lucene and hadoop are broken. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (NUTCH-791) External links for published javadocs are partially broken
External links for published javadocs are partially broken -- Key: NUTCH-791 URL: https://issues.apache.org/jira/browse/NUTCH-791 Project: Nutch Issue Type: Bug Components: documentation Reporter: Sami Siren Lucene and Hadoop links point to non existing urls. For some versions of apidocs the links are just broken and for some they do not exist at all. Basically what is required is that the javadocs are generated again with proper urls for external packages. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (NUTCH-790) Some external javadoc links are broken
[ https://issues.apache.org/jira/browse/NUTCH-790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren resolved NUTCH-790. -- Resolution: Fixed Fix Version/s: 1.1 committed Some external javadoc links are broken -- Key: NUTCH-790 URL: https://issues.apache.org/jira/browse/NUTCH-790 Project: Nutch Issue Type: Improvement Components: build Reporter: Sami Siren Assignee: Sami Siren Priority: Trivial Fix For: 1.1 Attachments: NUTCH-790.patch Nutch javadoc links for lucene and hadoop are broken. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
