[JENKINS] Lucene-Solr-trunk-Windows (32bit/jdk1.8.0_20-ea-b21) - Build # 4191 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/4191/ Java: 32bit/jdk1.8.0_20-ea-b21 -client -XX:+UseParallelGC All tests passed Build Log: [...truncated 51837 lines...] BUILD FAILED C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\build.xml:467: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\build.xml:406: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\extra-targets.xml:87: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\extra-targets.xml:181: Source checkout is dirty after running tests!!! Offending files: * ./solr/licenses/log4j-1.2.16.jar.sha1 Total time: 174 minutes 31 seconds Build step 'Invoke Ant' marked build as failure [description-setter] Description set: Java: 32bit/jdk1.8.0_20-ea-b21 -client -XX:+UseParallelGC Archiving artifacts Recording test results Email was triggered for: Failure - Any Sending email for trigger: Failure - Any - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-5827) Make all Directory implementations correctly fail with IllegalArgumentException if slices are out of bounds
Uwe Schindler created LUCENE-5827:
-
Summary: Make all Directory implementations correctly fail with
IllegalArgumentException if slices are out of bounds
Key: LUCENE-5827
URL: https://issues.apache.org/jira/browse/LUCENE-5827
Project: Lucene - Core
Issue Type: Bug
Components: core/store
Affects Versions: 4.9, 4.8
Reporter: Uwe Schindler
Assignee: Uwe Schindler
After implementing LUCENE-5681, I noticed, that some directory implementations
(like NIOFSDirectory) do not do bounds checks on slice creation. We should do
this to early detect bugs, if file formats break because of index corrumption.
This test in BaseDirectoryTestCase does not pass for all directory impls:
{code:java}
public void testSliceOutOfBounds() throws Exception {
Directory dir = getDirectory(createTempDir(testSliceOutOfBounds));
IndexOutput o = dir.createOutput(out, newIOContext(random()));
final int len = random().nextInt(2040) + 8;
byte[] b = new byte[len];
o.writeBytes(b, 0, len);
o.close();
IndexInput i = dir.openInput(out, newIOContext(random()));
try {
i.slice(slice1, 0, len + 1);
fail(Did not get IllegalArgumentException);
} catch (IllegalArgumentException iae) {
// pass
}
try {
i.slice(slice2, -1, len);
fail(Did not get IllegalArgumentException);
} catch (IllegalArgumentException iae) {
// pass
}
IndexInput slice = i.slice(slice3, 4, len / 2);
try {
slice.slice(slice3sub, 1, len / 2);
fail(Did not get IllegalArgumentException);
} catch (IllegalArgumentException iae) {
// pass
}
i.close();
dir.close();
}
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-5681) Fix RAMDirectory's IndexInput to not double-buffer on slice()
[ https://issues.apache.org/jira/browse/LUCENE-5681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler resolved LUCENE-5681. --- Resolution: Fixed Fix RAMDirectory's IndexInput to not double-buffer on slice() - Key: LUCENE-5681 URL: https://issues.apache.org/jira/browse/LUCENE-5681 Project: Lucene - Core Issue Type: Bug Components: core/store Reporter: Uwe Schindler Assignee: Uwe Schindler Fix For: 5.0, 4.10 Attachments: LUCENE-5681.patch, LUCENE-5681.patch, LUCENE-5681.patch After LUCENE-4371, we still have a non-optimal implementation of IndexInput#slice() in RAMDirectory. We should fix that to use the cloning approach like other directories do -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5827) Make all Directory implementations correctly fail with IllegalArgumentException if slices are out of bounds
[
https://issues.apache.org/jira/browse/LUCENE-5827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-5827:
--
Attachment: LUCENE-5827.patch
Simple patch. Test now passes.
Make all Directory implementations correctly fail with
IllegalArgumentException if slices are out of bounds
---
Key: LUCENE-5827
URL: https://issues.apache.org/jira/browse/LUCENE-5827
Project: Lucene - Core
Issue Type: Bug
Components: core/store
Affects Versions: 4.8, 4.9
Reporter: Uwe Schindler
Assignee: Uwe Schindler
Attachments: LUCENE-5827.patch
After implementing LUCENE-5681, I noticed, that some directory
implementations (like NIOFSDirectory) do not do bounds checks on slice
creation. We should do this to early detect bugs, if file formats break
because of index corrumption.
This test in BaseDirectoryTestCase does not pass for all directory impls:
{code:java}
public void testSliceOutOfBounds() throws Exception {
Directory dir = getDirectory(createTempDir(testSliceOutOfBounds));
IndexOutput o = dir.createOutput(out, newIOContext(random()));
final int len = random().nextInt(2040) + 8;
byte[] b = new byte[len];
o.writeBytes(b, 0, len);
o.close();
IndexInput i = dir.openInput(out, newIOContext(random()));
try {
i.slice(slice1, 0, len + 1);
fail(Did not get IllegalArgumentException);
} catch (IllegalArgumentException iae) {
// pass
}
try {
i.slice(slice2, -1, len);
fail(Did not get IllegalArgumentException);
} catch (IllegalArgumentException iae) {
// pass
}
IndexInput slice = i.slice(slice3, 4, len / 2);
try {
slice.slice(slice3sub, 1, len / 2);
fail(Did not get IllegalArgumentException);
} catch (IllegalArgumentException iae) {
// pass
}
i.close();
dir.close();
}
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-5828) Improve BufferedIndexInput.SlicedIndexInput to directly delegate
Uwe Schindler created LUCENE-5828: - Summary: Improve BufferedIndexInput.SlicedIndexInput to directly delegate Key: LUCENE-5828 URL: https://issues.apache.org/jira/browse/LUCENE-5828 Project: Lucene - Core Issue Type: Bug Reporter: Uwe Schindler Assignee: Uwe Schindler Currently we have some IndexInputs which do not have a separate slice() implementation. Those are using BufferedIndexInput#wrap(), which extends BufferedInputStream. This is nonsense, because the underlying IndexInput is in most cases already Buffered, and if not, its not needed. This issue will change SlicedIndexInput to directly delegate, correcting offsets. The new class SlicedIndexInput will be top level and public. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-5827) Make all Directory implementations correctly fail with IllegalArgumentException if slices are out of bounds
[
https://issues.apache.org/jira/browse/LUCENE-5827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler resolved LUCENE-5827.
---
Resolution: Fixed
Fix Version/s: 4.10
5.0
Make all Directory implementations correctly fail with
IllegalArgumentException if slices are out of bounds
---
Key: LUCENE-5827
URL: https://issues.apache.org/jira/browse/LUCENE-5827
Project: Lucene - Core
Issue Type: Bug
Components: core/store
Affects Versions: 4.8, 4.9
Reporter: Uwe Schindler
Assignee: Uwe Schindler
Fix For: 5.0, 4.10
Attachments: LUCENE-5827.patch
After implementing LUCENE-5681, I noticed, that some directory
implementations (like NIOFSDirectory) do not do bounds checks on slice
creation. We should do this to early detect bugs, if file formats break
because of index corrumption.
This test in BaseDirectoryTestCase does not pass for all directory impls:
{code:java}
public void testSliceOutOfBounds() throws Exception {
Directory dir = getDirectory(createTempDir(testSliceOutOfBounds));
IndexOutput o = dir.createOutput(out, newIOContext(random()));
final int len = random().nextInt(2040) + 8;
byte[] b = new byte[len];
o.writeBytes(b, 0, len);
o.close();
IndexInput i = dir.openInput(out, newIOContext(random()));
try {
i.slice(slice1, 0, len + 1);
fail(Did not get IllegalArgumentException);
} catch (IllegalArgumentException iae) {
// pass
}
try {
i.slice(slice2, -1, len);
fail(Did not get IllegalArgumentException);
} catch (IllegalArgumentException iae) {
// pass
}
IndexInput slice = i.slice(slice3, 4, len / 2);
try {
slice.slice(slice3sub, 1, len / 2);
fail(Did not get IllegalArgumentException);
} catch (IllegalArgumentException iae) {
// pass
}
i.close();
dir.close();
}
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5828) Improve BufferedIndexInput.SlicedIndexInput to directly delegate
[ https://issues.apache.org/jira/browse/LUCENE-5828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14063327#comment-14063327 ] Uwe Schindler commented on LUCENE-5828: --- This would also simplify the LUCENE-5681 fix: We would no longer need to implement custom slices for RAMDirectoy. Improve BufferedIndexInput.SlicedIndexInput to directly delegate Key: LUCENE-5828 URL: https://issues.apache.org/jira/browse/LUCENE-5828 Project: Lucene - Core Issue Type: Bug Reporter: Uwe Schindler Assignee: Uwe Schindler Currently we have some IndexInputs which do not have a separate slice() implementation. Those are using BufferedIndexInput#wrap(), which extends BufferedInputStream. This is nonsense, because the underlying IndexInput is in most cases already Buffered, and if not, its not needed. This issue will change SlicedIndexInput to directly delegate, correcting offsets. The new class SlicedIndexInput will be top level and public. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-trunk-Linux-java7-64-analyzers - Build # 10272 - Failure!
Build: builds.flonkings.com/job/Lucene-trunk-Linux-java7-64-analyzers/10272/ 1 tests failed. REGRESSION: org.apache.lucene.analysis.core.TestRandomChains.testRandomChains Error Message: startOffset must be non-negative, and endOffset must be = startOffset, startOffset=5,endOffset=4 Stack Trace: java.lang.IllegalArgumentException: startOffset must be non-negative, and endOffset must be = startOffset, startOffset=5,endOffset=4 at __randomizedtesting.SeedInfo.seed([E7A1BE0FEB0D643C:DA40976EAC1F79FC]:0) at org.apache.lucene.analysis.tokenattributes.PackedTokenAttributeImpl.setOffset(PackedTokenAttributeImpl.java:107) at org.apache.lucene.analysis.shingle.ShingleFilter.incrementToken(ShingleFilter.java:345) at org.apache.lucene.analysis.ValidatingTokenFilter.incrementToken(ValidatingTokenFilter.java:68) at org.apache.lucene.analysis.miscellaneous.ScandinavianFoldingFilter.incrementToken(ScandinavianFoldingFilter.java:73) at org.apache.lucene.analysis.ValidatingTokenFilter.incrementToken(ValidatingTokenFilter.java:68) at org.apache.lucene.analysis.BaseTokenStreamTestCase.checkResetException(BaseTokenStreamTestCase.java:404) at org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:498) at org.apache.lucene.analysis.core.TestRandomChains.testRandomChains(TestRandomChains.java:906) 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 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:43) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at
[jira] [Updated] (LUCENE-5828) Improve BufferedIndexInput.SlicedIndexInput to directly delegate
[ https://issues.apache.org/jira/browse/LUCENE-5828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated LUCENE-5828: -- Attachment: LUCENE-5828.patch Patch. Improve BufferedIndexInput.SlicedIndexInput to directly delegate Key: LUCENE-5828 URL: https://issues.apache.org/jira/browse/LUCENE-5828 Project: Lucene - Core Issue Type: Bug Reporter: Uwe Schindler Assignee: Uwe Schindler Attachments: LUCENE-5828.patch Currently we have some IndexInputs which do not have a separate slice() implementation. Those are using BufferedIndexInput#wrap(), which extends BufferedInputStream. This is nonsense, because the underlying IndexInput is in most cases already Buffered, and if not, its not needed. This issue will change SlicedIndexInput to directly delegate, correcting offsets. The new class SlicedIndexInput will be top level and public. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5828) Improve BufferedIndexInput.SlicedIndexInput to directly delegate
[ https://issues.apache.org/jira/browse/LUCENE-5828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14063372#comment-14063372 ] Robert Muir commented on LUCENE-5828: - Is this really correct? if i make a slice 0-5 out of length 10 and then read 6 bytes from it, what happens? Improve BufferedIndexInput.SlicedIndexInput to directly delegate Key: LUCENE-5828 URL: https://issues.apache.org/jira/browse/LUCENE-5828 Project: Lucene - Core Issue Type: Bug Reporter: Uwe Schindler Assignee: Uwe Schindler Attachments: LUCENE-5828.patch Currently we have some IndexInputs which do not have a separate slice() implementation. Those are using BufferedIndexInput#wrap(), which extends BufferedInputStream. This is nonsense, because the underlying IndexInput is in most cases already Buffered, and if not, its not needed. This issue will change SlicedIndexInput to directly delegate, correcting offsets. The new class SlicedIndexInput will be top level and public. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6156) Exception while using group with timeAllowed on SolrCloud.
[
https://issues.apache.org/jira/browse/SOLR-6156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14063390#comment-14063390
]
Modassar Ather commented on SOLR-6156:
--
While debugging found that the create() method under SearchGroupsFieldCommand
class return an empty list of collectors if topNGroups 0 and if
includeGroupCount is false.
And if the collectors list is empty CommandHandler class invokes
searchWithTimeLimiter(query, filter, null);. null is passed as collectors.
With the null collector passed an instance of TimeLimitingCollector is created
in searchWithTimeLimiter(...) method of CommandHandler class if
queryCommand.getTimeAllowed() 0.
Code snippet from CommandHandler. Here in the code below the collector passed
to TimeLimitingCollector is null.
if (queryCommand.getTimeAllowed() 0 ) {
collector = new TimeLimitingCollector(collector,
TimeLimitingCollector.getGlobalCounter(), queryCommand.getTimeAllowed());
}
The NullPointerException occurrs when the TimeLimitingCollector instance
created with null collector invokes setNextReader(...)
Not sure if topNGroups should be greater than 0 or includeGroupCount should be
true when using timeAllowed or it is an issue. Kindly provide inputs.
Also let me know if the collectors list is null and timeAllowed0 which
collector can be used to create the instance of TimeLimitingCollector.
Thanks,
Modassar
Exception while using group with timeAllowed on SolrCloud.
--
Key: SOLR-6156
URL: https://issues.apache.org/jira/browse/SOLR-6156
Project: Solr
Issue Type: Bug
Reporter: Modassar Ather
Following exception is thrown when using grouping with timeAllowed. Solr
version used is 4.8.0.
SEVERE:
null:org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException:
java.lang.NullPointerException
at
org.apache.lucene.search.TimeLimitingCollector.setNextReader(TimeLimitingCollector.java:158)
at
org.apache.lucene.search.MultiCollector.setNextReader(MultiCollector.java:113)
at
org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:612)
at
org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:297)
at
org.apache.solr.search.grouping.CommandHandler.searchWithTimeLimiter(CommandHandler.java:219)
at
org.apache.solr.search.grouping.CommandHandler.execute(CommandHandler.java:156)
at
org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:338)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:218)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1952)
at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:774)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:418)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:207)
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5828) Improve BufferedIndexInput.SlicedIndexInput to directly delegate
[ https://issues.apache.org/jira/browse/LUCENE-5828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14063394#comment-14063394 ] Uwe Schindler commented on LUCENE-5828: --- Robert: That is the issue I am targeting at the moment. There are no bounds checks at all. Improve BufferedIndexInput.SlicedIndexInput to directly delegate Key: LUCENE-5828 URL: https://issues.apache.org/jira/browse/LUCENE-5828 Project: Lucene - Core Issue Type: Bug Reporter: Uwe Schindler Assignee: Uwe Schindler Attachments: LUCENE-5828.patch Currently we have some IndexInputs which do not have a separate slice() implementation. Those are using BufferedIndexInput#wrap(), which extends BufferedInputStream. This is nonsense, because the underlying IndexInput is in most cases already Buffered, and if not, its not needed. This issue will change SlicedIndexInput to directly delegate, correcting offsets. The new class SlicedIndexInput will be top level and public. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5828) Improve BufferedIndexInput.SlicedIndexInput to directly delegate
[ https://issues.apache.org/jira/browse/LUCENE-5828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated LUCENE-5828: -- Attachment: LUCENE-5828.patch Patch with bounds checks. Like other impls I did not add bounds checks to RandomAccess (others don't do this, too). Improve BufferedIndexInput.SlicedIndexInput to directly delegate Key: LUCENE-5828 URL: https://issues.apache.org/jira/browse/LUCENE-5828 Project: Lucene - Core Issue Type: Bug Reporter: Uwe Schindler Assignee: Uwe Schindler Attachments: LUCENE-5828.patch, LUCENE-5828.patch Currently we have some IndexInputs which do not have a separate slice() implementation. Those are using BufferedIndexInput#wrap(), which extends BufferedInputStream. This is nonsense, because the underlying IndexInput is in most cases already Buffered, and if not, its not needed. This issue will change SlicedIndexInput to directly delegate, correcting offsets. The new class SlicedIndexInput will be top level and public. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5828) Improve BufferedIndexInput.SlicedIndexInput to directly delegate
[ https://issues.apache.org/jira/browse/LUCENE-5828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14063410#comment-14063410 ] Robert Muir commented on LUCENE-5828: - I dont think we should do this: its going to cost a per-byte bounds check. The current buffering is more efficient. Improve BufferedIndexInput.SlicedIndexInput to directly delegate Key: LUCENE-5828 URL: https://issues.apache.org/jira/browse/LUCENE-5828 Project: Lucene - Core Issue Type: Bug Reporter: Uwe Schindler Assignee: Uwe Schindler Attachments: LUCENE-5828.patch, LUCENE-5828.patch Currently we have some IndexInputs which do not have a separate slice() implementation. Those are using BufferedIndexInput#wrap(), which extends BufferedInputStream. This is nonsense, because the underlying IndexInput is in most cases already Buffered, and if not, its not needed. This issue will change SlicedIndexInput to directly delegate, correcting offsets. The new class SlicedIndexInput will be top level and public. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5828) Improve BufferedIndexInput.SlicedIndexInput to directly delegate
[ https://issues.apache.org/jira/browse/LUCENE-5828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14063416#comment-14063416 ] Uwe Schindler commented on LUCENE-5828: --- Thanks Robert! I expected that already, just had no time to benchmark (came back from lunch a minute ago). The slice wrapper is not used in any core directories, so maybe we should leave it as it is. I added a warning in the previous issue, but for already slow IndexInputs like HDFS I don't care. I will close this issue as won't fix. The bounds checks are the issue. We could make it faster by let it delegating all read calls, but I don't think its worth. Improve BufferedIndexInput.SlicedIndexInput to directly delegate Key: LUCENE-5828 URL: https://issues.apache.org/jira/browse/LUCENE-5828 Project: Lucene - Core Issue Type: Bug Reporter: Uwe Schindler Assignee: Uwe Schindler Attachments: LUCENE-5828.patch, LUCENE-5828.patch Currently we have some IndexInputs which do not have a separate slice() implementation. Those are using BufferedIndexInput#wrap(), which extends BufferedInputStream. This is nonsense, because the underlying IndexInput is in most cases already Buffered, and if not, its not needed. This issue will change SlicedIndexInput to directly delegate, correcting offsets. The new class SlicedIndexInput will be top level and public. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5828) Improve BufferedIndexInput.SlicedIndexInput to directly delegate
[ https://issues.apache.org/jira/browse/LUCENE-5828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated LUCENE-5828: -- Component/s: core/store Improve BufferedIndexInput.SlicedIndexInput to directly delegate Key: LUCENE-5828 URL: https://issues.apache.org/jira/browse/LUCENE-5828 Project: Lucene - Core Issue Type: Bug Components: core/store Reporter: Uwe Schindler Assignee: Uwe Schindler Attachments: LUCENE-5828.patch, LUCENE-5828.patch Currently we have some IndexInputs which do not have a separate slice() implementation. Those are using BufferedIndexInput#wrap(), which extends BufferedInputStream. This is nonsense, because the underlying IndexInput is in most cases already Buffered, and if not, its not needed. This issue will change SlicedIndexInput to directly delegate, correcting offsets. The new class SlicedIndexInput will be top level and public. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (LUCENE-5828) Improve BufferedIndexInput.SlicedIndexInput to directly delegate
[ https://issues.apache.org/jira/browse/LUCENE-5828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler closed LUCENE-5828. - Resolution: Won't Fix Improve BufferedIndexInput.SlicedIndexInput to directly delegate Key: LUCENE-5828 URL: https://issues.apache.org/jira/browse/LUCENE-5828 Project: Lucene - Core Issue Type: Bug Components: core/store Reporter: Uwe Schindler Assignee: Uwe Schindler Attachments: LUCENE-5828.patch, LUCENE-5828.patch Currently we have some IndexInputs which do not have a separate slice() implementation. Those are using BufferedIndexInput#wrap(), which extends BufferedInputStream. This is nonsense, because the underlying IndexInput is in most cases already Buffered, and if not, its not needed. This issue will change SlicedIndexInput to directly delegate, correcting offsets. The new class SlicedIndexInput will be top level and public. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5746) solr.xml parsing of str vs int vs bool is brittle; fails silently; expects odd type for shareSchema
[
https://issues.apache.org/jira/browse/SOLR-5746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14063425#comment-14063425
]
Maciej Zasada commented on SOLR-5746:
-
Hi [~hossman],
thanks for the code review and all your suggestions. I'll keep them in mind for
the future work. Revised patch looks good to me.
Cheers,
Maciej
solr.xml parsing of str vs int vs bool is brittle; fails silently;
expects odd type for shareSchema
--
Key: SOLR-5746
URL: https://issues.apache.org/jira/browse/SOLR-5746
Project: Solr
Issue Type: Bug
Affects Versions: 4.3, 4.4, 4.5, 4.6
Reporter: Hoss Man
Attachments: SOLR-5746.patch, SOLR-5746.patch, SOLR-5746.patch,
SOLR-5746.patch, SOLR-5746.patch
A comment in the ref guide got me looking at ConfigSolrXml.java and noticing
that the parsing of solr.xml options here is very brittle and confusing. In
particular:
* if a boolean option foo is expected along the lines of {{bool
name=footrue/bool}} it will silently ignore {{str
name=footrue/str}}
* likewise for an int option {{int name=bar32/int}} vs {{str
name=bar32/str}}
... this is inconsistent with the way solrconfig.xml is parsed. In
solrconfig.xml, the xml nodes are parsed into a NamedList, and the above
options will work in either form, but an invalid value such as {{bool
name=fooNOT A BOOLEAN/bool}} will generate an error earlier (when
parsing config) then {{str name=fooNOT A BOOLEAN/str}} (attempt to
parse the string as a bool the first time the config value is needed)
In addition, i notice this really confusing line...
{code}
propMap.put(CfgProp.SOLR_SHARESCHEMA,
doSub(solr/str[@name='shareSchema']));
{code}
shareSchema is used internally as a boolean option, but as written the
parsing code will ignore it unless the user explicitly configures it as a
{{str/}}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Examples of multi-core same Solr instance test cases?
Anybody know of any Solr test cases that exercise two Solr cores in the same Solr instance? Thanks
Re: svn commit: r1610909 - /lucene/dev/trunk/solr/core/src/test/org/apache/solr/schema/TestCloudSchemaless.java
Thanks Shalin! - Steve
On Jul 16, 2014, at 1:02 AM, sha...@apache.org wrote:
Author: shalin
Date: Wed Jul 16 05:02:36 2014
New Revision: 1610909
URL: http://svn.apache.org/r1610909
Log:
SOLR-6137: Fix off-by-one error in array access
Modified:
lucene/dev/trunk/solr/core/src/test/org/apache/solr/schema/TestCloudSchemaless.java
Modified:
lucene/dev/trunk/solr/core/src/test/org/apache/solr/schema/TestCloudSchemaless.java
URL:
http://svn.apache.org/viewvc/lucene/dev/trunk/solr/core/src/test/org/apache/solr/schema/TestCloudSchemaless.java?rev=1610909r1=1610908r2=1610909view=diff
==
---
lucene/dev/trunk/solr/core/src/test/org/apache/solr/schema/TestCloudSchemaless.java
(original)
+++
lucene/dev/trunk/solr/core/src/test/org/apache/solr/schema/TestCloudSchemaless.java
Wed Jul 16 05:02:36 2014
@@ -123,7 +123,7 @@ public class TestCloudSchemaless extends
int trials = 50;
// generate enough docs so that we can expect at least a doc per slice
int numDocsPerTrial = (int)(slices * (Math.log(slices) + 1));
-SolrServer ss = clients.get(random().nextInt(clients.size() + 1));
+SolrServer ss = clients.get(random().nextInt(clients.size()));
int docNumber = 0;
for (int i = 0; i trials; ++i) {
ListSolrInputDocument docs = new ArrayList();
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-6232) Allow cores that have failed to init to be deleted via CoreAdminHandler
[ https://issues.apache.org/jira/browse/SOLR-6232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Woodward resolved SOLR-6232. - Resolution: Fixed Fix Version/s: 4.10 Allow cores that have failed to init to be deleted via CoreAdminHandler --- Key: SOLR-6232 URL: https://issues.apache.org/jira/browse/SOLR-6232 Project: Solr Issue Type: Improvement Reporter: Alan Woodward Assignee: Alan Woodward Priority: Minor Fix For: 4.10 Attachments: SOLR-6232.patch If a core fails to init due to index corruption or something similar, it can't currently be removed with an UNLOAD command, you have to go do it manually. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5746) solr.xml parsing of str vs int vs bool is brittle; fails silently; expects odd type for shareSchema
[
https://issues.apache.org/jira/browse/SOLR-5746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14063623#comment-14063623
]
Alan Woodward commented on SOLR-5746:
-
+1, some nice cleanups here.
My only review comment would be to prefer using hamcrest assertThat() functions
in tests, rather than assertTrue(), just because you get nicer error messages
when they fail. But that's a pretty nitty nit to pick.
solr.xml parsing of str vs int vs bool is brittle; fails silently;
expects odd type for shareSchema
--
Key: SOLR-5746
URL: https://issues.apache.org/jira/browse/SOLR-5746
Project: Solr
Issue Type: Bug
Affects Versions: 4.3, 4.4, 4.5, 4.6
Reporter: Hoss Man
Attachments: SOLR-5746.patch, SOLR-5746.patch, SOLR-5746.patch,
SOLR-5746.patch, SOLR-5746.patch
A comment in the ref guide got me looking at ConfigSolrXml.java and noticing
that the parsing of solr.xml options here is very brittle and confusing. In
particular:
* if a boolean option foo is expected along the lines of {{bool
name=footrue/bool}} it will silently ignore {{str
name=footrue/str}}
* likewise for an int option {{int name=bar32/int}} vs {{str
name=bar32/str}}
... this is inconsistent with the way solrconfig.xml is parsed. In
solrconfig.xml, the xml nodes are parsed into a NamedList, and the above
options will work in either form, but an invalid value such as {{bool
name=fooNOT A BOOLEAN/bool}} will generate an error earlier (when
parsing config) then {{str name=fooNOT A BOOLEAN/str}} (attempt to
parse the string as a bool the first time the config value is needed)
In addition, i notice this really confusing line...
{code}
propMap.put(CfgProp.SOLR_SHARESCHEMA,
doSub(solr/str[@name='shareSchema']));
{code}
shareSchema is used internally as a boolean option, but as written the
parsing code will ignore it unless the user explicitly configures it as a
{{str/}}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5473) Split clusterstate.json per collection and watch states selectively
[ https://issues.apache.org/jira/browse/SOLR-5473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-5473: - Attachment: SOLR-5473-74.patch if theUrlList is empty , it makes sense to invalidate cache and fail Split clusterstate.json per collection and watch states selectively Key: SOLR-5473 URL: https://issues.apache.org/jira/browse/SOLR-5473 Project: Solr Issue Type: Sub-task Components: SolrCloud Reporter: Noble Paul Assignee: Noble Paul Fix For: 5.0 Attachments: SOLR-5473-74 .patch, SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74_POC.patch, SOLR-5473-configname-fix.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473_undo.patch, ec2-23-20-119-52_solr.log, ec2-50-16-38-73_solr.log As defined in the parent issue, store the states of each collection under /collections/collectionname/state.json node -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-NightlyTests-4.x - Build # 579 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-4.x/579/ 2 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.handler.TestReplicationHandlerBackup Error Message: 1 thread leaked from SUITE scope at org.apache.solr.handler.TestReplicationHandlerBackup: 1) Thread[id=4286, name=Thread-2129, state=RUNNABLE, group=TGRP-TestReplicationHandlerBackup] at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) at java.net.Socket.connect(Socket.java:579) at java.net.Socket.connect(Socket.java:528) at sun.net.NetworkClient.doConnect(NetworkClient.java:180) at sun.net.www.http.HttpClient.openServer(HttpClient.java:432) at sun.net.www.http.HttpClient.openServer(HttpClient.java:527) at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:652) at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1323) at java.net.URL.openStream(URL.java:1037) at org.apache.solr.handler.TestReplicationHandlerBackup$BackupThread.run(TestReplicationHandlerBackup.java:314) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE scope at org.apache.solr.handler.TestReplicationHandlerBackup: 1) Thread[id=4286, name=Thread-2129, state=RUNNABLE, group=TGRP-TestReplicationHandlerBackup] at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) at java.net.Socket.connect(Socket.java:579) at java.net.Socket.connect(Socket.java:528) at sun.net.NetworkClient.doConnect(NetworkClient.java:180) at sun.net.www.http.HttpClient.openServer(HttpClient.java:432) at sun.net.www.http.HttpClient.openServer(HttpClient.java:527) at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:652) at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1323) at java.net.URL.openStream(URL.java:1037) at org.apache.solr.handler.TestReplicationHandlerBackup$BackupThread.run(TestReplicationHandlerBackup.java:314) at __randomizedtesting.SeedInfo.seed([F9DC4C562C640CC3]:0) FAILED: junit.framework.TestSuite.org.apache.solr.handler.TestReplicationHandlerBackup Error Message: There are still zombie threads that couldn't be terminated:1) Thread[id=4286, name=Thread-2129, state=RUNNABLE, group=TGRP-TestReplicationHandlerBackup] at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) at java.net.Socket.connect(Socket.java:579) at java.net.Socket.connect(Socket.java:528) at sun.net.NetworkClient.doConnect(NetworkClient.java:180) at sun.net.www.http.HttpClient.openServer(HttpClient.java:432) at sun.net.www.http.HttpClient.openServer(HttpClient.java:527) at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:652) at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1323) at java.net.URL.openStream(URL.java:1037) at org.apache.solr.handler.TestReplicationHandlerBackup$BackupThread.run(TestReplicationHandlerBackup.java:314) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: There are still zombie threads that couldn't be terminated: 1) Thread[id=4286, name=Thread-2129, state=RUNNABLE, group=TGRP-TestReplicationHandlerBackup] at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) at java.net.Socket.connect(Socket.java:579) at java.net.Socket.connect(Socket.java:528) at sun.net.NetworkClient.doConnect(NetworkClient.java:180) at
[JENKINS] Lucene-Solr-trunk-Windows (32bit/jdk1.8.0_20-ea-b21) - Build # 4192 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/4192/ Java: 32bit/jdk1.8.0_20-ea-b21 -client -XX:+UseConcMarkSweepGC All tests passed Build Log: [...truncated 51796 lines...] BUILD FAILED C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\build.xml:467: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\build.xml:406: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\extra-targets.xml:87: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\extra-targets.xml:181: Source checkout is dirty after running tests!!! Offending files: * ./solr/licenses/log4j-1.2.16.jar.sha1 Total time: 176 minutes 44 seconds Build step 'Invoke Ant' marked build as failure [description-setter] Description set: Java: 32bit/jdk1.8.0_20-ea-b21 -client -XX:+UseConcMarkSweepGC Archiving artifacts Recording test results Email was triggered for: Failure - Any Sending email for trigger: Failure - Any - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-trunk-Windows (32bit/jdk1.8.0_20-ea-b21) - Build # 4192 - Still Failing!
This may have been caused by me but I don't understand ... ./solr/licenses/log4j-1.2.16.jar.sha1 came up as a problem when running precommit task, so I did jar-checksums and then committed the resulting sha1 file ... why is the source checkout dirty? On Wed, Jul 16, 2014 at 11:46 AM, Policeman Jenkins Server jenk...@thetaphi.de wrote: Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/4192/ Java: 32bit/jdk1.8.0_20-ea-b21 -client -XX:+UseConcMarkSweepGC All tests passed Build Log: [...truncated 51796 lines...] BUILD FAILED C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\build.xml:467: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\build.xml:406: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\extra-targets.xml:87: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\extra-targets.xml:181: Source checkout is dirty after running tests!!! Offending files: * ./solr/licenses/log4j-1.2.16.jar.sha1 Total time: 176 minutes 44 seconds Build step 'Invoke Ant' marked build as failure [description-setter] Description set: Java: 32bit/jdk1.8.0_20-ea-b21 -client -XX:+UseConcMarkSweepGC Archiving artifacts Recording test results Email was triggered for: Failure - Any Sending email for trigger: Failure - Any - 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] (LUCENE-5826) Support proper hunspell case handling and related options
[
https://issues.apache.org/jira/browse/LUCENE-5826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14063799#comment-14063799
]
Ryan Ernst commented on LUCENE-5826:
Looks good. A couple minor comments.
* Can the TODO around line 176 of Stemmer.java be removed?
* {{stem()}} is pretty long. Can the block that computes {{compatible}} be
moved out? It is almost exactly the same for the prefix and suffix loops?
Support proper hunspell case handling and related options
-
Key: LUCENE-5826
URL: https://issues.apache.org/jira/browse/LUCENE-5826
Project: Lucene - Core
Issue Type: Improvement
Reporter: Robert Muir
Attachments: LUCENE-5826.patch
When ignoreCase=false, we should accept title-cased/upper-cased forms just
like hunspell -m. Furthermore there are some options around this:
* LANG: can turn on alternate casing for turkish/azeri
* KEEPCASE: can prevent acceptance of title/upper cased forms for words
While we are here setting up the same logic anyway, add support for similar
options:
* NEEDAFFIX/PSEUDOROOT: form is invalid without being affixed
* ONLYINCOMPOUND: form/affixes only make sense inside compounds.
This stuff is unrelated to the ignoreCase=true option. If you use that option
though, it does use correct alternate casing for tr_TR/az_AZ now though.
I didn't yet implement CHECKSHARPS because it seems more complicated, I have
to figure out what the logic there should be first.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5826) Support proper hunspell case handling and related options
[ https://issues.apache.org/jira/browse/LUCENE-5826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14063821#comment-14063821 ] Robert Muir commented on LUCENE-5826: - Thanks for looking. hmm, I removed the TODO locally, i dont know how it didnt make it into the patch. As far as refactoring stem(), I am opposed to this, its too early for that. Once the core features (e.g. decompounding) are implemented, then I think it will be the right time. Until then it will just cause pain with zero gain: create useless abstractions, oversharing, and bugs. Support proper hunspell case handling and related options - Key: LUCENE-5826 URL: https://issues.apache.org/jira/browse/LUCENE-5826 Project: Lucene - Core Issue Type: Improvement Reporter: Robert Muir Attachments: LUCENE-5826.patch When ignoreCase=false, we should accept title-cased/upper-cased forms just like hunspell -m. Furthermore there are some options around this: * LANG: can turn on alternate casing for turkish/azeri * KEEPCASE: can prevent acceptance of title/upper cased forms for words While we are here setting up the same logic anyway, add support for similar options: * NEEDAFFIX/PSEUDOROOT: form is invalid without being affixed * ONLYINCOMPOUND: form/affixes only make sense inside compounds. This stuff is unrelated to the ignoreCase=true option. If you use that option though, it does use correct alternate casing for tr_TR/az_AZ now though. I didn't yet implement CHECKSHARPS because it seems more complicated, I have to figure out what the logic there should be first. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-trunk-Windows (32bit/jdk1.8.0_20-ea-b21) - Build # 4192 - Still Failing!
Some bug in ivy around syncing jars if I remember right? I think you have to run clean-jars. This has happened before. -- Mark Miller about.me/markrmiller On July 16, 2014 at 10:53:15 AM, Timothy Potter (thelabd...@gmail.com) wrote: This may have been caused by me but I don't understand ... ./solr/licenses/log4j-1.2.16.jar.sha1 came up as a problem when running precommit task, so I did jar-checksums and then committed the resulting sha1 file ... why is the source checkout dirty? On Wed, Jul 16, 2014 at 11:46 AM, Policeman Jenkins Server wrote: Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/4192/ Java: 32bit/jdk1.8.0_20-ea-b21 -client -XX:+UseConcMarkSweepGC All tests passed Build Log: [...truncated 51796 lines...] BUILD FAILED C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\build.xml:467: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\build.xml:406: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\extra-targets.xml:87: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\extra-targets.xml:181: Source checkout is dirty after running tests!!! Offending files: * ./solr/licenses/log4j-1.2.16.jar.sha1 Total time: 176 minutes 44 seconds Build step 'Invoke Ant' marked build as failure [description-setter] Description set: Java: 32bit/jdk1.8.0_20-ea-b21 -client -XX:+UseConcMarkSweepGC Archiving artifacts Recording test results Email was triggered for: Failure - Any Sending email for trigger: Failure - Any - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5826) Support proper hunspell case handling and related options
[ https://issues.apache.org/jira/browse/LUCENE-5826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14063855#comment-14063855 ] Robert Muir commented on LUCENE-5826: - I created a followup issue to try to factor that big method after decomposition is implemented: LUCENE-5829 Support proper hunspell case handling and related options - Key: LUCENE-5826 URL: https://issues.apache.org/jira/browse/LUCENE-5826 Project: Lucene - Core Issue Type: Improvement Reporter: Robert Muir Attachments: LUCENE-5826.patch When ignoreCase=false, we should accept title-cased/upper-cased forms just like hunspell -m. Furthermore there are some options around this: * LANG: can turn on alternate casing for turkish/azeri * KEEPCASE: can prevent acceptance of title/upper cased forms for words While we are here setting up the same logic anyway, add support for similar options: * NEEDAFFIX/PSEUDOROOT: form is invalid without being affixed * ONLYINCOMPOUND: form/affixes only make sense inside compounds. This stuff is unrelated to the ignoreCase=true option. If you use that option though, it does use correct alternate casing for tr_TR/az_AZ now though. I didn't yet implement CHECKSHARPS because it seems more complicated, I have to figure out what the logic there should be first. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-5829) try to refactor main stem() loop of Hunspell stemmer
Robert Muir created LUCENE-5829: --- Summary: try to refactor main stem() loop of Hunspell stemmer Key: LUCENE-5829 URL: https://issues.apache.org/jira/browse/LUCENE-5829 Project: Lucene - Core Issue Type: Bug Reporter: Robert Muir As pointed out by Ryan on LUCENE-5826 This is the most complicated part, basically intersecting against 3 FSTs. But currently its premature to try to fix: its incomplete. it doesn't yet implement all the features it needs like decomposition. After we do this, we should see if we can refactor logic (e.g. somehow share affix compatibility better and so on). -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5473) Split clusterstate.json per collection and watch states selectively
[
https://issues.apache.org/jira/browse/SOLR-5473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14063857#comment-14063857
]
Jessica Cheng commented on SOLR-5473:
-
{quote}invalidate cache and fail{quote}
I think it should just behave as if it received an INVALID_STATE in the
response and tries to reload the zk state, and retry.
Split clusterstate.json per collection and watch states selectively
Key: SOLR-5473
URL: https://issues.apache.org/jira/browse/SOLR-5473
Project: Solr
Issue Type: Sub-task
Components: SolrCloud
Reporter: Noble Paul
Assignee: Noble Paul
Fix For: 5.0
Attachments: SOLR-5473-74 .patch, SOLR-5473-74.patch,
SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch,
SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch,
SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch,
SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch,
SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch,
SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch,
SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch,
SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch,
SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch,
SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch,
SOLR-5473-74.patch, SOLR-5473-74_POC.patch, SOLR-5473-configname-fix.patch,
SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch,
SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch,
SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch,
SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch,
SOLR-5473.patch, SOLR-5473.patch, SOLR-5473_undo.patch,
ec2-23-20-119-52_solr.log, ec2-50-16-38-73_solr.log
As defined in the parent issue, store the states of each collection under
/collections/collectionname/state.json node
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5825) Allowing the benchmarking algorithm to choose PostingsFormat
[ https://issues.apache.org/jira/browse/LUCENE-5825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Varun V Shenoy updated LUCENE-5825: Attachment: patch_17_Jul_2014 Supports configurable Postings Format through codec.postingsFormat alg parameter Allowing the benchmarking algorithm to choose PostingsFormat Key: LUCENE-5825 URL: https://issues.apache.org/jira/browse/LUCENE-5825 Project: Lucene - Core Issue Type: Improvement Components: modules/benchmark Affects Versions: 5.0 Reporter: Varun V Shenoy Priority: Minor Fix For: 5.0 Attachments: patch_17_Jul_2014 The algorithm file for benchmarking should allow PostingsFormat to be configurable. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5825) Allowing the benchmarking algorithm to choose PostingsFormat
[ https://issues.apache.org/jira/browse/LUCENE-5825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Varun V Shenoy updated LUCENE-5825: Attachment: (was: patch_17_Jul_2014) Allowing the benchmarking algorithm to choose PostingsFormat Key: LUCENE-5825 URL: https://issues.apache.org/jira/browse/LUCENE-5825 Project: Lucene - Core Issue Type: Improvement Components: modules/benchmark Affects Versions: 5.0 Reporter: Varun V Shenoy Priority: Minor Fix For: 5.0 The algorithm file for benchmarking should allow PostingsFormat to be configurable. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Issue Comment Deleted] (LUCENE-5825) Allowing the benchmarking algorithm to choose PostingsFormat
[ https://issues.apache.org/jira/browse/LUCENE-5825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Varun V Shenoy updated LUCENE-5825: Comment: was deleted (was: Supports configurable Postings Format through codec.postingsFormat alg parameter) Allowing the benchmarking algorithm to choose PostingsFormat Key: LUCENE-5825 URL: https://issues.apache.org/jira/browse/LUCENE-5825 Project: Lucene - Core Issue Type: Improvement Components: modules/benchmark Affects Versions: 5.0 Reporter: Varun V Shenoy Priority: Minor Fix For: 5.0 Attachments: patch_17_Jul_2014 The algorithm file for benchmarking should allow PostingsFormat to be configurable. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5825) Allowing the benchmarking algorithm to choose PostingsFormat
[ https://issues.apache.org/jira/browse/LUCENE-5825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Varun V Shenoy updated LUCENE-5825: Attachment: patch_17_Jul_2014 Supports configurable Postings Format through codec.postingsFormat alg parameter Allowing the benchmarking algorithm to choose PostingsFormat Key: LUCENE-5825 URL: https://issues.apache.org/jira/browse/LUCENE-5825 Project: Lucene - Core Issue Type: Improvement Components: modules/benchmark Affects Versions: 5.0 Reporter: Varun V Shenoy Priority: Minor Fix For: 5.0 Attachments: patch_17_Jul_2014 The algorithm file for benchmarking should allow PostingsFormat to be configurable. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-MAVEN] Lucene-Solr-Maven-trunk #1168: POMs out of sync
Build: https://builds.apache.org/job/Lucene-Solr-Maven-trunk/1168/ 2 tests failed. FAILED: org.apache.solr.core.TestCoreContainer.testDeleteBadCores Error Message: Unable to create core [badcore] Stack Trace: org.apache.solr.common.SolrException: Unable to create core [badcore] at org.apache.solr.core.ConfigSetService$Default.locateInstanceDir(ConfigSetService.java:157) at org.apache.solr.core.ConfigSetService$Default.createCoreResourceLoader(ConfigSetService.java:142) at org.apache.solr.core.ConfigSetService.getConfig(ConfigSetService.java:58) at org.apache.solr.core.CoreContainer.create(CoreContainer.java:485) at org.apache.solr.core.CoreContainer.create(CoreContainer.java:462) at org.apache.solr.core.TestCoreContainer.testDeleteBadCores(TestCoreContainer.java:241) FAILED: org.apache.solr.cloud.MultiThreadedOCPTest.testDistribSearch Error Message: Task 3002 did not complete, final state: running Stack Trace: java.lang.AssertionError: Task 3002 did not complete, final state: running at __randomizedtesting.SeedInfo.seed([D3B4B722FCDCA893:5252393A8B83C8AF]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.apache.solr.cloud.MultiThreadedOCPTest.testDeduplicationOfSubmittedTasks(MultiThreadedOCPTest.java:162) at org.apache.solr.cloud.MultiThreadedOCPTest.doTest(MultiThreadedOCPTest.java:71) Build Log: [...truncated 55048 lines...] BUILD FAILED /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Maven-trunk/build.xml:490: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Maven-trunk/build.xml:182: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Maven-trunk/extra-targets.xml:77: Java returned: 1 Total time: 228 minutes 16 seconds Build step 'Invoke Ant' marked build as failure Recording test results Email was triggered for: Failure Sending email for trigger: Failure - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-5826) Support proper hunspell case handling and related options
[ https://issues.apache.org/jira/browse/LUCENE-5826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir resolved LUCENE-5826. - Resolution: Fixed Fix Version/s: 4.10 5.0 Support proper hunspell case handling and related options - Key: LUCENE-5826 URL: https://issues.apache.org/jira/browse/LUCENE-5826 Project: Lucene - Core Issue Type: Improvement Reporter: Robert Muir Fix For: 5.0, 4.10 Attachments: LUCENE-5826.patch When ignoreCase=false, we should accept title-cased/upper-cased forms just like hunspell -m. Furthermore there are some options around this: * LANG: can turn on alternate casing for turkish/azeri * KEEPCASE: can prevent acceptance of title/upper cased forms for words While we are here setting up the same logic anyway, add support for similar options: * NEEDAFFIX/PSEUDOROOT: form is invalid without being affixed * ONLYINCOMPOUND: form/affixes only make sense inside compounds. This stuff is unrelated to the ignoreCase=true option. If you use that option though, it does use correct alternate casing for tr_TR/az_AZ now though. I didn't yet implement CHECKSHARPS because it seems more complicated, I have to figure out what the logic there should be first. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2894) Implement distributed pivot faceting
[
https://issues.apache.org/jira/browse/SOLR-2894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Muldowney updated SOLR-2894:
---
Attachment: SOLR-2894.patch
bq. Just to clarify: you are saying that bbc isn't included in the top set in
the distrib call because overrequest is so low, which is inconcsistent with the
control where bbc is in the top – but all of the values returned by the distrib
call do in fact have accurate refined counts ... correct?
It *was* not refining properly, which I attributed to the lack of overrequest
but that was incorrect. The test is actually the only one that tests the
following criteria:
* A value that should be in the top elements is not because the
overrequesting didn't pick it up or too many shards had values too small. (In
this case {{bbc}} only has a value of 150 from the initial round, when its
actual value is 445, larger than {{microsoft}}'s inital value of 398)
* There is a shard that has responded with an empty response, aka it has no
documents (shard#3 is always empty in the long test file)
When those two things combine we had an error in our refinement code where we
would add {{Integer.MAX_VALUE}} to the possible count, overflowing the {{int}}
and causing it to go negative, and we would never ask for refinement. So we
would get {{microsoft:398}} over {{bbc}} *Fixed*
I have fixed the null issue that keeps away from counting towards the
{{facet.limit}}
I have fixed the null issue that keeps it around even when its less than
{{facet.mincount}}
I have fixed the issue where an empty response from a shard would render all
values on the cusp of making it into the top values never get refined.
Are you still seeing the infinite recursion problem? The seeds you provided
earlier pass locally for me.
Implement distributed pivot faceting
Key: SOLR-2894
URL: https://issues.apache.org/jira/browse/SOLR-2894
Project: Solr
Issue Type: Improvement
Reporter: Erik Hatcher
Assignee: Hoss Man
Fix For: 4.9, 5.0
Attachments: SOLR-2894-mincount-minification.patch,
SOLR-2894-reworked.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch,
SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch,
SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch,
SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch,
SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch,
SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch,
SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch,
SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch,
SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch,
SOLR-2894_cloud_test.patch, dateToObject.patch, pivot_mincount_problem.sh
Following up on SOLR-792, pivot faceting currently only supports
undistributed mode. Distributed pivot faceting needs to be implemented.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-6252) Simplify UnInvertedField#getUnInvertedField synchronization module
Vamsee Yarlagadda created SOLR-6252: --- Summary: Simplify UnInvertedField#getUnInvertedField synchronization module Key: SOLR-6252 URL: https://issues.apache.org/jira/browse/SOLR-6252 Project: Solr Issue Type: Improvement Components: search Affects Versions: 5.0 Reporter: Vamsee Yarlagadda Priority: Minor Looks like UnInvertedField#getUnInvertedField has implemented a bit additional synchronization module rather than what is required, and thereby increasing the complexity. https://github.com/apache/lucene-solr/blob/trunk/solr/core/src/java/org/apache/solr/request/UnInvertedField.java#L667 As pointed out in the above link, as the synchronization is performed on the cache variable(which itself will protect the threads from obtaining access to the cache), we can safely remove all the placeholder flags. As long as cache.get() is in synchronized block, we can simply populate the cache with new entries and other threads will be able to see the changes. This change has been introduced in https://issues.apache.org/jira/browse/SOLR-2548 (Multithreaded faceting) -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6252) Simplify UnInvertedField#getUnInvertedField synchronization module
[ https://issues.apache.org/jira/browse/SOLR-6252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsee Yarlagadda updated SOLR-6252: Attachment: SOLR-6252.patch Simplify UnInvertedField#getUnInvertedField synchronization module -- Key: SOLR-6252 URL: https://issues.apache.org/jira/browse/SOLR-6252 Project: Solr Issue Type: Improvement Components: search Affects Versions: 5.0 Reporter: Vamsee Yarlagadda Priority: Minor Attachments: SOLR-6252.patch Looks like UnInvertedField#getUnInvertedField has implemented a bit additional synchronization module rather than what is required, and thereby increasing the complexity. https://github.com/apache/lucene-solr/blob/trunk/solr/core/src/java/org/apache/solr/request/UnInvertedField.java#L667 As pointed out in the above link, as the synchronization is performed on the cache variable(which itself will protect the threads from obtaining access to the cache), we can safely remove all the placeholder flags. As long as cache.get() is in synchronized block, we can simply populate the cache with new entries and other threads will be able to see the changes. This change has been introduced in https://issues.apache.org/jira/browse/SOLR-2548 (Multithreaded faceting) -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6252) Simplify UnInvertedField#getUnInvertedField synchronization module
[ https://issues.apache.org/jira/browse/SOLR-6252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14064290#comment-14064290 ] Gregory Chanan commented on SOLR-6252: -- bq. // This thread will load this field, don't let other threads try. This comment no longer seems relevant Simplify UnInvertedField#getUnInvertedField synchronization module -- Key: SOLR-6252 URL: https://issues.apache.org/jira/browse/SOLR-6252 Project: Solr Issue Type: Improvement Components: search Affects Versions: 5.0 Reporter: Vamsee Yarlagadda Priority: Minor Attachments: SOLR-6252.patch Looks like UnInvertedField#getUnInvertedField has implemented a bit additional synchronization module rather than what is required, and thereby increasing the complexity. https://github.com/apache/lucene-solr/blob/trunk/solr/core/src/java/org/apache/solr/request/UnInvertedField.java#L667 As pointed out in the above link, as the synchronization is performed on the cache variable(which itself will protect the threads from obtaining access to the cache), we can safely remove all the placeholder flags. As long as cache.get() is in synchronized block, we can simply populate the cache with new entries and other threads will be able to see the changes. This change has been introduced in https://issues.apache.org/jira/browse/SOLR-2548 (Multithreaded faceting) -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6252) Simplify UnInvertedField#getUnInvertedField synchronization module
[ https://issues.apache.org/jira/browse/SOLR-6252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsee Yarlagadda updated SOLR-6252: Attachment: SOLR-6252v2.patch Removed the extra comment as pointed by Greg. Simplify UnInvertedField#getUnInvertedField synchronization module -- Key: SOLR-6252 URL: https://issues.apache.org/jira/browse/SOLR-6252 Project: Solr Issue Type: Improvement Components: search Affects Versions: 5.0 Reporter: Vamsee Yarlagadda Priority: Minor Attachments: SOLR-6252.patch, SOLR-6252v2.patch Looks like UnInvertedField#getUnInvertedField has implemented a bit additional synchronization module rather than what is required, and thereby increasing the complexity. https://github.com/apache/lucene-solr/blob/trunk/solr/core/src/java/org/apache/solr/request/UnInvertedField.java#L667 As pointed out in the above link, as the synchronization is performed on the cache variable(which itself will protect the threads from obtaining access to the cache), we can safely remove all the placeholder flags. As long as cache.get() is in synchronized block, we can simply populate the cache with new entries and other threads will be able to see the changes. This change has been introduced in https://issues.apache.org/jira/browse/SOLR-2548 (Multithreaded faceting) -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6251) incorrect 'missing required field' during update - document definitely has it
[
https://issues.apache.org/jira/browse/SOLR-6251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14064477#comment-14064477
]
Nathan Neulinger commented on SOLR-6251:
FYI. We finally tracked down the problem at least 99.9% sure at this point,
and it was staring me in the face the whole time - just never noticed:
{noformat}
[{id:4b2c4d09-31e2-4fe2-b767-3868efbdcda1,channel: {add:
preet},channel: {add: adam}}]
{noformat}
Look at the JSON... It's trying to add two channels... Should have been:
{noformat}
[{id:4b2c4d09-31e2-4fe2-b767-3868efbdcda1,channel: {add: preet}},
{id:4b2c4d09-31e2-4fe2-b767-3868efbdcda1,channel: {add: adam}}]
{noformat}
I half wonder how it chose to interpret that particular chunk of json, but
either way, I think the origin of our issue is resolved.
incorrect 'missing required field' during update - document definitely has it
-
Key: SOLR-6251
URL: https://issues.apache.org/jira/browse/SOLR-6251
Project: Solr
Issue Type: Bug
Components: SolrCloud
Affects Versions: 4.8
Environment: 4.8.0. Two nodes, SolrCloud, external ZK ensemble. All
on EC2. The two hosts are round-robin'd behind an ELB.
Reporter: Nathan Neulinger
Labels: replication
Attachments: schema.xml
Document added on solr1. We can see the distribute take place from solr1 to
solr2 and returning a success. Subsequent searches returning document,
clearly showing the field as being there. Later on, an update is done to add
to an element of the document - and the update fails. The update was sent to
solr2 instance.
Schema marks the 'timestamp' field as required, so the initial insert should
not work if the field isn't present.
Symptom is intermittent - we're seeing this randomly, with no warning or
triggering that we can see, but in all cases, it's getting the error in
response to an update when the instance tries to distribute the change to the
other node.
Searches that were run AFTER the update also show the field as being present
in the document.
Will add full trace of operations in the comments shortly. pcap captures of
ALL traffic for the two nodes on 8983 is available if requested.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0_20-ea-b21) - Build # 10833 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/10833/ Java: 64bit/jdk1.8.0_20-ea-b21 -XX:-UseCompressedOops -XX:+UseG1GC All tests passed Build Log: [...truncated 58865 lines...] BUILD FAILED /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:467: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:406: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/extra-targets.xml:87: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/extra-targets.xml:181: Source checkout is dirty after running tests!!! Offending files: * ./solr/licenses/log4j-1.2.16.jar.sha1 Total time: 108 minutes 4 seconds Build step 'Invoke Ant' marked build as failure [description-setter] Description set: Java: 64bit/jdk1.8.0_20-ea-b21 -XX:-UseCompressedOops -XX:+UseG1GC Archiving artifacts Recording test results Email was triggered for: Failure - Any Sending email for trigger: Failure - Any - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0_05) - Build # 10834 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/10834/ Java: 64bit/jdk1.8.0_05 -XX:+UseCompressedOops -XX:+UseSerialGC 1 tests failed. REGRESSION: org.apache.lucene.uninverting.TestFieldCacheSort.testEmptyStringVsNullStringSort Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([7E05B9090292D3F9:1FE68BDE7AF3D549]:0) at org.apache.lucene.index.AssertingAtomicReader.getSortedDocValues(AssertingAtomicReader.java:638) at org.apache.lucene.index.MultiDocValues.getSortedValues(MultiDocValues.java:312) at org.apache.lucene.index.SlowCompositeReaderWrapper.getSortedDocValues(SlowCompositeReaderWrapper.java:128) at org.apache.lucene.index.FilterAtomicReader.getSortedDocValues(FilterAtomicReader.java:414) at org.apache.lucene.index.AssertingAtomicReader.getSortedDocValues(AssertingAtomicReader.java:635) at org.apache.lucene.index.ParallelAtomicReader.getSortedDocValues(ParallelAtomicReader.java:288) at org.apache.lucene.index.DocValues.getSorted(DocValues.java:273) at org.apache.lucene.search.FieldComparator$TermOrdValComparator.getSortedDocValues(FieldComparator.java:821) at org.apache.lucene.search.FieldComparator$TermOrdValComparator.setNextReader(FieldComparator.java:826) at org.apache.lucene.search.TopFieldCollector$OneComparatorNonScoringCollector.doSetNextReader(TopFieldCollector.java:97) at org.apache.lucene.search.SimpleCollector.getLeafCollector(SimpleCollector.java:33) at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:605) at org.apache.lucene.search.AssertingIndexSearcher.search(AssertingIndexSearcher.java:94) at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:573) at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:525) at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:502) at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:318) at org.apache.lucene.uninverting.TestFieldCacheSort.testEmptyStringVsNullStringSort(TestFieldCacheSort.java:1029) 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
