[jira] [Commented] (SOLR-3575) solr.xml should default to persist=true
[ https://issues.apache.org/jira/browse/SOLR-3575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13509569#comment-13509569 ] Magnus Bergmark commented on SOLR-3575: --- related: it would be nice if the coming/going of cores didn't necessitate changing solr.xml Perhaps every directory under the solr home could implicitly define a collection. Not a good idea. We unload cores to save memory on some machines, then load them on demand. This would make it much harder for us to accomplish. Also, what would happen if a core was unloaded? solr.xml should default to persist=true --- Key: SOLR-3575 URL: https://issues.apache.org/jira/browse/SOLR-3575 Project: Solr Issue Type: Improvement Reporter: Mark Miller Assignee: Mark Miller Fix For: 4.0-BETA, 5.0 The default of false is kind of silly IMO. -- 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] (LUCENE-4586) Change default ResultMode of FacetRequest to PER_NODE_IN_TREE
Shai Erera created LUCENE-4586:
--
Summary: Change default ResultMode of FacetRequest to
PER_NODE_IN_TREE
Key: LUCENE-4586
URL: https://issues.apache.org/jira/browse/LUCENE-4586
Project: Lucene - Core
Issue Type: Improvement
Components: modules/facet
Reporter: Shai Erera
Assignee: Shai Erera
Priority: Minor
Fix For: 4.1, 5.0
Today the default ResultMode is GLOBAL_FLAT, but it should be PER_NODE_IN_TREE.
ResultMode is being used whenever you set the depth of FacetRequest to greater
than 1. The difference between the two is:
* PER_NODE_IN_TREE would then compute the top-K categories recursively, for
every top category at every level (up to depth). The results are returned in a
tree structure as well. For instance:
{noformat}
Date
2010
March
February
2011
April
May
{noformat}
* GLOBAL_FLAT computes the top categories among all the nodes up to depth, and
returns a flat list of categories.
GLOBAL_FLAT is faster to compute than PER_NODE_IN_TREE (it just computes top-K
among N total categories), however I think that it's less intuitive, and
therefore should not be used as a default. In fact, I think this is kind of an
expert usage.
--
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-4141) EDismax: Strange combination of subqueries with parentheses
[ https://issues.apache.org/jira/browse/SOLR-4141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13509590#comment-13509590 ] Leonhard Maylein commented on SOLR-4141: Oh, what a pity! Then I have to check to user query in the front end first to decide if the edismax parser is applicable or not. If the user types in parentheses, there is no chance to use the edismax handler because the user would be very surprised by the the result. Or, perhaps, I have to prefix every word within the parentheses with a plus sign (and if there are camel case words I have to separate the word parts before). But I think this is not the whole purpose of the edismax query parser. EDismax: Strange combination of subqueries with parentheses --- Key: SOLR-4141 URL: https://issues.apache.org/jira/browse/SOLR-4141 Project: Solr Issue Type: Bug Components: query parsers Affects Versions: 4.0 Reporter: Leonhard Maylein fi = field name, mm=100% (all examples) The query 'fi:a fi:b' (parsed query: '(+((fi:a fi:b)~2))/no_coord') is interpreted as 'fi:a AND fi:b' This also applies to the queries '(fi:a fi:b)' respectively 'fi:(a b)'. But the query '(fi:a fi:b) (fi:a fi:b)' (parsed query: '(+(((fi:a fi:b) (fi:a fi:b))~2))/no_coord') shows the same result as 'fi:a OR fi:b'. I'm not sure but I think this is a bug, isn't it? If it's a intended behavior I think it is very difficult to explain this to a searcher. -- 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-4580) Facet DrillDown should return a ConstantScoreQuery
[ https://issues.apache.org/jira/browse/LUCENE-4580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13509616#comment-13509616 ] Shai Erera commented on LUCENE-4580: I understand what you mean by 0f, sorry. I will fix it. Also, I think that I'll simplify SimpleSearcher to create the FacetSearchParams up front, so that it's clear where they're created. In addition, I think that we can cut down the number of query() methods in DrillDown, to always take a baseQuery and handle the case that it's null. Will post an updated patch soon. Facet DrillDown should return a ConstantScoreQuery -- Key: LUCENE-4580 URL: https://issues.apache.org/jira/browse/LUCENE-4580 Project: Lucene - Core Issue Type: Improvement Components: modules/facet Reporter: Shai Erera Priority: Minor Attachments: LUCENE-4580.patch DrillDown is a helper class which the user can use to convert a facet value that a user selected into a Query for performing drill-down or narrowing the results. The API has several static methods that create e.g. a Term or Query. Rather than creating a Query, it would make more sense to create a Filter I think. In most cases, the clicked facets should not affect the scoring of documents. Anyway, even if it turns out that it must return a Query (which I doubt), we should at least modify the impl to return a ConstantScoreQuery. -- 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] (LUCENE-4580) Facet DrillDown should return a ConstantScoreQuery
[ https://issues.apache.org/jira/browse/LUCENE-4580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shai Erera updated LUCENE-4580: --- Attachment: LUCENE-4580.patch * Removed DrillDown.query() which didn't take baseQuery -- DrillDown will usually be used for drill-down queries. However, the query() methods handle the case where baseQuery is null. * Fixed SimpleSearcher.searchWithDrillDown to initialize FacetIndexingParams and pass it to the other methods. I think this is ready to go in. Facet DrillDown should return a ConstantScoreQuery -- Key: LUCENE-4580 URL: https://issues.apache.org/jira/browse/LUCENE-4580 Project: Lucene - Core Issue Type: Improvement Components: modules/facet Reporter: Shai Erera Priority: Minor Attachments: LUCENE-4580.patch, LUCENE-4580.patch DrillDown is a helper class which the user can use to convert a facet value that a user selected into a Query for performing drill-down or narrowing the results. The API has several static methods that create e.g. a Term or Query. Rather than creating a Query, it would make more sense to create a Filter I think. In most cases, the clicked facets should not affect the scoring of documents. Anyway, even if it turns out that it must return a Query (which I doubt), we should at least modify the impl to return a ConstantScoreQuery. -- 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-4580) Facet DrillDown should return a ConstantScoreQuery
[ https://issues.apache.org/jira/browse/LUCENE-4580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13509628#comment-13509628 ] Gilad Barkai commented on LUCENE-4580: -- +1 Facet DrillDown should return a ConstantScoreQuery -- Key: LUCENE-4580 URL: https://issues.apache.org/jira/browse/LUCENE-4580 Project: Lucene - Core Issue Type: Improvement Components: modules/facet Reporter: Shai Erera Priority: Minor Attachments: LUCENE-4580.patch, LUCENE-4580.patch DrillDown is a helper class which the user can use to convert a facet value that a user selected into a Query for performing drill-down or narrowing the results. The API has several static methods that create e.g. a Term or Query. Rather than creating a Query, it would make more sense to create a Filter I think. In most cases, the clicked facets should not affect the scoring of documents. Anyway, even if it turns out that it must return a Query (which I doubt), we should at least modify the impl to return a ConstantScoreQuery. -- 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-4580) Facet DrillDown should return a ConstantScoreQuery
[ https://issues.apache.org/jira/browse/LUCENE-4580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13509632#comment-13509632 ] Commit Tag Bot commented on LUCENE-4580: [trunk commit] Shai Erera http://svn.apache.org/viewvc?view=revisionrevision=1416860 LUCENE-4580: Facet DrillDown should return a ConstantScoreQuery Facet DrillDown should return a ConstantScoreQuery -- Key: LUCENE-4580 URL: https://issues.apache.org/jira/browse/LUCENE-4580 Project: Lucene - Core Issue Type: Improvement Components: modules/facet Reporter: Shai Erera Priority: Minor Attachments: LUCENE-4580.patch, LUCENE-4580.patch DrillDown is a helper class which the user can use to convert a facet value that a user selected into a Query for performing drill-down or narrowing the results. The API has several static methods that create e.g. a Term or Query. Rather than creating a Query, it would make more sense to create a Filter I think. In most cases, the clicked facets should not affect the scoring of documents. Anyway, even if it turns out that it must return a Query (which I doubt), we should at least modify the impl to return a ConstantScoreQuery. -- 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
dev-tools/eclipse/dot.classpath is broken?
Hi It references lucene/analysis/icu/src/test-files but I don't see such directory, and eclipse complains. Is it safe to remove it from dot.classpath or has it been moved elsewhere? Shai
[jira] [Resolved] (LUCENE-4580) Facet DrillDown should return a ConstantScoreQuery
[ https://issues.apache.org/jira/browse/LUCENE-4580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shai Erera resolved LUCENE-4580. Resolution: Fixed Fix Version/s: 5.0 4.1 Assignee: Shai Erera Lucene Fields: New,Patch Available (was: New) Committed to trunk and 4x. Facet DrillDown should return a ConstantScoreQuery -- Key: LUCENE-4580 URL: https://issues.apache.org/jira/browse/LUCENE-4580 Project: Lucene - Core Issue Type: Improvement Components: modules/facet Reporter: Shai Erera Assignee: Shai Erera Priority: Minor Fix For: 4.1, 5.0 Attachments: LUCENE-4580.patch, LUCENE-4580.patch DrillDown is a helper class which the user can use to convert a facet value that a user selected into a Query for performing drill-down or narrowing the results. The API has several static methods that create e.g. a Term or Query. Rather than creating a Query, it would make more sense to create a Filter I think. In most cases, the clicked facets should not affect the scoring of documents. Anyway, even if it turns out that it must return a Query (which I doubt), we should at least modify the impl to return a ConstantScoreQuery. -- 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-4580) Facet DrillDown should return a ConstantScoreQuery
[ https://issues.apache.org/jira/browse/LUCENE-4580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13509647#comment-13509647 ] Commit Tag Bot commented on LUCENE-4580: [branch_4x commit] Shai Erera http://svn.apache.org/viewvc?view=revisionrevision=1416864 LUCENE-4580: Facet DrillDown should return a ConstantScoreQuery Facet DrillDown should return a ConstantScoreQuery -- Key: LUCENE-4580 URL: https://issues.apache.org/jira/browse/LUCENE-4580 Project: Lucene - Core Issue Type: Improvement Components: modules/facet Reporter: Shai Erera Assignee: Shai Erera Priority: Minor Fix For: 4.1, 5.0 Attachments: LUCENE-4580.patch, LUCENE-4580.patch DrillDown is a helper class which the user can use to convert a facet value that a user selected into a Query for performing drill-down or narrowing the results. The API has several static methods that create e.g. a Term or Query. Rather than creating a Query, it would make more sense to create a Filter I think. In most cases, the clicked facets should not affect the scoring of documents. Anyway, even if it turns out that it must return a Query (which I doubt), we should at least modify the impl to return a ConstantScoreQuery. -- 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
[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.7.0_09) - Build # 3055 - Failure!
Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Linux/3055/ Java: 64bit/jdk1.7.0_09 -XX:+UseConcMarkSweepGC 1 tests failed. REGRESSION: org.apache.lucene.facet.search.DrillDownTest.testScoring Error Message: score of doc=4 modified expected:0.804885745048523 but was:0.5365905165672302 Stack Trace: java.lang.AssertionError: score of doc=4 modified expected:0.804885745048523 but was:0.5365905165672302 at __randomizedtesting.SeedInfo.seed([3C984CDCB25F27BB:1EBA4BE3B82B45EA]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:443) at org.apache.lucene.facet.search.DrillDownTest.testScoring(DrillDownTest.java:208) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358) at java.lang.Thread.run(Thread.java:722) Build Log: [...truncated 6528 lines...] [junit4:junit4] Suite: org.apache.lucene.facet.search.DrillDownTest [junit4:junit4] 2 NOTE: reproduce with: ant test -Dtestcase=DrillDownTest -Dtests.method=testScoring -Dtests.seed=3C984CDCB25F27BB -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=fr_LU -Dtests.timezone=Pacific/Tongatapu
[jira] [Commented] (SOLR-4114) Collection API: Allow multiple shards from one collection on the same Solr server
[
https://issues.apache.org/jira/browse/SOLR-4114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13509687#comment-13509687
]
Per Steffensen commented on SOLR-4114:
--
bq. We have to do something else other than a one minute sleep in the test.
In checkForCollection we are willing to wait up to 120 secs (used to be 60
secs) for the collection to be created (correctly). So it is kinda obvious to
also wait at least 60 secs to verify that nothing related to a collection was
actually created in cases where you want to be sure that nothing is created. In
the case of waiting for a collection being created correctly you can skip the
waiting as soon as you see that is has been created correctly. In the case
where you want to see that nothing gets created you have no chance to do that.
I think the 60 sec wait fits well into the way the test already works.
bq. I'd like the default data dir to remain /data. If you are not doing
anything special that works fine.
Thats also fine, but as soon at you create more than one shard on the same
node, dont you need different data-dirs? You cant have two shards using the
same folder for lucene-index-files, right? Did I get the instance-dir and
data-dir concepts wrong? Or is it the instance-dir you want to vary between
different shards? I would say that running only one shard on a node IS doing
something special.
bq. I'd also like the ability to override the data dir on per shard basis, but
I'm not sure what the best API for that is.
Yes, me too, but that has to be another ticket/issue. For now, until the API
allowes to control the data-dir-naming, it should be ok for the algorithm to
decide for something reasonable by itself.
bq. So I'd like to support what you want, but I don't want to change the
default behavior.
I agree, but if I got the concepts correct you cannot use /data as data-dir
for more than one shard on each node. So default behaviour about using /data
as data-dir will not work as soon as you run more than one shard on a node. I
probably got something wrong - please try to explain.
bq. My latest patch - I'll commit this soon and we can iterate from there.
Well I would prefer you committed my patch, and we can iterate from there :-)
It will also make it much easier to get SOLR-4120 in, which I hope you will
also consider.
Had a quick peek at your patch and have the following comments
* I see that you removed the auto-reduce replica-per-shard to never have more
than one replica of the same shard on the same node-feature and just issue a
warning instead in OverseerCollectionProcessor (the if (numShardsPerSlice
nodeList.size())-thingy). It is ok for me, eventhough I believe it is
pointless to replicate data to the same machine and under the same Solr
instance. But then you probably need to change the BasicDistrbutedZkTest also -
in checkCollectionExceptations I believe you'll need to change from
{code}
int expectedShardsPerSlice = (Math.min(clusterState.getLiveNodes().size(),
numShardsNumReplicaList.get(1) + 1));
{code}
to
{code}
int expectedShardsPerSlice = numShardsNumReplicaList.get(1) + 1;
{code}
* You removed the following lines (because you just want default-values for
instance-dir and data-dir)
{code}
params.set(CoreAdminParams.INSTANCE_DIR, .);
params.set(CoreAdminParams.DATA_DIR, shardName + _data);
{code}
I still do not understand how that will work, but hopefully you will explain
* You didnt like my rename of variable replica to
nodeUrlWithoutProtocolPart in OverseerCollectionProcessor.createCollection.
As I said on mailing-list I dont like the term replica as a replacement for
what we used to call shards, because I think it will cause misunderstandings,
as replica is also (in my mind) a role played at runtime. But getting the
terms right and reflect them correctly in API, variable-names etc. across the
code must be another issue/ticket. But here in this specific example replica
is just a very bad name, because the variable is not even containing a
replica-url, which would require the shard/replica-name to be postfixed to
the string. So this replica-variable is closest to being an node-url (without
the protocol part) - NOT a shard/replica-url. I would accept my name-change if
I where you, but I have a motto of carefully choosing my fights and this is a
fight I will not fight for very long :-)
* I see that you did not include my changes to HttpShardHandler, making
shardToUrls-map (renamed) concurrency protected through getURLs-method
(renamed to getFullURLs), so that you do not have to use the map so carefully
outside. I understand that it has very little to do with this issue SOLR-4114,
but it is a nice modification. Please consider committing it - maybe related to
another issue/ticket. It is little bit of a problem that good refactoring does
not easy get in as part of issues/tickets not requiring the refactor. If
Re: [JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.7.0_09) - Build # 3055 - Failure!
It looks to be caused by the random IndexSearcher that's created. I'm still checking if it can alter the scoring, since that test verifies that scores between two invocations of IndexSearcher.search() do not change. Anyway, this looks like a test issue. Shai On Tue, Dec 4, 2012 at 1:45 PM, Policeman Jenkins Server jenk...@sd-datasolutions.de wrote: Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Linux/3055/ Java: 64bit/jdk1.7.0_09 -XX:+UseConcMarkSweepGC 1 tests failed. REGRESSION: org.apache.lucene.facet.search.DrillDownTest.testScoring Error Message: score of doc=4 modified expected:0.804885745048523 but was:0.5365905165672302 Stack Trace: java.lang.AssertionError: score of doc=4 modified expected:0.804885745048523 but was:0.5365905165672302 at __randomizedtesting.SeedInfo.seed([3C984CDCB25F27BB:1EBA4BE3B82B45EA]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:443) at org.apache.lucene.facet.search.DrillDownTest.testScoring(DrillDownTest.java:208) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
[jira] [Updated] (SOLR-3926) solrj should support better way of finding active sorts
[
https://issues.apache.org/jira/browse/SOLR-3926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eirik Lygre updated SOLR-3926:
--
Attachment: SOLR-3926.patch
This patch implements the API as discussed above. The patch contains javadoc
and unit tests, and was built against
http://svn.apache.org/repos/asf/lucene/dev/branches/branch_4x.
This patch solves the original requirements that led to this issue
(introspection of active sorts), and hopefully also the requirements of the
Solr project (as represented by [~yo...@apache.org] and [~hossman]).
solrj should support better way of finding active sorts
---
Key: SOLR-3926
URL: https://issues.apache.org/jira/browse/SOLR-3926
Project: Solr
Issue Type: Improvement
Components: clients - java
Affects Versions: 4.0
Reporter: Eirik Lygre
Priority: Minor
Fix For: 4.1
Attachments: SOLR-3926.patch, SOLR-3926.patch, SOLR-3926.patch,
SOLR-3926.patch
The Solrj api uses ortogonal concepts for setting/removing and getting sort
information. Setting/removing uses a combination of (name,order), while
getters return a String name order:
{code}
public SolrQuery setSortField(String field, ORDER order);
public SolrQuery addSortField(String field, ORDER order);
public SolrQuery removeSortField(String field, ORDER order);
public String[] getSortFields();
public String getSortField();
{code}
If you want to use the current sort information to present a list of active
sorts, with the possibility to remove then, you need to manually parse the
string(s) returned from getSortFields, to recreate the information required
by removeSortField(). Not difficult, but not convenient either :-)
Therefore this suggestion: Add a new method {{public MapString,ORDER
getSortFieldMap();}} which returns an ordered map of active sort fields. This
will make introspection of the current sort setup much easier.
{code}
public MapString, ORDER getSortFieldMap() {
String[] actualSortFields = getSortFields();
if (actualSortFields == null || actualSortFields.length == 0)
return Collections.emptyMap();
MapString, ORDER sortFieldMap = new LinkedHashMapString, ORDER();
for (String sortField : actualSortFields) {
String[] fieldSpec = sortField.trim().split( );
sortFieldMap.put(fieldSpec[0], ORDER.valueOf(fieldSpec[1]));
}
return Collections.unmodifiableMap(sortFieldMap);
}
{code}
For what it's worth, this is possible client code:
{code}
System.out.println(Active sorts);
MapString, ORDER fieldMap = getSortFieldMap(query);
for (String field : fieldMap.keySet()) {
System.out.println(- + field + ; dir= + fieldMap.get(field));
}
{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
[JENKINS] Lucene-Solr-4.x-Linux (32bit/jdk1.8.0-ea-b65) - Build # 3046 - Failure!
Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-4.x-Linux/3046/ Java: 32bit/jdk1.8.0-ea-b65 -client -XX:+UseSerialGC 1 tests failed. REGRESSION: org.apache.lucene.facet.search.DrillDownTest.testScoring Error Message: score of doc=4 modified expected:2.304394006729126 but was:1.5362627506256104 Stack Trace: java.lang.AssertionError: score of doc=4 modified expected:2.304394006729126 but was:1.5362627506256104 at __randomizedtesting.SeedInfo.seed([D1495224FFA8AD3F:F36B551BF5DCCF6E]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:443) at org.apache.lucene.facet.search.DrillDownTest.testScoring(DrillDownTest.java:208) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:474) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358) at java.lang.Thread.run(Thread.java:722) Build Log: [...truncated 6398 lines...] [junit4:junit4] Suite: org.apache.lucene.facet.search.DrillDownTest [junit4:junit4] 2 NOTE: reproduce with: ant test -Dtestcase=DrillDownTest -Dtests.method=testScoring -Dtests.seed=D1495224FFA8AD3F -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=de_AT -Dtests.timezone=America/Cayenne
[jira] [Commented] (SOLR-4141) EDismax: Strange combination of subqueries with parentheses
[ https://issues.apache.org/jira/browse/SOLR-4141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13509725#comment-13509725 ] Jack Krupansky commented on SOLR-4141: -- Feel free to suggest an improvement to make edismax at least customizable to address your needs. EDismax: Strange combination of subqueries with parentheses --- Key: SOLR-4141 URL: https://issues.apache.org/jira/browse/SOLR-4141 Project: Solr Issue Type: Bug Components: query parsers Affects Versions: 4.0 Reporter: Leonhard Maylein fi = field name, mm=100% (all examples) The query 'fi:a fi:b' (parsed query: '(+((fi:a fi:b)~2))/no_coord') is interpreted as 'fi:a AND fi:b' This also applies to the queries '(fi:a fi:b)' respectively 'fi:(a b)'. But the query '(fi:a fi:b) (fi:a fi:b)' (parsed query: '(+(((fi:a fi:b) (fi:a fi:b))~2))/no_coord') shows the same result as 'fi:a OR fi:b'. I'm not sure but I think this is a bug, isn't it? If it's a intended behavior I think it is very difficult to explain this to a searcher. -- 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
Re: [JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.7.0_09) - Build # 3055 - Failure!
It was a real bug -- DrilDown.query did not set disableCoord=true on the result BooleanQuery, and RandomSimProvider caught that ! Committed a fix. Shai On Tue, Dec 4, 2012 at 2:05 PM, Shai Erera ser...@gmail.com wrote: It looks to be caused by the random IndexSearcher that's created. I'm still checking if it can alter the scoring, since that test verifies that scores between two invocations of IndexSearcher.search() do not change. Anyway, this looks like a test issue. Shai On Tue, Dec 4, 2012 at 1:45 PM, Policeman Jenkins Server jenk...@sd-datasolutions.de wrote: Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Linux/3055/ Java: 64bit/jdk1.7.0_09 -XX:+UseConcMarkSweepGC 1 tests failed. REGRESSION: org.apache.lucene.facet.search.DrillDownTest.testScoring Error Message: score of doc=4 modified expected:0.804885745048523 but was:0.5365905165672302 Stack Trace: java.lang.AssertionError: score of doc=4 modified expected:0.804885745048523 but was:0.5365905165672302 at __randomizedtesting.SeedInfo.seed([3C984CDCB25F27BB:1EBA4BE3B82B45EA]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:443) at org.apache.lucene.facet.search.DrillDownTest.testScoring(DrillDownTest.java:208) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at
Re: dev-tools/eclipse/dot.classpath is broken?
Hi Shai - it's safe to remove. On Dec 4, 2012 5:09 AM, Shai Erera ser...@gmail.com wrote: Hi It references lucene/analysis/icu/src/test-files but I don't see such directory, and eclipse complains. Is it safe to remove it from dot.classpath or has it been moved elsewhere? Shai
Re: dev-tools/eclipse/dot.classpath is broken?
ok done. On Tue, Dec 4, 2012 at 3:50 PM, Steve Rowe sar...@gmail.com wrote: Hi Shai - it's safe to remove. On Dec 4, 2012 5:09 AM, Shai Erera ser...@gmail.com wrote: Hi It references lucene/analysis/icu/src/test-files but I don't see such directory, and eclipse complains. Is it safe to remove it from dot.classpath or has it been moved elsewhere? Shai
[jira] [Commented] (SOLR-1028) Automatic core loading unloading for multicore
[ https://issues.apache.org/jira/browse/SOLR-1028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13509759#comment-13509759 ] Yonik Seeley commented on SOLR-1028: TestLazyCores seems to have failed a number of times since it was added here. http://svn.apache.org/viewvc?rev=1403710view=rev Anyone have any clues? Automatic core loading unloading for multicore -- Key: SOLR-1028 URL: https://issues.apache.org/jira/browse/SOLR-1028 Project: Solr Issue Type: New Feature Components: multicore Affects Versions: 4.0, 5.0 Reporter: Noble Paul Assignee: Erick Erickson Fix For: 4.1, 5.0 Attachments: SOLR-1028.patch, SOLR-1028.patch usecase: I have many small cores (say one per user) on a single Solr box . All the cores are not be always needed . But when I need it I should be able to directly issue a search request and the core must be STARTED automatically and the request must be served. This also requires that I must have an upper limit on the no:of cores that should be loaded at any given point in time. If the limit is crossed the CoreContainer must unload a core (preferably the least recently used core) There must be a choice of specifying some cores as fixed. These cores must never be unloaded -- 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] [Comment Edited] (SOLR-3425) CloudSolrServer can't create cores when using the zkHost based constructor
[ https://issues.apache.org/jira/browse/SOLR-3425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13509769#comment-13509769 ] Per Steffensen edited comment on SOLR-3425 at 12/4/12 2:42 PM: --- You talk about using CloudSolrServer and/or LBHttpSolrServer for access to Core Admin API. This a little strange because: * A Core Admin API request should be sent to a specific Solr node in order for you to control where the shard is created (or removed from) * CloudSolrServer and LBHttpSolrServer are all about sending requests that can end up going to a (randmon) node among several nodes With the quick-fix code above (Tommaso Teofili 01/May/12) you will end up having your shard created on a random node among all live nodes - it is very rarely want you want. So as long as we are talking about accessing Core Admin API you probably always want to use HttpSolrServer, which is aimed a sending the request to a specific node. But when talking about creating an entire collection consisting of many shards, it is certainly meaningful to use CloudSolrServer. To create entire collections (without having to create each shard yourself using the Core Admin API) we now have the Collection API in 4.0.0. The Collection API can be used through CloudSolrServer, except... * You cant create your first collection through CloudSolrServer * You cant create a collection through a CloudSolrServer, where default-collection is the collection you want to create * etc ...basically because CloudSolrServer wants an existing collection (pointed to by its default-collection or a collection-name provided in the actual request) before it can do anything. This will be fixed with SOLR-4140, but is not in 4.0.0. Other things not in Collection API of 4.0.0 * You cant have more than one shard per collection on a single node - fixed in TLT-4114 * You cant specify which Solr nodes the shards for a new collection is allowed to be spread across - they are just spread across all live Solr nodes - fixed in TLT-4120 Please state if you still believe something is missing or unclear. Or else you might want to state that your problems are solved with the 4.0.0 Collection API (maybe plus one or more of SOLR-4140, SOLR-4114 and SOLR-4120 which will hopefully be in the next release) by closing this issue SOLR-3425 was (Author: steff1193): You talk about using CloudSolrServer and/or LBHttpSolrServer for access to Core Admin API. This a little strange because: * A Core Admin API request should be sent to a specific Solr node in order for you to control where the shard is created (or removed from) * CloudSolrServer and LBHttpSolrServer are all about sending requests that can end up going to a (randmon) node among several nodes With the quick-fix code above (Tommaso Teofili 01/May/12) you will end up having your shard created on a random node among all live nodes - it is very rarely want you want. So as long as we are talking about accessing Core Admin API you probably always want to use HttpSolrServer, which is aimed a sending the request to a specific node. But when talking about creating an entire collection consisting of many shards, it is certainly meaningful to use CloudSolrServer. To create entire collections (without having to create each shard yourself using the Core Admin API) we now have the Collection API in 4.0.0. The Collection API can be used through CloudSolrServer, except... * You cant create your first collection through CloudSolrServer * You cant create a collection through a CloudSolrServer, where default-collection is the collection you want to create * etc ...basically because CloudSolrServer wants an existing collection (pointed to by its default-collection or a collection-name provided in the actual request) before it can do anything. This will be fixed with SOLR-4140, but is not in 4.0.0. Other things not in Collection API of 4.0.0 * You cant have more than one shard per collection on a single node - fixed in TLT-4114 * You cant specify which Solr nodes the shards for a new collection is allowed to be spread across - they are just spread across all live Solr nodes - fixed in TLT-4120 Please state if you still believe something is missing or unclear. Or else you might want to state that your problems are solved with the 4.0.0 Collection API (maybe plus one or more of SOLR-4140, SOLR-4114 and SOLR-4120 which will hopefully be in the next release) by closing this issue SOLR-3425 CloudSolrServer can't create cores when using the zkHost based constructor -- Key: SOLR-3425 URL: https://issues.apache.org/jira/browse/SOLR-3425 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Tommaso
[jira] [Commented] (SOLR-3425) CloudSolrServer can't create cores when using the zkHost based constructor
[ https://issues.apache.org/jira/browse/SOLR-3425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13509769#comment-13509769 ] Per Steffensen commented on SOLR-3425: -- You talk about using CloudSolrServer and/or LBHttpSolrServer for access to Core Admin API. This a little strange because: * A Core Admin API request should be sent to a specific Solr node in order for you to control where the shard is created (or removed from) * CloudSolrServer and LBHttpSolrServer are all about sending requests that can end up going to a (randmon) node among several nodes With the quick-fix code above (Tommaso Teofili 01/May/12) you will end up having your shard created on a random node among all live nodes - it is very rarely want you want. So as long as we are talking about accessing Core Admin API you probably always want to use HttpSolrServer, which is aimed a sending the request to a specific node. But when talking about creating an entire collection consisting of many shards, it is certainly meaningful to use CloudSolrServer. To create entire collections (without having to create each shard yourself using the Core Admin API) we now have the Collection API in 4.0.0. The Collection API can be used through CloudSolrServer, except... * You cant create your first collection through CloudSolrServer * You cant create a collection through a CloudSolrServer, where default-collection is the collection you want to create * etc ...basically because CloudSolrServer wants an existing collection (pointed to by its default-collection or a collection-name provided in the actual request) before it can do anything. This will be fixed with SOLR-4140, but is not in 4.0.0. Other things not in Collection API of 4.0.0 * You cant have more than one shard per collection on a single node - fixed in TLT-4114 * You cant specify which Solr nodes the shards for a new collection is allowed to be spread across - they are just spread across all live Solr nodes - fixed in TLT-4120 Please state if you still believe something is missing or unclear. Or else you might want to state that your problems are solved with the 4.0.0 Collection API (maybe plus one or more of SOLR-4140, SOLR-4114 and SOLR-4120 which will hopefully be in the next release) by closing this issue SOLR-3425 CloudSolrServer can't create cores when using the zkHost based constructor -- Key: SOLR-3425 URL: https://issues.apache.org/jira/browse/SOLR-3425 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Tommaso Teofili Assignee: Mark Miller Priority: Minor Fix For: 4.1 Attachments: SOLR-3425-test.patch When programmatically creating cores with a running SolrCloud instance the CloudSolrServer uses the slices nodes information to feed the underlying LBHttpSolrServer so it fails to create cores as there aren't any slices for any new collection (as it's still to be created). This happens when using the CloudSolrServer constructor which takes the ZK host as only parameter while it can be avoided by using the constructor which also takes the list of Solr URLs and the underlying LBHttpSolrServer is actually used for making the core creation request. However it'd be good to use the ZK host live nodes information to automatically issue a core creation command on one of the underlying Solr hosts without having to specify the full list of URLs beforehand. The scenario is when one wants to create a collection with N shards so the client sends N core creation requests for the same collection thus the SolrCloud stuff should just take care of choosing the host where to issue the core creation request and update the cluster state. -- 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-4140) Collection API: CloudSolrServer cannot be used to create collection with referencing an existing collection
[ https://issues.apache.org/jira/browse/SOLR-4140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13509774#comment-13509774 ] Per Steffensen commented on SOLR-4140: -- SOLR-3425 is certainly related, but if there are parts in it that are not solved with SOLR-4140, I am not sure. I posted a comment to SOLR-3425, describing this and that, and basically asking for a new evaluation of whether SOLR-3425 is still relevant (or can be closed) after SOLR-4140 Collection API: CloudSolrServer cannot be used to create collection with referencing an existing collection --- Key: SOLR-4140 URL: https://issues.apache.org/jira/browse/SOLR-4140 Project: Solr Issue Type: Bug Components: multicore, SolrCloud Affects Versions: 4.0 Reporter: Per Steffensen Assignee: Per Steffensen Priority: Minor Labels: collection-api, multicore Attachments: SOLR-4140_trunk.patch CloudSolrServer needs an existing collection to be able to forward requests. For some requests it is not logical that you ned to have or reference an existing collection. E.g. if you want to use CloudSolrServer to create a collection - especially: * If you have no collections already and want to create your first collection * If you like to create your CloudSolrServer once and for all, and want to set default-collection on it to point to your favorite collection, but also use this CloudSolrServer to create this favorite collection Yes, HttpSolrServer can be used, but * Some of us like to use CloudSolrServer for everything * Using HttpSolrServer you need to check youself which nodes are running, in order to send the create-request to one of them -- 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-4137) FastVectorHighlighter: StringIndexOutOfBoundsException in BaseFragmentsBuilder
[ https://issues.apache.org/jira/browse/SOLR-4137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13509777#comment-13509777 ] Markus Jelsma commented on SOLR-4137: - I have to add that we're also seeing this rather frequently with analyzers that use the WDF. FastVectorHighlighter: StringIndexOutOfBoundsException in BaseFragmentsBuilder -- Key: SOLR-4137 URL: https://issues.apache.org/jira/browse/SOLR-4137 Project: Solr Issue Type: Bug Components: highlighter Affects Versions: 3.6.1 Reporter: Marcel under some circumstances the BaseFragmentsBuilder genereates a StringIndexOutOfBoundsException inside the makeFragment method. The starting offset is higher than the end offset. I did a small patch checking the offsets and posted it over there at Stackoverflow: http://stackoverflow.com/questions/12456448/solr-highlight-bug-with-usefastvectorhighlighter The code in 4.0 seems to be the same as in 3.6.1 Example how to reproduce the behaviour: There is a word called www.DAKgesundAktivBonus.de inside the index. If you search for dak bonus some offset calculations went wrong. -- 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] [Comment Edited] (SOLR-3425) CloudSolrServer can't create cores when using the zkHost based constructor
[ https://issues.apache.org/jira/browse/SOLR-3425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13509769#comment-13509769 ] Per Steffensen edited comment on SOLR-3425 at 12/4/12 2:58 PM: --- You talk about using CloudSolrServer and/or LBHttpSolrServer for access to Core Admin API. This a little strange because: * A Core Admin API request should be sent to a specific Solr node in order for you to control where the shard is created (or removed from) * CloudSolrServer and LBHttpSolrServer are all about sending requests that can end up going to a (randmon) node among several nodes With the quick-fix code above (Tommaso Teofili 01/May/12) you will end up having your shard created on a random node among all live nodes - it is very rarely want you want. So as long as we are talking about accessing Core Admin API you probably always want to use HttpSolrServer, which is aimed a sending the request to a specific node. But when talking about creating an entire collection consisting of many shards, it is certainly meaningful to use CloudSolrServer. To create entire collections (without having to create each shard yourself using the Core Admin API) we now have the Collection API in 4.0.0. The Collection API can be used through CloudSolrServer, except... * You cant create your first collection through CloudSolrServer * You cant create a collection through a CloudSolrServer, where default-collection is the collection you want to create * etc ...basically because CloudSolrServer wants an existing collection (pointed to by its default-collection or a collection-name provided in the actual request) before it can do anything. This will be fixed with SOLR-4140, but is not in 4.0.0. Other things not in Collection API of 4.0.0 * You cant have more than one shard per collection on a single node - fixed in SOLR-4114 * You cant specify which Solr nodes the shards for a new collection is allowed to be spread across - they are just spread across all live Solr nodes - fixed in SOLR-4120 Please state if you still believe something is missing or unclear. Or else you might want to state that your problems are solved with the 4.0.0 Collection API (maybe plus one or more of SOLR-4140, SOLR-4114 and SOLR-4120 which will hopefully be in the next release) by closing this issue SOLR-3425 was (Author: steff1193): You talk about using CloudSolrServer and/or LBHttpSolrServer for access to Core Admin API. This a little strange because: * A Core Admin API request should be sent to a specific Solr node in order for you to control where the shard is created (or removed from) * CloudSolrServer and LBHttpSolrServer are all about sending requests that can end up going to a (randmon) node among several nodes With the quick-fix code above (Tommaso Teofili 01/May/12) you will end up having your shard created on a random node among all live nodes - it is very rarely want you want. So as long as we are talking about accessing Core Admin API you probably always want to use HttpSolrServer, which is aimed a sending the request to a specific node. But when talking about creating an entire collection consisting of many shards, it is certainly meaningful to use CloudSolrServer. To create entire collections (without having to create each shard yourself using the Core Admin API) we now have the Collection API in 4.0.0. The Collection API can be used through CloudSolrServer, except... * You cant create your first collection through CloudSolrServer * You cant create a collection through a CloudSolrServer, where default-collection is the collection you want to create * etc ...basically because CloudSolrServer wants an existing collection (pointed to by its default-collection or a collection-name provided in the actual request) before it can do anything. This will be fixed with SOLR-4140, but is not in 4.0.0. Other things not in Collection API of 4.0.0 * You cant have more than one shard per collection on a single node - fixed in TLT-4114 * You cant specify which Solr nodes the shards for a new collection is allowed to be spread across - they are just spread across all live Solr nodes - fixed in TLT-4120 Please state if you still believe something is missing or unclear. Or else you might want to state that your problems are solved with the 4.0.0 Collection API (maybe plus one or more of SOLR-4140, SOLR-4114 and SOLR-4120 which will hopefully be in the next release) by closing this issue SOLR-3425 CloudSolrServer can't create cores when using the zkHost based constructor -- Key: SOLR-3425 URL: https://issues.apache.org/jira/browse/SOLR-3425 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter:
[jira] [Updated] (SOLR-4140) Collection API: CloudSolrServer cannot be used to create collection without referencing an existing collection
[ https://issues.apache.org/jira/browse/SOLR-4140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Per Steffensen updated SOLR-4140: - Summary: Collection API: CloudSolrServer cannot be used to create collection without referencing an existing collection (was: Collection API: CloudSolrServer cannot be used to create collection with referencing an existing collection) Collection API: CloudSolrServer cannot be used to create collection without referencing an existing collection -- Key: SOLR-4140 URL: https://issues.apache.org/jira/browse/SOLR-4140 Project: Solr Issue Type: Bug Components: multicore, SolrCloud Affects Versions: 4.0 Reporter: Per Steffensen Assignee: Per Steffensen Priority: Minor Labels: collection-api, multicore Attachments: SOLR-4140_trunk.patch CloudSolrServer needs an existing collection to be able to forward requests. For some requests it is not logical that you ned to have or reference an existing collection. E.g. if you want to use CloudSolrServer to create a collection - especially: * If you have no collections already and want to create your first collection * If you like to create your CloudSolrServer once and for all, and want to set default-collection on it to point to your favorite collection, but also use this CloudSolrServer to create this favorite collection Yes, HttpSolrServer can be used, but * Some of us like to use CloudSolrServer for everything * Using HttpSolrServer you need to check youself which nodes are running, in order to send the create-request to one of them -- 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-4144) SolrCloud replication high heap consumption
Markus Jelsma created SOLR-4144:
---
Summary: SolrCloud replication high heap consumption
Key: SOLR-4144
URL: https://issues.apache.org/jira/browse/SOLR-4144
Project: Solr
Issue Type: Bug
Components: replication (java), SolrCloud
Affects Versions: 5.0
Environment: 5.0-SNAPSHOT 1366361:1416494M - markus - 2012-12-03
14:09:13
Reporter: Markus Jelsma
Priority: Critical
Fix For: 5.0
Recent versions of SolrCloud require a very high heap size vs. older versions.
Another cluster of 5.0.0.2012.10.09.19.29.59 (~4GB per core) can restore an
empty node without taking a lot of heap (xmx=256m). Recent versions and current
trunk fail miserably even with a higher heap (750m). Both clusters have 10
nodes, 10 shards and 2 cores per node. One note to add is that the cluster on
which this fails has only about 1.5GB per core due to changing in the Lucene
codec such as compression.
After start up everything goes fine...
{code}
2012-12-04 15:05:35,013 INFO [solr.cloud.RecoveryStrategy] - [RecoveryThread] -
: Begin buffering updates. core=shard_c
2012-12-04 15:05:35,013 INFO [solr.cloud.RecoveryStrategy] - [RecoveryThread] -
: Begin buffering updates. core=shard_b
2012-12-04 15:05:35,013 INFO [solr.update.UpdateLog] - [RecoveryThread] - :
Starting to buffer updates. FSUpdateLog{state=ACTIVE, tlog=null}
2012-12-04 15:05:35,013 INFO [solr.update.UpdateLog] - [RecoveryThread] - :
Starting to buffer updates. FSUpdateLog{state=ACTIVE, tlog=null}
2012-12-04 15:05:35,013 INFO [solr.cloud.RecoveryStrategy] - [RecoveryThread] -
: Attempting to replicate from http://178.21.118.190:8080/solr/shard_b/.
core=shard_b
2012-12-04 15:05:35,013 INFO [solr.cloud.RecoveryStrategy] - [RecoveryThread] -
: Attempting to replicate from http://178.21.118.192:8080/solr/shard_c/.
core=shard_c
2012-12-04 15:05:35,014 INFO [solrj.impl.HttpClientUtil] - [RecoveryThread] - :
Creating new http client,
config:maxConnections=128maxConnectionsPerHost=32followRedirects=false
2012-12-04 15:05:35,014 INFO [solrj.impl.HttpClientUtil] - [RecoveryThread] - :
Creating new http client,
config:maxConnections=128maxConnectionsPerHost=32followRedirects=false
2012-12-04 15:05:35,052 INFO [solr.handler.ReplicationHandler] -
[RecoveryThread] - : Commits will be reserved for 1
2012-12-04 15:05:35,052 INFO [solr.handler.ReplicationHandler] -
[RecoveryThread] - : Commits will be reserved for 1
2012-12-04 15:05:35,053 INFO [solrj.impl.HttpClientUtil] - [RecoveryThread] - :
Creating new http client,
config:connTimeout=5000socketTimeout=2allowCompression=falsemaxConnections=1maxConnectionsPerHost=1
2012-12-04 15:05:35,060 INFO [solr.handler.SnapPuller] - [RecoveryThread] - :
No value set for 'pollInterval'. Timer Task not started.
2012-12-04 15:05:35,060 INFO [solr.handler.SnapPuller] - [RecoveryThread] - :
No value set for 'pollInterval'. Timer Task not started.
2012-12-04 15:05:35,069 INFO [solr.handler.SnapPuller] - [RecoveryThread] - :
Master's generation: 48
2012-12-04 15:05:35,069 INFO [solr.handler.SnapPuller] - [RecoveryThread] - :
Slave's generation: 1
2012-12-04 15:05:35,069 INFO [solr.handler.SnapPuller] - [RecoveryThread] - :
Starting replication process
2012-12-04 15:05:35,069 INFO [solr.handler.SnapPuller] - [RecoveryThread] - :
Master's generation: 47
2012-12-04 15:05:35,069 INFO [solr.handler.SnapPuller] - [RecoveryThread] - :
Slave's generation: 1
2012-12-04 15:05:35,070 INFO [solr.handler.SnapPuller] - [RecoveryThread] - :
Starting replication process
2012-12-04 15:05:35,078 INFO [solr.handler.SnapPuller] - [RecoveryThread] - :
Number of files in latest index in master: 235
2012-12-04 15:05:35,079 INFO [solr.handler.SnapPuller] - [RecoveryThread] - :
Number of files in latest index in master: 287
2012-12-04 15:05:35,084 WARN [solr.core.CachingDirectoryFactory] -
[RecoveryThread] - : No lockType configured for
NRTCachingDirectory(org.apache.lucene.store.MMapDirectory@/opt/solr/cores/shard_c/data/index.20121204150535080
lockFactory=org.apache.lucene.store.NativeFSLockFactory@57530551;
maxCacheMB=48.0 maxMergeSizeMB=4.0) assuming 'simple'
2012-12-04 15:05:35,085 INFO [solr.core.CachingDirectoryFactory] -
[RecoveryThread] - : return new directory for
/opt/solr/cores/shard_c/data/index.20121204150535080 forceNew:false
2012-12-04 15:05:35,085 INFO [solr.core.CachingDirectoryFactory] -
[RecoveryThread] - : Releasing directory:/opt/solr/cores/shard_c/data
2012-12-04 15:05:35,085 WARN [solr.core.CachingDirectoryFactory] -
[RecoveryThread] - : No lockType configured for
NRTCachingDirectory(org.apache.lucene.store.MMapDirectory@/opt/solr/cores/shard_b/data/index.20121204150535079
lockFactory=org.apache.lucene.store.NativeFSLockFactory@512fb063;
maxCacheMB=48.0 maxMergeSizeMB=4.0) assuming 'simple'
2012-12-04 15:05:35,085 INFO
[jira] [Commented] (SOLR-3425) CloudSolrServer can't create cores when using the zkHost based constructor
[ https://issues.apache.org/jira/browse/SOLR-3425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13509793#comment-13509793 ] Tommaso Teofili commented on SOLR-3425: --- this issue was opened before the Collections API was designed, so basically things have changed along time but apart from that as long as there's SOLR-4140 the use case I opened this for is safe, therefore I'll close it. Thanks [~steff1193] for helping out. CloudSolrServer can't create cores when using the zkHost based constructor -- Key: SOLR-3425 URL: https://issues.apache.org/jira/browse/SOLR-3425 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Tommaso Teofili Assignee: Mark Miller Priority: Minor Fix For: 4.1 Attachments: SOLR-3425-test.patch When programmatically creating cores with a running SolrCloud instance the CloudSolrServer uses the slices nodes information to feed the underlying LBHttpSolrServer so it fails to create cores as there aren't any slices for any new collection (as it's still to be created). This happens when using the CloudSolrServer constructor which takes the ZK host as only parameter while it can be avoided by using the constructor which also takes the list of Solr URLs and the underlying LBHttpSolrServer is actually used for making the core creation request. However it'd be good to use the ZK host live nodes information to automatically issue a core creation command on one of the underlying Solr hosts without having to specify the full list of URLs beforehand. The scenario is when one wants to create a collection with N shards so the client sends N core creation requests for the same collection thus the SolrCloud stuff should just take care of choosing the host where to issue the core creation request and update the cluster state. -- 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-3425) CloudSolrServer can't create cores when using the zkHost based constructor
[ https://issues.apache.org/jira/browse/SOLR-3425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili resolved SOLR-3425. --- Resolution: Fixed CloudSolrServer can't create cores when using the zkHost based constructor -- Key: SOLR-3425 URL: https://issues.apache.org/jira/browse/SOLR-3425 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Tommaso Teofili Assignee: Mark Miller Priority: Minor Fix For: 4.1 Attachments: SOLR-3425-test.patch When programmatically creating cores with a running SolrCloud instance the CloudSolrServer uses the slices nodes information to feed the underlying LBHttpSolrServer so it fails to create cores as there aren't any slices for any new collection (as it's still to be created). This happens when using the CloudSolrServer constructor which takes the ZK host as only parameter while it can be avoided by using the constructor which also takes the list of Solr URLs and the underlying LBHttpSolrServer is actually used for making the core creation request. However it'd be good to use the ZK host live nodes information to automatically issue a core creation command on one of the underlying Solr hosts without having to specify the full list of URLs beforehand. The scenario is when one wants to create a collection with N shards so the client sends N core creation requests for the same collection thus the SolrCloud stuff should just take care of choosing the host where to issue the core creation request and update the cluster state. -- 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
Re: Solrj question
Believe there are no setParser method on CloudSolrServer? Have you tried this: XMLWriter.writeResponse(a java.io.Writer for your XML output, your SolrQueryRequest, your SolrQueryResponse) It will require you to include solr-core, since that is where XMLWriter lives. But it is a little inefficient, if I understand you correctly. If you have a CloudSolrServer doing a request and asks for a response in e.g. XML format, then this CloudSolrServer will receive a XML response over the wire, parse it into a SolrQueryResponse object and then you will take that SolrQueryResponse and serialize it back to XML. It would be nicer if you just used whatever was received on the wire directly. Regards, Per Steffensen Erick Erickson skrev: haven't tried this personally, but try this: server.setParser(new XMLResponseParser()); Best Erick On Mon, Dec 3, 2012 at 10:24 AM, Steve Molloy smol...@opentext.com wrote: I’ve been digging around a bit and could not find any straight-forward way of getting back the XML response after calling Solr using Solrj. The query method returns a QueryResponse object, which is great in most cases. But our use case implies pushing the response back to whatever format was requested, but still use the CloudSolrServer client. This is very easy with the javabin format, using the JavaBinCodec, but is there equivalent utilities to marshal into other formats from a NamedList? Otherwise, could the functionality be isolated for better reuse? Thanks, Steve Molloy Content Analytics Lead | RD Phone: (514) 908-5406 406 Website: www.opentext.com Nstein is now OpenText. Please update your address book with my new email address. This email message is confidential, may be privileged, and is intended for the exclusive use of the addressee. Any other person is strictly prohibited from disclosing or reproducing it. If the addressee cannot be reached or is unknown to you, please inform the sender by return email and delete this email message and all copies immediately.
[jira] [Updated] (SOLR-3583) Percentiles for facets, pivot facets, and distributed pivot facets
[ https://issues.apache.org/jira/browse/SOLR-3583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Russell updated SOLR-3583: Attachment: SOLR-3583.patch Now works with facet.missing=true Percentiles for facets, pivot facets, and distributed pivot facets -- Key: SOLR-3583 URL: https://issues.apache.org/jira/browse/SOLR-3583 Project: Solr Issue Type: Improvement Reporter: Chris Russell Priority: Minor Labels: newbie, patch Fix For: 4.1 Attachments: SOLR-3583.patch, SOLR-3583.patch, SOLR-3583.patch Built on top of SOLR-2894, this patch adds percentiles and averages to facets, pivot facets, and distributed pivot facets by making use of range facet internals. -- 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] (LUCENE-4586) Change default ResultMode of FacetRequest to PER_NODE_IN_TREE
[
https://issues.apache.org/jira/browse/LUCENE-4586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shai Erera updated LUCENE-4586:
---
Attachment: LUCENE-4586.patch
Patch changes the default ResultMode to PER_NODE_IN_TREE. That uncovered a
potential bug in TopKInEachNodeHandler where it didn't resolve ties on facet
values by ordinal -- this lead to inconsistent ordering of facet results
(discovered by SamplingWrapperTest).
I had to fix some tests that relied on GLOBAL_FLAT mode for results
verification (it's easier to verify results in that mode).
Added a CHANGES entry under back-compat changes.
All tests pass (tried many iterations).
Change default ResultMode of FacetRequest to PER_NODE_IN_TREE
-
Key: LUCENE-4586
URL: https://issues.apache.org/jira/browse/LUCENE-4586
Project: Lucene - Core
Issue Type: Improvement
Components: modules/facet
Reporter: Shai Erera
Assignee: Shai Erera
Priority: Minor
Fix For: 4.1, 5.0
Attachments: LUCENE-4586.patch
Today the default ResultMode is GLOBAL_FLAT, but it should be
PER_NODE_IN_TREE. ResultMode is being used whenever you set the depth of
FacetRequest to greater than 1. The difference between the two is:
* PER_NODE_IN_TREE would then compute the top-K categories recursively, for
every top category at every level (up to depth). The results are returned in
a tree structure as well. For instance:
{noformat}
Date
2010
March
February
2011
April
May
{noformat}
* GLOBAL_FLAT computes the top categories among all the nodes up to depth,
and returns a flat list of categories.
GLOBAL_FLAT is faster to compute than PER_NODE_IN_TREE (it just computes
top-K among N total categories), however I think that it's less intuitive,
and therefore should not be used as a default. In fact, I think this is kind
of an expert usage.
--
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] (LUCENE-4586) Change default ResultMode of FacetRequest to PER_NODE_IN_TREE
[
https://issues.apache.org/jira/browse/LUCENE-4586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shai Erera updated LUCENE-4586:
---
Attachment: LUCENE-4586.patch
Same patch, but moved the CHANGES entry under a Changes in Runtime Behavior
section
Change default ResultMode of FacetRequest to PER_NODE_IN_TREE
-
Key: LUCENE-4586
URL: https://issues.apache.org/jira/browse/LUCENE-4586
Project: Lucene - Core
Issue Type: Improvement
Components: modules/facet
Reporter: Shai Erera
Assignee: Shai Erera
Priority: Minor
Fix For: 4.1, 5.0
Attachments: LUCENE-4586.patch, LUCENE-4586.patch
Today the default ResultMode is GLOBAL_FLAT, but it should be
PER_NODE_IN_TREE. ResultMode is being used whenever you set the depth of
FacetRequest to greater than 1. The difference between the two is:
* PER_NODE_IN_TREE would then compute the top-K categories recursively, for
every top category at every level (up to depth). The results are returned in
a tree structure as well. For instance:
{noformat}
Date
2010
March
February
2011
April
May
{noformat}
* GLOBAL_FLAT computes the top categories among all the nodes up to depth,
and returns a flat list of categories.
GLOBAL_FLAT is faster to compute than PER_NODE_IN_TREE (it just computes
top-K among N total categories), however I think that it's less intuitive,
and therefore should not be used as a default. In fact, I think this is kind
of an expert usage.
--
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-3030) StopTermTypesFilter and Factory allows filtering based on the TermTypeAttribute
[ https://issues.apache.org/jira/browse/SOLR-3030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Wooden updated SOLR-3030: -- Attachment: SOLR-3030 4.0.patch Updated this patch for 4.0.0 StopTermTypesFilter and Factory allows filtering based on the TermTypeAttribute --- Key: SOLR-3030 URL: https://issues.apache.org/jira/browse/SOLR-3030 Project: Solr Issue Type: New Feature Components: Schema and Analysis Affects Versions: 4.0-ALPHA Reporter: Monica Skidmore Priority: Trivial Labels: features, newbie, patch Attachments: SOLR-3030 4.0.patch, SOLR-3030.patch Original Estimate: 168h Remaining Estimate: 168h This filter will remove terms based on the TermTypeAttribute, using a list of StopTermTypes from the StopTermTypes file specified by the user as an attribute of the filter factory in their schema. -- 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-3030) StopTermTypesFilter and Factory allows filtering based on the TermTypeAttribute
[ https://issues.apache.org/jira/browse/SOLR-3030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13509828#comment-13509828 ] Steven Rowe commented on SOLR-3030: --- @John Wooden: as Tommaso Teofili mentioned in the previous post, the functionality provided by this issue already exists in Lucene/Solr: TypeTokenFilter(Factory). In fact, TypeTokenFilter also can handle whitelisted types in addition to the blacklisting functionality provided here. Is there something here that TypeTokenFilter can't do? AFAICT, this issue should be closed as Won't Fix. StopTermTypesFilter and Factory allows filtering based on the TermTypeAttribute --- Key: SOLR-3030 URL: https://issues.apache.org/jira/browse/SOLR-3030 Project: Solr Issue Type: New Feature Components: Schema and Analysis Affects Versions: 4.0-ALPHA Reporter: Monica Skidmore Priority: Trivial Labels: features, newbie, patch Attachments: SOLR-3030 4.0.patch, SOLR-3030.patch Original Estimate: 168h Remaining Estimate: 168h This filter will remove terms based on the TermTypeAttribute, using a list of StopTermTypes from the StopTermTypes file specified by the user as an attribute of the filter factory in their schema. -- 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-4586) Change default ResultMode of FacetRequest to PER_NODE_IN_TREE
[
https://issues.apache.org/jira/browse/LUCENE-4586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13509847#comment-13509847
]
Gilad Barkai commented on LUCENE-4586:
--
Patch looks good, ready for a commit.
+1
Change default ResultMode of FacetRequest to PER_NODE_IN_TREE
-
Key: LUCENE-4586
URL: https://issues.apache.org/jira/browse/LUCENE-4586
Project: Lucene - Core
Issue Type: Improvement
Components: modules/facet
Reporter: Shai Erera
Assignee: Shai Erera
Priority: Minor
Fix For: 4.1, 5.0
Attachments: LUCENE-4586.patch, LUCENE-4586.patch
Today the default ResultMode is GLOBAL_FLAT, but it should be
PER_NODE_IN_TREE. ResultMode is being used whenever you set the depth of
FacetRequest to greater than 1. The difference between the two is:
* PER_NODE_IN_TREE would then compute the top-K categories recursively, for
every top category at every level (up to depth). The results are returned in
a tree structure as well. For instance:
{noformat}
Date
2010
March
February
2011
April
May
{noformat}
* GLOBAL_FLAT computes the top categories among all the nodes up to depth,
and returns a flat list of categories.
GLOBAL_FLAT is faster to compute than PER_NODE_IN_TREE (it just computes
top-K among N total categories), however I think that it's less intuitive,
and therefore should not be used as a default. In fact, I think this is kind
of an expert usage.
--
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-4586) Change default ResultMode of FacetRequest to PER_NODE_IN_TREE
[
https://issues.apache.org/jira/browse/LUCENE-4586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13509852#comment-13509852
]
Shai Erera commented on LUCENE-4586:
Thanks. I'll give tests a couple more runs on my box before I commit.
Change default ResultMode of FacetRequest to PER_NODE_IN_TREE
-
Key: LUCENE-4586
URL: https://issues.apache.org/jira/browse/LUCENE-4586
Project: Lucene - Core
Issue Type: Improvement
Components: modules/facet
Reporter: Shai Erera
Assignee: Shai Erera
Priority: Minor
Fix For: 4.1, 5.0
Attachments: LUCENE-4586.patch, LUCENE-4586.patch
Today the default ResultMode is GLOBAL_FLAT, but it should be
PER_NODE_IN_TREE. ResultMode is being used whenever you set the depth of
FacetRequest to greater than 1. The difference between the two is:
* PER_NODE_IN_TREE would then compute the top-K categories recursively, for
every top category at every level (up to depth). The results are returned in
a tree structure as well. For instance:
{noformat}
Date
2010
March
February
2011
April
May
{noformat}
* GLOBAL_FLAT computes the top categories among all the nodes up to depth,
and returns a flat list of categories.
GLOBAL_FLAT is faster to compute than PER_NODE_IN_TREE (it just computes
top-K among N total categories), however I think that it's less intuitive,
and therefore should not be used as a default. In fact, I think this is kind
of an expert usage.
--
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] (LUCENE-4585) Spatial RecursivePrefixTreeFilter has some bugs with indexing non-point shapes
[ https://issues.apache.org/jira/browse/LUCENE-4585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley updated LUCENE-4585: - Attachment: LUCENE-4585_PrefixTree_bugs.patch The attached patch resolves the aforementioned problems. However note that when a point is indexed, the final full-length token is not indexed with a trailing leaf '+' byte variant; it was before. The up-side is that we save one token per indexed point (~1/12th savings if 11 maxLevels). The semantics of that '+' are intended to be that the entire grid cell represents an indexed shape for matching, so compare the rectangle for it with the query shape. But for points, it should be the center point of the cell, so no '+'. If a user doesn't re-index, then an indexed point is 1/2 the smallest grid cell closer to a query shape and as such might match when it didn't before. Quite minor I think but worth mentioning. Spatial RecursivePrefixTreeFilter has some bugs with indexing non-point shapes -- Key: LUCENE-4585 URL: https://issues.apache.org/jira/browse/LUCENE-4585 Project: Lucene - Core Issue Type: Bug Components: modules/spatial Affects Versions: 4.0 Reporter: David Smiley Attachments: LUCENE-4585_PrefixTree_bugs.patch RecursivePrefixTreeFilter has some bugs that can occur when searching indexed shapes. One bug is an unpositioned termsEnum. It through an exception in testing; I'm not sure what its effects would be in production. The other couple bugs are hard to describe here but were rare to occur in extensive testing. The effects were probably a slim chance of matching an indexed shape near the query shape. And SpatialPrefixTree does not support an indexed shape that covers the entire globe. These bugs were discovered during development of tests for RPTF LUCENE-4419 which I will submit shortly. -- 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] [Comment Edited] (LUCENE-4585) Spatial RecursivePrefixTreeFilter has some bugs with indexing non-point shapes
[ https://issues.apache.org/jira/browse/LUCENE-4585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13509854#comment-13509854 ] David Smiley edited comment on LUCENE-4585 at 12/4/12 4:58 PM: --- The attached patch resolves the aforementioned problems. However note that when a point is indexed, the final full-length token is not indexed with a trailing leaf '\+' byte variant; it was before. The up-side is that we save one token per indexed point (~1/12th savings if 11 maxLevels). The semantics of that '\+' are intended to be that the entire grid cell represents an indexed shape for matching, so compare the rectangle for it with the query shape. But for points, it should be the center point of the cell, so no '+'. If a user doesn't re-index, then an indexed point is 1/2 the smallest grid cell closer to a query shape and as such might match when it didn't before. Quite minor I think but worth mentioning. was (Author: dsmiley): The attached patch resolves the aforementioned problems. However note that when a point is indexed, the final full-length token is not indexed with a trailing leaf '+' byte variant; it was before. The up-side is that we save one token per indexed point (~1/12th savings if 11 maxLevels). The semantics of that '+' are intended to be that the entire grid cell represents an indexed shape for matching, so compare the rectangle for it with the query shape. But for points, it should be the center point of the cell, so no '+'. If a user doesn't re-index, then an indexed point is 1/2 the smallest grid cell closer to a query shape and as such might match when it didn't before. Quite minor I think but worth mentioning. Spatial RecursivePrefixTreeFilter has some bugs with indexing non-point shapes -- Key: LUCENE-4585 URL: https://issues.apache.org/jira/browse/LUCENE-4585 Project: Lucene - Core Issue Type: Bug Components: modules/spatial Affects Versions: 4.0 Reporter: David Smiley Attachments: LUCENE-4585_PrefixTree_bugs.patch RecursivePrefixTreeFilter has some bugs that can occur when searching indexed shapes. One bug is an unpositioned termsEnum. It through an exception in testing; I'm not sure what its effects would be in production. The other couple bugs are hard to describe here but were rare to occur in extensive testing. The effects were probably a slim chance of matching an indexed shape near the query shape. And SpatialPrefixTree does not support an indexed shape that covers the entire globe. These bugs were discovered during development of tests for RPTF LUCENE-4419 which I will submit shortly. -- 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] (LUCENE-4583) StraightBytesDocValuesField fails if bytes 32k
[
https://issues.apache.org/jira/browse/LUCENE-4583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barakat Barakat updated LUCENE-4583:
Attachment: LUCENE-4583.patch
I updated the code to work when start isn't zero. The code can still crash if
you ask for a length that goes beyond the total size of the paged bytes, but
I'm not sure how you guys like to prevent things like that. The code seems to
be working fine with our Solr core so far. I am new to posting patches and
writing test units in Java so please let me know if there is anything wrong
with the code.
StraightBytesDocValuesField fails if bytes 32k
Key: LUCENE-4583
URL: https://issues.apache.org/jira/browse/LUCENE-4583
Project: Lucene - Core
Issue Type: Bug
Components: core/index
Affects Versions: 4.0, 4.1, 5.0
Reporter: David Smiley
Priority: Critical
Fix For: 4.1
Attachments: LUCENE-4583.patch
I didn't observe any limitations on the size of a bytes based DocValues field
value in the docs. It appears that the limit is 32k, although I didn't get
any friendly error telling me that was the limit. 32k is kind of small IMO;
I suspect this limit is unintended and as such is a bug.The following
test fails:
{code:java}
public void testBigDocValue() throws IOException {
Directory dir = newDirectory();
IndexWriter writer = new IndexWriter(dir, writerConfig(false));
Document doc = new Document();
BytesRef bytes = new BytesRef((4+4)*4097);//4096 works
bytes.length = bytes.bytes.length;//byte data doesn't matter
doc.add(new StraightBytesDocValuesField(dvField, bytes));
writer.addDocument(doc);
writer.commit();
writer.close();
DirectoryReader reader = DirectoryReader.open(dir);
DocValues docValues = MultiDocValues.getDocValues(reader, dvField);
//FAILS IF BYTES IS BIG!
docValues.getSource().getBytes(0, bytes);
reader.close();
dir.close();
}
{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-1575) loading solr.xml takes a lot of time when there are lot of cores
[ https://issues.apache.org/jira/browse/SOLR-1575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13509857#comment-13509857 ] olivier soyez commented on SOLR-1575: - We have around 50K cores with loadOnStart=false and same issue to start the server. It takes a very long time to start, and it is just the time taken for loading the config file listing the available solr cores : solr.xml. To solve this, in the load function, I just replace the line 532 of CoreContainer.java (Apache Solr 4.0 release) from p.setCoreProperties(readProperties(cfg, node)); to p.setCoreProperties(readProperties(cfg, node.getParentNode().removeChild(node))); Now, it takes a few seconds to start the server loading solr.xml takes a lot of time when there are lot of cores Key: SOLR-1575 URL: https://issues.apache.org/jira/browse/SOLR-1575 Project: Solr Issue Type: Improvement Components: multicore Reporter: Noble Paul Priority: Minor Fix For: 1.5 We have around 38K cores which takes up around 25 mins to start the server. Keep in mind that no cores are started and this is the time taken for loading the solr.xml. -- 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-4114) Collection API: Allow multiple shards from one collection on the same Solr server
[ https://issues.apache.org/jira/browse/SOLR-4114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13509861#comment-13509861 ] Mark Miller commented on SOLR-4114: --- Yeah, I minimized the patch down to just dealing with this issue. I'm away from home and just looking to get this issue completed with minimum fuss. 'nodeUrlWithoutProtocolPart' is just so long and I didn't see it helping much in terms of code readability - if you have a better fitting name that is a little less verbose, I think I'd be more into it. bq. I see that you removed the auto-reduce replica-per-shard t Yeah, I don't think I agree with changing the users params on him - I'd rather warn and let the user do what he wants to do rather than trying to outthink him ahead of time. If he decides he wants more than one repica on an instance for some reason, that's his deal - we can warn him though. bq. You removed the following lines (because you just want default-values for instance-dir and data-dir) Right - it should match collection1 - eg newcollection/data should be the data dir just like collection1/data and rather than something like newcollection_data. In my experience and testing, data ends up in the cores own instance dir - not some common dir. bq. making shardToUrls-map (renamed) concurrency protected Yup - it seemed unrelated and I'm busy so I didn't want to think about it. My goal is to get the essence of this thing committed - it's a lot easier to then fight over smaller pieces on top of that. Progress not perfection. Collection API: Allow multiple shards from one collection on the same Solr server - Key: SOLR-4114 URL: https://issues.apache.org/jira/browse/SOLR-4114 Project: Solr Issue Type: New Feature Components: multicore, SolrCloud Affects Versions: 4.0 Environment: Solr 4.0.0 release Reporter: Per Steffensen Assignee: Per Steffensen Labels: collection-api, multicore, shard, shard-allocation Attachments: SOLR-4114.patch, SOLR-4114.patch, SOLR-4114.patch, SOLR-4114.patch, SOLR-4114_trunk.patch We should support running multiple shards from one collection on the same Solr server - the run a collection with 8 shards on a 4 Solr server cluster (each Solr server running 2 shards). Performance tests at our side has shown that this is a good idea, and it is also a good idea for easy elasticity later on - it is much easier to move an entire existing shards from one Solr server to another one that just joined the cluter than it is to split an exsiting shard among the Solr that used to run it and the new Solr. See dev mailing list discussion Multiple shards for one collection on the same Solr server -- 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-4114) Collection API: Allow multiple shards from one collection on the same Solr server
[ https://issues.apache.org/jira/browse/SOLR-4114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13509864#comment-13509864 ] Mark Miller commented on SOLR-4114: --- bq. In checkForCollection we are willing to wait up to 120 secs (used to be 60 secs) for the collection to be created (correctly). So it is kinda obvious to also wait at least 60 secs to verify that nothing related to a collection was actually created in cases where you want to be sure that nothing is created. We poll so that we wait up to 120 seconds for a slow comp, but a fast comp won't need to wait nearly that long. The 60 wait hits everyone no matter what. We generally try avoid any hard waits like that. I understand you can't really poll in this case, so I'm not sure the best way to test that - I made it a TODO for now. Collection API: Allow multiple shards from one collection on the same Solr server - Key: SOLR-4114 URL: https://issues.apache.org/jira/browse/SOLR-4114 Project: Solr Issue Type: New Feature Components: multicore, SolrCloud Affects Versions: 4.0 Environment: Solr 4.0.0 release Reporter: Per Steffensen Assignee: Per Steffensen Labels: collection-api, multicore, shard, shard-allocation Attachments: SOLR-4114.patch, SOLR-4114.patch, SOLR-4114.patch, SOLR-4114.patch, SOLR-4114_trunk.patch We should support running multiple shards from one collection on the same Solr server - the run a collection with 8 shards on a 4 Solr server cluster (each Solr server running 2 shards). Performance tests at our side has shown that this is a good idea, and it is also a good idea for easy elasticity later on - it is much easier to move an entire existing shards from one Solr server to another one that just joined the cluter than it is to split an exsiting shard among the Solr that used to run it and the new Solr. See dev mailing list discussion Multiple shards for one collection on the same Solr server -- 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-4114) Collection API: Allow multiple shards from one collection on the same Solr server
[ https://issues.apache.org/jira/browse/SOLR-4114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13509882#comment-13509882 ] Commit Tag Bot commented on SOLR-4114: -- [trunk commit] Mark Robert Miller http://svn.apache.org/viewvc?view=revisionrevision=1417045 SOLR-4114: Allow creating more than one shard per instance with the Collection API. Collection API: Allow multiple shards from one collection on the same Solr server - Key: SOLR-4114 URL: https://issues.apache.org/jira/browse/SOLR-4114 Project: Solr Issue Type: New Feature Components: multicore, SolrCloud Affects Versions: 4.0 Environment: Solr 4.0.0 release Reporter: Per Steffensen Assignee: Per Steffensen Labels: collection-api, multicore, shard, shard-allocation Attachments: SOLR-4114.patch, SOLR-4114.patch, SOLR-4114.patch, SOLR-4114.patch, SOLR-4114_trunk.patch We should support running multiple shards from one collection on the same Solr server - the run a collection with 8 shards on a 4 Solr server cluster (each Solr server running 2 shards). Performance tests at our side has shown that this is a good idea, and it is also a good idea for easy elasticity later on - it is much easier to move an entire existing shards from one Solr server to another one that just joined the cluter than it is to split an exsiting shard among the Solr that used to run it and the new Solr. See dev mailing list discussion Multiple shards for one collection on the same Solr server -- 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
Re: Odd pattern of segment creation - branch_4x bug?
On 12/3/2012 9:46 PM, Yonik Seeley wrote: On Mon, Dec 3, 2012 at 11:36 PM, Shawn Heisey s...@elyograg.org wrote: updateHandler class=solr.DirectUpdateHandler2 autoCommit maxDocs65536/maxDocs maxTime30/maxTime /autoCommit updateLog / /updateHandler Yeah, seems like that just should generate hard commits. Are you using delete by querys at all? The current implementation can do an NRT reopen as part of it's implementation. When I do deletes, it's done exclusively using deleteByQuery in SolrJ, with something like did:(1000 OR 1001 OR 1002 OR 1003) as the query. Before doing the delete, I do a search using the same query and only proceed to do the delete on that shard if numFound from the query is more than zero. I don't know if this is necessary information, but no deletes are happening while I do my full-import. Nothing else happens to the index at all while DIH is doing its thing. This is new experimentation with autocommit. By using autocommit, the commit at the end of an import is much faster. When autocommit is turned off, it is several minutes between the last document add and the handler returning to idle status. I like this new faster commit, but if I can't get an autocommit to only produce one segment, I may go back to the old way, to reduce the I/O impact from the more frequent merges. Thanks, Shawn - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4114) Collection API: Allow multiple shards from one collection on the same Solr server
[ https://issues.apache.org/jira/browse/SOLR-4114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13509910#comment-13509910 ] Commit Tag Bot commented on SOLR-4114: -- [branch_4x commit] Mark Robert Miller http://svn.apache.org/viewvc?view=revisionrevision=1417070 SOLR-4114: Allow creating more than one shard per instance with the Collection API. Collection API: Allow multiple shards from one collection on the same Solr server - Key: SOLR-4114 URL: https://issues.apache.org/jira/browse/SOLR-4114 Project: Solr Issue Type: New Feature Components: multicore, SolrCloud Affects Versions: 4.0 Environment: Solr 4.0.0 release Reporter: Per Steffensen Assignee: Per Steffensen Labels: collection-api, multicore, shard, shard-allocation Attachments: SOLR-4114.patch, SOLR-4114.patch, SOLR-4114.patch, SOLR-4114.patch, SOLR-4114_trunk.patch We should support running multiple shards from one collection on the same Solr server - the run a collection with 8 shards on a 4 Solr server cluster (each Solr server running 2 shards). Performance tests at our side has shown that this is a good idea, and it is also a good idea for easy elasticity later on - it is much easier to move an entire existing shards from one Solr server to another one that just joined the cluter than it is to split an exsiting shard among the Solr that used to run it and the new Solr. See dev mailing list discussion Multiple shards for one collection on the same Solr server -- 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] (LUCENE-4585) Spatial RecursivePrefixTreeFilter has some bugs with indexing non-point shapes
[ https://issues.apache.org/jira/browse/LUCENE-4585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley updated LUCENE-4585: - Attachment: LUCENE-4585_PrefixTree_bugs.patch Updated patch with the correct set of files. Spatial RecursivePrefixTreeFilter has some bugs with indexing non-point shapes -- Key: LUCENE-4585 URL: https://issues.apache.org/jira/browse/LUCENE-4585 Project: Lucene - Core Issue Type: Bug Components: modules/spatial Affects Versions: 4.0 Reporter: David Smiley Attachments: LUCENE-4585_PrefixTree_bugs.patch, LUCENE-4585_PrefixTree_bugs.patch RecursivePrefixTreeFilter has some bugs that can occur when searching indexed shapes. One bug is an unpositioned termsEnum. It through an exception in testing; I'm not sure what its effects would be in production. The other couple bugs are hard to describe here but were rare to occur in extensive testing. The effects were probably a slim chance of matching an indexed shape near the query shape. And SpatialPrefixTree does not support an indexed shape that covers the entire globe. These bugs were discovered during development of tests for RPTF LUCENE-4419 which I will submit shortly. -- 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
[JENKINS] Lucene-Solr-trunk-Windows (32bit/jdk1.7.0_09) - Build # 2052 - Failure!
Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Windows/2052/ Java: 32bit/jdk1.7.0_09 -server -XX:+UseG1GC All tests passed Build Log: [...truncated 13648 lines...] BUILD FAILED C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\build.xml:88: The following files contain @author tags, tabs or nocommits: * solr/core/src/test/org/apache/solr/cloud/BasicDistributedZkTest.java Total time: 52 minutes 34 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Recording test results Description set: Java: 32bit/jdk1.7.0_09 -server -XX:+UseG1GC Email was triggered for: Failure Sending email for trigger: Failure - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.6.0_37) - Build # 3061 - Failure!
Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Linux/3061/ Java: 64bit/jdk1.6.0_37 -XX:+UseParallelGC All tests passed Build Log: [...truncated 12949 lines...] BUILD FAILED /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:88: The following files contain @author tags, tabs or nocommits: * solr/core/src/test/org/apache/solr/cloud/BasicDistributedZkTest.java Total time: 27 minutes 56 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Recording test results Description set: Java: 64bit/jdk1.6.0_37 -XX:+UseParallelGC Email was triggered for: Failure Sending email for trigger: Failure - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
RE: Solrj question
Thanks, for some reason I got stopped with the fact that XMLWriter wanted SolrQueryRequest/Response instead of the NamedList available in solrj's QueryResponse and never looked at building those from the info I already had. It is working now. For the comment on efficiency, I do have to agree that parsing to Java object and then serializing back is less than optimal to say the least. The reason it has to be done in our case is because the component acting as proxy also supports extra parameters for some of our business logic that will modify the incoming query in some cases, decide where it goes in others, etc. So to avoid rewriting the logic inside of CloudSolrServer, I want to reuse it (I really hate duplicating code). But the output is a Java object (QueryResponse), so I have to serialize it back. Unless there's a way to get the original message before it's unmarshaled into the QueryResponse, in which case I'd be more than happy to use that as-is. :) Anyways, as I mentioned, it seems to be working for now. And I do use javabin between that component and Solr no matter what was asked in the request since I can then marshal it to anything. Steve Molloy Content Analytics Lead | RD Phone: (514) 908-5406 406 Website: www.opentext.comhttp://www.opentext.com/ [http://www.opentext.com/2/emailsupport-logo-opentext-2010.gif]http://www.opentext.com/2/email-signature-logo http://www.opentext.com/2/email-signature-event We can't solve problems by using the same kind of thinking we used when we created them. Attributed to Albert Einstein From: Per Steffensen [mailto:st...@designware.dk] Sent: Tuesday, December 04, 2012 10:24 AM To: dev@lucene.apache.org Subject: Re: Solrj question Believe there are no setParser method on CloudSolrServer? Have you tried this: XMLWriter.writeResponse(a java.io.Writer for your XML output, your SolrQueryRequest, your SolrQueryResponse) It will require you to include solr-core, since that is where XMLWriter lives. But it is a little inefficient, if I understand you correctly. If you have a CloudSolrServer doing a request and asks for a response in e.g. XML format, then this CloudSolrServer will receive a XML response over the wire, parse it into a SolrQueryResponse object and then you will take that SolrQueryResponse and serialize it back to XML. It would be nicer if you just used whatever was received on the wire directly. Regards, Per Steffensen Erick Erickson skrev: haven't tried this personally, but try this: server.setParser(new XMLResponseParser()); Best Erick On Mon, Dec 3, 2012 at 10:24 AM, Steve Molloy smol...@opentext.commailto:smol...@opentext.com wrote: I've been digging around a bit and could not find any straight-forward way of getting back the XML response after calling Solr using Solrj. The query method returns a QueryResponse object, which is great in most cases. But our use case implies pushing the response back to whatever format was requested, but still use the CloudSolrServer client. This is very easy with the javabin format, using the JavaBinCodec, but is there equivalent utilities to marshal into other formats from a NamedList? Otherwise, could the functionality be isolated for better reuse? Thanks, Steve Molloy Content Analytics Lead | RD Phone: (514) 908-5406 406tel:908-5406%20406 Website: www.opentext.comhttp://www.opentext.com/ [http://www.opentext.com/2/emailsupport-logo-opentext-2010.gif]http://www.opentext.com/2/email-signature-logo Nstein is now OpenText. Please update your address book with my new email address. This email message is confidential, may be privileged, and is intended for the exclusive use of the addressee. Any other person is strictly prohibited from disclosing or reproducing it. If the addressee cannot be reached or is unknown to you, please inform the sender by return email and delete this email message and all copies immediately. inline: image001.gifinline: image002.gif
Re: JSON Format Mbeans Stat Error
: The result that we have is :
:
: solr-mbeans:[
: CORE,{...},
: QUERYHANDLER,{...},
: CACHE,{...},...
:
: In other terms, a table with a succession of
: key,value,key,value,key,value,... and not a map.
Correct. see the json.nl param which controls how NamedList data is
included in the response...
http://wiki.apache.org/solr/SolJSON#JSON_specific_parameters
-Hoss
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_09) - Build # 3026 - Failure!
You should take a look at the precommit target you pointed me at! - Mark On Dec 2, 2012, at 3:00 PM, Michael McCandless luc...@mikemccandless.com wrote: Woops, I committed a fix ... Mike McCandless http://blog.mikemccandless.com On Sun, Dec 2, 2012 at 5:53 PM, Policeman Jenkins Server jenk...@sd-datasolutions.de wrote: Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Linux/3026/ Java: 32bit/jdk1.7.0_09 -server -XX:+UseParallelGC All tests passed Build Log: [...truncated 25027 lines...] BUILD FAILED /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:60: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build.xml:285: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-build.xml:1526: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-build.xml:1560: Compile failed; see the compiler error output for details. Total time: 28 minutes 52 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Recording test results Description set: Java: 32bit/jdk1.7.0_09 -server -XX:+UseParallelGC Email was triggered for: Failure Sending email for trigger: Failure - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_09) - Build # 3026 - Failure!
Yes, my bad, sorry :( I share your view that it's annoyingly slow to run the top-level ant precommit, especially when it's a tiny change. So this time I took a shortcut and ran ant javadocs in lucene/core as a proxy for a top-level ant precommit, yet that was not good enough because the ecj compiler is more picky. I'd really love to have a per-module ant precommit. Mike McCandless http://blog.mikemccandless.com On Tue, Dec 4, 2012 at 2:25 PM, Mark Miller markrmil...@gmail.com wrote: You should take a look at the precommit target you pointed me at! - Mark On Dec 2, 2012, at 3:00 PM, Michael McCandless luc...@mikemccandless.com wrote: Woops, I committed a fix ... Mike McCandless http://blog.mikemccandless.com On Sun, Dec 2, 2012 at 5:53 PM, Policeman Jenkins Server jenk...@sd-datasolutions.de wrote: Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Linux/3026/ Java: 32bit/jdk1.7.0_09 -server -XX:+UseParallelGC All tests passed Build Log: [...truncated 25027 lines...] BUILD FAILED /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:60: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build.xml:285: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-build.xml:1526: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-build.xml:1560: Compile failed; see the compiler error output for details. Total time: 28 minutes 52 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Recording test results Description set: Java: 32bit/jdk1.7.0_09 -server -XX:+UseParallelGC Email was triggered for: Failure Sending email for trigger: Failure - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4114) Collection API: Allow multiple shards from one collection on the same Solr server
[ https://issues.apache.org/jira/browse/SOLR-4114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13509960#comment-13509960 ] Per Steffensen commented on SOLR-4114: -- bq. We poll so that we wait up to 120 seconds for a slow comp, but a fast comp won't need to wait nearly that long. The 60 wait hits everyone no matter what. We generally try avoid any hard waits like that. I understand you can't really poll in this case, so I'm not sure the best way to test that - I made it a TODO for now. Ok with a TODO, but it should be about making a more clever solution than the 60 sec wait. You commented out the assert-method checkCollectionIsNotCreated, which means that we now have an unprotected feature in the code-base. Anyone can go ruin this feature tomorrow and no one will notice. Yes, I believe the main value of tests is their ability to protect other people from accidently ruining existing fuctionality. All the comments below are very unimportant compared to this - I am really serious about this. Get checkCollectionIsNotCreated running now so that the code is protected, then think about a more clever solution later (if you think such a thing exists). TODO's have a tendency to be forgotten. bq. Yeah, I minimized the patch down to just dealing with this issue. I'm away from home and just looking to get this issue completed with minimum fuss. Then the easiest thing would probably have been, to take everything in, except for things you thought would actually ruin existing stuff. Instead of using time to find every little detail that could be left out. Do not misunderstand me, I am glad you used your time to get it committed, but I also want to influence the way you committers work, whenever I have the chance. Only thinking about our common interrest - a good Solr. I have a bad gut feeling that the code-base is so messy because no one ever refactors. Refactoring is something you usually do while solving some specific (potentially) unrelated task. No one goes refactoring just to do refactoring, but it is extremely important that refactoring has an easy way into the code-base. bq. 'nodeUrlWithoutProtocolPart' is just so long and I didn't see it helping much in terms of code readability - if you have a better fitting name that is a little less verbose, I think I'd be more into it. Well, first of all a long saying name is much better than a short misleading name, and second of all that name really isnt very long :-) bq. Yeah, I don't think I agree with changing the users params on him - I'd rather warn and let the user do what he wants to do rather than trying to outthink him ahead of time. If he decides he wants more than one repica on an instance for some reason, that's his deal - we can warn him though. Ok, cool bq. Right - it should match collection1 - eg newcollection/data should be the data dir just like collection1/data and rather than something like newcollection_data. In my experience and testing, data ends up in the cores own instance dir - not some common dir. Didnt learn much from this explanation, but I will have to do a little studying on instance-dir and data-dir to understand how your solution will ever work. I will get back with an official complaint (just a comment here or a mail on the mailing list :-) ) if I still do not think it will work after I have done my studying. bq. Yup - it seemed unrelated and I'm busy so I didn't want to think about it... Still easier to just take it in, unless you saw it harming more than it helped. I am worried about refactoring in this project! Trust your test-suite :-) Collection API: Allow multiple shards from one collection on the same Solr server - Key: SOLR-4114 URL: https://issues.apache.org/jira/browse/SOLR-4114 Project: Solr Issue Type: New Feature Components: multicore, SolrCloud Affects Versions: 4.0 Environment: Solr 4.0.0 release Reporter: Per Steffensen Assignee: Per Steffensen Labels: collection-api, multicore, shard, shard-allocation Attachments: SOLR-4114.patch, SOLR-4114.patch, SOLR-4114.patch, SOLR-4114.patch, SOLR-4114_trunk.patch We should support running multiple shards from one collection on the same Solr server - the run a collection with 8 shards on a 4 Solr server cluster (each Solr server running 2 shards). Performance tests at our side has shown that this is a good idea, and it is also a good idea for easy elasticity later on - it is much easier to move an entire existing shards from one Solr server to another one that just joined the cluter than it is to split an exsiting shard among the Solr that used to run it and the new Solr. See dev mailing list discussion
Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_09) - Build # 3026 - Failure!
On Dec 4, 2012, at 2:45 PM, Michael McCandless luc...@mikemccandless.com wrote: I'd really love to have a per-module ant precommit. +1 - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_09) - Build # 3026 - Failure!
: I'd really love to have a per-module ant precommit.
That's not really viable is it?
small tweaks in one class might leave everything fine and dandy in that
module, but another module that depends on it could break as a result (eg:
removing a method/variable that is {@link}ed to, etc...)
-Hoss
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4114) Collection API: Allow multiple shards from one collection on the same Solr server
[ https://issues.apache.org/jira/browse/SOLR-4114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13509967#comment-13509967 ] Mark Miller commented on SOLR-4114: --- bq. Still easier to just take it in For me it's easier to not take it in :) I have to vet what I take in. I think you will find it easier to get stuff in if your refactoring is related to the issue. Otherwise make a refactoring issue. bq. Trust your test-suite It's not my test-suite, it's a huge shard test-suite and I don't blindly trust it. It certainly doesn't test everything. Collection API: Allow multiple shards from one collection on the same Solr server - Key: SOLR-4114 URL: https://issues.apache.org/jira/browse/SOLR-4114 Project: Solr Issue Type: New Feature Components: multicore, SolrCloud Affects Versions: 4.0 Environment: Solr 4.0.0 release Reporter: Per Steffensen Assignee: Per Steffensen Labels: collection-api, multicore, shard, shard-allocation Attachments: SOLR-4114.patch, SOLR-4114.patch, SOLR-4114.patch, SOLR-4114.patch, SOLR-4114_trunk.patch We should support running multiple shards from one collection on the same Solr server - the run a collection with 8 shards on a 4 Solr server cluster (each Solr server running 2 shards). Performance tests at our side has shown that this is a good idea, and it is also a good idea for easy elasticity later on - it is much easier to move an entire existing shards from one Solr server to another one that just joined the cluter than it is to split an exsiting shard among the Solr that used to run it and the new Solr. See dev mailing list discussion Multiple shards for one collection on the same Solr server -- 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
Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_09) - Build # 3026 - Failure!
Well perhaps there is a middle ground - 'quasi-precommit' that just checks fast
stuff per module… (eg doesn't build all the javadocs)
Then we would catch more, but perhaps not everything.
Precommit is scary slow and if it's so slow no one will use it, it's almost not
so helpful.
- Mark
On Dec 4, 2012, at 11:53 AM, Chris Hostetter hossman_luc...@fucit.org wrote:
: I'd really love to have a per-module ant precommit.
That's not really viable is it?
small tweaks in one class might leave everything fine and dandy in that
module, but another module that depends on it could break as a result (eg:
removing a method/variable that is {@link}ed to, etc...)
-Hoss
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_09) - Build # 3026 - Failure!
On Tue, Dec 4, 2012 at 3:00 PM, Mark Miller markrmil...@gmail.com wrote: Well perhaps there is a middle ground - 'quasi-precommit' that just checks fast stuff per module… (eg doesn't build all the javadocs) Right, is seems like a good number off the checks (no tabs, nocommits, author tags, ecj is happy) can be done only on the current module ... Precommit is scary slow and if it's so slow no one will use it, it's almost not so helpful. Especially when the original change is trivial (all I did was rename a boolean param, and add some javadocs about it, here). Hmm I wonder if we could parallelize it ... Mike McCandless http://blog.mikemccandless.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_09) - Build # 3026 - Failure!
I think one useful middle point might be to only run checks on modules that
have pending changes. Yes, as Hoss points out, an unchanged module's javadocs
might no longer work (etc.), but I don't think that's the common case.
On Dec 4, 2012, at 3:00 PM, Mark Miller markrmil...@gmail.com wrote:
Well perhaps there is a middle ground - 'quasi-precommit' that just checks
fast stuff per module… (eg doesn't build all the javadocs)
Then we would catch more, but perhaps not everything.
Precommit is scary slow and if it's so slow no one will use it, it's almost
not so helpful.
- Mark
On Dec 4, 2012, at 11:53 AM, Chris Hostetter hossman_luc...@fucit.org wrote:
: I'd really love to have a per-module ant precommit.
That's not really viable is it?
small tweaks in one class might leave everything fine and dandy in that
module, but another module that depends on it could break as a result (eg:
removing a method/variable that is {@link}ed to, etc...)
-Hoss
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_09) - Build # 3026 - Failure!
I think the slowness problem can be fixed way easier than that.
Actually in my opinion the main bug is the speed of building javadocs
themselves. Today this requires lots of building of useless jars and some
other things that are unnecessary.
I also think javadocs for a module get rebuilt across the whole thing
because they are depended on by some other module's javadocs, and so on.
I really don't think the checks should be weakened in any way. These checks
are necessary (people will complain about them at release vote time, so we
have to keep the codebase in good order and not just all make a mess for
months, waiting for some RM to clean it up).
On Tue, Dec 4, 2012 at 3:16 PM, Steve Rowe sar...@gmail.com wrote:
I think one useful middle point might be to only run checks on modules
that have pending changes. Yes, as Hoss points out, an unchanged module's
javadocs might no longer work (etc.), but I don't think that's the common
case.
On Dec 4, 2012, at 3:00 PM, Mark Miller markrmil...@gmail.com wrote:
Well perhaps there is a middle ground - 'quasi-precommit' that just
checks fast stuff per module… (eg doesn't build all the javadocs)
Then we would catch more, but perhaps not everything.
Precommit is scary slow and if it's so slow no one will use it, it's
almost not so helpful.
- Mark
On Dec 4, 2012, at 11:53 AM, Chris Hostetter hossman_luc...@fucit.org
wrote:
: I'd really love to have a per-module ant precommit.
That's not really viable is it?
small tweaks in one class might leave everything fine and dandy in that
module, but another module that depends on it could break as a result
(eg:
removing a method/variable that is {@link}ed to, etc...)
-Hoss
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-4587) WordBreakSpellChecker treats bytes as chars
James Dyer created LUCENE-4587: -- Summary: WordBreakSpellChecker treats bytes as chars Key: LUCENE-4587 URL: https://issues.apache.org/jira/browse/LUCENE-4587 Project: Lucene - Core Issue Type: Bug Components: modules/spellchecker Affects Versions: 4.0 Reporter: Andreas Hubold Assignee: James Dyer Fix For: 4.1, 5.0 Originally opened as SOLR-4115. -- 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-4115) WordBreakSpellChecker throws ArrayIndexOutOfBoundsException for random query string
[
https://issues.apache.org/jira/browse/SOLR-4115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Dyer resolved SOLR-4115.
--
Resolution: Duplicate
Assignee: James Dyer
I opened LUCENE-4587 and will resolve with a fix there.
WordBreakSpellChecker throws ArrayIndexOutOfBoundsException for random query
string
---
Key: SOLR-4115
URL: https://issues.apache.org/jira/browse/SOLR-4115
Project: Solr
Issue Type: Bug
Components: spellchecker
Affects Versions: 4.0
Environment: java version 1.6.0_37
Java(TM) SE Runtime Environment (build 1.6.0_37-b06)
Java HotSpot(TM) 64-Bit Server VM (build 20.12-b01, mixed mode)
Reporter: Andreas Hubold
Assignee: James Dyer
The following SolrJ test code causes an ArrayIndexOutOfBoundsException in the
WordBreakSpellChecker. I tested this with the Solr 4.0.0 example webapp
started with {{java -jar start.jar}}.
{code:java}
@Test
public void testWordbreakSpellchecker() throws Exception {
SolrQuery q = new SolrQuery(\uD864\uDC79);
q.setRequestHandler(/browse);
q.setParam(spellcheck.dictionary, wordbreak);
HttpSolrServer server = new HttpSolrServer(http://localhost:8983/solr;);
server.query(q, SolrRequest.METHOD.POST);
}
{code}
{noformat}
INFO: [collection1] webapp=/solr path=/browse
params={spellcheck.dictionary=wordbreakqt=/browsewt=javabinq=?version=2}
hits=0 status=500 QTime=11
Nov 28, 2012 11:23:01 AM org.apache.solr.common.SolrException log
SEVERE: null:java.lang.ArrayIndexOutOfBoundsException: 1
at org.apache.lucene.util.UnicodeUtil.UTF8toUTF16(UnicodeUtil.java:599)
at org.apache.lucene.util.BytesRef.utf8ToString(BytesRef.java:165)
at org.apache.lucene.index.Term.text(Term.java:72)
at
org.apache.lucene.search.spell.WordBreakSpellChecker.generateSuggestWord(WordBreakSpellChecker.java:350)
at
org.apache.lucene.search.spell.WordBreakSpellChecker.generateBreakUpSuggestions(WordBreakSpellChecker.java:283)
at
org.apache.lucene.search.spell.WordBreakSpellChecker.suggestWordBreaks(WordBreakSpellChecker.java:122)
at
org.apache.solr.spelling.WordBreakSolrSpellChecker.getSuggestions(WordBreakSolrSpellChecker.java:229)
at
org.apache.solr.handler.component.SpellCheckComponent.process(SpellCheckComponent.java:172)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:206)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1699)
at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:455)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:276)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1337)
at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:484)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119)
at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:524)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:233)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1065)
at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:413)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:192)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:999)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
at
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:250)
at
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:149)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:111)
at org.eclipse.jetty.server.Server.handle(Server.java:351)
at
org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:454)
at
org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:47)
at
org.eclipse.jetty.server.AbstractHttpConnection.content(AbstractHttpConnection.java:900)
at
org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.content(AbstractHttpConnection.java:954)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:857)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)
at
org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:66)
at
Re: Solrj question
Steve Molloy skrev:
I really hate duplicating code
I love you :-)
Unless there's a way to get the original message before it's
unmarshaled into the QueryResponse, in which case I'd be more than
happy to use that as-is. J
Ha ha. Just had a short look at the code, and tried to hack it, but got
tired, so I didnt complete or test it. But maybe this will help you
(completely untested - dont even know if it will compile):
CloudSolrServer client = new
CloudSolrServer(zk-connect-string, new LBHttpSolrServer(null) {
@Override
protected HttpSolrServer makeServer(String
baseUrl) throws MalformedURLException {
return new HttpSolrServer(baseUrl,
getHttpClient(), null) {
@Override
public NamedListObject request(final
SolrRequest request) throws SolrServerException, IOException{
return request(request, null);
}
};
}
});
InputStream responseDirectlyFromWire =
(InputStream)client.query(query).getResponse().get(stream);
[jira] [Updated] (LUCENE-4499) Multi-word synonym filter (synonym expansion)
[ https://issues.apache.org/jira/browse/LUCENE-4499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Chyla updated LUCENE-4499: Attachment: LUCENE-4499.patch A new patch, as the old version was extending wrong class (which cause web tests to fail) Multi-word synonym filter (synonym expansion) - Key: LUCENE-4499 URL: https://issues.apache.org/jira/browse/LUCENE-4499 Project: Lucene - Core Issue Type: Improvement Components: core/other Affects Versions: 4.1, 5.0 Reporter: Roman Chyla Priority: Minor Labels: analysis, multi-word, synonyms Fix For: 5.0 Attachments: LUCENE-4499.patch, LUCENE-4499.patch I apologize for bringing the multi-token synonym expansion up again. There is an old, unresolved issue at LUCENE-1622 [1] While solving the problem for our needs [2], I discovered that the current SolrSynonym parser (and the wonderful FTS) have almost everything to satisfactorily handle both the query and index time synonym expansion. It seems that people often need to use the synonym filter *slightly* differently at indexing and query time. In our case, we must do different things during indexing and querying. Example sentence: Mirrors of the Hubble space telescope pointed at XA5 This is what we need (comma marks position bump): indexing: mirrors,hubble|hubble space telescope|hst,space,telescope,pointed,xa5|astroobject#5 querying: +mirrors +(hubble space telescope | hst) +pointed +(xa5|astroboject#5) This translated to following needs: indexing time: single-token synonyms = return only synonyms multi-token synonyms = return original tokens *AND* the synonyms query time: single-token: return only synonyms (but preserve case) multi-token: return only synonyms We need the original tokens for the proximity queries, if we indexed 'hubble space telescope' as one token, we cannot search for 'hubble NEAR telescope' You may (not) be surprised, but Lucene already supports ALL of these requirements. The patch is an attempt to state the problem differently. I am not sure if it is the best option, however it works perfectly for our needs and it seems it could work for general public too. Especially if the SynonymFilterFactory had a preconfigured sets of SynonymMapBuilders - and people would just choose what situation they use. Please look at the unittest. links: [1] https://issues.apache.org/jira/browse/LUCENE-1622 [2] http://labs.adsabs.harvard.edu/trac/ads-invenio/ticket/158 [3] seems to have similar request: http://lucene.472066.n3.nabble.com/Proposal-Full-support-for-multi-word-synonyms-at-query-time-td4000522.html -- 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
Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_09) - Build # 3026 - Failure!
We are not talking about weakening them on Jenkins though. It won't wait till
release time, it will be caught 10 min later by Jenkins.
But if we can make it faster and keep all the checks, then by all means!
Mark
Sent from my iPhone
On Dec 4, 2012, at 12:23 PM, Robert Muir rcm...@gmail.com wrote:
I think the slowness problem can be fixed way easier than that.
Actually in my opinion the main bug is the speed of building javadocs
themselves. Today this requires lots of building of useless jars and some
other things that are unnecessary.
I also think javadocs for a module get rebuilt across the whole thing
because they are depended on by some other module's javadocs, and so on.
I really don't think the checks should be weakened in any way. These checks
are necessary (people will complain about them at release vote time, so we
have to keep the codebase in good order and not just all make a mess for
months, waiting for some RM to clean it up).
On Tue, Dec 4, 2012 at 3:16 PM, Steve Rowe sar...@gmail.com wrote:
I think one useful middle point might be to only run checks on modules that
have pending changes. Yes, as Hoss points out, an unchanged module's
javadocs might no longer work (etc.), but I don't think that's the common
case.
On Dec 4, 2012, at 3:00 PM, Mark Miller markrmil...@gmail.com wrote:
Well perhaps there is a middle ground - 'quasi-precommit' that just checks
fast stuff per module… (eg doesn't build all the javadocs)
Then we would catch more, but perhaps not everything.
Precommit is scary slow and if it's so slow no one will use it, it's
almost not so helpful.
- Mark
On Dec 4, 2012, at 11:53 AM, Chris Hostetter hossman_luc...@fucit.org
wrote:
: I'd really love to have a per-module ant precommit.
That's not really viable is it?
small tweaks in one class might leave everything fine and dandy in that
module, but another module that depends on it could break as a result (eg:
removing a method/variable that is {@link}ed to, etc...)
-Hoss
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_09) - Build # 3026 - Failure!
On Tue, Dec 4, 2012 at 3:33 PM, Mark Miller markrmil...@gmail.com wrote: We are not talking about weakening them on Jenkins though. It won't wait till release time, it will be caught 10 min later by Jenkins. Right but that then doesnt really improve the situation (its less than 10 minutes to check locally), because if someone does commit-and-run we are still left with a broke build. I'm not concerned about this stuff tripping at all if people are looking out and fixing stuff. I do have some concerns about not running the javadocs checks, because part of the point is check everything we can automatically since it makes someone go and look at the file and perhaps then they also see some text is out of date too (not just syntax). I'm not trying to say the system is perfect or even works, only time will tell. But I do feel like it helps keep the documentation from falling out of date, especially when the stuff is fresh in the committers mind.
[jira] [Commented] (SOLR-4114) Collection API: Allow multiple shards from one collection on the same Solr server
[ https://issues.apache.org/jira/browse/SOLR-4114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13510020#comment-13510020 ] Per Steffensen commented on SOLR-4114: -- Ok, will you please consider enabling the 60 sec test (maybe reduce it to 10 or 30 sec) so that the feature is protected until someone comes up with a better/faster test. Please!!! Collection API: Allow multiple shards from one collection on the same Solr server - Key: SOLR-4114 URL: https://issues.apache.org/jira/browse/SOLR-4114 Project: Solr Issue Type: New Feature Components: multicore, SolrCloud Affects Versions: 4.0 Environment: Solr 4.0.0 release Reporter: Per Steffensen Assignee: Per Steffensen Labels: collection-api, multicore, shard, shard-allocation Attachments: SOLR-4114.patch, SOLR-4114.patch, SOLR-4114.patch, SOLR-4114.patch, SOLR-4114_trunk.patch We should support running multiple shards from one collection on the same Solr server - the run a collection with 8 shards on a 4 Solr server cluster (each Solr server running 2 shards). Performance tests at our side has shown that this is a good idea, and it is also a good idea for easy elasticity later on - it is much easier to move an entire existing shards from one Solr server to another one that just joined the cluter than it is to split an exsiting shard among the Solr that used to run it and the new Solr. See dev mailing list discussion Multiple shards for one collection on the same Solr server -- 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-4114) Collection API: Allow multiple shards from one collection on the same Solr server
[ https://issues.apache.org/jira/browse/SOLR-4114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13510038#comment-13510038 ] Mark Miller commented on SOLR-4114: --- I'm happy to commit a test for this, but lets come up with something that doesn't have a long sleep like this. I suppose a 10 second sleep is more agreeable, but these things add up and and I'd rather come up with a better test. Collection API: Allow multiple shards from one collection on the same Solr server - Key: SOLR-4114 URL: https://issues.apache.org/jira/browse/SOLR-4114 Project: Solr Issue Type: New Feature Components: multicore, SolrCloud Affects Versions: 4.0 Environment: Solr 4.0.0 release Reporter: Per Steffensen Assignee: Per Steffensen Labels: collection-api, multicore, shard, shard-allocation Attachments: SOLR-4114.patch, SOLR-4114.patch, SOLR-4114.patch, SOLR-4114.patch, SOLR-4114_trunk.patch We should support running multiple shards from one collection on the same Solr server - the run a collection with 8 shards on a 4 Solr server cluster (each Solr server running 2 shards). Performance tests at our side has shown that this is a good idea, and it is also a good idea for easy elasticity later on - it is much easier to move an entire existing shards from one Solr server to another one that just joined the cluter than it is to split an exsiting shard among the Solr that used to run it and the new Solr. See dev mailing list discussion Multiple shards for one collection on the same Solr server -- 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] (LUCENE-4419) Test RecursivePrefixTree indexing non-point data
[ https://issues.apache.org/jira/browse/LUCENE-4419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley updated LUCENE-4419: - Attachment: LUCENE-4419_Test_indexing_non-point_shapes.patch The attached test SpatialOpRecursivePrefixTreeTest tests the RecursivePrefixTree extensively. It yielded the bugs in LUCENE-4585. It uses the QuadPrefixTree with random levels and random scan threshold for RecursivePrefixTreeFilter. Some randomly generated rectangles are asserted as a MUST match, and some are optional depending on the grid approximation. QuadPrefixTree was chosen because it supports non-geo, and this test has some simplistic logic in going from shape - grid-snapped shape that would be more complicated in geospatial that ultimately RecursivePrefixTree doesn't care about any way -- it's Spatial4j + GeohashPrefixTree that deal with that. This test added an evaluate() method to SpatialOperation which I found quite handy. With this in place and this test as a template, it should be easy to test for operations other than intersect once they are supported. Test RecursivePrefixTree indexing non-point data Key: LUCENE-4419 URL: https://issues.apache.org/jira/browse/LUCENE-4419 Project: Lucene - Core Issue Type: Improvement Components: modules/spatial Reporter: David Smiley Assignee: David Smiley Attachments: LUCENE-4419_Test_indexing_non-point_shapes.patch RecursivePrefixTreeFilter was modified in ~July 2011 to support spatial filtering of non-point indexed shapes. It seems to work when playing with the capability but it isn't tested. It really needs to be as this is a major feature. I imagine an approach in which some randomly generated rectangles are indexed and then a randomly generated rectangle is queried. The right answer can be calculated brute-force and then compared with the filter. In order to deal with shape imprecision, the randomly generated shapes could be generated to fit a course grid (e.g. round everything to a 1 degree interval). -- 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
Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_09) - Build # 3026 - Failure!
I guess my point is that since no one runs it (except perhaps you), it's not really helping anything. And the broken build is really more minor than a true broken build if tests at least still pass. Personally, I'm pretty okay with a nocommit failing the build for 30 minutes if the tests still pass. Most of these issues are basic enough that anyone can jump in and fix it if it's causing them issues as well. Just remove the tabs, fix the javadoc, etc. - Mark On Dec 4, 2012, at 12:56 PM, Robert Muir rcm...@gmail.com wrote: On Tue, Dec 4, 2012 at 3:33 PM, Mark Miller markrmil...@gmail.com wrote: We are not talking about weakening them on Jenkins though. It won't wait till release time, it will be caught 10 min later by Jenkins. Right but that then doesnt really improve the situation (its less than 10 minutes to check locally), because if someone does commit-and-run we are still left with a broke build. I'm not concerned about this stuff tripping at all if people are looking out and fixing stuff. I do have some concerns about not running the javadocs checks, because part of the point is check everything we can automatically since it makes someone go and look at the file and perhaps then they also see some text is out of date too (not just syntax). I'm not trying to say the system is perfect or even works, only time will tell. But I do feel like it helps keep the documentation from falling out of date, especially when the stuff is fresh in the committers mind. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4419) Test RecursivePrefixTree indexing non-point data
[ https://issues.apache.org/jira/browse/LUCENE-4419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13510077#comment-13510077 ] David Smiley commented on LUCENE-4419: -- Whoops; there's a stupid if (i != 5) continue; on line ~68 which I should have labelled with a NOCOMMIT that's in the patch. Test RecursivePrefixTree indexing non-point data Key: LUCENE-4419 URL: https://issues.apache.org/jira/browse/LUCENE-4419 Project: Lucene - Core Issue Type: Improvement Components: modules/spatial Reporter: David Smiley Assignee: David Smiley Attachments: LUCENE-4419_Test_indexing_non-point_shapes.patch RecursivePrefixTreeFilter was modified in ~July 2011 to support spatial filtering of non-point indexed shapes. It seems to work when playing with the capability but it isn't tested. It really needs to be as this is a major feature. I imagine an approach in which some randomly generated rectangles are indexed and then a randomly generated rectangle is queried. The right answer can be calculated brute-force and then compared with the filter. In order to deal with shape imprecision, the randomly generated shapes could be generated to fit a course grid (e.g. round everything to a 1 degree interval). -- 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-4145) Getting a NPE when the result set is null
Amandeep Saini created SOLR-4145: Summary: Getting a NPE when the result set is null Key: SOLR-4145 URL: https://issues.apache.org/jira/browse/SOLR-4145 Project: Solr Issue Type: Bug Affects Versions: 4.0 Reporter: Amandeep Saini Re: org.apache.solr.handler.dataimport.JdbcDataSource In line 250, resultSet.getMetaData() is called. However, if the resultSet is null, a NPE is thrown. In line 254, the null check is done (if (resultSet == null)) The contents of line 250 should occur after the null check. I am getting the NPE after trying to delete some data in my DB using the DIH. The DIH is probably not meant for that but it would benefit me if it worked and I don't see a big change in the code in order to do it. -- 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-4144) SolrCloud replication high heap consumption
[
https://issues.apache.org/jira/browse/SOLR-4144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13510105#comment-13510105
]
Mark Miller commented on SOLR-4144:
---
Thanks for the report! I will try and investigate this soon - I'm on an 11 inch
low powered macbook air for the week, so I may not get to it till next week,
but we will see...
SolrCloud replication high heap consumption
---
Key: SOLR-4144
URL: https://issues.apache.org/jira/browse/SOLR-4144
Project: Solr
Issue Type: Bug
Components: replication (java), SolrCloud
Affects Versions: 5.0
Environment: 5.0-SNAPSHOT 1366361:1416494M - markus - 2012-12-03
14:09:13
Reporter: Markus Jelsma
Priority: Critical
Fix For: 5.0
Recent versions of SolrCloud require a very high heap size vs. older
versions. Another cluster of 5.0.0.2012.10.09.19.29.59 (~4GB per core) can
restore an empty node without taking a lot of heap (xmx=256m). Recent
versions and current trunk fail miserably even with a higher heap (750m).
Both clusters have 10 nodes, 10 shards and 2 cores per node. One note to add
is that the cluster on which this fails has only about 1.5GB per core due to
changing in the Lucene codec such as compression.
After start up everything goes fine...
{code}
2012-12-04 15:05:35,013 INFO [solr.cloud.RecoveryStrategy] - [RecoveryThread]
- : Begin buffering updates. core=shard_c
2012-12-04 15:05:35,013 INFO [solr.cloud.RecoveryStrategy] - [RecoveryThread]
- : Begin buffering updates. core=shard_b
2012-12-04 15:05:35,013 INFO [solr.update.UpdateLog] - [RecoveryThread] - :
Starting to buffer updates. FSUpdateLog{state=ACTIVE, tlog=null}
2012-12-04 15:05:35,013 INFO [solr.update.UpdateLog] - [RecoveryThread] - :
Starting to buffer updates. FSUpdateLog{state=ACTIVE, tlog=null}
2012-12-04 15:05:35,013 INFO [solr.cloud.RecoveryStrategy] - [RecoveryThread]
- : Attempting to replicate from http://178.21.118.190:8080/solr/shard_b/.
core=shard_b
2012-12-04 15:05:35,013 INFO [solr.cloud.RecoveryStrategy] - [RecoveryThread]
- : Attempting to replicate from http://178.21.118.192:8080/solr/shard_c/.
core=shard_c
2012-12-04 15:05:35,014 INFO [solrj.impl.HttpClientUtil] - [RecoveryThread] -
: Creating new http client,
config:maxConnections=128maxConnectionsPerHost=32followRedirects=false
2012-12-04 15:05:35,014 INFO [solrj.impl.HttpClientUtil] - [RecoveryThread] -
: Creating new http client,
config:maxConnections=128maxConnectionsPerHost=32followRedirects=false
2012-12-04 15:05:35,052 INFO [solr.handler.ReplicationHandler] -
[RecoveryThread] - : Commits will be reserved for 1
2012-12-04 15:05:35,052 INFO [solr.handler.ReplicationHandler] -
[RecoveryThread] - : Commits will be reserved for 1
2012-12-04 15:05:35,053 INFO [solrj.impl.HttpClientUtil] - [RecoveryThread] -
: Creating new http client,
config:connTimeout=5000socketTimeout=2allowCompression=falsemaxConnections=1maxConnectionsPerHost=1
2012-12-04 15:05:35,060 INFO [solr.handler.SnapPuller] - [RecoveryThread] - :
No value set for 'pollInterval'. Timer Task not started.
2012-12-04 15:05:35,060 INFO [solr.handler.SnapPuller] - [RecoveryThread] - :
No value set for 'pollInterval'. Timer Task not started.
2012-12-04 15:05:35,069 INFO [solr.handler.SnapPuller] - [RecoveryThread] - :
Master's generation: 48
2012-12-04 15:05:35,069 INFO [solr.handler.SnapPuller] - [RecoveryThread] - :
Slave's generation: 1
2012-12-04 15:05:35,069 INFO [solr.handler.SnapPuller] - [RecoveryThread] - :
Starting replication process
2012-12-04 15:05:35,069 INFO [solr.handler.SnapPuller] - [RecoveryThread] - :
Master's generation: 47
2012-12-04 15:05:35,069 INFO [solr.handler.SnapPuller] - [RecoveryThread] - :
Slave's generation: 1
2012-12-04 15:05:35,070 INFO [solr.handler.SnapPuller] - [RecoveryThread] - :
Starting replication process
2012-12-04 15:05:35,078 INFO [solr.handler.SnapPuller] - [RecoveryThread] - :
Number of files in latest index in master: 235
2012-12-04 15:05:35,079 INFO [solr.handler.SnapPuller] - [RecoveryThread] - :
Number of files in latest index in master: 287
2012-12-04 15:05:35,084 WARN [solr.core.CachingDirectoryFactory] -
[RecoveryThread] - : No lockType configured for
NRTCachingDirectory(org.apache.lucene.store.MMapDirectory@/opt/solr/cores/shard_c/data/index.20121204150535080
lockFactory=org.apache.lucene.store.NativeFSLockFactory@57530551;
maxCacheMB=48.0 maxMergeSizeMB=4.0) assuming 'simple'
2012-12-04 15:05:35,085 INFO [solr.core.CachingDirectoryFactory] -
[RecoveryThread] - : return new directory for
/opt/solr/cores/shard_c/data/index.20121204150535080 forceNew:false
2012-12-04 15:05:35,085 INFO [solr.core.CachingDirectoryFactory] -
[jira] [Resolved] (SOLR-3987) Provide Collection API request results beyond manual inspection.
[ https://issues.apache.org/jira/browse/SOLR-3987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-3987. --- Resolution: Duplicate Assignee: Mark Miller I'm closing this as a dupe of SOLR-4043 since this one has a patch. Provide Collection API request results beyond manual inspection. Key: SOLR-3987 URL: https://issues.apache.org/jira/browse/SOLR-3987 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Mark Miller Assignee: Mark Miller Fix For: 4.1, 5.0 -- 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-4043) Add ability to get success/failure responses from Collections API.
[ https://issues.apache.org/jira/browse/SOLR-4043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13510114#comment-13510114 ] Mark Miller commented on SOLR-4043: --- Thanks a lot for this patch Raintung! I'm going to try and get it up to date with trunk shortly. Add ability to get success/failure responses from Collections API. -- Key: SOLR-4043 URL: https://issues.apache.org/jira/browse/SOLR-4043 Project: Solr Issue Type: Improvement Components: SolrCloud Affects Versions: 4.0-ALPHA, 4.0-BETA, 4.0 Environment: Solr cloud cluster Reporter: Raintung Li Assignee: Mark Miller Fix For: 4.1, 5.0 Attachments: patch-4043.txt The create/delete/reload collections are asynchronous process, the client can't get the right response, only make sure the information have been saved into the OverseerCollectionQueue. The client will get the response directly that don't wait the result of behavior(create/delete/reload collection) whatever successful. The easy solution is client wait until the asynchronous process success, the create/delete/reload collection thread will save the response into OverseerCollectionQueue, then notify client to get the response. -- 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-4138) currency field isn't compatible with frange query
[
https://issues.apache.org/jira/browse/SOLR-4138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-4138:
---
Attachment: SOLR-4138.patch
Thanks for reporting this Grzegorz,
The general problem seems to be that while CurrencyField has a
CurrencyValueSource that it uses for range queries and sorting, it doesn't
override FieldType.getValueSource() to return one of these in cases when people
use currency fields in functions.
Even with this simple addition however, your test as written still doesn't
pass, because CurrencyValueSource operates using the internal long values of
the currency, based on Currency.getDefaultFractionDigits() for the default
currency .. so if USD is the configured default, you get a value of 500.0
(cents) from the value source instead of 5.0 when a document is indexed with
a value of 5,USD.
I've attached a patch with the trivial getVaueSource() and tests showing the
_current_ behavior, but i'm not entirely certain if this is really the behavior
we want ... changing it would probably require some meaty rewrites to
CurrencyValueSource to take in options about whether the
getDefaultFractionDigits() logic should be undone to produce the more human
friendly values ... or perhaps just wrapping it in a special ValueSource that
applies that logic in the getValueSource case so existing usages in
getRangeQuery would be unaffected.
currency field isn't compatible with frange query
-
Key: SOLR-4138
URL: https://issues.apache.org/jira/browse/SOLR-4138
Project: Solr
Issue Type: Bug
Components: search
Affects Versions: 4.0
Reporter: Grzegorz Sobczyk
Attachments: SOLR-4135-test.patch, SOLR-4138.patch
Filtering using {!frange} syntax isn't work properly. (rather at all)
--
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-4138) currency field doesn't work with functions (ie: isn't compatible with frange query)
[
https://issues.apache.org/jira/browse/SOLR-4138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-4138:
---
Description:
In general, using CurrencyField with FunctionQueries doesn't work
In particular, as originally reported...
Filtering using {!frange} syntax isn't work properly. (rather at all)
was:Filtering using {!frange} syntax isn't work properly. (rather at all)
Summary: currency field doesn't work with functions (ie: isn't
compatible with frange query) (was: currency field isn't compatible with
frange query)
enhancing summary description to reflect broader scope of issue
currency field doesn't work with functions (ie: isn't compatible with frange
query)
---
Key: SOLR-4138
URL: https://issues.apache.org/jira/browse/SOLR-4138
Project: Solr
Issue Type: Bug
Components: search
Affects Versions: 4.0
Reporter: Grzegorz Sobczyk
Attachments: SOLR-4135-test.patch, SOLR-4138.patch
In general, using CurrencyField with FunctionQueries doesn't work
In particular, as originally reported...
Filtering using {!frange} syntax isn't work properly. (rather at all)
--
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-3428) SolrCmdDistributor flushAdds/flushDeletes problems
[ https://issues.apache.org/jira/browse/SOLR-3428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13510132#comment-13510132 ] Mark Miller commented on SOLR-3428: --- This can likely be closed - at some point I fixed 1 and 2 (adding Per to the CHANGES entries) and added targeted tests for them and I'm not yet convinced that 3 is a problem (which doesn't guarantee it's not - but I have not found a situation where it is a problem). SolrCmdDistributor flushAdds/flushDeletes problems -- Key: SOLR-3428 URL: https://issues.apache.org/jira/browse/SOLR-3428 Project: Solr Issue Type: Bug Components: replication (java), SolrCloud, update Affects Versions: 4.0-ALPHA Reporter: Per Steffensen Assignee: Per Steffensen Labels: add, delete, replica, solrcloud, update Fix For: 4.1 Original Estimate: 24h Remaining Estimate: 24h A few problems with SolrCmdDistributor.flushAdds/flushDeletes * If number of AddRequests/DeleteRequests in alist/dlist is below limit for a specific node the method returns immediately and doesnt flush for subsequent nodes * When returning immediately because there is below limit requests for a given node, then previous nodes that have already been flushed/submitted are not removed from adds/deletes maps (causing them to be flushed/submitted again the next time flushAdds/flushDeletes is executed) * The idea about just combining params does not work for SEEN_LEADER params (and probably others as well). Since SEEN_LEADER cannot be expressed (unlike commitWithin and overwrite) for individual operations in the request, you need to sent two separate submits. One containing requests with SEEN_LEADER=true and one with SEEN_LEADER=false. -- 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-4043) Add ability to get success/failure responses from Collections API.
[ https://issues.apache.org/jira/browse/SOLR-4043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13510136#comment-13510136 ] Mark Miller commented on SOLR-4043: --- Raintung, is this patch against 4.0 rather than 4x or 5x on Nov 7? Add ability to get success/failure responses from Collections API. -- Key: SOLR-4043 URL: https://issues.apache.org/jira/browse/SOLR-4043 Project: Solr Issue Type: Improvement Components: SolrCloud Affects Versions: 4.0-ALPHA, 4.0-BETA, 4.0 Environment: Solr cloud cluster Reporter: Raintung Li Assignee: Mark Miller Fix For: 4.1, 5.0 Attachments: patch-4043.txt The create/delete/reload collections are asynchronous process, the client can't get the right response, only make sure the information have been saved into the OverseerCollectionQueue. The client will get the response directly that don't wait the result of behavior(create/delete/reload collection) whatever successful. The easy solution is client wait until the asynchronous process success, the create/delete/reload collection thread will save the response into OverseerCollectionQueue, then notify client to get the response. -- 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-3239) Function for returning a CurrencyField as a virtual field
[
https://issues.apache.org/jira/browse/SOLR-3239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13510157#comment-13510157
]
Hoss Man commented on SOLR-3239:
bq. A special case would be that you want only formatting, not conversion.
I'm not sure if that's a good idea ... it's tempting to look at your examples
and think it should be the original currency, but what about when it's wrapped
in another function?
This comes up because of some of the questions in SOLR-4138 -- I think it would
make a lot of sense if currency(price_c) returned the human value of the
price_c field in the default currency, (ie: 5.5 if the indexed value is
equivalent to 5.5,USD) regardless of which currency was used when the doc was
indexed. That way you could do things like
sum(currency(price_field),prod($ship_cost,weight_field)) and get comparable
values across all documents regardless of the currency used in each document.
it might make more sense to have a currency(...) function that explicitly
deals with the conversion of different currencies, and then have an independent
\[currencyft\] DocTransformer for dealing with the locale based formatting of
currency. We'd get the currency conversion as input to other functions
benefit i described above independently from the need to format; and you could
have the format currencies in locale benefit independently of whether someone
actually used CurrencyField
not to mention then you cold wrap the formating around some complex function
that involved the currency values...
{code}
?q=foo
// uses default currency for consistency of value comparisons
total_price=sum(currency(price_field),prod($ship_cost,weight_field))
sort=$total_price+asc
// fmt overrides default currency to be users currency
fl=id,[currencyfmt v=$total_price currency=GBP locale=en_us]
{code}
Function for returning a CurrencyField as a virtual field
-
Key: SOLR-3239
URL: https://issues.apache.org/jira/browse/SOLR-3239
Project: Solr
Issue Type: New Feature
Reporter: Jan Høydahl
Fix For: 4.1
With the new CurrencyField from SOLR-2202, we can now do range queries, sort
and soon faceting on CurrencyField.
One thing we cannot do is return a converted value. We can only return the
stored value which must be in the same currency as it was entered, e.g.
10.0,USD. People now have to do this conversion in application layer,
reading the same currency.xml file as in Solr. This is a mess to keep in
sync, and is hard to support with other ExchangeRateProviders or in other
client languages than Java.
This patch should implement a Function which takes a field name and requested
currency as input and returns the converted value. Optionally it could also
take care of localized display, e.g. $10.0 instead of 10.0,USD. Proposed
syntax:
{code}
fl=title,price:currency(price_c,EUR) # Returns price_c in EUR as
price
fl=title,price:currency(price_c,EUR,en_US) # Returns price_c in EUR,
formatted according to en_US locale
{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
Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_09) - Build # 3026 - Failure!
I'm running it. It takes just over 4 minutes for me. Pretty minor IMHO. On Dec 4, 2012, at 5:26 PM, Mark Miller markrmil...@gmail.com wrote: I guess my point is that since no one runs it (except perhaps you), it's not really helping anything. And the broken build is really more minor than a true broken build if tests at least still pass. Personally, I'm pretty okay with a nocommit failing the build for 30 minutes if the tests still pass. Most of these issues are basic enough that anyone can jump in and fix it if it's causing them issues as well. Just remove the tabs, fix the javadoc, etc. - Mark On Dec 4, 2012, at 12:56 PM, Robert Muir rcm...@gmail.com wrote: On Tue, Dec 4, 2012 at 3:33 PM, Mark Miller markrmil...@gmail.com wrote: We are not talking about weakening them on Jenkins though. It won't wait till release time, it will be caught 10 min later by Jenkins. Right but that then doesnt really improve the situation (its less than 10 minutes to check locally), because if someone does commit-and-run we are still left with a broke build. I'm not concerned about this stuff tripping at all if people are looking out and fixing stuff. I do have some concerns about not running the javadocs checks, because part of the point is check everything we can automatically since it makes someone go and look at the file and perhaps then they also see some text is out of date too (not just syntax). I'm not trying to say the system is perfect or even works, only time will tell. But I do feel like it helps keep the documentation from falling out of date, especially when the stuff is fresh in the committers mind. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_09) - Build # 3026 - Failure!
On Dec 4, 2012, at 4:18 PM, Steve Rowe sar...@gmail.com wrote: I'm running it. It takes just over 4 minutes for me. Pretty minor IMHO. I suppose if you have long tests anyway - typically my solr tests run takes 3:30 to 4 minutes, so doubling my time is not really something I'm ready to swallow. - Mark - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3575) solr.xml should default to persist=true
[ https://issues.apache.org/jira/browse/SOLR-3575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13510183#comment-13510183 ] Mark Miller commented on SOLR-3575: --- We would still support loading and unloading. bq. Also, what would happen if a core was unloaded? The simple properties file or whatever in each core folder would indicate the core was not 'loaded'. Or one of many other solutions. solr.xml should default to persist=true --- Key: SOLR-3575 URL: https://issues.apache.org/jira/browse/SOLR-3575 Project: Solr Issue Type: Improvement Reporter: Mark Miller Assignee: Mark Miller Fix For: 4.0-BETA, 5.0 The default of false is kind of silly IMO. -- 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
Re: Solrj question
: Believe there are no setParser method on CloudSolrServer? I'm not sure why CloudSolrServer doesn't let you specify the parser ... i would suggest filing a feature request to make that possible. Even assuming you have that, Erick's suggestion isn't quite what you want... : haven't tried this personally, but try this: : server.setParser(new XMLResponseParser()); ...because that tells the SolrServer instance to use the XMLResponseParser to parse the data into a QueryResponse. What you want is essentially to write your own ResponesParser that doesn't do any parsing, and just returns a pointer to the the InputStream it's given. Assuming you have that, it may not matter that CloudSolrServer doesn't let you specify a default RequestParser, you *should* be able to just call SolrRequest.setResponseParser() to force your specific parser to be used (but i haven't sanity checked that works with CloudSolrServer) -Hoss - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4043) Add ability to get success/failure responses from Collections API.
[ https://issues.apache.org/jira/browse/SOLR-4043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13510206#comment-13510206 ] Raintung Li commented on SOLR-4043: --- Mark, this patch is base on 4.0 Add ability to get success/failure responses from Collections API. -- Key: SOLR-4043 URL: https://issues.apache.org/jira/browse/SOLR-4043 Project: Solr Issue Type: Improvement Components: SolrCloud Affects Versions: 4.0-ALPHA, 4.0-BETA, 4.0 Environment: Solr cloud cluster Reporter: Raintung Li Assignee: Mark Miller Fix For: 4.1, 5.0 Attachments: patch-4043.txt The create/delete/reload collections are asynchronous process, the client can't get the right response, only make sure the information have been saved into the OverseerCollectionQueue. The client will get the response directly that don't wait the result of behavior(create/delete/reload collection) whatever successful. The easy solution is client wait until the asynchronous process success, the create/delete/reload collection thread will save the response into OverseerCollectionQueue, then notify client to get the response. -- 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-1581) Facet by Function
[ https://issues.apache.org/jira/browse/SOLR-1581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13510230#comment-13510230 ] Ted Strauss commented on SOLR-1581: --- I'd like to offer to co-sponsor work on this issue if anyone here knows where to go with it. This relates to my issue https://issues.apache.org/jira/browse/SOLR-3742 Thanks Facet by Function - Key: SOLR-1581 URL: https://issues.apache.org/jira/browse/SOLR-1581 Project: Solr Issue Type: New Feature Reporter: Grant Ingersoll Fix For: 4.1 Attachments: SOLR-1581.patch It would be really great if we could execute a function and quantize it into buckets that could then be returned as facets. -- 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
[JENKINS] Lucene-Solr-4.x-Windows (32bit/jdk1.7.0_09) - Build # 2050 - Failure!
Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-4.x-Windows/2050/ Java: 32bit/jdk1.7.0_09 -server -XX:+UseG1GC All tests passed Build Log: [...truncated 28804 lines...] BUILD FAILED C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\build.xml:60: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\solr\build.xml:499: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\lucene\common-build.xml:1961: Can't get https://issues.apache.org/jira/rest/api/2/project/SOLR to C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\solr\build\docs\changes\jiraVersionList.json Total time: 58 minutes 55 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Recording test results Description set: Java: 32bit/jdk1.7.0_09 -server -XX:+UseG1GC Email was triggered for: Failure Sending email for trigger: Failure - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
