[jira] [Updated] (SOLR-4586) Increase default maxBooleanClauses
[ https://issues.apache.org/jira/browse/SOLR-4586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shawn Heisey updated SOLR-4586: --- Attachment: SOLR-4586.patch I located the heliosearch commit that eliminated the clause limit. The work I had started was fairly similar, so I kept my work but pulled the static code block and the additional test from HS. Indirectly this will also fix SOLR-6695. I set the log message about the deprecated parameter at info ... should that be moved to warn? Increase default maxBooleanClauses -- Key: SOLR-4586 URL: https://issues.apache.org/jira/browse/SOLR-4586 Project: Solr Issue Type: Improvement Affects Versions: 4.2 Environment: 4.3-SNAPSHOT 1456767M - ncindex - 2013-03-15 13:11:50 Reporter: Shawn Heisey Attachments: SOLR-4586.patch, SOLR-4586.patch, SOLR-4586.patch, SOLR-4586.patch, SOLR-4586.patch, SOLR-4586.patch, SOLR-4586_verify_maxClauses.patch In the #solr IRC channel, I mentioned the maxBooleanClauses limitation to someone asking a question about queries. Mark Miller told me that maxBooleanClauses no longer applies, that the limitation was removed from Lucene sometime in the 3.x series. The config still shows up in the example even in the just-released 4.2. Checking through the source code, I found that the config option is parsed and the value stored in objects, but does not actually seem to be used by anything. I removed every trace of it that I could find, and all tests still pass. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4586) Increase default maxBooleanClauses
[ https://issues.apache.org/jira/browse/SOLR-4586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14197896#comment-14197896 ] Shawn Heisey commented on SOLR-4586: If this looks acceptable, my plan is to commit to 5x, then merge to trunk and remove the config parsing and deprecation log message. Increase default maxBooleanClauses -- Key: SOLR-4586 URL: https://issues.apache.org/jira/browse/SOLR-4586 Project: Solr Issue Type: Improvement Affects Versions: 4.2 Environment: 4.3-SNAPSHOT 1456767M - ncindex - 2013-03-15 13:11:50 Reporter: Shawn Heisey Attachments: SOLR-4586.patch, SOLR-4586.patch, SOLR-4586.patch, SOLR-4586.patch, SOLR-4586.patch, SOLR-4586.patch, SOLR-4586_verify_maxClauses.patch In the #solr IRC channel, I mentioned the maxBooleanClauses limitation to someone asking a question about queries. Mark Miller told me that maxBooleanClauses no longer applies, that the limitation was removed from Lucene sometime in the 3.x series. The config still shows up in the example even in the just-released 4.2. Checking through the source code, I found that the config option is parsed and the value stored in objects, but does not actually seem to be used by anything. I removed every trace of it that I could find, and all tests still pass. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-NightlyTests-trunk - Build # 635 - Still Failing
I committed a fix to the test - it was just wrong and tested the wrong thing. Shai On Tue, Sep 30, 2014 at 5:32 PM, Shai Erera ser...@gmail.com wrote: I've tried to change the test to assert better that the facet counts are sampled OK. E.g. the test currently computes a STDDEV, but that's wrong since we have only 5 categories that are sampled, and so it's not a real normal distribution, and every difference from the mean results in a very high STDDEV... So I tried Pearson's Chi-Squared test ( http://en.wikipedia.org/wiki/Pearson%27s_chi-squared_test), which works better on more runs, but still fails from time to time. At that point I started thinking what exactly are we testing -- we have a Random sampler which samples DOCUMENTS not CATEGORIES. So e.g. if I index documents w/ categories in that order: A B C D A B C D A B C D and so forth, and I sample every 4th DOCUMENT, I could very well count only category D, while A, B and C might see none to very low counts, resulting in big STDDEV, or Chi-Square result. The sampler has no knowledge of the indexed categories, only the indexed documents. And you could easily write an adversary indexer which indexes categories such that the random sampler almost never samples some categories. Instead I think we should assert that the sampler sampled roughly e.g. 10% of the docs, irrespective of the counts of the categories. What do you think? On Tue, Sep 23, 2014 at 9:47 PM, Shai Erera ser...@gmail.com wrote: This is a test bug, but I'm not yet sure how to fix it. The test verifies the sampling works OK by computing some statistics about the counted facets. In particular it computes the standard deviation and ensures that it's smaller than some arbitrary value (200). However, with this seed and test parameters, the standard deviation is 215, and I've verified that with any seed, if you fix the number of indexed documents to a high enough number (50,000), it will likely be bigger than 200. What I'm not sure about is how to fix the test -- increasing the number from 200 to 300 will only push the limit further until another failure, because of other test parameters. I can do that, and investigate again if another run fails. But increasing that number too high misses the point I think, since if our random sampling isn't really random, we'll fail to detect that. Basically, with some very bad luck, we could sample such that we hit the maximum value of the variance, and therefore no matter the value we'll compare the standard deviation to, we might run into this extremely bad-luck-case at some point. One choice is to increase the value now, and accept that some runs may fail, once in a long while ... Do we have other tests that do random sampling of stuff and assert the sampled values? Shai On Mon, Sep 22, 2014 at 10:19 PM, Apache Jenkins Server jenk...@builds.apache.org wrote: Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-trunk/635/ 1 tests failed. REGRESSION: org.apache.lucene.facet.TestRandomSamplingFacetsCollector.testRandomSampling Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([EB7A704156A4175F:162195CE7F3E0E8]:0) at org.junit.Assert.fail(Assert.java:92) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertTrue(Assert.java:54) at org.apache.lucene.facet.TestRandomSamplingFacetsCollector.testRandomSampling(TestRandomSamplingFacetsCollector.java:136) 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:606) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at
[jira] [Closed] (LUCENE-5526) Forced merges
[
https://issues.apache.org/jira/browse/LUCENE-5526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adrien Grand closed LUCENE-5526.
Resolution: Not a Problem
Agreed, I guess this is not needed anymore since the merge policy can be
changed on a live index.
Forced merges
-
Key: LUCENE-5526
URL: https://issues.apache.org/jira/browse/LUCENE-5526
Project: Lucene - Core
Issue Type: Improvement
Reporter: Adrien Grand
Priority: Minor
{{IndexWriter.forceMerge}} allows to force merges if the number of segments
is higher than a configured limit. I would like to have the ability to also
force a merge if there is a single segment in the directory. This is possible
today by closing the IndexWriter, reopening with a custom merge policy such
as {{UpgradeIndexMergePolicy}}, running a {{forceMerge}} and finally
reopening again with the original merge policy but this is a bit impractical
and if possible I would like to be able to do it without reopening the writer
twice.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6038) FieldValueFilter regression
[ https://issues.apache.org/jira/browse/LUCENE-6038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14197942#comment-14197942 ] ASF subversion and git services commented on LUCENE-6038: - Commit 1636827 from [~jpountz] in branch 'dev/trunk' [ https://svn.apache.org/r1636827 ] LUCENE-6038: Re-enable FieldValueFilter optimizations based on the way the docsWithField bits are implemented. FieldValueFilter regression --- Key: LUCENE-6038 URL: https://issues.apache.org/jira/browse/LUCENE-6038 Project: Lucene - Core Issue Type: Bug Reporter: Adrien Grand Assignee: Adrien Grand Priority: Minor Fix For: 5.0 Attachments: LUCENE-6038.patch, LUCENE-6038.patch The decoupling of FixedBitSet from a DocIdSet (LUCENE-5441) introduced a regression in FieldValueFilter, which checks if the bits for documents with a field is an instance of a DocIdSet. Yet FixedBitSet does not extend DocIdSet anymore. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-6038) FieldValueFilter regression
[ https://issues.apache.org/jira/browse/LUCENE-6038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrien Grand resolved LUCENE-6038. -- Resolution: Fixed Fix Version/s: 5.0 FieldValueFilter regression --- Key: LUCENE-6038 URL: https://issues.apache.org/jira/browse/LUCENE-6038 Project: Lucene - Core Issue Type: Bug Reporter: Adrien Grand Assignee: Adrien Grand Priority: Minor Fix For: 5.0 Attachments: LUCENE-6038.patch, LUCENE-6038.patch The decoupling of FixedBitSet from a DocIdSet (LUCENE-5441) introduced a regression in FieldValueFilter, which checks if the bits for documents with a field is an instance of a DocIdSet. Yet FixedBitSet does not extend DocIdSet anymore. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6038) FieldValueFilter regression
[ https://issues.apache.org/jira/browse/LUCENE-6038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14197946#comment-14197946 ] ASF subversion and git services commented on LUCENE-6038: - Commit 1636828 from [~jpountz] in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1636828 ] LUCENE-6038: Re-enable FieldValueFilter optimizations based on the way the docsWithField bits are implemented. FieldValueFilter regression --- Key: LUCENE-6038 URL: https://issues.apache.org/jira/browse/LUCENE-6038 Project: Lucene - Core Issue Type: Bug Reporter: Adrien Grand Assignee: Adrien Grand Priority: Minor Fix For: 5.0 Attachments: LUCENE-6038.patch, LUCENE-6038.patch The decoupling of FixedBitSet from a DocIdSet (LUCENE-5441) introduced a regression in FieldValueFilter, which checks if the bits for documents with a field is an instance of a DocIdSet. Yet FixedBitSet does not extend DocIdSet anymore. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6693) Start script for windows fails with 32bit JRE
[
https://issues.apache.org/jira/browse/SOLR-6693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14197967#comment-14197967
]
Daniel Collins commented on SOLR-6693:
--
Yeah, I was half-joking and half-serious when I suggested JVM re-install.
Windows JVM installs always seem somewhat prone to needing a re-install from
time to time, The {{C:\Windows\System32\java.exe}} always seems to favour the
last JVM you installed as well, so if you have (for example) a Java 7 and
Java 8 JVM installed, and then you update your Java 7 JVM, that becomes the new
default. You have to re-update Java 8 to update that magic version of
{{java.exe}}.
It always makes me glad to get back to Linux every time I have to use Windows,
at least there applications get installed into directories, if they are on your
path (or I explicitly run them), they get used, if they aren't, they don't. It
makes so much more sense that way :-)
Start script for windows fails with 32bit JRE
-
Key: SOLR-6693
URL: https://issues.apache.org/jira/browse/SOLR-6693
Project: Solr
Issue Type: Bug
Components: scripts and tools
Affects Versions: 4.10.2
Environment: WINDOWS 8.1
Reporter: Jan Høydahl
Labels: bin\solr.cmd
Fix For: 5.0, Trunk
*Reproduce:*
# Install JRE8 from www.java.com (typically {{C:\Program Files
(x86)\Java\jre1.8.0_25}})
# Run the command {{bin\solr start -V}}
The result is:
{{\Java\jre1.8.0_25\bin\java was unexpected at this time.}}
*Reason*
This comes from bad quoting of the {{%SOLR%}} variable. I think it's because
of the parenthesis that it freaks out. I think the same would apply for a
32-bit JDK because of the (x86) in the path, but I have not tested.
Tip: You can remove the line {{@ECHO OFF}} at the top to see exactly which is
the offending line
*Solution*
Quoting the lines where %JAVA% is printed, e.g. instead of
{noformat}
@echo Using Java: %JAVA%
{noformat}
then use
{noformat}
@echo Using Java: %JAVA%
{noformat}
This is needed several places.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
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.8.0_20) - Build # 11569 - Still Failing!
Woops, I'll fix. Mike McCandless http://blog.mikemccandless.com On Wed, Nov 5, 2014 at 1:11 AM, Policeman Jenkins Server jenk...@thetaphi.de wrote: Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/11569/ Java: 32bit/jdk1.8.0_20 -server -XX:+UseParallelGC (asserts: false) 1 tests failed. REGRESSION: org.apache.lucene.util.automaton.TestAutomaton.testRandomFinite Error Message: Determinizing automaton would result in more than 1 states. Stack Trace: org.apache.lucene.util.automaton.TooComplexToDeterminizeException: Determinizing automaton would result in more than 1 states. at __randomizedtesting.SeedInfo.seed([F610068DB20613FB:B1A660B00D9676DA]:0) at org.apache.lucene.util.automaton.Operations.determinize(Operations.java:739) at org.apache.lucene.util.automaton.TestAutomaton.randomNoOp(TestAutomaton.java:600) at org.apache.lucene.util.automaton.TestAutomaton.unionTerms(TestAutomaton.java:665) at org.apache.lucene.util.automaton.TestAutomaton.assertSame(TestAutomaton.java:1080) at org.apache.lucene.util.automaton.TestAutomaton.testRandomFinite(TestAutomaton.java:1033) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) 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:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) 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 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at
[jira] [Commented] (LUCENE-6046) RegExp.toAutomaton high memory use
[
https://issues.apache.org/jira/browse/LUCENE-6046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14197970#comment-14197970
]
ASF subversion and git services commented on LUCENE-6046:
-
Commit 1636830 from [~mikemccand] in branch 'dev/trunk'
[ https://svn.apache.org/r1636830 ]
LUCENE-6046: let this test determinize massive automata
RegExp.toAutomaton high memory use
--
Key: LUCENE-6046
URL: https://issues.apache.org/jira/browse/LUCENE-6046
Project: Lucene - Core
Issue Type: Bug
Components: core/queryparser
Affects Versions: 4.10.1
Reporter: Lee Hinman
Assignee: Michael McCandless
Priority: Minor
Fix For: 4.10.3, 5.0, Trunk
Attachments: LUCENE-6046.patch, LUCENE-6046.patch, LUCENE-6046.patch
When creating an automaton from an org.apache.lucene.util.automaton.RegExp,
it's possible for the automaton to use so much memory it exceeds the maximum
array size for java.
The following caused an OutOfMemoryError with a 32gb heap:
{noformat}
new
RegExp(\\[\\[(Datei|File|Bild|Image):[^]]*alt=[^]|}]{50,200}).toAutomaton();
{noformat}
When increased to a 60gb heap, the following exception is thrown:
{noformat}
1 java.lang.IllegalArgumentException: requested array size 2147483624
exceeds maximum array in java (2147483623)
1
__randomizedtesting.SeedInfo.seed([7BE81EF678615C32:95C8057A4ABA5B52]:0)
1 org.apache.lucene.util.ArrayUtil.oversize(ArrayUtil.java:168)
1 org.apache.lucene.util.ArrayUtil.grow(ArrayUtil.java:295)
1
org.apache.lucene.util.automaton.Automaton$Builder.addTransition(Automaton.java:639)
1
org.apache.lucene.util.automaton.Operations.determinize(Operations.java:741)
1
org.apache.lucene.util.automaton.MinimizationOperations.minimizeHopcroft(MinimizationOperations.java:62)
1
org.apache.lucene.util.automaton.MinimizationOperations.minimize(MinimizationOperations.java:51)
1 org.apache.lucene.util.automaton.RegExp.toAutomaton(RegExp.java:477)
1 org.apache.lucene.util.automaton.RegExp.toAutomaton(RegExp.java:426)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6046) RegExp.toAutomaton high memory use
[
https://issues.apache.org/jira/browse/LUCENE-6046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14197972#comment-14197972
]
ASF subversion and git services commented on LUCENE-6046:
-
Commit 1636831 from [~mikemccand] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1636831 ]
LUCENE-6046: let this test determinize massive automata
RegExp.toAutomaton high memory use
--
Key: LUCENE-6046
URL: https://issues.apache.org/jira/browse/LUCENE-6046
Project: Lucene - Core
Issue Type: Bug
Components: core/queryparser
Affects Versions: 4.10.1
Reporter: Lee Hinman
Assignee: Michael McCandless
Priority: Minor
Fix For: 4.10.3, 5.0, Trunk
Attachments: LUCENE-6046.patch, LUCENE-6046.patch, LUCENE-6046.patch
When creating an automaton from an org.apache.lucene.util.automaton.RegExp,
it's possible for the automaton to use so much memory it exceeds the maximum
array size for java.
The following caused an OutOfMemoryError with a 32gb heap:
{noformat}
new
RegExp(\\[\\[(Datei|File|Bild|Image):[^]]*alt=[^]|}]{50,200}).toAutomaton();
{noformat}
When increased to a 60gb heap, the following exception is thrown:
{noformat}
1 java.lang.IllegalArgumentException: requested array size 2147483624
exceeds maximum array in java (2147483623)
1
__randomizedtesting.SeedInfo.seed([7BE81EF678615C32:95C8057A4ABA5B52]:0)
1 org.apache.lucene.util.ArrayUtil.oversize(ArrayUtil.java:168)
1 org.apache.lucene.util.ArrayUtil.grow(ArrayUtil.java:295)
1
org.apache.lucene.util.automaton.Automaton$Builder.addTransition(Automaton.java:639)
1
org.apache.lucene.util.automaton.Operations.determinize(Operations.java:741)
1
org.apache.lucene.util.automaton.MinimizationOperations.minimizeHopcroft(MinimizationOperations.java:62)
1
org.apache.lucene.util.automaton.MinimizationOperations.minimize(MinimizationOperations.java:51)
1 org.apache.lucene.util.automaton.RegExp.toAutomaton(RegExp.java:477)
1 org.apache.lucene.util.automaton.RegExp.toAutomaton(RegExp.java:426)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6046) RegExp.toAutomaton high memory use
[
https://issues.apache.org/jira/browse/LUCENE-6046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14197974#comment-14197974
]
ASF subversion and git services commented on LUCENE-6046:
-
Commit 1636832 from [~mikemccand] in branch 'dev/branches/lucene_solr_4_10'
[ https://svn.apache.org/r1636832 ]
LUCENE-6046: let this test determinize massive automata
RegExp.toAutomaton high memory use
--
Key: LUCENE-6046
URL: https://issues.apache.org/jira/browse/LUCENE-6046
Project: Lucene - Core
Issue Type: Bug
Components: core/queryparser
Affects Versions: 4.10.1
Reporter: Lee Hinman
Assignee: Michael McCandless
Priority: Minor
Fix For: 4.10.3, 5.0, Trunk
Attachments: LUCENE-6046.patch, LUCENE-6046.patch, LUCENE-6046.patch
When creating an automaton from an org.apache.lucene.util.automaton.RegExp,
it's possible for the automaton to use so much memory it exceeds the maximum
array size for java.
The following caused an OutOfMemoryError with a 32gb heap:
{noformat}
new
RegExp(\\[\\[(Datei|File|Bild|Image):[^]]*alt=[^]|}]{50,200}).toAutomaton();
{noformat}
When increased to a 60gb heap, the following exception is thrown:
{noformat}
1 java.lang.IllegalArgumentException: requested array size 2147483624
exceeds maximum array in java (2147483623)
1
__randomizedtesting.SeedInfo.seed([7BE81EF678615C32:95C8057A4ABA5B52]:0)
1 org.apache.lucene.util.ArrayUtil.oversize(ArrayUtil.java:168)
1 org.apache.lucene.util.ArrayUtil.grow(ArrayUtil.java:295)
1
org.apache.lucene.util.automaton.Automaton$Builder.addTransition(Automaton.java:639)
1
org.apache.lucene.util.automaton.Operations.determinize(Operations.java:741)
1
org.apache.lucene.util.automaton.MinimizationOperations.minimizeHopcroft(MinimizationOperations.java:62)
1
org.apache.lucene.util.automaton.MinimizationOperations.minimize(MinimizationOperations.java:51)
1 org.apache.lucene.util.automaton.RegExp.toAutomaton(RegExp.java:477)
1 org.apache.lucene.util.automaton.RegExp.toAutomaton(RegExp.java:426)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5889) AnalyzingInfixSuggester should expose commit()
[ https://issues.apache.org/jira/browse/LUCENE-5889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14197983#comment-14197983 ] Michael McCandless commented on LUCENE-5889: I think we shouldn't backport commit to 4.10.x? That branch is only for bug fixes... hopefully we soon release 5.0, which has the new commit method. AnalyzingInfixSuggester should expose commit() -- Key: LUCENE-5889 URL: https://issues.apache.org/jira/browse/LUCENE-5889 Project: Lucene - Core Issue Type: Improvement Components: modules/spellchecker Reporter: Mike Sokolov Fix For: 5.0, Trunk Attachments: LUCENE-5889.patch, LUCENE-5889.patch There is no way short of close() for a user of AnalyzingInfixSuggester to cause it to commit() its underlying index: only refresh() is provided. But callers might want to ensure the index is flushed to disk without closing. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-5.x-Linux (32bit/jdk1.8.0_40-ea-b09) - Build # 11406 - Still Failing!
I committed a fix. Mike McCandless http://blog.mikemccandless.com On Tue, Nov 4, 2014 at 7:03 PM, Policeman Jenkins Server jenk...@thetaphi.de wrote: Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/11406/ Java: 32bit/jdk1.8.0_40-ea-b09 -client -XX:+UseConcMarkSweepGC (asserts: false) 1 tests failed. REGRESSION: org.apache.lucene.util.automaton.TestAutomaton.testRandomFinite Error Message: Determinizing automaton would result in more than 1 states. Stack Trace: org.apache.lucene.util.automaton.TooComplexToDeterminizeException: Determinizing automaton would result in more than 1 states. at __randomizedtesting.SeedInfo.seed([17CE8379D33E977E:5078E5446CAEF25F]:0) at org.apache.lucene.util.automaton.Operations.determinize(Operations.java:739) at org.apache.lucene.util.automaton.TestAutomaton.assertSame(TestAutomaton.java:1080) at org.apache.lucene.util.automaton.TestAutomaton.testRandomFinite(TestAutomaton.java:1033) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) 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:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) 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 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) 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:365) at java.lang.Thread.run(Thread.java:745) Build Log: [...truncated 1464 lines...]
[jira] [Created] (LUCENE-6049) Cryptic exception if all docs in a segment hit non-aborting exceptions before adding their doc values
Michael McCandless created LUCENE-6049: -- Summary: Cryptic exception if all docs in a segment hit non-aborting exceptions before adding their doc values Key: LUCENE-6049 URL: https://issues.apache.org/jira/browse/LUCENE-6049 Project: Lucene - Core Issue Type: Bug Reporter: Michael McCandless Assignee: Michael McCandless Fix For: 4.10.3, Trunk, 5.x -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6049) Cryptic exception if all docs in a segment hit non-aborting exceptions before adding their doc values
[
https://issues.apache.org/jira/browse/LUCENE-6049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless updated LUCENE-6049:
---
Component/s: core/index
Description:
I hit this while working on LUCENE-6005:
If you add a document with a single field that's both indexed and has doc
values, and during inversion it hits a non-aborting exception, and all docs for
a given segment had this happen, then you'll hit this confusing exception:
{noformat}
java.lang.AssertionError: segment=_0(6.0.0):C2: field=test has docValues but
did not write them
at
__randomizedtesting.SeedInfo.seed([21BFA52E65A19C81:3A824781C0F77629]:0)
at
org.apache.lucene.index.DefaultIndexingChain.writeDocValues(DefaultIndexingChain.java:146)
at
org.apache.lucene.index.DefaultIndexingChain.flush(DefaultIndexingChain.java:93)
at
org.apache.lucene.index.DocumentsWriterPerThread.flush(DocumentsWriterPerThread.java:440)
at
org.apache.lucene.index.DocumentsWriter.doFlush(DocumentsWriter.java:511)
at
org.apache.lucene.index.DocumentsWriter.flushAllThreads(DocumentsWriter.java:622)
at org.apache.lucene.index.IndexWriter.doFlush(IndexWriter.java:3016)
at org.apache.lucene.index.IndexWriter.flush(IndexWriter.java:2992)
at org.apache.lucene.index.IndexWriter.shutdown(IndexWriter.java:946)
at org.apache.lucene.index.IndexWriter.close(IndexWriter.java:991)
at
org.apache.lucene.index.TestDocValuesIndexing.testExcIndexingDocBeforeDocValues(TestDocValuesIndexing.java:927)
{noformat}
The good news here is that exception is new from LUCENE-6019 and it prevents
this case from causing index corruption, but the bad news is, you shouldn't
even get an exception writing the segment in the first place.
Cryptic exception if all docs in a segment hit non-aborting exceptions before
adding their doc values
-
Key: LUCENE-6049
URL: https://issues.apache.org/jira/browse/LUCENE-6049
Project: Lucene - Core
Issue Type: Bug
Components: core/index
Reporter: Michael McCandless
Assignee: Michael McCandless
Fix For: 4.10.3, Trunk, 5.x
I hit this while working on LUCENE-6005:
If you add a document with a single field that's both indexed and has doc
values, and during inversion it hits a non-aborting exception, and all docs
for a given segment had this happen, then you'll hit this confusing exception:
{noformat}
java.lang.AssertionError: segment=_0(6.0.0):C2: field=test has docValues
but did not write them
at
__randomizedtesting.SeedInfo.seed([21BFA52E65A19C81:3A824781C0F77629]:0)
at
org.apache.lucene.index.DefaultIndexingChain.writeDocValues(DefaultIndexingChain.java:146)
at
org.apache.lucene.index.DefaultIndexingChain.flush(DefaultIndexingChain.java:93)
at
org.apache.lucene.index.DocumentsWriterPerThread.flush(DocumentsWriterPerThread.java:440)
at
org.apache.lucene.index.DocumentsWriter.doFlush(DocumentsWriter.java:511)
at
org.apache.lucene.index.DocumentsWriter.flushAllThreads(DocumentsWriter.java:622)
at org.apache.lucene.index.IndexWriter.doFlush(IndexWriter.java:3016)
at org.apache.lucene.index.IndexWriter.flush(IndexWriter.java:2992)
at org.apache.lucene.index.IndexWriter.shutdown(IndexWriter.java:946)
at org.apache.lucene.index.IndexWriter.close(IndexWriter.java:991)
at
org.apache.lucene.index.TestDocValuesIndexing.testExcIndexingDocBeforeDocValues(TestDocValuesIndexing.java:927)
{noformat}
The good news here is that exception is new from LUCENE-6019 and it prevents
this case from causing index corruption, but the bad news is, you shouldn't
even get an exception writing the segment in the first place.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6049) Cryptic exception if all docs in a segment hit non-aborting exceptions before adding their doc values
[
https://issues.apache.org/jira/browse/LUCENE-6049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless updated LUCENE-6049:
---
Attachment: LUCENE-6049.patch
Patch w/ test and fix.
I think we have to move away from this dangerous
{{FieldInfos.addOrUpdate(String,IndexableFieldType)}} method, but this is just
a baby step (fixing it to not carry over DocValuesType).
Cryptic exception if all docs in a segment hit non-aborting exceptions before
adding their doc values
-
Key: LUCENE-6049
URL: https://issues.apache.org/jira/browse/LUCENE-6049
Project: Lucene - Core
Issue Type: Bug
Components: core/index
Reporter: Michael McCandless
Assignee: Michael McCandless
Fix For: 4.10.3, Trunk, 5.x
Attachments: LUCENE-6049.patch
I hit this while working on LUCENE-6005:
If you add a document with a single field that's both indexed and has doc
values, and during inversion it hits a non-aborting exception, and all docs
for a given segment had this happen, then you'll hit this confusing exception:
{noformat}
java.lang.AssertionError: segment=_0(6.0.0):C2: field=test has docValues
but did not write them
at
__randomizedtesting.SeedInfo.seed([21BFA52E65A19C81:3A824781C0F77629]:0)
at
org.apache.lucene.index.DefaultIndexingChain.writeDocValues(DefaultIndexingChain.java:146)
at
org.apache.lucene.index.DefaultIndexingChain.flush(DefaultIndexingChain.java:93)
at
org.apache.lucene.index.DocumentsWriterPerThread.flush(DocumentsWriterPerThread.java:440)
at
org.apache.lucene.index.DocumentsWriter.doFlush(DocumentsWriter.java:511)
at
org.apache.lucene.index.DocumentsWriter.flushAllThreads(DocumentsWriter.java:622)
at org.apache.lucene.index.IndexWriter.doFlush(IndexWriter.java:3016)
at org.apache.lucene.index.IndexWriter.flush(IndexWriter.java:2992)
at org.apache.lucene.index.IndexWriter.shutdown(IndexWriter.java:946)
at org.apache.lucene.index.IndexWriter.close(IndexWriter.java:991)
at
org.apache.lucene.index.TestDocValuesIndexing.testExcIndexingDocBeforeDocValues(TestDocValuesIndexing.java:927)
{noformat}
The good news here is that exception is new from LUCENE-6019 and it prevents
this case from causing index corruption, but the bad news is, you shouldn't
even get an exception writing the segment in the first place.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6058) Solr needs a new website
[ https://issues.apache.org/jira/browse/SOLR-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14198135#comment-14198135 ] ASF subversion and git services commented on SOLR-6058: --- Commit 1636846 from [~gsingers] in branch 'cms/branches/solr_6058' [ https://svn.apache.org/r1636846 ] SOLR-6058: arrange book items Solr needs a new website Key: SOLR-6058 URL: https://issues.apache.org/jira/browse/SOLR-6058 Project: Solr Issue Type: Task Reporter: Grant Ingersoll Assignee: Grant Ingersoll Attachments: HTML.rar, SOLR-6058, SOLR-6058.location-fix.patchfile, SOLR-6058.offset-fix.patch, Solr_Icons.pdf, Solr_Logo_on_black.pdf, Solr_Logo_on_black.png, Solr_Logo_on_orange.pdf, Solr_Logo_on_orange.png, Solr_Logo_on_white.pdf, Solr_Logo_on_white.png, Solr_Styleguide.pdf Solr needs a new website: better organization of content, less verbose, more pleasing graphics, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6058) Solr needs a new website
[ https://issues.apache.org/jira/browse/SOLR-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14198138#comment-14198138 ] ASF subversion and git services commented on SOLR-6058: --- Commit 1636847 from [~gsingers] in branch 'cms/branches/solr_6058' [ https://svn.apache.org/r1636847 ] SOLR-6058: arrange book items Solr needs a new website Key: SOLR-6058 URL: https://issues.apache.org/jira/browse/SOLR-6058 Project: Solr Issue Type: Task Reporter: Grant Ingersoll Assignee: Grant Ingersoll Attachments: HTML.rar, SOLR-6058, SOLR-6058.location-fix.patchfile, SOLR-6058.offset-fix.patch, Solr_Icons.pdf, Solr_Logo_on_black.pdf, Solr_Logo_on_black.png, Solr_Logo_on_orange.pdf, Solr_Logo_on_orange.png, Solr_Logo_on_white.pdf, Solr_Logo_on_white.png, Solr_Styleguide.pdf Solr needs a new website: better organization of content, less verbose, more pleasing graphics, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5528) Add context to AnalyzingInfixSuggester
[ https://issues.apache.org/jira/browse/LUCENE-5528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14198145#comment-14198145 ] Arcadius Ahouansou commented on LUCENE-5528: Another alternative may be to have something like MapBytesRef,Boolean instead of SetBytesRef where the boolean indicates whether the entry is a SHOULD or a MUST Add context to AnalyzingInfixSuggester -- Key: LUCENE-5528 URL: https://issues.apache.org/jira/browse/LUCENE-5528 Project: Lucene - Core Issue Type: Improvement Reporter: Michael McCandless Assignee: Michael McCandless Fix For: 4.8, Trunk Attachments: LUCENE-5528-1.patch, LUCENE-5528-1.patch, LUCENE-5528-1.patch, LUCENE-5528-1.patch, LUCENE-5528.patch, LUCENE-5528.patch, contextInputIteratImpl.patch Spinoff from LUCENE-5350. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6058) Solr needs a new website
[ https://issues.apache.org/jira/browse/SOLR-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14198153#comment-14198153 ] Grant Ingersoll commented on SOLR-6058: --- For those watching this issue, we've noticed some weird behavior with certain browsers and I was wondering if others could report if they see it to. On the main page (solr-index.html), under the Learn More About Solr section, the links to learn more about Features, Resources, etc. don't always work when you hover over the box. For instance, on Chrome when I look at http://lucene.lukesh.com/solr/, I can't click on any of those items. Strangely enough, if I open the Chrome Developer Tools or view the page source, I can. Additionally, when I look at my own local copy, I don't have any trouble. Links also seem to work in Firefox, but don't always work in Safari. I know [~steve_rowe] has said he has had similar failures as well. Can people report back here whether they are seeing it or whether it is perhaps some sort of caching bug, perhaps? Solr needs a new website Key: SOLR-6058 URL: https://issues.apache.org/jira/browse/SOLR-6058 Project: Solr Issue Type: Task Reporter: Grant Ingersoll Assignee: Grant Ingersoll Attachments: HTML.rar, SOLR-6058, SOLR-6058.location-fix.patchfile, SOLR-6058.offset-fix.patch, Solr_Icons.pdf, Solr_Logo_on_black.pdf, Solr_Logo_on_black.png, Solr_Logo_on_orange.pdf, Solr_Logo_on_orange.png, Solr_Logo_on_white.pdf, Solr_Logo_on_white.png, Solr_Styleguide.pdf Solr needs a new website: better organization of content, less verbose, more pleasing graphics, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-SmokeRelease-5.x - Build # 208 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-5.x/208/ No tests ran. Build Log: [...truncated 51652 lines...] prepare-release-no-sign: [mkdir] Created dir: /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/dist [copy] Copying 446 files to /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/dist/lucene [copy] Copying 254 files to /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/dist/solr [smoker] Java 1.7 JAVA_HOME=/home/jenkins/tools/java/latest1.7 [smoker] NOTE: output encoding is US-ASCII [smoker] [smoker] Load release URL file:/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/dist/... [smoker] [smoker] Test Lucene... [smoker] test basics... [smoker] get KEYS [smoker] 0.1 MB in 0.01 sec (8.7 MB/sec) [smoker] check changes HTML... [smoker] download lucene-5.0.0-src.tgz... [smoker] 27.8 MB in 0.04 sec (680.6 MB/sec) [smoker] verify md5/sha1 digests [smoker] download lucene-5.0.0.tgz... [smoker] 63.7 MB in 0.10 sec (658.6 MB/sec) [smoker] verify md5/sha1 digests [smoker] download lucene-5.0.0.zip... [smoker] 73.2 MB in 0.15 sec (495.0 MB/sec) [smoker] verify md5/sha1 digests [smoker] unpack lucene-5.0.0.tgz... [smoker] verify JAR metadata/identity/no javax.* or java.* classes... [smoker] test demo with 1.7... [smoker] got 5561 hits for query lucene [smoker] checkindex with 1.7... [smoker] check Lucene's javadoc JAR [smoker] unpack lucene-5.0.0.zip... [smoker] verify JAR metadata/identity/no javax.* or java.* classes... [smoker] test demo with 1.7... [smoker] got 5561 hits for query lucene [smoker] checkindex with 1.7... [smoker] check Lucene's javadoc JAR [smoker] unpack lucene-5.0.0-src.tgz... [smoker] make sure no JARs/WARs in src dist... [smoker] run ant validate [smoker] run tests w/ Java 7 and testArgs='-Dtests.jettyConnector=Socket -Dtests.disableHdfs=true -Dtests.multiplier=1 -Dtests.slow=false'... [smoker] test demo with 1.7... [smoker] got 206 hits for query lucene [smoker] checkindex with 1.7... [smoker] generate javadocs w/ Java 7... [smoker] [smoker] Crawl/parse... [smoker] [smoker] Verify... [smoker] confirm all releases have coverage in TestBackwardsCompatibility [smoker] find all past Lucene releases... [smoker] run TestBackwardsCompatibility.. [smoker] success! [smoker] [smoker] Test Solr... [smoker] test basics... [smoker] get KEYS [smoker] 0.1 MB in 0.01 sec (11.4 MB/sec) [smoker] check changes HTML... [smoker] download solr-5.0.0-src.tgz... [smoker] 34.1 MB in 0.09 sec (372.2 MB/sec) [smoker] verify md5/sha1 digests [smoker] download solr-5.0.0.tgz... [smoker] 146.3 MB in 1.12 sec (130.7 MB/sec) [smoker] verify md5/sha1 digests [smoker] download solr-5.0.0.zip... [smoker] 152.4 MB in 1.01 sec (151.7 MB/sec) [smoker] verify md5/sha1 digests [smoker] unpack solr-5.0.0.tgz... [smoker] verify JAR metadata/identity/no javax.* or java.* classes... [smoker] unpack lucene-5.0.0.tgz... [smoker] **WARNING**: skipping check of /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/tmp/unpack/solr-5.0.0/contrib/dataimporthandler-extras/lib/javax.mail-1.5.1.jar: it has javax.* classes [smoker] **WARNING**: skipping check of /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/tmp/unpack/solr-5.0.0/contrib/dataimporthandler-extras/lib/activation-1.1.1.jar: it has javax.* classes [smoker] verify WAR metadata/contained JAR identity/no javax.* or java.* classes... [smoker] unpack lucene-5.0.0.tgz... [smoker] copying unpacked distribution for Java 7 ... [smoker] test solr example w/ Java 7... [smoker] start Solr instance (log=/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/tmp/unpack/solr-5.0.0-java7/solr-example.log)... [smoker] startup done [smoker] Failed to determine the port of a local Solr instance, cannot create core! [smoker] test utf8... [smoker] [smoker] command sh ./exampledocs/test_utf8.sh http://localhost:8983/solr/techproducts; failed: [smoker] ERROR: Could not curl to Solr - is curl installed? Is Solr not running? [smoker] [smoker] [smoker] stop server using: bin/solr stop -p 8983 [smoker] No process found for Solr node running on port 8983 [smoker] ***WARNING***: Solr instance didn't respond to SIGINT; using SIGKILL
[jira] [Commented] (LUCENE-6049) Cryptic exception if all docs in a segment hit non-aborting exceptions before adding their doc values
[
https://issues.apache.org/jira/browse/LUCENE-6049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14198158#comment-14198158
]
Michael McCandless commented on LUCENE-6049:
Actually I'm going to try to nuke FieldInfos.addOrUpdate entirely: this is a
scary method and it has caused too many bugs over the years.
Cryptic exception if all docs in a segment hit non-aborting exceptions before
adding their doc values
-
Key: LUCENE-6049
URL: https://issues.apache.org/jira/browse/LUCENE-6049
Project: Lucene - Core
Issue Type: Bug
Components: core/index
Reporter: Michael McCandless
Assignee: Michael McCandless
Fix For: 4.10.3, Trunk, 5.x
Attachments: LUCENE-6049.patch
I hit this while working on LUCENE-6005:
If you add a document with a single field that's both indexed and has doc
values, and during inversion it hits a non-aborting exception, and all docs
for a given segment had this happen, then you'll hit this confusing exception:
{noformat}
java.lang.AssertionError: segment=_0(6.0.0):C2: field=test has docValues
but did not write them
at
__randomizedtesting.SeedInfo.seed([21BFA52E65A19C81:3A824781C0F77629]:0)
at
org.apache.lucene.index.DefaultIndexingChain.writeDocValues(DefaultIndexingChain.java:146)
at
org.apache.lucene.index.DefaultIndexingChain.flush(DefaultIndexingChain.java:93)
at
org.apache.lucene.index.DocumentsWriterPerThread.flush(DocumentsWriterPerThread.java:440)
at
org.apache.lucene.index.DocumentsWriter.doFlush(DocumentsWriter.java:511)
at
org.apache.lucene.index.DocumentsWriter.flushAllThreads(DocumentsWriter.java:622)
at org.apache.lucene.index.IndexWriter.doFlush(IndexWriter.java:3016)
at org.apache.lucene.index.IndexWriter.flush(IndexWriter.java:2992)
at org.apache.lucene.index.IndexWriter.shutdown(IndexWriter.java:946)
at org.apache.lucene.index.IndexWriter.close(IndexWriter.java:991)
at
org.apache.lucene.index.TestDocValuesIndexing.testExcIndexingDocBeforeDocValues(TestDocValuesIndexing.java:927)
{noformat}
The good news here is that exception is new from LUCENE-6019 and it prevents
this case from causing index corruption, but the bad news is, you shouldn't
even get an exception writing the segment in the first place.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6048) AnalyzingInfixSuggester should clear its index in build()
[
https://issues.apache.org/jira/browse/LUCENE-6048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14198166#comment-14198166
]
Michael McCandless commented on LUCENE-6048:
Hmm, I'm confused: its build method passes OpenMode.CREATE when opening a new
writer, which should clear the previous index?
AnalyzingInfixSuggester should clear its index in build()
-
Key: LUCENE-6048
URL: https://issues.apache.org/jira/browse/LUCENE-6048
Project: Lucene - Core
Issue Type: Bug
Reporter: Mike Sokolov
AnalyzingInfixSuggester should clear its index in build() before adding new
documents from the input. This would bring it in line with other Lookup
implementations. Currently it appends any suggestions to those already in the
index. Note the javadoc which says Builds up a new internal {@link Lookup}
representation. Alternatively, it could expose a clear() method, but this
wouldn't be called by the existing Solr logic.
I've had to work around this limitation now by using reflection to get a
handle on AIS.writer to clear it before calling build().
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6058) Solr needs a new website
[ https://issues.apache.org/jira/browse/SOLR-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14198181#comment-14198181 ] Grant Ingersoll commented on SOLR-6058: --- The really odd thing, is the Getting Started section further below is more or less the same and it works fine. Solr needs a new website Key: SOLR-6058 URL: https://issues.apache.org/jira/browse/SOLR-6058 Project: Solr Issue Type: Task Reporter: Grant Ingersoll Assignee: Grant Ingersoll Attachments: HTML.rar, SOLR-6058, SOLR-6058.location-fix.patchfile, SOLR-6058.offset-fix.patch, Solr_Icons.pdf, Solr_Logo_on_black.pdf, Solr_Logo_on_black.png, Solr_Logo_on_orange.pdf, Solr_Logo_on_orange.png, Solr_Logo_on_white.pdf, Solr_Logo_on_white.png, Solr_Styleguide.pdf Solr needs a new website: better organization of content, less verbose, more pleasing graphics, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6058) Solr needs a new website
[ https://issues.apache.org/jira/browse/SOLR-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14198193#comment-14198193 ] ASF subversion and git services commented on SOLR-6058: --- Commit 1636849 from [~gsingers] in branch 'cms/branches/solr_6058' [ https://svn.apache.org/r1636849 ] SOLR-6058: testing div area Solr needs a new website Key: SOLR-6058 URL: https://issues.apache.org/jira/browse/SOLR-6058 Project: Solr Issue Type: Task Reporter: Grant Ingersoll Assignee: Grant Ingersoll Attachments: HTML.rar, SOLR-6058, SOLR-6058.location-fix.patchfile, SOLR-6058.offset-fix.patch, Solr_Icons.pdf, Solr_Logo_on_black.pdf, Solr_Logo_on_black.png, Solr_Logo_on_orange.pdf, Solr_Logo_on_orange.png, Solr_Logo_on_white.pdf, Solr_Logo_on_white.png, Solr_Styleguide.pdf Solr needs a new website: better organization of content, less verbose, more pleasing graphics, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6058) Solr needs a new website
[ https://issues.apache.org/jira/browse/SOLR-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14198227#comment-14198227 ] ASF subversion and git services commented on SOLR-6058: --- Commit 1636853 from [~gsingers] in branch 'cms/branches/solr_6058' [ https://svn.apache.org/r1636853 ] SOLR-6058: add source mapping files Solr needs a new website Key: SOLR-6058 URL: https://issues.apache.org/jira/browse/SOLR-6058 Project: Solr Issue Type: Task Reporter: Grant Ingersoll Assignee: Grant Ingersoll Attachments: HTML.rar, SOLR-6058, SOLR-6058.location-fix.patchfile, SOLR-6058.offset-fix.patch, Solr_Icons.pdf, Solr_Logo_on_black.pdf, Solr_Logo_on_black.png, Solr_Logo_on_orange.pdf, Solr_Logo_on_orange.png, Solr_Logo_on_white.pdf, Solr_Logo_on_white.png, Solr_Styleguide.pdf Solr needs a new website: better organization of content, less verbose, more pleasing graphics, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6058) Solr needs a new website
[ https://issues.apache.org/jira/browse/SOLR-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14198230#comment-14198230 ] Grant Ingersoll commented on SOLR-6058: --- More oddities: If you zoom in (to like 125%) using Chrome on these links (apple-+ on Mac), then they work just fine. I've also notice that if you go slowly from the bottom of the element, you can get it to highlight. Solr needs a new website Key: SOLR-6058 URL: https://issues.apache.org/jira/browse/SOLR-6058 Project: Solr Issue Type: Task Reporter: Grant Ingersoll Assignee: Grant Ingersoll Attachments: HTML.rar, SOLR-6058, SOLR-6058.location-fix.patchfile, SOLR-6058.offset-fix.patch, Solr_Icons.pdf, Solr_Logo_on_black.pdf, Solr_Logo_on_black.png, Solr_Logo_on_orange.pdf, Solr_Logo_on_orange.png, Solr_Logo_on_white.pdf, Solr_Logo_on_white.png, Solr_Styleguide.pdf Solr needs a new website: better organization of content, less verbose, more pleasing graphics, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6058) Solr needs a new website
[ https://issues.apache.org/jira/browse/SOLR-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14198232#comment-14198232 ] Grant Ingersoll commented on SOLR-6058: --- More fun: if you zoom out w/ Dev Tools on, than you can incur the same bad behavior. Seems like there has to be an open tag or something. I did a validation of the page and it seems fine. Solr needs a new website Key: SOLR-6058 URL: https://issues.apache.org/jira/browse/SOLR-6058 Project: Solr Issue Type: Task Reporter: Grant Ingersoll Assignee: Grant Ingersoll Attachments: HTML.rar, SOLR-6058, SOLR-6058.location-fix.patchfile, SOLR-6058.offset-fix.patch, Solr_Icons.pdf, Solr_Logo_on_black.pdf, Solr_Logo_on_black.png, Solr_Logo_on_orange.pdf, Solr_Logo_on_orange.png, Solr_Logo_on_white.pdf, Solr_Logo_on_white.png, Solr_Styleguide.pdf Solr needs a new website: better organization of content, less verbose, more pleasing graphics, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6690) Highlight expanded results
[
https://issues.apache.org/jira/browse/SOLR-6690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Endele updated SOLR-6690:
---
Attachment: HighlightComponent.java.patch
Added a patch for Solr core trunk.
I'm not a Solr core expert. It's just a rough sketch, but it seems to work.
Still to do:
- The order of the ExpandComponent and the HighlightComponent needs to be
switched to make it work (as mentioned in the issue description). I'm not sure
what effects changing the default order in
org.apache.solr.handler.component.SearchHandler.getDefaultComponents() may have.
- It would be good to have a config param to turn this on, I guess. Suggestion:
{{hl.expanded=true/false}}.
Highlight expanded results
--
Key: SOLR-6690
URL: https://issues.apache.org/jira/browse/SOLR-6690
Project: Solr
Issue Type: Wish
Reporter: Simon Endele
Priority: Minor
Labels: expand, highlight
Attachments: HighlightComponent.java.patch
Is it possible to apply the highlighting to documents in the expand section
in the Solr response?
I'm aware that https://cwiki.apache.org/confluence/x/jiBqAg states:
All downstream components (faceting, highlighting, etc...) will work with
the collapsed result set.
So I tried to put the highlight component after the expand component like
this:
{code:xml}arr name=components
strquery/str
strfacet/str
strstats/str
strdebug/str
strexpand/str
strhighlight/str
/arr{code}
But with no effect.
Is there another switch that needs to be flipped or could this be implemented
easily?
IMHO this is quite a common use case...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6690) Highlight expanded results
[
https://issues.apache.org/jira/browse/SOLR-6690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Endele updated SOLR-6690:
---
Description:
Is it possible to highlight documents in the expand section in the Solr
response?
I'm aware that https://cwiki.apache.org/confluence/x/jiBqAg states:
All downstream components (faceting, highlighting, etc...) will work with the
collapsed result set.
So I tried to put the highlight component after the expand component like this:
{code:xml}arr name=components
strquery/str
strfacet/str
strstats/str
strdebug/str
strexpand/str
strhighlight/str
/arr{code}
But with no effect.
Is there another switch that needs to be flipped or could this be implemented
easily?
IMHO this is quite a common use case...
was:
Is it possible to apply the highlighting to documents in the expand section
in the Solr response?
I'm aware that https://cwiki.apache.org/confluence/x/jiBqAg states:
All downstream components (faceting, highlighting, etc...) will work with the
collapsed result set.
So I tried to put the highlight component after the expand component like this:
{code:xml}arr name=components
strquery/str
strfacet/str
strstats/str
strdebug/str
strexpand/str
strhighlight/str
/arr{code}
But with no effect.
Is there another switch that needs to be flipped or could this be implemented
easily?
IMHO this is quite a common use case...
Highlight expanded results
--
Key: SOLR-6690
URL: https://issues.apache.org/jira/browse/SOLR-6690
Project: Solr
Issue Type: Wish
Reporter: Simon Endele
Priority: Minor
Labels: expand, highlight
Attachments: HighlightComponent.java.patch
Is it possible to highlight documents in the expand section in the Solr
response?
I'm aware that https://cwiki.apache.org/confluence/x/jiBqAg states:
All downstream components (faceting, highlighting, etc...) will work with
the collapsed result set.
So I tried to put the highlight component after the expand component like
this:
{code:xml}arr name=components
strquery/str
strfacet/str
strstats/str
strdebug/str
strexpand/str
strhighlight/str
/arr{code}
But with no effect.
Is there another switch that needs to be flipped or could this be implemented
easily?
IMHO this is quite a common use case...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6058) Solr needs a new website
[ https://issues.apache.org/jira/browse/SOLR-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14198248#comment-14198248 ] Grant Ingersoll commented on SOLR-6058: --- Hmm: http://stackoverflow.com/questions/6393827/can-i-nest-a-button-element-inside-an-a-using-html5 may be the cause? Solr needs a new website Key: SOLR-6058 URL: https://issues.apache.org/jira/browse/SOLR-6058 Project: Solr Issue Type: Task Reporter: Grant Ingersoll Assignee: Grant Ingersoll Attachments: HTML.rar, SOLR-6058, SOLR-6058.location-fix.patchfile, SOLR-6058.offset-fix.patch, Solr_Icons.pdf, Solr_Logo_on_black.pdf, Solr_Logo_on_black.png, Solr_Logo_on_orange.pdf, Solr_Logo_on_orange.png, Solr_Logo_on_white.pdf, Solr_Logo_on_white.png, Solr_Styleguide.pdf Solr needs a new website: better organization of content, less verbose, more pleasing graphics, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6690) Highlight expanded results
[
https://issues.apache.org/jira/browse/SOLR-6690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Endele updated SOLR-6690:
---
Component/s: highlighter
Highlight expanded results
--
Key: SOLR-6690
URL: https://issues.apache.org/jira/browse/SOLR-6690
Project: Solr
Issue Type: Wish
Components: highlighter
Reporter: Simon Endele
Priority: Minor
Labels: expand, highlight
Attachments: HighlightComponent.java.patch
Is it possible to highlight documents in the expand section in the Solr
response?
I'm aware that https://cwiki.apache.org/confluence/x/jiBqAg states:
All downstream components (faceting, highlighting, etc...) will work with
the collapsed result set.
So I tried to put the highlight component after the expand component like
this:
{code:xml}arr name=components
strquery/str
strfacet/str
strstats/str
strdebug/str
strexpand/str
strhighlight/str
/arr{code}
But with no effect.
Is there another switch that needs to be flipped or could this be implemented
easily?
IMHO this is quite a common use case...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5528) Add context to AnalyzingInfixSuggester
[ https://issues.apache.org/jira/browse/LUCENE-5528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14198260#comment-14198260 ] Michael McCandless commented on LUCENE-5528: Hi [~arcadius], I think it makes sense to give more control over how context is applied; could you open a new issue for this? Add context to AnalyzingInfixSuggester -- Key: LUCENE-5528 URL: https://issues.apache.org/jira/browse/LUCENE-5528 Project: Lucene - Core Issue Type: Improvement Reporter: Michael McCandless Assignee: Michael McCandless Fix For: 4.8, Trunk Attachments: LUCENE-5528-1.patch, LUCENE-5528-1.patch, LUCENE-5528-1.patch, LUCENE-5528-1.patch, LUCENE-5528.patch, LUCENE-5528.patch, contextInputIteratImpl.patch Spinoff from LUCENE-5350. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Using wordnet synonyms to expand a query in Lucene 4.10 version
I am using Lucene 4.10 and would like to know how wordnet can be used to expand an input query for this version of Lucene. the program fragment is as follows: *File file = new File(model/wn_s.pl); InputStream stream = new FileInputStream(file); Reader rulesReader = new InputStreamReader(stream); SynonymMap.Builder parser = null; parser = new WordnetSynonymParser(true, true, new ClassicAnalyzer()); ((WordnetSynonymParser) parser).parse(rulesReader); SynonymMap synonymMap = parser.build();* the following exception will be produced when running the program *java.text.ParseException:Invalid synonym rule line 109.* I have searched much materials in google, but i have not resolve this exception. I want to know how to use the WordNetSynonymParser, Can you paste a sample code for me? thank you. -- View this message in context: http://lucene.472066.n3.nabble.com/Using-wordnet-synonyms-to-expand-a-query-in-Lucene-4-10-version-tp4167712.html Sent from the Lucene - Java Developer mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-6048) AnalyzingInfixSuggester should clear its index in build()
[
https://issues.apache.org/jira/browse/LUCENE-6048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Sokolov resolved LUCENE-6048.
--
Resolution: Invalid
uh, yeah. I had some problem like this, but it must have been due to
something else - sorry for the noise.
AnalyzingInfixSuggester should clear its index in build()
-
Key: LUCENE-6048
URL: https://issues.apache.org/jira/browse/LUCENE-6048
Project: Lucene - Core
Issue Type: Bug
Reporter: Mike Sokolov
AnalyzingInfixSuggester should clear its index in build() before adding new
documents from the input. This would bring it in line with other Lookup
implementations. Currently it appends any suggestions to those already in the
index. Note the javadoc which says Builds up a new internal {@link Lookup}
representation. Alternatively, it could expose a clear() method, but this
wouldn't be called by the existing Solr logic.
I've had to work around this limitation now by using reflection to get a
handle on AIS.writer to clear it before calling build().
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (LUCENE-6048) AnalyzingInfixSuggester should clear its index in build()
[
https://issues.apache.org/jira/browse/LUCENE-6048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Sokolov closed LUCENE-6048.
AnalyzingInfixSuggester should clear its index in build()
-
Key: LUCENE-6048
URL: https://issues.apache.org/jira/browse/LUCENE-6048
Project: Lucene - Core
Issue Type: Bug
Reporter: Mike Sokolov
AnalyzingInfixSuggester should clear its index in build() before adding new
documents from the input. This would bring it in line with other Lookup
implementations. Currently it appends any suggestions to those already in the
index. Note the javadoc which says Builds up a new internal {@link Lookup}
representation. Alternatively, it could expose a clear() method, but this
wouldn't be called by the existing Solr logic.
I've had to work around this limitation now by using reflection to get a
handle on AIS.writer to clear it before calling build().
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6058) Solr needs a new website
[ https://issues.apache.org/jira/browse/SOLR-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14198288#comment-14198288 ] ASF subversion and git services commented on SOLR-6058: --- Commit 1636856 from [~gsingers] in branch 'cms/branches/solr_6058' [ https://svn.apache.org/r1636856 ] SOLR-6058: remove nested buttons Solr needs a new website Key: SOLR-6058 URL: https://issues.apache.org/jira/browse/SOLR-6058 Project: Solr Issue Type: Task Reporter: Grant Ingersoll Assignee: Grant Ingersoll Attachments: HTML.rar, SOLR-6058, SOLR-6058.location-fix.patchfile, SOLR-6058.offset-fix.patch, Solr_Icons.pdf, Solr_Logo_on_black.pdf, Solr_Logo_on_black.png, Solr_Logo_on_orange.pdf, Solr_Logo_on_orange.png, Solr_Logo_on_white.pdf, Solr_Logo_on_white.png, Solr_Styleguide.pdf Solr needs a new website: better organization of content, less verbose, more pleasing graphics, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6058) Solr needs a new website
[
https://issues.apache.org/jira/browse/SOLR-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14198290#comment-14198290
]
Grant Ingersoll commented on SOLR-6058:
---
Starting to think the issue is the interaction with the div and the a tag on
those links. It seems there is some oddities in how it is handling the nested
div in the a tag. Hard to explain, but if you hover the mouse in the correct
place, you'll see the a tag can be selected to the left of the main box area.
You can see this further by putting some junk text in the a tag, but outside of
the nested div, as in:
{code}
a href=/solr/features.htmldiv class=boxFoo
div class=imgimg
src=/solr/assets/images/icon-features.svg//div
div class=title
h3Features/h3
/div
pHundreds of features make Solr incredibly versatile./p
span class=btn1Learn More/span
/div/a
{code}
Solr needs a new website
Key: SOLR-6058
URL: https://issues.apache.org/jira/browse/SOLR-6058
Project: Solr
Issue Type: Task
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
Attachments: HTML.rar, SOLR-6058, SOLR-6058.location-fix.patchfile,
SOLR-6058.offset-fix.patch, Solr_Icons.pdf, Solr_Logo_on_black.pdf,
Solr_Logo_on_black.png, Solr_Logo_on_orange.pdf, Solr_Logo_on_orange.png,
Solr_Logo_on_white.pdf, Solr_Logo_on_white.png, Solr_Styleguide.pdf
Solr needs a new website: better organization of content, less verbose, more
pleasing graphics, etc.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-6705) SOLR Start script
Carsten Grønbjerg Lützen created SOLR-6705: -- Summary: SOLR Start script Key: SOLR-6705 URL: https://issues.apache.org/jira/browse/SOLR-6705 Project: Solr Issue Type: Bug Components: scripts and tools Affects Versions: 4.10.2 Environment: Mac Yosemite 10.10 java -version java version 1.8.0_25 Java(TM) SE Runtime Environment (build 1.8.0_25-b17) Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode) Reporter: Carsten Grønbjerg Lützen Priority: Trivial When using the start script in bin: ./solr start The following warnings occur from Java: Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=256m; support was removed in 8.0 Java HotSpot(TM) 64-Bit Server VM warning: ignoring option PermSize=256m; support was removed in 8.0 Java HotSpot(TM) 64-Bit Server VM warning: ignoring option CMSTriggerPermRatio=80; support was removed in 8.0 Java HotSpot(TM) 64-Bit Server VM warning: CMSFullGCsBeforeCompaction is deprecated and will likely be removed in a future release. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6533) Support editing common solrconfig.xml values
[
https://issues.apache.org/jira/browse/SOLR-6533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14198325#comment-14198325
]
ASF subversion and git services commented on SOLR-6533:
---
Commit 1636862 from [~noble.paul] in branch 'dev/trunk'
[ https://svn.apache.org/r1636862 ]
SOLR-6533,SOLR-6654
Support editing common solrconfig.xml values
Key: SOLR-6533
URL: https://issues.apache.org/jira/browse/SOLR-6533
Project: Solr
Issue Type: Sub-task
Reporter: Noble Paul
Attachments: SOLR-6533.patch, SOLR-6533.patch, SOLR-6533.patch,
SOLR-6533.patch, SOLR-6533.patch, SOLR-6533.patch, SOLR-6533.patch,
SOLR-6533.patch
There are a bunch of properties in solrconfig.xml which users want to edit.
We will attack them first
These properties will be persisted to a separate file called config.json (or
whatever file). Instead of saving in the same format we will have well known
properties which users can directly edit
{code}
updateHandler.autoCommit.maxDocs
query.filterCache.initialSize
{code}
The api will be modeled around the bulk schema API
{code:javascript}
curl http://localhost:8983/solr/collection1/config -H
'Content-type:application/json' -d '{
set-property : {updateHandler.autoCommit.maxDocs:5},
unset-property: updateHandler.autoCommit.maxDocs
}'
{code}
{code:javascript}
//or use this to set ${mypropname} values
curl http://localhost:8983/solr/collection1/config -H
'Content-type:application/json' -d '{
set-user-property : {mypropname:my_prop_val},
unset-user-property:{mypropname}
}'
{code}
The values stored in the config.json will always take precedence and will be
applied after loading solrconfig.xml.
An http GET on /config path will give the real config that is applied .
An http GET of/config/overlay gives out the content of the configOverlay.json
/config/component-name gives only the fchild of the same name from /config
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6654) add a standard way to listen to config changes in cloud mode
[ https://issues.apache.org/jira/browse/SOLR-6654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14198326#comment-14198326 ] ASF subversion and git services commented on SOLR-6654: --- Commit 1636862 from [~noble.paul] in branch 'dev/trunk' [ https://svn.apache.org/r1636862 ] SOLR-6533,SOLR-6654 add a standard way to listen to config changes in cloud mode Key: SOLR-6654 URL: https://issues.apache.org/jira/browse/SOLR-6654 Project: Solr Issue Type: Sub-task Reporter: Noble Paul Assignee: Noble Paul -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6533) Support editing common solrconfig.xml values
[
https://issues.apache.org/jira/browse/SOLR-6533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14198333#comment-14198333
]
ASF subversion and git services commented on SOLR-6533:
---
Commit 1636863 from [~noble.paul] in branch 'dev/trunk'
[ https://svn.apache.org/r1636863 ]
SOLR-6533
Support editing common solrconfig.xml values
Key: SOLR-6533
URL: https://issues.apache.org/jira/browse/SOLR-6533
Project: Solr
Issue Type: Sub-task
Reporter: Noble Paul
Attachments: SOLR-6533.patch, SOLR-6533.patch, SOLR-6533.patch,
SOLR-6533.patch, SOLR-6533.patch, SOLR-6533.patch, SOLR-6533.patch,
SOLR-6533.patch
There are a bunch of properties in solrconfig.xml which users want to edit.
We will attack them first
These properties will be persisted to a separate file called config.json (or
whatever file). Instead of saving in the same format we will have well known
properties which users can directly edit
{code}
updateHandler.autoCommit.maxDocs
query.filterCache.initialSize
{code}
The api will be modeled around the bulk schema API
{code:javascript}
curl http://localhost:8983/solr/collection1/config -H
'Content-type:application/json' -d '{
set-property : {updateHandler.autoCommit.maxDocs:5},
unset-property: updateHandler.autoCommit.maxDocs
}'
{code}
{code:javascript}
//or use this to set ${mypropname} values
curl http://localhost:8983/solr/collection1/config -H
'Content-type:application/json' -d '{
set-user-property : {mypropname:my_prop_val},
unset-user-property:{mypropname}
}'
{code}
The values stored in the config.json will always take precedence and will be
applied after loading solrconfig.xml.
An http GET on /config path will give the real config that is applied .
An http GET of/config/overlay gives out the content of the configOverlay.json
/config/component-name gives only the fchild of the same name from /config
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4586) Increase default maxBooleanClauses
[ https://issues.apache.org/jira/browse/SOLR-4586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14198367#comment-14198367 ] Yonik Seeley commented on SOLR-4586: Unfortunately this issue never got consensus as Robert reiterated his -1 Increase default maxBooleanClauses -- Key: SOLR-4586 URL: https://issues.apache.org/jira/browse/SOLR-4586 Project: Solr Issue Type: Improvement Affects Versions: 4.2 Environment: 4.3-SNAPSHOT 1456767M - ncindex - 2013-03-15 13:11:50 Reporter: Shawn Heisey Attachments: SOLR-4586.patch, SOLR-4586.patch, SOLR-4586.patch, SOLR-4586.patch, SOLR-4586.patch, SOLR-4586.patch, SOLR-4586_verify_maxClauses.patch In the #solr IRC channel, I mentioned the maxBooleanClauses limitation to someone asking a question about queries. Mark Miller told me that maxBooleanClauses no longer applies, that the limitation was removed from Lucene sometime in the 3.x series. The config still shows up in the example even in the just-released 4.2. Checking through the source code, I found that the config option is parsed and the value stored in objects, but does not actually seem to be used by anything. I removed every trace of it that I could find, and all tests still pass. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4586) Increase default maxBooleanClauses
[ https://issues.apache.org/jira/browse/SOLR-4586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14198371#comment-14198371 ] David Smiley commented on SOLR-4586: [~rcmuir] now has a conflict-of-interest that he didn't have at the time he voted. +1 to commit to 5x. Increase default maxBooleanClauses -- Key: SOLR-4586 URL: https://issues.apache.org/jira/browse/SOLR-4586 Project: Solr Issue Type: Improvement Affects Versions: 4.2 Environment: 4.3-SNAPSHOT 1456767M - ncindex - 2013-03-15 13:11:50 Reporter: Shawn Heisey Attachments: SOLR-4586.patch, SOLR-4586.patch, SOLR-4586.patch, SOLR-4586.patch, SOLR-4586.patch, SOLR-4586.patch, SOLR-4586_verify_maxClauses.patch In the #solr IRC channel, I mentioned the maxBooleanClauses limitation to someone asking a question about queries. Mark Miller told me that maxBooleanClauses no longer applies, that the limitation was removed from Lucene sometime in the 3.x series. The config still shows up in the example even in the just-released 4.2. Checking through the source code, I found that the config option is parsed and the value stored in objects, but does not actually seem to be used by anything. I removed every trace of it that I could find, and all tests still pass. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6654) add a standard way to listen to config changes in cloud mode
[ https://issues.apache.org/jira/browse/SOLR-6654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14198375#comment-14198375 ] Shalin Shekhar Mangar commented on SOLR-6654: - What is this standard way? Can we please add some details here? add a standard way to listen to config changes in cloud mode Key: SOLR-6654 URL: https://issues.apache.org/jira/browse/SOLR-6654 Project: Solr Issue Type: Sub-task Reporter: Noble Paul Assignee: Noble Paul -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6705) SOLR Start script
[ https://issues.apache.org/jira/browse/SOLR-6705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14198378#comment-14198378 ] Shawn Heisey commented on SOLR-6705: Those messages are there because you're running Java 8. The first three parameters mentioned don't do anything when running Java 8, the last one currently does change behavior, but won't in a future version. These parameters DO have meaning to Java 7, which is a supported platform for the currently available Solr releases, and will continue to be supported by the 5.0 release. Increasing PermSize (the first two parameters mentioned) is a perfectly valid thing to do on Java 7. The third and fourth messages refer to garbage collection tuning parameters that are supported by Java 7. They were intentionally included to speed up garbage collection. Although it might be possible to include changes that would get rid of these warnings on Java 8, it would make the start script significantly more complicated. That complexity means bugs would be more likely to escape notice and affect users. I would much rather see warnings than bugs. I'll leave the issue open right now, in case a committer with more experience has a different take on your concern. SOLR Start script - Key: SOLR-6705 URL: https://issues.apache.org/jira/browse/SOLR-6705 Project: Solr Issue Type: Bug Components: scripts and tools Affects Versions: 4.10.2 Environment: Mac Yosemite 10.10 java -version java version 1.8.0_25 Java(TM) SE Runtime Environment (build 1.8.0_25-b17) Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode) Reporter: Carsten Grønbjerg Lützen Priority: Trivial When using the start script in bin: ./solr start The following warnings occur from Java: Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=256m; support was removed in 8.0 Java HotSpot(TM) 64-Bit Server VM warning: ignoring option PermSize=256m; support was removed in 8.0 Java HotSpot(TM) 64-Bit Server VM warning: ignoring option CMSTriggerPermRatio=80; support was removed in 8.0 Java HotSpot(TM) 64-Bit Server VM warning: CMSFullGCsBeforeCompaction is deprecated and will likely be removed in a future release. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2927) SolrIndexSearcher's register do not match close and SolrCore's closeSearcher
[ https://issues.apache.org/jira/browse/SOLR-2927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cyrille Roy updated SOLR-2927: -- Attachment: (was: SOLR-2927.patch) SolrIndexSearcher's register do not match close and SolrCore's closeSearcher Key: SOLR-2927 URL: https://issues.apache.org/jira/browse/SOLR-2927 Project: Solr Issue Type: Bug Components: search Affects Versions: 4.0-ALPHA Environment: JDK1.6/CentOS Reporter: tom liu Assignee: Shalin Shekhar Mangar Fix For: 5.0, Trunk Attachments: SOLR-2927.patch, mbean-leak-jira.png # SolrIndexSearcher's register method put the name of searcher, but SolrCore's closeSearcher method remove name of currentSearcher on infoRegistry. # SolrIndexSearcher's register method put the name of cache, but SolrIndexSearcher's close do not remove the name of cache. so, there maybe lost some memory leak. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2927) SolrIndexSearcher's register do not match close and SolrCore's closeSearcher
[ https://issues.apache.org/jira/browse/SOLR-2927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14198385#comment-14198385 ] Cyrille Roy commented on SOLR-2927: --- I removed the initial patch I provided as [~shalinmangar] enriched it for branch_5X SolrIndexSearcher's register do not match close and SolrCore's closeSearcher Key: SOLR-2927 URL: https://issues.apache.org/jira/browse/SOLR-2927 Project: Solr Issue Type: Bug Components: search Affects Versions: 4.0-ALPHA Environment: JDK1.6/CentOS Reporter: tom liu Assignee: Shalin Shekhar Mangar Fix For: 5.0, Trunk Attachments: SOLR-2927.patch, mbean-leak-jira.png # SolrIndexSearcher's register method put the name of searcher, but SolrCore's closeSearcher method remove name of currentSearcher on infoRegistry. # SolrIndexSearcher's register method put the name of cache, but SolrIndexSearcher's close do not remove the name of cache. so, there maybe lost some memory leak. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6654) add a standard way to listen to config changes in cloud mode
[ https://issues.apache.org/jira/browse/SOLR-6654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14198386#comment-14198386 ] Mark Miller commented on SOLR-6654: --- +1 IMO, f you are not really going to use this JIRA issue for anything, I think it would be a lot clearer to have removed / closed it and done everything in SOLR-6533. It seems this issue is simply here to sum up part of the work in SOLR-6533 in a vague sentence - fine if more was intended and then that changed, but then lets clean things up so it's easier for others to follow. add a standard way to listen to config changes in cloud mode Key: SOLR-6654 URL: https://issues.apache.org/jira/browse/SOLR-6654 Project: Solr Issue Type: Sub-task Reporter: Noble Paul Assignee: Noble Paul -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6685) ConcurrentModificationException in Overseer Stats API
[ https://issues.apache.org/jira/browse/SOLR-6685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar updated SOLR-6685: Attachment: SOLR-6685.patch This patch changes the Stats map to be a ConcurrentHashMap and gets rid of the (inconsistent) synchronized blocks in the Stats methods. Synchronization is not required for iteration anymore. I found that failureDetails was being iterated without synchronization in OCP.getOverseerStatus. ConcurrentModificationException in Overseer Stats API - Key: SOLR-6685 URL: https://issues.apache.org/jira/browse/SOLR-6685 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.10.1 Reporter: Shalin Shekhar Mangar Assignee: Shalin Shekhar Mangar Fix For: 5.0, Trunk Attachments: SOLR-6685.patch I just found a concurrent modification exception in OverseerCollectionProcessor while iterating over the overseer stats. The iteration should be synchronized. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6685) ConcurrentModificationException in Overseer Stats API
[ https://issues.apache.org/jira/browse/SOLR-6685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar updated SOLR-6685: Attachment: SOLR-6685.patch Actually the iteration of failureDetails in OCP.getOverseerStats is not required because we return a copy of the original list. ConcurrentModificationException in Overseer Stats API - Key: SOLR-6685 URL: https://issues.apache.org/jira/browse/SOLR-6685 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.10.1 Reporter: Shalin Shekhar Mangar Assignee: Shalin Shekhar Mangar Fix For: 5.0, Trunk Attachments: SOLR-6685.patch, SOLR-6685.patch I just found a concurrent modification exception in OverseerCollectionProcessor while iterating over the overseer stats. The iteration should be synchronized. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request: clarified the Sort(Sortfield...) constru...
Github user s4ke commented on the pull request: https://github.com/apache/lucene-solr/pull/20#issuecomment-61812659 This is kind of important for users not familiar with the concept of how sorting works in Lucene and would have saved me a lot of time while coding if this comment was there at that time. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6685) ConcurrentModificationException in Overseer Stats API
[ https://issues.apache.org/jira/browse/SOLR-6685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14198416#comment-14198416 ] ASF subversion and git services commented on SOLR-6685: --- Commit 1636876 from sha...@apache.org in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1636876 ] SOLR-6685: ConcurrentModificationException in Overseer Status API ConcurrentModificationException in Overseer Stats API - Key: SOLR-6685 URL: https://issues.apache.org/jira/browse/SOLR-6685 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.10.1 Reporter: Shalin Shekhar Mangar Assignee: Shalin Shekhar Mangar Fix For: 5.0, Trunk Attachments: SOLR-6685.patch, SOLR-6685.patch I just found a concurrent modification exception in OverseerCollectionProcessor while iterating over the overseer stats. The iteration should be synchronized. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-6685) ConcurrentModificationException in Overseer Stats API
[ https://issues.apache.org/jira/browse/SOLR-6685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar resolved SOLR-6685. - Resolution: Fixed ConcurrentModificationException in Overseer Stats API - Key: SOLR-6685 URL: https://issues.apache.org/jira/browse/SOLR-6685 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.10.1 Reporter: Shalin Shekhar Mangar Assignee: Shalin Shekhar Mangar Fix For: 5.0, Trunk Attachments: SOLR-6685.patch, SOLR-6685.patch I just found a concurrent modification exception in OverseerCollectionProcessor while iterating over the overseer stats. The iteration should be synchronized. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request: clarified the Sort(Sortfield...) constru...
Github user shalinmangar commented on the pull request: https://github.com/apache/lucene-solr/pull/20#issuecomment-61814987 Hi s4ke, I think you need to create a corresponding Lucene Jira issue and then mention the issue number in a comment here. Otherwise it's just a dangling patch which goes nowhere. That's probably why no one has looked at it. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6654) add a standard way to listen to config changes in cloud mode
[ https://issues.apache.org/jira/browse/SOLR-6654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14198434#comment-14198434 ] Noble Paul commented on SOLR-6654: -- Actually, I wanted to change the schema listening mechanism skidoo as a part of this. That's why I created this add a standard way to listen to config changes in cloud mode Key: SOLR-6654 URL: https://issues.apache.org/jira/browse/SOLR-6654 Project: Solr Issue Type: Sub-task Reporter: Noble Paul Assignee: Noble Paul -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-6654) add a standard way to listen to config changes in cloud mode
[ https://issues.apache.org/jira/browse/SOLR-6654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14198434#comment-14198434 ] Noble Paul edited comment on SOLR-6654 at 11/5/14 2:42 PM: --- Actually, I wanted to change the schema listening mechanism too as a part of this. That's why I created this. was (Author: noblepaul): Actually, I wanted to change the schema listening mechanism skidoo as a part of this. That's why I created this add a standard way to listen to config changes in cloud mode Key: SOLR-6654 URL: https://issues.apache.org/jira/browse/SOLR-6654 Project: Solr Issue Type: Sub-task Reporter: Noble Paul Assignee: Noble Paul -- This message was sent by Atlassian JIRA (v6.3.4#6332) - 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_67) - Build # 4415 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/4415/ Java: 32bit/jdk1.7.0_67 -client -XX:+UseParallelGC (asserts: true) 1 tests failed. REGRESSION: org.apache.solr.schema.TestCloudSchemaless.testDistribSearch Error Message: QUERY FAILED: xpath=/response/arr[@name='fields']/lst/str[@name='name'][.='newTestFieldInt448'] request=/schema/fields?wt=xml response=?xml version=1.0 encoding=UTF-8? response lst name=responseHeader int name=status0/int int name=QTime25/int /lst arr name=fields lst str name=name_version_/str str name=typelong/str bool name=indexedtrue/bool bool name=storedtrue/bool /lst lst str name=nameconstantField/str str name=typetdouble/str /lst lst str name=nameid/str str name=typestring/str bool name=multiValuedfalse/bool bool name=indexedtrue/bool bool name=storedtrue/bool bool name=requiredtrue/bool /lst lst str name=namenewTestFieldInt0/str str name=typetlong/str /lst lst str name=namenewTestFieldInt1/str str name=typetlong/str /lst lst str name=namenewTestFieldInt10/str str name=typetlong/str /lst lst str name=namenewTestFieldInt100/str str name=typetlong/str /lst lst str name=namenewTestFieldInt101/str str name=typetlong/str /lst lst str name=namenewTestFieldInt102/str str name=typetlong/str /lst lst str name=namenewTestFieldInt103/str str name=typetlong/str /lst lst str name=namenewTestFieldInt104/str str name=typetlong/str /lst lst str name=namenewTestFieldInt105/str str name=typetlong/str /lst lst str name=namenewTestFieldInt106/str str name=typetlong/str /lst lst str name=namenewTestFieldInt107/str str name=typetlong/str /lst lst str name=namenewTestFieldInt108/str str name=typetlong/str /lst lst str name=namenewTestFieldInt109/str str name=typetlong/str /lst lst str name=namenewTestFieldInt11/str str name=typetlong/str /lst lst str name=namenewTestFieldInt110/str str name=typetlong/str /lst lst str name=namenewTestFieldInt111/str str name=typetlong/str /lst lst str name=namenewTestFieldInt112/str str name=typetlong/str /lst lst str name=namenewTestFieldInt113/str str name=typetlong/str /lst lst str name=namenewTestFieldInt114/str str name=typetlong/str /lst lst str name=namenewTestFieldInt115/str str name=typetlong/str /lst lst str name=namenewTestFieldInt116/str str name=typetlong/str /lst lst str name=namenewTestFieldInt117/str str name=typetlong/str /lst lst str name=namenewTestFieldInt118/str str name=typetlong/str /lst lst str name=namenewTestFieldInt119/str str name=typetlong/str /lst lst str name=namenewTestFieldInt12/str str name=typetlong/str /lst lst str name=namenewTestFieldInt120/str str name=typetlong/str /lst lst str name=namenewTestFieldInt121/str str name=typetlong/str /lst lst str name=namenewTestFieldInt122/str str name=typetlong/str /lst lst str name=namenewTestFieldInt123/str str name=typetlong/str /lst lst str name=namenewTestFieldInt124/str str name=typetlong/str /lst lst str name=namenewTestFieldInt125/str str name=typetlong/str /lst lst str name=namenewTestFieldInt126/str str name=typetlong/str /lst lst str name=namenewTestFieldInt127/str str name=typetlong/str /lst lst str name=namenewTestFieldInt128/str str name=typetlong/str /lst lst str name=namenewTestFieldInt129/str str name=typetlong/str /lst lst str name=namenewTestFieldInt13/str str name=typetlong/str /lst lst str name=namenewTestFieldInt130/str str name=typetlong/str /lst lst str name=namenewTestFieldInt131/str str name=typetlong/str /lst lst str name=namenewTestFieldInt132/str str name=typetlong/str /lst lst str name=namenewTestFieldInt133/str str name=typetlong/str /lst lst str name=namenewTestFieldInt134/str str name=typetlong/str /lst lst str name=namenewTestFieldInt135/str str name=typetlong/str /lst lst str name=namenewTestFieldInt136/str str name=typetlong/str /lst lst str name=namenewTestFieldInt137/str str name=typetlong/str /lst lst str name=namenewTestFieldInt138/str str name=typetlong/str /lst lst str name=namenewTestFieldInt139/str str name=typetlong/str /lst lst str name=namenewTestFieldInt14/str str name=typetlong/str /lst lst str name=namenewTestFieldInt140/str str name=typetlong/str /lst lst str name=namenewTestFieldInt141/str str name=typetlong/str /lst lst str name=namenewTestFieldInt142/str str name=typetlong/str /lst
[jira] [Commented] (SOLR-6654) add a standard way to listen to config changes in cloud mode
[ https://issues.apache.org/jira/browse/SOLR-6654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14198448#comment-14198448 ] Noble Paul commented on SOLR-6654: -- [~shalinmangar] I added a method called ZkController.registerConfListenerForCore() so that any component can listen for a conf directory in ZK. I was focussing on SOLR-6533 , I shall add more stuff to this ticket before I close this add a standard way to listen to config changes in cloud mode Key: SOLR-6654 URL: https://issues.apache.org/jira/browse/SOLR-6654 Project: Solr Issue Type: Sub-task Reporter: Noble Paul Assignee: Noble Paul -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-6705) SOLR Start script
[ https://issues.apache.org/jira/browse/SOLR-6705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson resolved SOLR-6705. -- Resolution: Invalid In the future, please raise issues like this on the user's list first so we can keep the JIRAs focused on code problems/improvements. SOLR Start script - Key: SOLR-6705 URL: https://issues.apache.org/jira/browse/SOLR-6705 Project: Solr Issue Type: Bug Components: scripts and tools Affects Versions: 4.10.2 Environment: Mac Yosemite 10.10 java -version java version 1.8.0_25 Java(TM) SE Runtime Environment (build 1.8.0_25-b17) Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode) Reporter: Carsten Grønbjerg Lützen Priority: Trivial When using the start script in bin: ./solr start The following warnings occur from Java: Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=256m; support was removed in 8.0 Java HotSpot(TM) 64-Bit Server VM warning: ignoring option PermSize=256m; support was removed in 8.0 Java HotSpot(TM) 64-Bit Server VM warning: ignoring option CMSTriggerPermRatio=80; support was removed in 8.0 Java HotSpot(TM) 64-Bit Server VM warning: CMSFullGCsBeforeCompaction is deprecated and will likely be removed in a future release. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6058) Solr needs a new website
[ https://issues.apache.org/jira/browse/SOLR-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14198468#comment-14198468 ] ASF subversion and git services commented on SOLR-6058: --- Commit 1636884 from [~gsingers] in branch 'cms/branches/solr_6058' [ https://svn.apache.org/r1636884 ] SOLR-6058: verbiage Solr needs a new website Key: SOLR-6058 URL: https://issues.apache.org/jira/browse/SOLR-6058 Project: Solr Issue Type: Task Reporter: Grant Ingersoll Assignee: Grant Ingersoll Attachments: HTML.rar, SOLR-6058, SOLR-6058.location-fix.patchfile, SOLR-6058.offset-fix.patch, Solr_Icons.pdf, Solr_Logo_on_black.pdf, Solr_Logo_on_black.png, Solr_Logo_on_orange.pdf, Solr_Logo_on_orange.png, Solr_Logo_on_white.pdf, Solr_Logo_on_white.png, Solr_Styleguide.pdf Solr needs a new website: better organization of content, less verbose, more pleasing graphics, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6058) Solr needs a new website
[ https://issues.apache.org/jira/browse/SOLR-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14198475#comment-14198475 ] Grant Ingersoll commented on SOLR-6058: --- OK, talked w/ [~steve_rowe] and he figured out that this issue is tied to the offset class that is on the section here. It causes the hover view part of it to be clipped at the bottom. This is most exacerbated when you zoom out (50%-75% or original) This happens across Chrome, Safari and FF. [~FranLukesh] Solr needs a new website Key: SOLR-6058 URL: https://issues.apache.org/jira/browse/SOLR-6058 Project: Solr Issue Type: Task Reporter: Grant Ingersoll Assignee: Grant Ingersoll Attachments: HTML.rar, SOLR-6058, SOLR-6058.location-fix.patchfile, SOLR-6058.offset-fix.patch, Solr_Icons.pdf, Solr_Logo_on_black.pdf, Solr_Logo_on_black.png, Solr_Logo_on_orange.pdf, Solr_Logo_on_orange.png, Solr_Logo_on_white.pdf, Solr_Logo_on_white.png, Solr_Styleguide.pdf Solr needs a new website: better organization of content, less verbose, more pleasing graphics, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-6706) /update/json/docs throws RuntimeException if a nested structure contains a non-leaf number field
Shalin Shekhar Mangar created SOLR-6706:
---
Summary: /update/json/docs throws RuntimeException if a nested
structure contains a non-leaf number field
Key: SOLR-6706
URL: https://issues.apache.org/jira/browse/SOLR-6706
Project: Solr
Issue Type: Bug
Components: update
Affects Versions: 4.10.2, 5.0, Trunk
Reporter: Shalin Shekhar Mangar
Fix For: 5.0, Trunk
The following JSON throws an exception:
{code}
{
a_string : abc,
a_num : 2.0,
a : {
b : [
{id:1, title : test1},
{id:2, title : test2}
]
}
}
{code}
{code}
curl
'http://localhost:8983/solr/collection1/update/json/docs?split=/a/bf=id:/a/b/idf=title_s:/a/b/titleindent=on'
-H 'Content-type:application/json' -d @test2.json
{
responseHeader:{
status:500,
QTime:0},
error:{
msg:unexpected token 3,
trace:java.lang.RuntimeException: unexpected token 3\n\tat
org.apache.solr.common.util.JsonRecordReader$Node.handleObjectStart(JsonRecordReader.java:400)\n\tat
org.apache.solr.common.util.JsonRecordReader$Node.parse(JsonRecordReader.java:281)\n\tat
org.apache.solr.common.util.JsonRecordReader$Node.access$200(JsonRecordReader.java:152)\n\tat
org.apache.solr.common.util.JsonRecordReader.streamRecords(JsonRecordReader.java:136)\n\tat
org.apache.solr.handler.loader.JsonLoader$SingleThreadedJsonLoader.handleSplitMode(JsonLoader.java:200)\n\tat
org.apache.solr.handler.loader.JsonLoader$SingleThreadedJsonLoader.processUpdate(JsonLoader.java:120)\n\tat
org.apache.solr.handler.loader.JsonLoader$SingleThreadedJsonLoader.load(JsonLoader.java:106)\n\tat
org.apache.solr.handler.loader.JsonLoader.load(JsonLoader.java:68)\n\tat
org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:99)\n\tat
org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:74)\n\tat
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)\n\tat
org.apache.solr.core.SolrCore.execute(SolrCore.java:1967)\n\tat
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:777)\n\tat
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:418)\n\tat
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:207)\n\tat
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)\n\tat
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)\n\tat
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)\n\tat
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)\n\tat
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)\n\tat
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)\n\tat
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)\n\tat
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)\n\tat
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)\n\tat
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)\n\tat
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)\n\tat
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)\n\tat
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)\n\tat
org.eclipse.jetty.server.Server.handle(Server.java:368)\n\tat
org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)\n\tat
org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53)\n\tat
org.eclipse.jetty.server.AbstractHttpConnection.content(AbstractHttpConnection.java:953)\n\tat
org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.content(AbstractHttpConnection.java:1014)\n\tat
org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:861)\n\tat
org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:240)\n\tat
org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72)\n\tat
org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264)\n\tat
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)\n\tat
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)\n\tat
java.lang.Thread.run(Thread.java:745)\n,
code:500}}
{code}
If I change a_num to an integer or remove it entirely then the document is
indexed successfully.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
[jira] [Updated] (SOLR-6706) /update/json/docs throws RuntimeException if a nested structure contains a non-leaf float field
[
https://issues.apache.org/jira/browse/SOLR-6706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shalin Shekhar Mangar updated SOLR-6706:
Summary: /update/json/docs throws RuntimeException if a nested structure
contains a non-leaf float field (was: /update/json/docs throws
RuntimeException if a nested structure contains a non-leaf number field)
/update/json/docs throws RuntimeException if a nested structure contains a
non-leaf float field
---
Key: SOLR-6706
URL: https://issues.apache.org/jira/browse/SOLR-6706
Project: Solr
Issue Type: Bug
Components: update
Affects Versions: 4.10.2, 5.0, Trunk
Reporter: Shalin Shekhar Mangar
Fix For: 5.0, Trunk
The following JSON throws an exception:
{code}
{
a_string : abc,
a_num : 2.0,
a : {
b : [
{id:1, title : test1},
{id:2, title : test2}
]
}
}
{code}
{code}
curl
'http://localhost:8983/solr/collection1/update/json/docs?split=/a/bf=id:/a/b/idf=title_s:/a/b/titleindent=on'
-H 'Content-type:application/json' -d @test2.json
{
responseHeader:{
status:500,
QTime:0},
error:{
msg:unexpected token 3,
trace:java.lang.RuntimeException: unexpected token 3\n\tat
org.apache.solr.common.util.JsonRecordReader$Node.handleObjectStart(JsonRecordReader.java:400)\n\tat
org.apache.solr.common.util.JsonRecordReader$Node.parse(JsonRecordReader.java:281)\n\tat
org.apache.solr.common.util.JsonRecordReader$Node.access$200(JsonRecordReader.java:152)\n\tat
org.apache.solr.common.util.JsonRecordReader.streamRecords(JsonRecordReader.java:136)\n\tat
org.apache.solr.handler.loader.JsonLoader$SingleThreadedJsonLoader.handleSplitMode(JsonLoader.java:200)\n\tat
org.apache.solr.handler.loader.JsonLoader$SingleThreadedJsonLoader.processUpdate(JsonLoader.java:120)\n\tat
org.apache.solr.handler.loader.JsonLoader$SingleThreadedJsonLoader.load(JsonLoader.java:106)\n\tat
org.apache.solr.handler.loader.JsonLoader.load(JsonLoader.java:68)\n\tat
org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:99)\n\tat
org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:74)\n\tat
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)\n\tat
org.apache.solr.core.SolrCore.execute(SolrCore.java:1967)\n\tat
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:777)\n\tat
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:418)\n\tat
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:207)\n\tat
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)\n\tat
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)\n\tat
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)\n\tat
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)\n\tat
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)\n\tat
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)\n\tat
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)\n\tat
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)\n\tat
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)\n\tat
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)\n\tat
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)\n\tat
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)\n\tat
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)\n\tat
org.eclipse.jetty.server.Server.handle(Server.java:368)\n\tat
org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)\n\tat
org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53)\n\tat
org.eclipse.jetty.server.AbstractHttpConnection.content(AbstractHttpConnection.java:953)\n\tat
org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.content(AbstractHttpConnection.java:1014)\n\tat
org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:861)\n\tat
org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:240)\n\tat
org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72)\n\tat
[jira] [Updated] (SOLR-6706) /update/json/docs throws RuntimeException if a nested structure contains a non-leaf float field
[
https://issues.apache.org/jira/browse/SOLR-6706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shalin Shekhar Mangar updated SOLR-6706:
Attachment: SOLR-6706.patch
Test to reproduce this bug.
/update/json/docs throws RuntimeException if a nested structure contains a
non-leaf float field
---
Key: SOLR-6706
URL: https://issues.apache.org/jira/browse/SOLR-6706
Project: Solr
Issue Type: Bug
Components: update
Affects Versions: 4.10.2, 5.0, Trunk
Reporter: Shalin Shekhar Mangar
Fix For: 5.0, Trunk
Attachments: SOLR-6706.patch
The following JSON throws an exception:
{code}
{
a_string : abc,
a_num : 2.0,
a : {
b : [
{id:1, title : test1},
{id:2, title : test2}
]
}
}
{code}
{code}
curl
'http://localhost:8983/solr/collection1/update/json/docs?split=/a/bf=id:/a/b/idf=title_s:/a/b/titleindent=on'
-H 'Content-type:application/json' -d @test2.json
{
responseHeader:{
status:500,
QTime:0},
error:{
msg:unexpected token 3,
trace:java.lang.RuntimeException: unexpected token 3\n\tat
org.apache.solr.common.util.JsonRecordReader$Node.handleObjectStart(JsonRecordReader.java:400)\n\tat
org.apache.solr.common.util.JsonRecordReader$Node.parse(JsonRecordReader.java:281)\n\tat
org.apache.solr.common.util.JsonRecordReader$Node.access$200(JsonRecordReader.java:152)\n\tat
org.apache.solr.common.util.JsonRecordReader.streamRecords(JsonRecordReader.java:136)\n\tat
org.apache.solr.handler.loader.JsonLoader$SingleThreadedJsonLoader.handleSplitMode(JsonLoader.java:200)\n\tat
org.apache.solr.handler.loader.JsonLoader$SingleThreadedJsonLoader.processUpdate(JsonLoader.java:120)\n\tat
org.apache.solr.handler.loader.JsonLoader$SingleThreadedJsonLoader.load(JsonLoader.java:106)\n\tat
org.apache.solr.handler.loader.JsonLoader.load(JsonLoader.java:68)\n\tat
org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:99)\n\tat
org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:74)\n\tat
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)\n\tat
org.apache.solr.core.SolrCore.execute(SolrCore.java:1967)\n\tat
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:777)\n\tat
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:418)\n\tat
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:207)\n\tat
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)\n\tat
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)\n\tat
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)\n\tat
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)\n\tat
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)\n\tat
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)\n\tat
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)\n\tat
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)\n\tat
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)\n\tat
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)\n\tat
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)\n\tat
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)\n\tat
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)\n\tat
org.eclipse.jetty.server.Server.handle(Server.java:368)\n\tat
org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)\n\tat
org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53)\n\tat
org.eclipse.jetty.server.AbstractHttpConnection.content(AbstractHttpConnection.java:953)\n\tat
org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.content(AbstractHttpConnection.java:1014)\n\tat
org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:861)\n\tat
org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:240)\n\tat
org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72)\n\tat
org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264)\n\tat
[jira] [Assigned] (SOLR-6706) /update/json/docs throws RuntimeException if a nested structure contains a non-leaf float field
[
https://issues.apache.org/jira/browse/SOLR-6706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul reassigned SOLR-6706:
Assignee: Noble Paul
/update/json/docs throws RuntimeException if a nested structure contains a
non-leaf float field
---
Key: SOLR-6706
URL: https://issues.apache.org/jira/browse/SOLR-6706
Project: Solr
Issue Type: Bug
Components: update
Affects Versions: 4.10.2, 5.0, Trunk
Reporter: Shalin Shekhar Mangar
Assignee: Noble Paul
Fix For: 5.0, Trunk
Attachments: SOLR-6706.patch
The following JSON throws an exception:
{code}
{
a_string : abc,
a_num : 2.0,
a : {
b : [
{id:1, title : test1},
{id:2, title : test2}
]
}
}
{code}
{code}
curl
'http://localhost:8983/solr/collection1/update/json/docs?split=/a/bf=id:/a/b/idf=title_s:/a/b/titleindent=on'
-H 'Content-type:application/json' -d @test2.json
{
responseHeader:{
status:500,
QTime:0},
error:{
msg:unexpected token 3,
trace:java.lang.RuntimeException: unexpected token 3\n\tat
org.apache.solr.common.util.JsonRecordReader$Node.handleObjectStart(JsonRecordReader.java:400)\n\tat
org.apache.solr.common.util.JsonRecordReader$Node.parse(JsonRecordReader.java:281)\n\tat
org.apache.solr.common.util.JsonRecordReader$Node.access$200(JsonRecordReader.java:152)\n\tat
org.apache.solr.common.util.JsonRecordReader.streamRecords(JsonRecordReader.java:136)\n\tat
org.apache.solr.handler.loader.JsonLoader$SingleThreadedJsonLoader.handleSplitMode(JsonLoader.java:200)\n\tat
org.apache.solr.handler.loader.JsonLoader$SingleThreadedJsonLoader.processUpdate(JsonLoader.java:120)\n\tat
org.apache.solr.handler.loader.JsonLoader$SingleThreadedJsonLoader.load(JsonLoader.java:106)\n\tat
org.apache.solr.handler.loader.JsonLoader.load(JsonLoader.java:68)\n\tat
org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:99)\n\tat
org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:74)\n\tat
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)\n\tat
org.apache.solr.core.SolrCore.execute(SolrCore.java:1967)\n\tat
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:777)\n\tat
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:418)\n\tat
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:207)\n\tat
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)\n\tat
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)\n\tat
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)\n\tat
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)\n\tat
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)\n\tat
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)\n\tat
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)\n\tat
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)\n\tat
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)\n\tat
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)\n\tat
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)\n\tat
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)\n\tat
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)\n\tat
org.eclipse.jetty.server.Server.handle(Server.java:368)\n\tat
org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)\n\tat
org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53)\n\tat
org.eclipse.jetty.server.AbstractHttpConnection.content(AbstractHttpConnection.java:953)\n\tat
org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.content(AbstractHttpConnection.java:1014)\n\tat
org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:861)\n\tat
org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:240)\n\tat
org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72)\n\tat
org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264)\n\tat
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)\n\tat
[jira] [Commented] (SOLR-6058) Solr needs a new website
[ https://issues.apache.org/jira/browse/SOLR-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14198527#comment-14198527 ] ASF subversion and git services commented on SOLR-6058: --- Commit 1636899 from [~gsingers] in branch 'cms/branches/solr_6058' [ https://svn.apache.org/r1636899 ] SOLR-6058: better handling of latest version Solr needs a new website Key: SOLR-6058 URL: https://issues.apache.org/jira/browse/SOLR-6058 Project: Solr Issue Type: Task Reporter: Grant Ingersoll Assignee: Grant Ingersoll Attachments: HTML.rar, SOLR-6058, SOLR-6058.location-fix.patchfile, SOLR-6058.offset-fix.patch, Solr_Icons.pdf, Solr_Logo_on_black.pdf, Solr_Logo_on_black.png, Solr_Logo_on_orange.pdf, Solr_Logo_on_orange.png, Solr_Logo_on_white.pdf, Solr_Logo_on_white.png, Solr_Styleguide.pdf Solr needs a new website: better organization of content, less verbose, more pleasing graphics, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6706) /update/json/docs throws RuntimeException if a nested structure contains a non-leaf float field
[
https://issues.apache.org/jira/browse/SOLR-6706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14198529#comment-14198529
]
ASF subversion and git services commented on SOLR-6706:
---
Commit 1636900 from [~noble.paul] in branch 'dev/trunk'
[ https://svn.apache.org/r1636900 ]
SOLR-6706
/update/json/docs throws RuntimeException if a nested structure contains a
non-leaf float field
---
Key: SOLR-6706
URL: https://issues.apache.org/jira/browse/SOLR-6706
Project: Solr
Issue Type: Bug
Components: update
Affects Versions: 4.10.2, 5.0, Trunk
Reporter: Shalin Shekhar Mangar
Assignee: Noble Paul
Fix For: 5.0, Trunk
Attachments: SOLR-6706.patch
The following JSON throws an exception:
{code}
{
a_string : abc,
a_num : 2.0,
a : {
b : [
{id:1, title : test1},
{id:2, title : test2}
]
}
}
{code}
{code}
curl
'http://localhost:8983/solr/collection1/update/json/docs?split=/a/bf=id:/a/b/idf=title_s:/a/b/titleindent=on'
-H 'Content-type:application/json' -d @test2.json
{
responseHeader:{
status:500,
QTime:0},
error:{
msg:unexpected token 3,
trace:java.lang.RuntimeException: unexpected token 3\n\tat
org.apache.solr.common.util.JsonRecordReader$Node.handleObjectStart(JsonRecordReader.java:400)\n\tat
org.apache.solr.common.util.JsonRecordReader$Node.parse(JsonRecordReader.java:281)\n\tat
org.apache.solr.common.util.JsonRecordReader$Node.access$200(JsonRecordReader.java:152)\n\tat
org.apache.solr.common.util.JsonRecordReader.streamRecords(JsonRecordReader.java:136)\n\tat
org.apache.solr.handler.loader.JsonLoader$SingleThreadedJsonLoader.handleSplitMode(JsonLoader.java:200)\n\tat
org.apache.solr.handler.loader.JsonLoader$SingleThreadedJsonLoader.processUpdate(JsonLoader.java:120)\n\tat
org.apache.solr.handler.loader.JsonLoader$SingleThreadedJsonLoader.load(JsonLoader.java:106)\n\tat
org.apache.solr.handler.loader.JsonLoader.load(JsonLoader.java:68)\n\tat
org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:99)\n\tat
org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:74)\n\tat
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)\n\tat
org.apache.solr.core.SolrCore.execute(SolrCore.java:1967)\n\tat
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:777)\n\tat
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:418)\n\tat
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:207)\n\tat
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)\n\tat
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)\n\tat
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)\n\tat
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)\n\tat
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)\n\tat
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)\n\tat
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)\n\tat
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)\n\tat
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)\n\tat
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)\n\tat
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)\n\tat
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)\n\tat
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)\n\tat
org.eclipse.jetty.server.Server.handle(Server.java:368)\n\tat
org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)\n\tat
org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53)\n\tat
org.eclipse.jetty.server.AbstractHttpConnection.content(AbstractHttpConnection.java:953)\n\tat
org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.content(AbstractHttpConnection.java:1014)\n\tat
org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:861)\n\tat
org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:240)\n\tat
org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72)\n\tat
[jira] [Commented] (SOLR-6058) Solr needs a new website
[ https://issues.apache.org/jira/browse/SOLR-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14198534#comment-14198534 ] ASF subversion and git services commented on SOLR-6058: --- Commit 1636901 from [~gsingers] in branch 'cms/branches/solr_6058' [ https://svn.apache.org/r1636901 ] SOLR-6058: ref guide links Solr needs a new website Key: SOLR-6058 URL: https://issues.apache.org/jira/browse/SOLR-6058 Project: Solr Issue Type: Task Reporter: Grant Ingersoll Assignee: Grant Ingersoll Attachments: HTML.rar, SOLR-6058, SOLR-6058.location-fix.patchfile, SOLR-6058.offset-fix.patch, Solr_Icons.pdf, Solr_Logo_on_black.pdf, Solr_Logo_on_black.png, Solr_Logo_on_orange.pdf, Solr_Logo_on_orange.png, Solr_Logo_on_white.pdf, Solr_Logo_on_white.png, Solr_Styleguide.pdf Solr needs a new website: better organization of content, less verbose, more pleasing graphics, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6706) /update/json/docs throws RuntimeException if a nested structure contains a non-leaf float field
[
https://issues.apache.org/jira/browse/SOLR-6706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14198538#comment-14198538
]
ASF subversion and git services commented on SOLR-6706:
---
Commit 1636904 from [~noble.paul] in branch 'dev/trunk'
[ https://svn.apache.org/r1636904 ]
SOLR-6706 missed changes.txt
/update/json/docs throws RuntimeException if a nested structure contains a
non-leaf float field
---
Key: SOLR-6706
URL: https://issues.apache.org/jira/browse/SOLR-6706
Project: Solr
Issue Type: Bug
Components: update
Affects Versions: 4.10.2, 5.0, Trunk
Reporter: Shalin Shekhar Mangar
Assignee: Noble Paul
Fix For: 5.0, Trunk
Attachments: SOLR-6706.patch
The following JSON throws an exception:
{code}
{
a_string : abc,
a_num : 2.0,
a : {
b : [
{id:1, title : test1},
{id:2, title : test2}
]
}
}
{code}
{code}
curl
'http://localhost:8983/solr/collection1/update/json/docs?split=/a/bf=id:/a/b/idf=title_s:/a/b/titleindent=on'
-H 'Content-type:application/json' -d @test2.json
{
responseHeader:{
status:500,
QTime:0},
error:{
msg:unexpected token 3,
trace:java.lang.RuntimeException: unexpected token 3\n\tat
org.apache.solr.common.util.JsonRecordReader$Node.handleObjectStart(JsonRecordReader.java:400)\n\tat
org.apache.solr.common.util.JsonRecordReader$Node.parse(JsonRecordReader.java:281)\n\tat
org.apache.solr.common.util.JsonRecordReader$Node.access$200(JsonRecordReader.java:152)\n\tat
org.apache.solr.common.util.JsonRecordReader.streamRecords(JsonRecordReader.java:136)\n\tat
org.apache.solr.handler.loader.JsonLoader$SingleThreadedJsonLoader.handleSplitMode(JsonLoader.java:200)\n\tat
org.apache.solr.handler.loader.JsonLoader$SingleThreadedJsonLoader.processUpdate(JsonLoader.java:120)\n\tat
org.apache.solr.handler.loader.JsonLoader$SingleThreadedJsonLoader.load(JsonLoader.java:106)\n\tat
org.apache.solr.handler.loader.JsonLoader.load(JsonLoader.java:68)\n\tat
org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:99)\n\tat
org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:74)\n\tat
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)\n\tat
org.apache.solr.core.SolrCore.execute(SolrCore.java:1967)\n\tat
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:777)\n\tat
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:418)\n\tat
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:207)\n\tat
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)\n\tat
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)\n\tat
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)\n\tat
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)\n\tat
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)\n\tat
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)\n\tat
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)\n\tat
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)\n\tat
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)\n\tat
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)\n\tat
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)\n\tat
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)\n\tat
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)\n\tat
org.eclipse.jetty.server.Server.handle(Server.java:368)\n\tat
org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)\n\tat
org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53)\n\tat
org.eclipse.jetty.server.AbstractHttpConnection.content(AbstractHttpConnection.java:953)\n\tat
org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.content(AbstractHttpConnection.java:1014)\n\tat
org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:861)\n\tat
org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:240)\n\tat
org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72)\n\tat
[jira] [Resolved] (SOLR-6706) /update/json/docs throws RuntimeException if a nested structure contains a non-leaf float field
[
https://issues.apache.org/jira/browse/SOLR-6706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul resolved SOLR-6706.
--
Resolution: Fixed
/update/json/docs throws RuntimeException if a nested structure contains a
non-leaf float field
---
Key: SOLR-6706
URL: https://issues.apache.org/jira/browse/SOLR-6706
Project: Solr
Issue Type: Bug
Components: update
Affects Versions: 4.10.2, 5.0, Trunk
Reporter: Shalin Shekhar Mangar
Assignee: Noble Paul
Fix For: 5.0, Trunk
Attachments: SOLR-6706.patch
The following JSON throws an exception:
{code}
{
a_string : abc,
a_num : 2.0,
a : {
b : [
{id:1, title : test1},
{id:2, title : test2}
]
}
}
{code}
{code}
curl
'http://localhost:8983/solr/collection1/update/json/docs?split=/a/bf=id:/a/b/idf=title_s:/a/b/titleindent=on'
-H 'Content-type:application/json' -d @test2.json
{
responseHeader:{
status:500,
QTime:0},
error:{
msg:unexpected token 3,
trace:java.lang.RuntimeException: unexpected token 3\n\tat
org.apache.solr.common.util.JsonRecordReader$Node.handleObjectStart(JsonRecordReader.java:400)\n\tat
org.apache.solr.common.util.JsonRecordReader$Node.parse(JsonRecordReader.java:281)\n\tat
org.apache.solr.common.util.JsonRecordReader$Node.access$200(JsonRecordReader.java:152)\n\tat
org.apache.solr.common.util.JsonRecordReader.streamRecords(JsonRecordReader.java:136)\n\tat
org.apache.solr.handler.loader.JsonLoader$SingleThreadedJsonLoader.handleSplitMode(JsonLoader.java:200)\n\tat
org.apache.solr.handler.loader.JsonLoader$SingleThreadedJsonLoader.processUpdate(JsonLoader.java:120)\n\tat
org.apache.solr.handler.loader.JsonLoader$SingleThreadedJsonLoader.load(JsonLoader.java:106)\n\tat
org.apache.solr.handler.loader.JsonLoader.load(JsonLoader.java:68)\n\tat
org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:99)\n\tat
org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:74)\n\tat
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)\n\tat
org.apache.solr.core.SolrCore.execute(SolrCore.java:1967)\n\tat
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:777)\n\tat
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:418)\n\tat
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:207)\n\tat
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)\n\tat
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)\n\tat
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)\n\tat
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)\n\tat
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)\n\tat
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)\n\tat
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)\n\tat
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)\n\tat
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)\n\tat
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)\n\tat
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)\n\tat
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)\n\tat
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)\n\tat
org.eclipse.jetty.server.Server.handle(Server.java:368)\n\tat
org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)\n\tat
org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53)\n\tat
org.eclipse.jetty.server.AbstractHttpConnection.content(AbstractHttpConnection.java:953)\n\tat
org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.content(AbstractHttpConnection.java:1014)\n\tat
org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:861)\n\tat
org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:240)\n\tat
org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72)\n\tat
org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264)\n\tat
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)\n\tat
[jira] [Commented] (SOLR-6706) /update/json/docs throws RuntimeException if a nested structure contains a non-leaf float field
[
https://issues.apache.org/jira/browse/SOLR-6706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14198542#comment-14198542
]
ASF subversion and git services commented on SOLR-6706:
---
Commit 1636905 from [~noble.paul] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1636905 ]
SOLR-6706
/update/json/docs throws RuntimeException if a nested structure contains a
non-leaf float field
---
Key: SOLR-6706
URL: https://issues.apache.org/jira/browse/SOLR-6706
Project: Solr
Issue Type: Bug
Components: update
Affects Versions: 4.10.2, 5.0, Trunk
Reporter: Shalin Shekhar Mangar
Assignee: Noble Paul
Fix For: 5.0, Trunk
Attachments: SOLR-6706.patch
The following JSON throws an exception:
{code}
{
a_string : abc,
a_num : 2.0,
a : {
b : [
{id:1, title : test1},
{id:2, title : test2}
]
}
}
{code}
{code}
curl
'http://localhost:8983/solr/collection1/update/json/docs?split=/a/bf=id:/a/b/idf=title_s:/a/b/titleindent=on'
-H 'Content-type:application/json' -d @test2.json
{
responseHeader:{
status:500,
QTime:0},
error:{
msg:unexpected token 3,
trace:java.lang.RuntimeException: unexpected token 3\n\tat
org.apache.solr.common.util.JsonRecordReader$Node.handleObjectStart(JsonRecordReader.java:400)\n\tat
org.apache.solr.common.util.JsonRecordReader$Node.parse(JsonRecordReader.java:281)\n\tat
org.apache.solr.common.util.JsonRecordReader$Node.access$200(JsonRecordReader.java:152)\n\tat
org.apache.solr.common.util.JsonRecordReader.streamRecords(JsonRecordReader.java:136)\n\tat
org.apache.solr.handler.loader.JsonLoader$SingleThreadedJsonLoader.handleSplitMode(JsonLoader.java:200)\n\tat
org.apache.solr.handler.loader.JsonLoader$SingleThreadedJsonLoader.processUpdate(JsonLoader.java:120)\n\tat
org.apache.solr.handler.loader.JsonLoader$SingleThreadedJsonLoader.load(JsonLoader.java:106)\n\tat
org.apache.solr.handler.loader.JsonLoader.load(JsonLoader.java:68)\n\tat
org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:99)\n\tat
org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:74)\n\tat
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)\n\tat
org.apache.solr.core.SolrCore.execute(SolrCore.java:1967)\n\tat
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:777)\n\tat
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:418)\n\tat
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:207)\n\tat
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)\n\tat
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)\n\tat
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)\n\tat
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)\n\tat
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)\n\tat
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)\n\tat
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)\n\tat
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)\n\tat
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)\n\tat
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)\n\tat
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)\n\tat
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)\n\tat
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)\n\tat
org.eclipse.jetty.server.Server.handle(Server.java:368)\n\tat
org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)\n\tat
org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53)\n\tat
org.eclipse.jetty.server.AbstractHttpConnection.content(AbstractHttpConnection.java:953)\n\tat
org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.content(AbstractHttpConnection.java:1014)\n\tat
org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:861)\n\tat
org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:240)\n\tat
org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72)\n\tat
[jira] [Created] (LUCENE-6050) Add possibility to specify SHOUD or MUST for each context for AnalyzingInfixSuggester.loockup()
Arcadius Ahouansou created LUCENE-6050:
--
Summary: Add possibility to specify SHOUD or MUST for each context
for AnalyzingInfixSuggester.loockup()
Key: LUCENE-6050
URL: https://issues.apache.org/jira/browse/LUCENE-6050
Project: Lucene - Core
Issue Type: Bug
Affects Versions: 4.10.2
Reporter: Arcadius Ahouansou
Priority: Minor
Currently
{code}
lookup(CharSequence key, SetBytesRef contexts, int num, boolean
allTermsRequired, boolean doHighlight, boolean allContextsRequired)
{code}
applies *SHOULD* to all contexts.
We need the ability to specify whether it's a *SHOULD* or a *MUST* on each
individual context.
Thanks
Arcadius.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5528) Add context to AnalyzingInfixSuggester
[ https://issues.apache.org/jira/browse/LUCENE-5528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14198545#comment-14198545 ] Arcadius Ahouansou commented on LUCENE-5528: Hi [~mikemccand]. The new issue is LUCENE-6050 Thanks. Add context to AnalyzingInfixSuggester -- Key: LUCENE-5528 URL: https://issues.apache.org/jira/browse/LUCENE-5528 Project: Lucene - Core Issue Type: Improvement Reporter: Michael McCandless Assignee: Michael McCandless Fix For: 4.8, Trunk Attachments: LUCENE-5528-1.patch, LUCENE-5528-1.patch, LUCENE-5528-1.patch, LUCENE-5528-1.patch, LUCENE-5528.patch, LUCENE-5528.patch, contextInputIteratImpl.patch Spinoff from LUCENE-5350. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Crazy Solr startup params, please review
Hi, I just reviewed the solr.sh.in and solr.cmd.in scripts in solr/bin folder. The following was committed but never discussed: # These GC settings have shown to work well for a number of common Solr workloads GC_TUNE=-XX:-UseSuperWord \ -XX:NewRatio=3 \ -XX:SurvivorRatio=4 \ -XX:TargetSurvivorRatio=90 \ -XX:MaxTenuringThreshold=8 \ -XX:+UseConcMarkSweepGC \ -XX:+UseParNewGC \ -XX:ConcGCThreads=4 -XX:ParallelGCThreads=4 \ -XX:+CMSScavengeBeforeRemark \ -XX:PretenureSizeThreshold=64m \ -XX:CMSFullGCsBeforeCompaction=1 \ -XX:+UseCMSInitiatingOccupancyOnly \ -XX:CMSInitiatingOccupancyFraction=50 \ -XX:CMSTriggerPermRatio=80 \ -XX:CMSMaxAbortablePrecleanTime=6000 \ -XX:+CMSParallelRemarkEnabled \ -XX:+ParallelRefProcEnabled \ -XX:+AggressiveOpts This is horrible, because of our experience with Hotspot bugs: -XX:+AggressiveOpts This option is vry risky and speed improvements are marginal. PLEASE DON'T DO THIS. If people want the new features they should wait for later Java releases and the new features are tested. See several tasks about the Java 7 disaster! In fact we had reports at Java 6 times when people had enabled this and were affected by the Java 7 GA bugs already in Java 6 and corrupted their indexes!!! -XX:-UseSuperWord If you have a Haswell CPU, all other improvements in these command line settings are eaten up by this flag! If you have 7u55 at minimum, you should never disable this. Things like BooleanFilter and other bitset operations are up to 2 times faster with Java 7u55 on Haswell CPUs and later!!! This setting only makes sense if you have one of those buggy JDKs (7u40 to 7u51). In all other cases this slows down enormous! In addition, enabling this option may break JDKs before 7u40 (this option was added in 7u40), so breaks: Unrecognized VM option 'UseSuperWord' It would be good, if we could fix the startup scripts not not have options, which may also break with JDK 8 or later! Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6058) Solr needs a new website
[ https://issues.apache.org/jira/browse/SOLR-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14198548#comment-14198548 ] Grant Ingersoll commented on SOLR-6058: --- [~sbower] any luck on the logo permission? We'd like to go live by this weekend. At some level, the fact that Bloomberg is a Solr user is a factual statement and doesn't require permission since it is public knowledge based off presentations, etc., but I do understand the use of a logo may not be the equivalent to that, so I'd rather make sure Bloomberg is OK with it. I can remove it if we can't get permission in time or we can switch to a factual statement. FWIW, I'd love to put highlight Bloomberg as a Solr case study somewhere on the Solr site if you are willing to do so. Solr needs a new website Key: SOLR-6058 URL: https://issues.apache.org/jira/browse/SOLR-6058 Project: Solr Issue Type: Task Reporter: Grant Ingersoll Assignee: Grant Ingersoll Attachments: HTML.rar, SOLR-6058, SOLR-6058.location-fix.patchfile, SOLR-6058.offset-fix.patch, Solr_Icons.pdf, Solr_Logo_on_black.pdf, Solr_Logo_on_black.png, Solr_Logo_on_orange.pdf, Solr_Logo_on_orange.png, Solr_Logo_on_white.pdf, Solr_Logo_on_white.png, Solr_Styleguide.pdf Solr needs a new website: better organization of content, less verbose, more pleasing graphics, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6698) Solr is not consistent wrt ZkCredentialsProvider / ZkCredentialProvider
[ https://issues.apache.org/jira/browse/SOLR-6698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14198557#comment-14198557 ] Mark Miller commented on SOLR-6698: --- +1 - remember to call it out in the CHANGES upgrade section when you add the CHANGES entry. Solr is not consistent wrt ZkCredentialsProvider / ZkCredentialProvider --- Key: SOLR-6698 URL: https://issues.apache.org/jira/browse/SOLR-6698 Project: Solr Issue Type: Bug Components: SolrCloud Reporter: Gregory Chanan Priority: Minor Attachments: SOLR-6698.patch Solr uses ZkCredentialsProvider / ZkCredentialProvider in inconsistent ways. For example, in the configs it's referred to as zkCredentialProvider https://github.com/apache/lucene-solr/blob/6dd0103c8130e6207151fa5c2f9ccfcfe9500c59/solr/core/src/java/org/apache/solr/core/ConfigSolrXml.java#L168 but the cloud scripts show it as zkCredentialsProvider (wrong): https://github.com/apache/lucene-solr/blob/6dd0103c8130e6207151fa5c2f9ccfcfe9500c59/solr/cloud-dev/solrcloud-start.sh#L7 The implementations refer to ZkCredentialsProvider, i.e.: https://github.com/apache/lucene-solr/blob/6dd0103c8130e6207151fa5c2f9ccfcfe9500c59/solr/solrj/src/java/org/apache/solr/common/cloud/ZkCredentialsProvider.java it would be good to be consistent here. I don't have a preference for which name to use. Unless we want to put in some code to handle old versions, it seems like we need to break compatibility (i.e. either rename the config names or the names of the implementing classes). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request: clarified the Sort(Sortfield...) constru...
Github user s4ke commented on the pull request: https://github.com/apache/lucene-solr/pull/20#issuecomment-61830995 Ok thanks. :) --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-NightlyTests-trunk - Build # 676 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-trunk/676/
1 tests failed.
REGRESSION:
org.apache.solr.handler.TestReplicationHandler.doTestReplicateAfterCoreReload
Error Message:
expected:[{indexVersion=1415200512131,generation=2,filelist=[_wo.fdt, _wo.fdx,
_wo.fnm, _wo.nvd, _wo.nvm, _wo.si, _wo_Memory_0.ram, _wp.cfe, _wp.cfs, _wp.si,
_wq.fdt, _wq.fdx, _wq.fnm, _wq.nvd, _wq.nvm, _wq.si, _wq_Memory_0.ram, _wr.fdt,
_wr.fdx, _wr.fnm, _wr.nvd, _wr.nvm, _wr.si, _wr_Memory_0.ram, _ws.fdt, _ws.fdx,
_ws.fnm, _ws.nvd, _ws.nvm, _ws.si, _ws_Memory_0.ram, _wt.fdt, _wt.fdx, _wt.fnm,
_wt.nvd, _wt.nvm, _wt.si, _wt_Memory_0.ram, _wu.fdt, _wu.fdx, _wu.fnm, _wu.nvd,
_wu.nvm, _wu.si, _wu_Memory_0.ram, _wv.fdt, _wv.fdx, _wv.fnm, _wv.nvd, _wv.nvm,
_wv.si, _wv_Memory_0.ram, _ww.fdt, _ww.fdx, _ww.fnm, _ww.nvd, _ww.nvm, _ww.si,
_ww_Memory_0.ram, _wx.fdt, _wx.fdx, _wx.fnm, _wx.nvd, _wx.nvm, _wx.si,
_wx_Memory_0.ram, _wy.fdt, _wy.fdx, _wy.fnm, _wy.nvd, _wy.nvm, _wy.si,
_wy_Memory_0.ram, _wz.fdt, _wz.fdx, _wz.fnm, _wz.nvd, _wz.nvm, _wz.si,
_wz_Memory_0.ram, _x0.fdt, _x0.fdx, _x0.fnm, _x0.nvd, _x0.nvm, _x0.si,
_x0_Memory_0.ram, _x1.fdt, _x1.fdx, _x1.fnm, _x1.nvd, _x1.nvm, _x1.si,
_x1_Memory_0.ram, _x2.fdt, _x2.fdx, _x2.fnm, _x2.nvd, _x2.nvm, _x2.si,
_x2_Memory_0.ram, _x3.fdt, _x3.fdx, _x3.fnm, _x3.nvd, _x3.nvm, _x3.si,
_x3_Memory_0.ram, _x4.fdt, _x4.fdx, _x4.fnm, _x4.nvd, _x4.nvm, _x4.si,
_x4_Memory_0.ram, _x5.fdt, _x5.fdx, _x5.fnm, _x5.nvd, _x5.nvm, _x5.si,
_x5_Memory_0.ram, _x6.fdt, _x6.fdx, _x6.fnm, _x6.nvd, _x6.nvm, _x6.si,
_x6_Memory_0.ram, _x7.fdt, _x7.fdx, _x7.fnm, _x7.nvd, _x7.nvm, _x7.si,
_x7_Memory_0.ram, _x8.fdt, _x8.fdx, _x8.fnm, _x8.nvd, _x8.nvm, _x8.si,
_x8_Memory_0.ram, _x9.fdt, _x9.fdx, _x9.fnm, _x9.nvd, _x9.nvm, _x9.si,
_x9_Memory_0.ram, _xb.fdt, _xb.fdx, _xb.fnm, _xb.nvd, _xb.nvm, _xb.si,
_xb_Memory_0.ram, segments_2]}] but
was:[{indexVersion=1415200512131,generation=3,filelist=[_x9.fdt, _x9.fdx,
_x9.fnm, _x9.nvd, _x9.nvm, _x9.si, _x9_Memory_0.ram, _xa.cfe, _xa.cfs, _xa.si,
_xb.fdt, _xb.fdx, _xb.fnm, _xb.nvd, _xb.nvm, _xb.si, _xb_Memory_0.ram,
segments_3]}, {indexVersion=1415200512131,generation=2,filelist=[_wo.fdt,
_wo.fdx, _wo.fnm, _wo.nvd, _wo.nvm, _wo.si, _wo_Memory_0.ram, _wp.cfe, _wp.cfs,
_wp.si, _wq.fdt, _wq.fdx, _wq.fnm, _wq.nvd, _wq.nvm, _wq.si, _wq_Memory_0.ram,
_wr.fdt, _wr.fdx, _wr.fnm, _wr.nvd, _wr.nvm, _wr.si, _wr_Memory_0.ram, _ws.fdt,
_ws.fdx, _ws.fnm, _ws.nvd, _ws.nvm, _ws.si, _ws_Memory_0.ram, _wt.fdt, _wt.fdx,
_wt.fnm, _wt.nvd, _wt.nvm, _wt.si, _wt_Memory_0.ram, _wu.fdt, _wu.fdx, _wu.fnm,
_wu.nvd, _wu.nvm, _wu.si, _wu_Memory_0.ram, _wv.fdt, _wv.fdx, _wv.fnm, _wv.nvd,
_wv.nvm, _wv.si, _wv_Memory_0.ram, _ww.fdt, _ww.fdx, _ww.fnm, _ww.nvd, _ww.nvm,
_ww.si, _ww_Memory_0.ram, _wx.fdt, _wx.fdx, _wx.fnm, _wx.nvd, _wx.nvm, _wx.si,
_wx_Memory_0.ram, _wy.fdt, _wy.fdx, _wy.fnm, _wy.nvd, _wy.nvm, _wy.si,
_wy_Memory_0.ram, _wz.fdt, _wz.fdx, _wz.fnm, _wz.nvd, _wz.nvm, _wz.si,
_wz_Memory_0.ram, _x0.fdt, _x0.fdx, _x0.fnm, _x0.nvd, _x0.nvm, _x0.si,
_x0_Memory_0.ram, _x1.fdt, _x1.fdx, _x1.fnm, _x1.nvd, _x1.nvm, _x1.si,
_x1_Memory_0.ram, _x2.fdt, _x2.fdx, _x2.fnm, _x2.nvd, _x2.nvm, _x2.si,
_x2_Memory_0.ram, _x3.fdt, _x3.fdx, _x3.fnm, _x3.nvd, _x3.nvm, _x3.si,
_x3_Memory_0.ram, _x4.fdt, _x4.fdx, _x4.fnm, _x4.nvd, _x4.nvm, _x4.si,
_x4_Memory_0.ram, _x5.fdt, _x5.fdx, _x5.fnm, _x5.nvd, _x5.nvm, _x5.si,
_x5_Memory_0.ram, _x6.fdt, _x6.fdx, _x6.fnm, _x6.nvd, _x6.nvm, _x6.si,
_x6_Memory_0.ram, _x7.fdt, _x7.fdx, _x7.fnm, _x7.nvd, _x7.nvm, _x7.si,
_x7_Memory_0.ram, _x8.fdt, _x8.fdx, _x8.fnm, _x8.nvd, _x8.nvm, _x8.si,
_x8_Memory_0.ram, _x9.fdt, _x9.fdx, _x9.fnm, _x9.nvd, _x9.nvm, _x9.si,
_x9_Memory_0.ram, _xb.fdt, _xb.fdx, _xb.fnm, _xb.nvd, _xb.nvm, _xb.si,
_xb_Memory_0.ram, segments_2]}]
Stack Trace:
java.lang.AssertionError:
expected:[{indexVersion=1415200512131,generation=2,filelist=[_wo.fdt, _wo.fdx,
_wo.fnm, _wo.nvd, _wo.nvm, _wo.si, _wo_Memory_0.ram, _wp.cfe, _wp.cfs, _wp.si,
_wq.fdt, _wq.fdx, _wq.fnm, _wq.nvd, _wq.nvm, _wq.si, _wq_Memory_0.ram, _wr.fdt,
_wr.fdx, _wr.fnm, _wr.nvd, _wr.nvm, _wr.si, _wr_Memory_0.ram, _ws.fdt, _ws.fdx,
_ws.fnm, _ws.nvd, _ws.nvm, _ws.si, _ws_Memory_0.ram, _wt.fdt, _wt.fdx, _wt.fnm,
_wt.nvd, _wt.nvm, _wt.si, _wt_Memory_0.ram, _wu.fdt, _wu.fdx, _wu.fnm, _wu.nvd,
_wu.nvm, _wu.si, _wu_Memory_0.ram, _wv.fdt, _wv.fdx, _wv.fnm, _wv.nvd, _wv.nvm,
_wv.si, _wv_Memory_0.ram, _ww.fdt, _ww.fdx, _ww.fnm, _ww.nvd, _ww.nvm, _ww.si,
_ww_Memory_0.ram, _wx.fdt, _wx.fdx, _wx.fnm, _wx.nvd, _wx.nvm, _wx.si,
_wx_Memory_0.ram, _wy.fdt, _wy.fdx, _wy.fnm, _wy.nvd, _wy.nvm, _wy.si,
_wy_Memory_0.ram, _wz.fdt, _wz.fdx, _wz.fnm, _wz.nvd, _wz.nvm, _wz.si,
_wz_Memory_0.ram, _x0.fdt, _x0.fdx, _x0.fnm, _x0.nvd, _x0.nvm, _x0.si,
_x0_Memory_0.ram, _x1.fdt, _x1.fdx, _x1.fnm, _x1.nvd, _x1.nvm, _x1.si,
_x1_Memory_0.ram, _x2.fdt, _x2.fdx, _x2.fnm, _x2.nvd, _x2.nvm, _x2.si,
_x2_Memory_0.ram, _x3.fdt, _x3.fdx, _x3.fnm, _x3.nvd, _x3.nvm, _x3.si,
[jira] [Commented] (SOLR-6654) add a standard way to listen to config changes in cloud mode
[ https://issues.apache.org/jira/browse/SOLR-6654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14198566#comment-14198566 ] Mark Miller commented on SOLR-6654: --- I also wish you would return to using commit messages beyond just the issue number as the rest of the project does. add a standard way to listen to config changes in cloud mode Key: SOLR-6654 URL: https://issues.apache.org/jira/browse/SOLR-6654 Project: Solr Issue Type: Sub-task Reporter: Noble Paul Assignee: Noble Paul -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: svn commit: r1636900 - in /lucene/dev/trunk/solr/solrj/src: java/org/apache/solr/common/util/JsonRecordReader.java test/org/apache/solr/common/util/TestJsonRecordReader.java
Noble: Any commit related to a Jira should mention thta jira # -- but
mentioning a Jira # by itself w/o any other info is not a helpful svn
message.
We should always be including a short descriptive message explaining
what/why we are making a change -- in every commit. if someone can't
think of a short summary that adequately captures things, then the commit
probably encompases too many things and should be done piece meal.
: Date: Wed, 05 Nov 2014 15:41:09 -
: From: no...@apache.org
: Reply-To: dev@lucene.apache.org
: To: comm...@lucene.apache.org
: Subject: svn commit: r1636900 - in /lucene/dev/trunk/solr/solrj/src:
: java/org/apache/solr/common/util/JsonRecordReader.java
: test/org/apache/solr/common/util/TestJsonRecordReader.java
:
: Author: noble
: Date: Wed Nov 5 15:41:08 2014
: New Revision: 1636900
:
: URL: http://svn.apache.org/r1636900
: Log:
: SOLR-6706
:
: Modified:
:
lucene/dev/trunk/solr/solrj/src/java/org/apache/solr/common/util/JsonRecordReader.java
:
lucene/dev/trunk/solr/solrj/src/test/org/apache/solr/common/util/TestJsonRecordReader.java
:
: Modified:
lucene/dev/trunk/solr/solrj/src/java/org/apache/solr/common/util/JsonRecordReader.java
: URL:
http://svn.apache.org/viewvc/lucene/dev/trunk/solr/solrj/src/java/org/apache/solr/common/util/JsonRecordReader.java?rev=1636900r1=1636899r2=1636900view=diff
: ==
: ---
lucene/dev/trunk/solr/solrj/src/java/org/apache/solr/common/util/JsonRecordReader.java
(original)
: +++
lucene/dev/trunk/solr/solrj/src/java/org/apache/solr/common/util/JsonRecordReader.java
Wed Nov 5 15:41:08 2014
: @@ -394,6 +394,7 @@ public class JsonRecordReader {
: event = parser.nextEvent();
: if (event == STRING ||
: event == LONG ||
: +event == NUMBER ||
: event == BIGNUMBER ||
: event == BOOLEAN ||
: event == NULL) {
:
: Modified:
lucene/dev/trunk/solr/solrj/src/test/org/apache/solr/common/util/TestJsonRecordReader.java
: URL:
http://svn.apache.org/viewvc/lucene/dev/trunk/solr/solrj/src/test/org/apache/solr/common/util/TestJsonRecordReader.java?rev=1636900r1=1636899r2=1636900view=diff
: ==
: ---
lucene/dev/trunk/solr/solrj/src/test/org/apache/solr/common/util/TestJsonRecordReader.java
(original)
: +++
lucene/dev/trunk/solr/solrj/src/test/org/apache/solr/common/util/TestJsonRecordReader.java
Wed Nov 5 15:41:08 2014
: @@ -180,7 +180,7 @@ public class TestJsonRecordReader exten
: records = streamer.getAllRecords(new StringReader(json));
: assertEquals(2, records.size());
: for (MapString, Object record : records) {
: - assertEquals(6,record.size());
: + assertEquals(6, record.size());
:assertTrue(record.containsKey(subject));
:assertTrue(record.containsKey(test));
:assertTrue(record.containsKey(marks));
: @@ -203,4 +203,24 @@ public class TestJsonRecordReader exten
:
:}
:
: + public void testNestedJsonWithFloats() throws Exception {
: +
: +String json = {\n +
: +\a_string\ : \abc\,\n +
: +\a_num\ : 2.0,\n +
: +\a\ : {\n +
: +\b\ : [\n +
: +{\id\:\1\, \title\ :
\test1\},\n +
: +{\id\:\2\, \title\ :
\test2\}\n +
: +]\n +
: +}\n +
: +}\n;
: +
: +JsonRecordReader streamer;
: +ListMapString, Object records;
: +
: +streamer = JsonRecordReader.getInst(/a/b,
Collections.singletonList(title_s:/a/b/title));
: +records = streamer.getAllRecords(new StringReader(json));
: +assertEquals(2, records.size());
: + }
: }
:
:
:
-Hoss
http://www.lucidworks.com/
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6058) Solr needs a new website
[ https://issues.apache.org/jira/browse/SOLR-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14198582#comment-14198582 ] ASF subversion and git services commented on SOLR-6058: --- Commit 1636912 from [~gsingers] in branch 'cms/branches/solr_6058' [ https://svn.apache.org/r1636912 ] SOLR-6058: powered by Solr needs a new website Key: SOLR-6058 URL: https://issues.apache.org/jira/browse/SOLR-6058 Project: Solr Issue Type: Task Reporter: Grant Ingersoll Assignee: Grant Ingersoll Attachments: HTML.rar, SOLR-6058, SOLR-6058.location-fix.patchfile, SOLR-6058.offset-fix.patch, Solr_Icons.pdf, Solr_Logo_on_black.pdf, Solr_Logo_on_black.png, Solr_Logo_on_orange.pdf, Solr_Logo_on_orange.png, Solr_Logo_on_white.pdf, Solr_Logo_on_white.png, Solr_Styleguide.pdf Solr needs a new website: better organization of content, less verbose, more pleasing graphics, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6058) Solr needs a new website
[ https://issues.apache.org/jira/browse/SOLR-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14198588#comment-14198588 ] Grant Ingersoll commented on SOLR-6058: --- OK, this is getting really close to done. I think we just have some issues left on the Detailed Features section and the tutorial for content. After that, a full read through, grammar, spelling, etc. and we are good to go. We also still need to figure out the links thing due to offsets on the main page (and other places, I presume) Pending those things completing, I intend to merge this to trunk and push this live over the weekend, as this has been baking for some time now and is very close to ready to go. We can always improve later. Solr needs a new website Key: SOLR-6058 URL: https://issues.apache.org/jira/browse/SOLR-6058 Project: Solr Issue Type: Task Reporter: Grant Ingersoll Assignee: Grant Ingersoll Attachments: HTML.rar, SOLR-6058, SOLR-6058.location-fix.patchfile, SOLR-6058.offset-fix.patch, Solr_Icons.pdf, Solr_Logo_on_black.pdf, Solr_Logo_on_black.png, Solr_Logo_on_orange.pdf, Solr_Logo_on_orange.png, Solr_Logo_on_white.pdf, Solr_Logo_on_white.png, Solr_Styleguide.pdf Solr needs a new website: better organization of content, less verbose, more pleasing graphics, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6040) Speedup broadword bit selection
[ https://issues.apache.org/jira/browse/LUCENE-6040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14198601#comment-14198601 ] ASF subversion and git services commented on LUCENE-6040: - Commit 1636913 from [~jpountz] in branch 'dev/trunk' [ https://svn.apache.org/r1636913 ] LUCENE-6040: Speedup broadword bit selection. Speedup broadword bit selection --- Key: LUCENE-6040 URL: https://issues.apache.org/jira/browse/LUCENE-6040 Project: Lucene - Core Issue Type: Improvement Components: core/other Reporter: Paul Elschot Priority: Minor Attachments: LUCENE-6040.patch, LUCENE-6040.patch Use table lookup instead of some broadword manipulations -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6040) Speedup broadword bit selection
[ https://issues.apache.org/jira/browse/LUCENE-6040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14198603#comment-14198603 ] ASF subversion and git services commented on LUCENE-6040: - Commit 1636914 from [~jpountz] in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1636914 ] LUCENE-6040: Speedup broadword bit selection. Speedup broadword bit selection --- Key: LUCENE-6040 URL: https://issues.apache.org/jira/browse/LUCENE-6040 Project: Lucene - Core Issue Type: Improvement Components: core/other Reporter: Paul Elschot Priority: Minor Attachments: LUCENE-6040.patch, LUCENE-6040.patch Use table lookup instead of some broadword manipulations -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-6040) Speedup broadword bit selection
[ https://issues.apache.org/jira/browse/LUCENE-6040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrien Grand resolved LUCENE-6040. -- Resolution: Fixed Fix Version/s: 5.0 This looks great, I just committed the patch. Thanks Paul! Speedup broadword bit selection --- Key: LUCENE-6040 URL: https://issues.apache.org/jira/browse/LUCENE-6040 Project: Lucene - Core Issue Type: Improvement Components: core/other Reporter: Paul Elschot Priority: Minor Fix For: 5.0 Attachments: LUCENE-6040.patch, LUCENE-6040.patch Use table lookup instead of some broadword manipulations -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2927) SolrIndexSearcher's register do not match close and SolrCore's closeSearcher
[ https://issues.apache.org/jira/browse/SOLR-2927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14198625#comment-14198625 ] Cyrille Roy commented on SOLR-2927: --- [~shalinmangar] I have some questions regarding the patch you provided. 1. I synced the trunk code and have some failures. I don't know how to check for trunk status other that rebuilding it (I did not find an url where we can check for trunk status) I updated the patch to have right after the closeHooks (line 1070) - ExecutorUtil.shutdown.AndAwaitTermination block - infoRegistry block With that, I have no more failures. This is the path I proposed in fact. I think it might be better to wait for searcherExecutor shutdown sooner than later because this thread can keep on doing some work whereas we are supposed to close the core. Thanks SolrIndexSearcher's register do not match close and SolrCore's closeSearcher Key: SOLR-2927 URL: https://issues.apache.org/jira/browse/SOLR-2927 Project: Solr Issue Type: Bug Components: search Affects Versions: 4.0-ALPHA Environment: JDK1.6/CentOS Reporter: tom liu Assignee: Shalin Shekhar Mangar Fix For: 5.0, Trunk Attachments: SOLR-2927.patch, mbean-leak-jira.png # SolrIndexSearcher's register method put the name of searcher, but SolrCore's closeSearcher method remove name of currentSearcher on infoRegistry. # SolrIndexSearcher's register method put the name of cache, but SolrIndexSearcher's close do not remove the name of cache. so, there maybe lost some memory leak. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-2927) SolrIndexSearcher's register do not match close and SolrCore's closeSearcher
[ https://issues.apache.org/jira/browse/SOLR-2927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14198625#comment-14198625 ] Cyrille Roy edited comment on SOLR-2927 at 11/5/14 4:56 PM: [~shalinmangar] I have some questions regarding the patch you provided. I synced the trunk code and have some failures. I don't know how to check for trunk status other that rebuilding it (I did not find an url where we can check for trunk status) I updated the patch to have right after the closeHooks (line 1070) - ExecutorUtil.shutdown.AndAwaitTermination block - infoRegistry block With that, I have no more failures. This is the path I proposed in fact. I think it might be better to wait for searcherExecutor shutdown sooner than later because this thread can keep on doing some work whereas we are supposed to close the core. Thanks was (Author: croy): [~shalinmangar] I have some questions regarding the patch you provided. 1. I synced the trunk code and have some failures. I don't know how to check for trunk status other that rebuilding it (I did not find an url where we can check for trunk status) I updated the patch to have right after the closeHooks (line 1070) - ExecutorUtil.shutdown.AndAwaitTermination block - infoRegistry block With that, I have no more failures. This is the path I proposed in fact. I think it might be better to wait for searcherExecutor shutdown sooner than later because this thread can keep on doing some work whereas we are supposed to close the core. Thanks SolrIndexSearcher's register do not match close and SolrCore's closeSearcher Key: SOLR-2927 URL: https://issues.apache.org/jira/browse/SOLR-2927 Project: Solr Issue Type: Bug Components: search Affects Versions: 4.0-ALPHA Environment: JDK1.6/CentOS Reporter: tom liu Assignee: Shalin Shekhar Mangar Fix For: 5.0, Trunk Attachments: SOLR-2927.patch, mbean-leak-jira.png # SolrIndexSearcher's register method put the name of searcher, but SolrCore's closeSearcher method remove name of currentSearcher on infoRegistry. # SolrIndexSearcher's register method put the name of cache, but SolrIndexSearcher's close do not remove the name of cache. so, there maybe lost some memory leak. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-2927) SolrIndexSearcher's register do not match close and SolrCore's closeSearcher
[ https://issues.apache.org/jira/browse/SOLR-2927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14198625#comment-14198625 ] Cyrille Roy edited comment on SOLR-2927 at 11/5/14 4:57 PM: [~shalinmangar] I have some questions regarding the patch you provided. I synced the trunk code and have some failures. I don't know how to check for trunk status other that rebuilding it (I did not find an url where we can check for trunk status) I updated the patch to have right after the closeHooks (line 1070) - ExecutorUtil.shutdown.AndAwaitTermination block - infoRegistry block With that, I have no more failures. This is the patch I proposed in fact (without the JMX update) I wonder if it would be better to wait for searcherExecutor shutdown sooner than later because this thread can keep on doing some work whereas we are supposed to close the core. Thanks was (Author: croy): [~shalinmangar] I have some questions regarding the patch you provided. I synced the trunk code and have some failures. I don't know how to check for trunk status other that rebuilding it (I did not find an url where we can check for trunk status) I updated the patch to have right after the closeHooks (line 1070) - ExecutorUtil.shutdown.AndAwaitTermination block - infoRegistry block With that, I have no more failures. This is the patch I proposed in fact (without the JMX update) I think it might be better to wait for searcherExecutor shutdown sooner than later because this thread can keep on doing some work whereas we are supposed to close the core. Thanks SolrIndexSearcher's register do not match close and SolrCore's closeSearcher Key: SOLR-2927 URL: https://issues.apache.org/jira/browse/SOLR-2927 Project: Solr Issue Type: Bug Components: search Affects Versions: 4.0-ALPHA Environment: JDK1.6/CentOS Reporter: tom liu Assignee: Shalin Shekhar Mangar Fix For: 5.0, Trunk Attachments: SOLR-2927.patch, mbean-leak-jira.png # SolrIndexSearcher's register method put the name of searcher, but SolrCore's closeSearcher method remove name of currentSearcher on infoRegistry. # SolrIndexSearcher's register method put the name of cache, but SolrIndexSearcher's close do not remove the name of cache. so, there maybe lost some memory leak. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-2927) SolrIndexSearcher's register do not match close and SolrCore's closeSearcher
[ https://issues.apache.org/jira/browse/SOLR-2927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14198625#comment-14198625 ] Cyrille Roy edited comment on SOLR-2927 at 11/5/14 4:56 PM: [~shalinmangar] I have some questions regarding the patch you provided. I synced the trunk code and have some failures. I don't know how to check for trunk status other that rebuilding it (I did not find an url where we can check for trunk status) I updated the patch to have right after the closeHooks (line 1070) - ExecutorUtil.shutdown.AndAwaitTermination block - infoRegistry block With that, I have no more failures. This is the patch I proposed in fact (without the JMX update) I think it might be better to wait for searcherExecutor shutdown sooner than later because this thread can keep on doing some work whereas we are supposed to close the core. Thanks was (Author: croy): [~shalinmangar] I have some questions regarding the patch you provided. I synced the trunk code and have some failures. I don't know how to check for trunk status other that rebuilding it (I did not find an url where we can check for trunk status) I updated the patch to have right after the closeHooks (line 1070) - ExecutorUtil.shutdown.AndAwaitTermination block - infoRegistry block With that, I have no more failures. This is the path I proposed in fact. I think it might be better to wait for searcherExecutor shutdown sooner than later because this thread can keep on doing some work whereas we are supposed to close the core. Thanks SolrIndexSearcher's register do not match close and SolrCore's closeSearcher Key: SOLR-2927 URL: https://issues.apache.org/jira/browse/SOLR-2927 Project: Solr Issue Type: Bug Components: search Affects Versions: 4.0-ALPHA Environment: JDK1.6/CentOS Reporter: tom liu Assignee: Shalin Shekhar Mangar Fix For: 5.0, Trunk Attachments: SOLR-2927.patch, mbean-leak-jira.png # SolrIndexSearcher's register method put the name of searcher, but SolrCore's closeSearcher method remove name of currentSearcher on infoRegistry. # SolrIndexSearcher's register method put the name of cache, but SolrIndexSearcher's close do not remove the name of cache. so, there maybe lost some memory leak. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Issue Comment Deleted] (SOLR-2927) SolrIndexSearcher's register do not match close and SolrCore's closeSearcher
[ https://issues.apache.org/jira/browse/SOLR-2927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cyrille Roy updated SOLR-2927: -- Comment: was deleted (was: [~shalinmangar] I have some questions regarding the patch you provided. I synced the trunk code and have some failures. I don't know how to check for trunk status other that rebuilding it (I did not find an url where we can check for trunk status) I updated the patch to have right after the closeHooks (line 1070) - ExecutorUtil.shutdown.AndAwaitTermination block - infoRegistry block With that, I have no more failures. This is the patch I proposed in fact (without the JMX update) I wonder if it would be better to wait for searcherExecutor shutdown sooner than later because this thread can keep on doing some work whereas we are supposed to close the core. Thanks) SolrIndexSearcher's register do not match close and SolrCore's closeSearcher Key: SOLR-2927 URL: https://issues.apache.org/jira/browse/SOLR-2927 Project: Solr Issue Type: Bug Components: search Affects Versions: 4.0-ALPHA Environment: JDK1.6/CentOS Reporter: tom liu Assignee: Shalin Shekhar Mangar Fix For: 5.0, Trunk Attachments: SOLR-2927.patch, mbean-leak-jira.png # SolrIndexSearcher's register method put the name of searcher, but SolrCore's closeSearcher method remove name of currentSearcher on infoRegistry. # SolrIndexSearcher's register method put the name of cache, but SolrIndexSearcher's close do not remove the name of cache. so, there maybe lost some memory leak. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2927) SolrIndexSearcher's register do not match close and SolrCore's closeSearcher
[
https://issues.apache.org/jira/browse/SOLR-2927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14198657#comment-14198657
]
Shalin Shekhar Mangar commented on SOLR-2927:
-
{quote} I synced the trunk code and have some failures.
I don't know how to check for trunk status other that rebuilding it (I did not
find an url where we can check for trunk status)
{quote}
What failures have you seen?
bq. I wonder if it would be better to wait for searcherExecutor shutdown sooner
than later because this thread can keep on doing some work whereas we are
supposed to close the core.
Once the searcherExecutor is shutdown, there won't be any searcher thread doing
any work (including warming). The on deck searcher is also closed before we
clear the infoRegistry.
SolrIndexSearcher's register do not match close and SolrCore's closeSearcher
Key: SOLR-2927
URL: https://issues.apache.org/jira/browse/SOLR-2927
Project: Solr
Issue Type: Bug
Components: search
Affects Versions: 4.0-ALPHA
Environment: JDK1.6/CentOS
Reporter: tom liu
Assignee: Shalin Shekhar Mangar
Fix For: 5.0, Trunk
Attachments: SOLR-2927.patch, mbean-leak-jira.png
# SolrIndexSearcher's register method put the name of searcher, but
SolrCore's closeSearcher method remove name of currentSearcher on
infoRegistry.
# SolrIndexSearcher's register method put the name of cache, but
SolrIndexSearcher's close do not remove the name of cache.
so, there maybe lost some memory leak.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2927) SolrIndexSearcher's register do not match close and SolrCore's closeSearcher
[ https://issues.apache.org/jira/browse/SOLR-2927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14198667#comment-14198667 ] Cyrille Roy commented on SOLR-2927: --- hi [~shalinmangar] I have some questions regarding the patch you provided. I backported the fix into branch_4_2 have some test failures. I updated the patch to have right after the closeHooks (line 1070) - ExecutorUtil.shutdown.AndAwaitTermination block - infoRegistry block With that, I have no more failures. I wonder if it would be better to wait for searcherExecutor shutdown sooner than later because this thread can keep on doing some work whereas we are supposed to close the core. Thanks SolrIndexSearcher's register do not match close and SolrCore's closeSearcher Key: SOLR-2927 URL: https://issues.apache.org/jira/browse/SOLR-2927 Project: Solr Issue Type: Bug Components: search Affects Versions: 4.0-ALPHA Environment: JDK1.6/CentOS Reporter: tom liu Assignee: Shalin Shekhar Mangar Fix For: 5.0, Trunk Attachments: SOLR-2927.patch, mbean-leak-jira.png # SolrIndexSearcher's register method put the name of searcher, but SolrCore's closeSearcher method remove name of currentSearcher on infoRegistry. # SolrIndexSearcher's register method put the name of cache, but SolrIndexSearcher's close do not remove the name of cache. so, there maybe lost some memory leak. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-2927) SolrIndexSearcher's register do not match close and SolrCore's closeSearcher
[ https://issues.apache.org/jira/browse/SOLR-2927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14198667#comment-14198667 ] Cyrille Roy edited comment on SOLR-2927 at 11/5/14 5:14 PM: hi [~shalinmangar] I have some questions regarding the patch you provided. I backported the fix into branch_4_2 and have some test failures. I updated the patch to have right after the closeHooks (line 1070) - ExecutorUtil.shutdown.AndAwaitTermination block - infoRegistry block With that, I have no more failures. I wonder if it would be better to wait for searcherExecutor shutdown sooner than later because this thread can keep on doing some work whereas we are supposed to close the core. Thanks was (Author: croy): hi [~shalinmangar] I have some questions regarding the patch you provided. I backported the fix into branch_4_2 have some test failures. I updated the patch to have right after the closeHooks (line 1070) - ExecutorUtil.shutdown.AndAwaitTermination block - infoRegistry block With that, I have no more failures. I wonder if it would be better to wait for searcherExecutor shutdown sooner than later because this thread can keep on doing some work whereas we are supposed to close the core. Thanks SolrIndexSearcher's register do not match close and SolrCore's closeSearcher Key: SOLR-2927 URL: https://issues.apache.org/jira/browse/SOLR-2927 Project: Solr Issue Type: Bug Components: search Affects Versions: 4.0-ALPHA Environment: JDK1.6/CentOS Reporter: tom liu Assignee: Shalin Shekhar Mangar Fix For: 5.0, Trunk Attachments: SOLR-2927.patch, mbean-leak-jira.png # SolrIndexSearcher's register method put the name of searcher, but SolrCore's closeSearcher method remove name of currentSearcher on infoRegistry. # SolrIndexSearcher's register method put the name of cache, but SolrIndexSearcher's close do not remove the name of cache. so, there maybe lost some memory leak. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6705) SOLR Start script
[ https://issues.apache.org/jira/browse/SOLR-6705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14198684#comment-14198684 ] Jan Høydahl commented on SOLR-6705: --- Actually I encouraged Carsten to file an issue for this, as the start script perfectly well can check Java version and optimize the set of options accordingly. It is a very bad OOTB experience for new users to get WARNINGs thrown on a normal legal startup. The argument that they are supposed to be there is not a good one, and I'd like us to polish the user experience to be best possible. I'll probably re-open this issue and start looking into it. SOLR Start script - Key: SOLR-6705 URL: https://issues.apache.org/jira/browse/SOLR-6705 Project: Solr Issue Type: Bug Components: scripts and tools Affects Versions: 4.10.2 Environment: Mac Yosemite 10.10 java -version java version 1.8.0_25 Java(TM) SE Runtime Environment (build 1.8.0_25-b17) Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode) Reporter: Carsten Grønbjerg Lützen Priority: Trivial When using the start script in bin: ./solr start The following warnings occur from Java: Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=256m; support was removed in 8.0 Java HotSpot(TM) 64-Bit Server VM warning: ignoring option PermSize=256m; support was removed in 8.0 Java HotSpot(TM) 64-Bit Server VM warning: ignoring option CMSTriggerPermRatio=80; support was removed in 8.0 Java HotSpot(TM) 64-Bit Server VM warning: CMSFullGCsBeforeCompaction is deprecated and will likely be removed in a future release. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-6707) Recovery/election for invalid core results in rapid-fire re-attempts until /overseer/queue is clogged
James Hardwick created SOLR-6707: Summary: Recovery/election for invalid core results in rapid-fire re-attempts until /overseer/queue is clogged Key: SOLR-6707 URL: https://issues.apache.org/jira/browse/SOLR-6707 Project: Solr Issue Type: Bug Affects Versions: 4.10 Reporter: James Hardwick We experienced an issue the other day that brought a production solr server down, and this is what we found after investigating: - Running solr instance with two separate cores, one of which is perpetually down because it's configs are not yet completely updated for Solr-cloud. This was thought to be harmless since it's not currently in use. - Solr experienced an internal server error I believe due in part to a fairly new feature we are using, which seemingly caused all cores to go down. - Solr immediately went into recovery, and subsequent leader election for each shard of each core. - Our primary core recovered immediately. Our additional core which was never active in the first place, attempted to recover but of course couldn't due to the improper configs. - Solr then began rapid-fire reattempting recovery of said node, trying maybe 20-30 times per second. - This in turn bombarded zookeepers /overseer/queue into oblivion - At some point /overseer/queue becomes so backed up that normal cluster coordination can no longer play out, and Solr topples over. I know this is a bit of an unusual circumstance due to us keeping the dead core around, and our quick solution has been to remove said core. However I can see other potential scenarios that might cause the same issue to arise. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6058) Solr needs a new website
[ https://issues.apache.org/jira/browse/SOLR-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14198743#comment-14198743 ] ASF subversion and git services commented on SOLR-6058: --- Commit 1636925 from [~sar...@syr.edu] in branch 'cms/branches/solr_6058' [ https://svn.apache.org/r1636925 ] SOLR-6058: Whne window width is narrower than the text in section.orange milestones (e.g. detailed features), allow the text to wrap Solr needs a new website Key: SOLR-6058 URL: https://issues.apache.org/jira/browse/SOLR-6058 Project: Solr Issue Type: Task Reporter: Grant Ingersoll Assignee: Grant Ingersoll Attachments: HTML.rar, SOLR-6058, SOLR-6058.location-fix.patchfile, SOLR-6058.offset-fix.patch, Solr_Icons.pdf, Solr_Logo_on_black.pdf, Solr_Logo_on_black.png, Solr_Logo_on_orange.pdf, Solr_Logo_on_orange.png, Solr_Logo_on_white.pdf, Solr_Logo_on_white.png, Solr_Styleguide.pdf Solr needs a new website: better organization of content, less verbose, more pleasing graphics, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Crazy Solr startup params, please review
Can we in a smart way build these best practices into the script, by testing JVM version and (un)setting some of these automatically based on version? The solr.in.* config could have a new option GC_TUNE_AUTO=true and GC_TUNE commented out. Then if auto is enabled, the bin/solr scripts will decide what flags to set. Experts can override. Also related is SOLR-6705, some options should be set automatically only for some JVM versions. -- Jan Høydahl, search solution architect Cominvent AS - www.cominvent.com 5. nov. 2014 kl. 16.53 skrev Uwe Schindler u...@thetaphi.de: Hi, I just reviewed the solr.sh.in and solr.cmd.in scripts in solr/bin folder. The following was committed but never discussed: # These GC settings have shown to work well for a number of common Solr workloads GC_TUNE=-XX:-UseSuperWord \ -XX:NewRatio=3 \ -XX:SurvivorRatio=4 \ -XX:TargetSurvivorRatio=90 \ -XX:MaxTenuringThreshold=8 \ -XX:+UseConcMarkSweepGC \ -XX:+UseParNewGC \ -XX:ConcGCThreads=4 -XX:ParallelGCThreads=4 \ -XX:+CMSScavengeBeforeRemark \ -XX:PretenureSizeThreshold=64m \ -XX:CMSFullGCsBeforeCompaction=1 \ -XX:+UseCMSInitiatingOccupancyOnly \ -XX:CMSInitiatingOccupancyFraction=50 \ -XX:CMSTriggerPermRatio=80 \ -XX:CMSMaxAbortablePrecleanTime=6000 \ -XX:+CMSParallelRemarkEnabled \ -XX:+ParallelRefProcEnabled \ -XX:+AggressiveOpts This is horrible, because of our experience with Hotspot bugs: -XX:+AggressiveOpts This option is vry risky and speed improvements are marginal. PLEASE DON'T DO THIS. If people want the new features they should wait for later Java releases and the new features are tested. See several tasks about the Java 7 disaster! In fact we had reports at Java 6 times when people had enabled this and were affected by the Java 7 GA bugs already in Java 6 and corrupted their indexes!!! -XX:-UseSuperWord If you have a Haswell CPU, all other improvements in these command line settings are eaten up by this flag! If you have 7u55 at minimum, you should never disable this. Things like BooleanFilter and other bitset operations are up to 2 times faster with Java 7u55 on Haswell CPUs and later!!! This setting only makes sense if you have one of those buggy JDKs (7u40 to 7u51). In all other cases this slows down enormous! In addition, enabling this option may break JDKs before 7u40 (this option was added in 7u40), so breaks: Unrecognized VM option 'UseSuperWord' It would be good, if we could fix the startup scripts not not have options, which may also break with JDK 8 or later! Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de - 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-2927) SolrIndexSearcher's register do not match close and SolrCore's closeSearcher
[ https://issues.apache.org/jira/browse/SOLR-2927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14198750#comment-14198750 ] Cyrille Roy commented on SOLR-2927: --- [junit4:junit4] Tests with failures (first 10 out of 11): [junit4:junit4] - org.apache.solr.MinimalSchemaTest (suite) [junit4:junit4] - org.apache.solr.cloud.SyncSliceTest (suite) [junit4:junit4] - org.apache.solr.cloud.UnloadDistributedZkTest (suite) [junit4:junit4] - org.apache.solr.cloud.AliasIntegrationTest (suite) [junit4:junit4] - org.apache.solr.cloud.BasicDistributedZk2Test (suite) [junit4:junit4] - org.apache.solr.cloud.FullSolrCloudDistribCmdsTest (suite) [junit4:junit4] - org.apache.solr.cloud.CollectionsAPIDistributedZkTest (suite) [junit4:junit4] - org.apache.solr.cloud.ShardRoutingTest (suite) [junit4:junit4] - org.apache.solr.cloud.RecoveryZkTest (suite) [junit4:junit4] - org.apache.solr.handler.admin.ShowFileRequestHandlerTest (suite) [junit4:junit4] [junit4:junit4] [junit4:junit4] JVM J0: 2.84 .. 890.21 = 887.37s [junit4:junit4] JVM J1: 2.84 .. 767.84 = 765.00s [junit4:junit4] JVM J2: 2.84 .. 881.17 = 878.34s [junit4:junit4] JVM J3: 3.09 .. 768.09 = 765.01s [junit4:junit4] Execution time total: 14 minutes 50 seconds [junit4:junit4] Tests summary: 272 suites, 1148 tests, 11 suite-level errors, 14 ignored (2 assumptions) I have often this stack: [junit4:junit4] 2 69753 T293 oasc.JmxMonitoredMap$SolrDynamicMBean.getMBeanInfo WARNING Could not getStatistics on info bean org.apache.solr.search.SolrIndexSearcher org.apache.lucene.store.AlreadyClosedException: this IndexReader is closed this is a warning, but it is a class updated by the patch so mentioning it. SolrIndexSearcher's register do not match close and SolrCore's closeSearcher Key: SOLR-2927 URL: https://issues.apache.org/jira/browse/SOLR-2927 Project: Solr Issue Type: Bug Components: search Affects Versions: 4.0-ALPHA Environment: JDK1.6/CentOS Reporter: tom liu Assignee: Shalin Shekhar Mangar Fix For: 5.0, Trunk Attachments: SOLR-2927.patch, mbean-leak-jira.png # SolrIndexSearcher's register method put the name of searcher, but SolrCore's closeSearcher method remove name of currentSearcher on infoRegistry. # SolrIndexSearcher's register method put the name of cache, but SolrIndexSearcher's close do not remove the name of cache. so, there maybe lost some memory leak. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
