[jira] [Commented] (LUCENE-5914) More options for stored fields compression
[ https://issues.apache.org/jira/browse/LUCENE-5914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231144#comment-14231144 ] Adrien Grand commented on LUCENE-5914: -- For the benchmarks, there are two reasons I think: - merging is not optimized to the byte level at all (yet?) - making each document compressible on its own makes the compressing more complicated (hence slow) Let's move forward with your idea to reuse the lz4 hc format as a first step. I will try to improve the shared dictionary approach in a different issue. More options for stored fields compression -- Key: LUCENE-5914 URL: https://issues.apache.org/jira/browse/LUCENE-5914 Project: Lucene - Core Issue Type: Improvement Reporter: Adrien Grand Assignee: Adrien Grand Fix For: 5.0 Attachments: LUCENE-5914.patch, LUCENE-5914.patch, LUCENE-5914.patch, LUCENE-5914.patch, LUCENE-5914.patch Since we added codec-level compression in Lucene 4.1 I think I got about the same amount of users complaining that compression was too aggressive and that compression was too light. I think it is due to the fact that we have users that are doing very different things with Lucene. For example if you have a small index that fits in the filesystem cache (or is close to), then you might never pay for actual disk seeks and in such a case the fact that the current stored fields format needs to over-decompress data can sensibly slow search down on cheap queries. On the other hand, it is more and more common to use Lucene for things like log analytics, and in that case you have huge amounts of data for which you don't care much about stored fields performance. However it is very frustrating to notice that the data that you store takes several times less space when you gzip it compared to your index although Lucene claims to compress stored fields. For that reason, I think it would be nice to have some kind of options that would allow to trade speed for compression in the default codec. -- 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-5914) More options for stored fields compression
[ https://issues.apache.org/jira/browse/LUCENE-5914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231163#comment-14231163 ] Robert Muir commented on LUCENE-5914: - the benchmark I did here are for HighCompressingCodec aka CompressionMode.HIGH_COMPRESSION which is actually deflate, not lz4 hc. I benchmarked lz4 hc as well, but i didn't seem like the right tradeoff, slow writes but for not much benefit. More options for stored fields compression -- Key: LUCENE-5914 URL: https://issues.apache.org/jira/browse/LUCENE-5914 Project: Lucene - Core Issue Type: Improvement Reporter: Adrien Grand Assignee: Adrien Grand Fix For: 5.0 Attachments: LUCENE-5914.patch, LUCENE-5914.patch, LUCENE-5914.patch, LUCENE-5914.patch, LUCENE-5914.patch Since we added codec-level compression in Lucene 4.1 I think I got about the same amount of users complaining that compression was too aggressive and that compression was too light. I think it is due to the fact that we have users that are doing very different things with Lucene. For example if you have a small index that fits in the filesystem cache (or is close to), then you might never pay for actual disk seeks and in such a case the fact that the current stored fields format needs to over-decompress data can sensibly slow search down on cheap queries. On the other hand, it is more and more common to use Lucene for things like log analytics, and in that case you have huge amounts of data for which you don't care much about stored fields performance. However it is very frustrating to notice that the data that you store takes several times less space when you gzip it compared to your index although Lucene claims to compress stored fields. For that reason, I think it would be nice to have some kind of options that would allow to trade speed for compression in the default codec. -- 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: r1641902 - in /lucene/dev/trunk/lucene: core/src/test/org/apache/lucene/index/TestIndexWriter.java test-framework/src/java/org/apache/lucene/mockfile/FilterFileSystem.java test-framewo
I'll fix the message to make it clear you are not running on WINDOWS
but rather our WindowsFS.
I agree we should strive to have our tests be portable across OS's ...
But unfortunately this test case is for a nasty corruption bug
(LUCENE-5574) that can't happen on Windows...
Mike McCandless
http://blog.mikemccandless.com
On Mon, Dec 1, 2014 at 7:14 PM, Robert Muir rcm...@gmail.com wrote:
-1.
our test framework doesnt need to support this. the problem here is
the test, its no good and doesnt work on windows. An assume is the
correct answer for a shitty test.
On Mon, Dec 1, 2014 at 5:46 PM, Chris Hostetter
hossman_luc...@fucit.org wrote:
: assumeFalse(this test can't run on Windows, Constants.WINDOWS);
:
: MockDirectoryWrapper dir = newMockDirectory();
: +if (TestUtil.isWindowsFS(dir)) {
: + dir.close();
: + assumeFalse(this test can't run on Windows, true);
: +}
this specific assume msg seems like a bad idea.
ie: a new dev, who doesn't know about the FS mocking behavior of
the test cases, who tries to run lucene tests on a mac and sees a
test skipped with the message this test can't run on Windows i'm going
to be confused as hell.
I also have to wonder: rather then just a straight assumeFalse, wouldn't
it be better in this case to just upwrap the mock windowsfs and just
explicitly use the real fs for this particular test? (in hte interest of
maximizing test coverage)
-Hoss
http://www.lucidworks.com/
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4509) Disable HttpClient stale check for performance and fewer spurious connection errors.
[ https://issues.apache.org/jira/browse/SOLR-4509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231190#comment-14231190 ] Oleg Kalnichevski commented on SOLR-4509: - The idea behind connection check optimizations in HC 4.4 is rather straight-forward: given the 'stale' check cannot be 100% reliable (the connection can turn 'stale' immediately after passing the check but before a request is issued) there is no point checking the connection indiscriminately before each and every request. It generally should be sufficient to check those connections that are more likely to get 'stale'. Usually those are the connections that have been sitting idle in the connection pool for a considerable period of time. HC 4.4 is most likely going to get delayed by a month or two. So, there should enough time to contribute an alternative solution if it turns out to be better than what we currently have. Oleg Disable HttpClient stale check for performance and fewer spurious connection errors. Key: SOLR-4509 URL: https://issues.apache.org/jira/browse/SOLR-4509 Project: Solr Issue Type: Improvement Components: search Environment: 5 node SmartOS cluster (all nodes living in same global zone - i.e. same physical machine) Reporter: Ryan Zezeski Assignee: Mark Miller Priority: Minor Fix For: 5.0, Trunk Attachments: IsStaleTime.java, SOLR-4509-4_4_0.patch, SOLR-4509.patch, SOLR-4509.patch, SOLR-4509.patch, SOLR-4509.patch, SOLR-4509.patch, baremetal-stale-nostale-med-latency.dat, baremetal-stale-nostale-med-latency.svg, baremetal-stale-nostale-throughput.dat, baremetal-stale-nostale-throughput.svg By disabling the Apache HTTP Client stale check I've witnessed a 2-4x increase in throughput and reduction of over 100ms. This patch was made in the context of a project I'm leading, called Yokozuna, which relies on distributed search. Here's the patch on Yokozuna: https://github.com/rzezeski/yokozuna/pull/26 Here's a write-up I did on my findings: http://www.zinascii.com/2013/solr-distributed-search-and-the-stale-check.html I'm happy to answer any questions or make changes to the patch to make it acceptable. ReviewBoard: https://reviews.apache.org/r/28393/ -- 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] (LUCENE-6086) Minor optimizations to the encoding of numerics in stored fields
Adrien Grand created LUCENE-6086: Summary: Minor optimizations to the encoding of numerics in stored fields Key: LUCENE-6086 URL: https://issues.apache.org/jira/browse/LUCENE-6086 Project: Lucene - Core Issue Type: Improvement Reporter: Adrien Grand Assignee: Adrien Grand Priority: Minor Fix For: 5.0 LUCENE-5914 explored minor optimizations for numeric encoding in stored fields, I think we should try to push them to the default format. -- 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-6086) Minor optimizations to the encoding of numerics in stored fields
[ https://issues.apache.org/jira/browse/LUCENE-6086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrien Grand updated LUCENE-6086: - Attachment: LUCENE-6086.patch The idea behing this encoding is that longs are often used to store timestamps, and that floats and doubles often store simple integral values. Here is a patch and a quick summary of the improvements. Float value representing an integer in -63..63: - trunk: 4 bytes - patch: 1 byte Other positive float values: - trunk: 4 bytes - patch: 4 bytes Other negative float values: - trunk: 4 bytes - patch: 5 bytes Double value representing an integer in -63..62: - trunk: 8 bytes - patch: 1 byte Double value that can be represented exactly with a float (eg. 1000, 0.25) - trunk: 8 bytes - patch: 5 bytes Other positive double values: - trunk: 8 bytes - patch: 8 bytes Other negative double values: - trunk: 8 bytes - patch: 9 bytes Long values use zig-zag encoding with some optimizations for timestamps. So for instance a number in -16..15: - trunk: 8 bytes - patch: 1 byte Now with second-level precision: - trunk: 8 bytes - patch: 5 bytes Now with hour-level precision: - trunk: 8 bytes - patch: 4 bytes Today (day precision): - trunk: 8 bytes - patch: 3 bytes Minor optimizations to the encoding of numerics in stored fields Key: LUCENE-6086 URL: https://issues.apache.org/jira/browse/LUCENE-6086 Project: Lucene - Core Issue Type: Improvement Reporter: Adrien Grand Assignee: Adrien Grand Priority: Minor Fix For: 5.0 Attachments: LUCENE-6086.patch LUCENE-5914 explored minor optimizations for numeric encoding in stored fields, I think we should try to push them to the default format. -- 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-6085) Add back SI.attributes (safely)
[ https://issues.apache.org/jira/browse/LUCENE-6085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231202#comment-14231202 ] Adrien Grand commented on LUCENE-6085: -- +1 Add back SI.attributes (safely) --- Key: LUCENE-6085 URL: https://issues.apache.org/jira/browse/LUCENE-6085 Project: Lucene - Core Issue Type: Bug Reporter: Robert Muir Attachments: LUCENE-6085.patch We removed this for two reasons: * nothing was using it * the map is unsafe if a codec tried to write to it during in-place dv update. But Adrien has a real use case (LUCENE-5914), and I think we can just add some safety for the updates case (e.g. if the map is unmodifiable then the trap will not exist, any put() will throw exception). In general, we should have more safety in SI anyway (diagnostics map, too). -- 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-5873) AssertionError in ToChildBlockJoinScorer.advance
[
https://issues.apache.org/jira/browse/LUCENE-5873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231210#comment-14231210
]
Adrien Grand commented on LUCENE-5873:
--
The contract of advance is to return the next matching doc ID on or after the
target, so it feels wrong to restrict the values that are legal as targets?
What about advancing to the next block by doing something like the code below?
{code}
if (parentBits.get(childTarget)) {
childTarget += 1;
}
{code}
AssertionError in ToChildBlockJoinScorer.advance
Key: LUCENE-5873
URL: https://issues.apache.org/jira/browse/LUCENE-5873
Project: Lucene - Core
Issue Type: Bug
Reporter: Varun Thacker
Priority: Minor
Attachments: LUCENE-5873.patch, LUCENE-5873.patch
When using ToChildBJQ and searching via IndexSearcher.search(Query query,
Filter filter, int n) if we provide a filter which matches both parent and
child documents we get this error
{noformat}
java.lang.AssertionError
at
__randomizedtesting.SeedInfo.seed([C346722DC1E4810C:A08F176AE828FA1D]:0)
at
org.apache.lucene.search.join.ToChildBlockJoinQuery$ToChildBlockJoinScorer.advance(ToChildBlockJoinQuery.java:286)
at
org.apache.lucene.search.FilteredQuery$LeapFrogScorer.advanceToNextCommonDoc(FilteredQuery.java:274)
at
org.apache.lucene.search.FilteredQuery$LeapFrogScorer.nextDoc(FilteredQuery.java:286)
at
org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll(Weight.java:192)
at
org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:163)
at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:35)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:614)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:483)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:440)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:273)
at
org.apache.lucene.search.join.TestBlockJoinValidation.testValidationForToChildBjqWithChildFilterQuery(TestBlockJoinValidation.java:124)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
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.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:110)
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
[jira] [Commented] (LUCENE-5873) AssertionError in ToChildBlockJoinScorer.advance
[
https://issues.apache.org/jira/browse/LUCENE-5873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231212#comment-14231212
]
Adrien Grand commented on LUCENE-5873:
--
(Just realized that some parents might not have children, so we would probably
rather required something like nextClearBit)
AssertionError in ToChildBlockJoinScorer.advance
Key: LUCENE-5873
URL: https://issues.apache.org/jira/browse/LUCENE-5873
Project: Lucene - Core
Issue Type: Bug
Reporter: Varun Thacker
Priority: Minor
Attachments: LUCENE-5873.patch, LUCENE-5873.patch
When using ToChildBJQ and searching via IndexSearcher.search(Query query,
Filter filter, int n) if we provide a filter which matches both parent and
child documents we get this error
{noformat}
java.lang.AssertionError
at
__randomizedtesting.SeedInfo.seed([C346722DC1E4810C:A08F176AE828FA1D]:0)
at
org.apache.lucene.search.join.ToChildBlockJoinQuery$ToChildBlockJoinScorer.advance(ToChildBlockJoinQuery.java:286)
at
org.apache.lucene.search.FilteredQuery$LeapFrogScorer.advanceToNextCommonDoc(FilteredQuery.java:274)
at
org.apache.lucene.search.FilteredQuery$LeapFrogScorer.nextDoc(FilteredQuery.java:286)
at
org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll(Weight.java:192)
at
org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:163)
at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:35)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:614)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:483)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:440)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:273)
at
org.apache.lucene.search.join.TestBlockJoinValidation.testValidationForToChildBjqWithChildFilterQuery(TestBlockJoinValidation.java:124)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
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.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:110)
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
[jira] [Comment Edited] (LUCENE-5873) AssertionError in ToChildBlockJoinScorer.advance
[
https://issues.apache.org/jira/browse/LUCENE-5873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231212#comment-14231212
]
Adrien Grand edited comment on LUCENE-5873 at 12/2/14 9:36 AM:
---
(Just realized that some parents might not have children, so we would probably
rather require something like nextClearBit)
was (Author: jpountz):
(Just realized that some parents might not have children, so we would probably
rather required something like nextClearBit)
AssertionError in ToChildBlockJoinScorer.advance
Key: LUCENE-5873
URL: https://issues.apache.org/jira/browse/LUCENE-5873
Project: Lucene - Core
Issue Type: Bug
Reporter: Varun Thacker
Priority: Minor
Attachments: LUCENE-5873.patch, LUCENE-5873.patch
When using ToChildBJQ and searching via IndexSearcher.search(Query query,
Filter filter, int n) if we provide a filter which matches both parent and
child documents we get this error
{noformat}
java.lang.AssertionError
at
__randomizedtesting.SeedInfo.seed([C346722DC1E4810C:A08F176AE828FA1D]:0)
at
org.apache.lucene.search.join.ToChildBlockJoinQuery$ToChildBlockJoinScorer.advance(ToChildBlockJoinQuery.java:286)
at
org.apache.lucene.search.FilteredQuery$LeapFrogScorer.advanceToNextCommonDoc(FilteredQuery.java:274)
at
org.apache.lucene.search.FilteredQuery$LeapFrogScorer.nextDoc(FilteredQuery.java:286)
at
org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll(Weight.java:192)
at
org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:163)
at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:35)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:614)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:483)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:440)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:273)
at
org.apache.lucene.search.join.TestBlockJoinValidation.testValidationForToChildBjqWithChildFilterQuery(TestBlockJoinValidation.java:124)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
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.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:110)
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
[jira] [Commented] (LUCENE-5873) AssertionError in ToChildBlockJoinScorer.advance
[
https://issues.apache.org/jira/browse/LUCENE-5873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231221#comment-14231221
]
Michael McCandless commented on LUCENE-5873:
Not that this is a violation of the contract of ToChildBJQ, i.e. that top-level
Filter must only match parent docs.
Still, I think we should make a best effort to detect mis-use and throw a
reasonable exception instead of AssertionError.
AssertionError in ToChildBlockJoinScorer.advance
Key: LUCENE-5873
URL: https://issues.apache.org/jira/browse/LUCENE-5873
Project: Lucene - Core
Issue Type: Bug
Reporter: Varun Thacker
Priority: Minor
Attachments: LUCENE-5873.patch, LUCENE-5873.patch
When using ToChildBJQ and searching via IndexSearcher.search(Query query,
Filter filter, int n) if we provide a filter which matches both parent and
child documents we get this error
{noformat}
java.lang.AssertionError
at
__randomizedtesting.SeedInfo.seed([C346722DC1E4810C:A08F176AE828FA1D]:0)
at
org.apache.lucene.search.join.ToChildBlockJoinQuery$ToChildBlockJoinScorer.advance(ToChildBlockJoinQuery.java:286)
at
org.apache.lucene.search.FilteredQuery$LeapFrogScorer.advanceToNextCommonDoc(FilteredQuery.java:274)
at
org.apache.lucene.search.FilteredQuery$LeapFrogScorer.nextDoc(FilteredQuery.java:286)
at
org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll(Weight.java:192)
at
org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:163)
at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:35)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:614)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:483)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:440)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:273)
at
org.apache.lucene.search.join.TestBlockJoinValidation.testValidationForToChildBjqWithChildFilterQuery(TestBlockJoinValidation.java:124)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
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.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:110)
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
[jira] [Comment Edited] (LUCENE-5873) AssertionError in ToChildBlockJoinScorer.advance
[
https://issues.apache.org/jira/browse/LUCENE-5873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231221#comment-14231221
]
Michael McCandless edited comment on LUCENE-5873 at 12/2/14 9:55 AM:
-
Note that this is a violation of the contract of ToChildBJQ, i.e. that
top-level Filter must only match parent docs.
Still, I think we should make a best effort to detect mis-use and throw a
reasonable exception instead of AssertionError.
was (Author: mikemccand):
Not that this is a violation of the contract of ToChildBJQ, i.e. that top-level
Filter must only match parent docs.
Still, I think we should make a best effort to detect mis-use and throw a
reasonable exception instead of AssertionError.
AssertionError in ToChildBlockJoinScorer.advance
Key: LUCENE-5873
URL: https://issues.apache.org/jira/browse/LUCENE-5873
Project: Lucene - Core
Issue Type: Bug
Reporter: Varun Thacker
Priority: Minor
Attachments: LUCENE-5873.patch, LUCENE-5873.patch
When using ToChildBJQ and searching via IndexSearcher.search(Query query,
Filter filter, int n) if we provide a filter which matches both parent and
child documents we get this error
{noformat}
java.lang.AssertionError
at
__randomizedtesting.SeedInfo.seed([C346722DC1E4810C:A08F176AE828FA1D]:0)
at
org.apache.lucene.search.join.ToChildBlockJoinQuery$ToChildBlockJoinScorer.advance(ToChildBlockJoinQuery.java:286)
at
org.apache.lucene.search.FilteredQuery$LeapFrogScorer.advanceToNextCommonDoc(FilteredQuery.java:274)
at
org.apache.lucene.search.FilteredQuery$LeapFrogScorer.nextDoc(FilteredQuery.java:286)
at
org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll(Weight.java:192)
at
org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:163)
at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:35)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:614)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:483)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:440)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:273)
at
org.apache.lucene.search.join.TestBlockJoinValidation.testValidationForToChildBjqWithChildFilterQuery(TestBlockJoinValidation.java:124)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
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.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:110)
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
[jira] [Created] (LUCENE-6087) SearcherManager should accept foreign DirectoryReader on init
Michael McCandless created LUCENE-6087: -- Summary: SearcherManager should accept foreign DirectoryReader on init Key: LUCENE-6087 URL: https://issues.apache.org/jira/browse/LUCENE-6087 Project: Lucene - Core Issue Type: Improvement Reporter: Michael McCandless Assignee: Michael McCandless Fix For: Trunk, 5.x Today you init SearcherManager either with a dir or an IndexWriter, but since we have a useful FilterDirectoryReader class to wrap the sub-readers, it's useful for apps to also pass their own wrapped DirectoryReader and have SearcherManager reopen from that. -- 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-6087) SearcherManager should accept foreign DirectoryReader on init
[ https://issues.apache.org/jira/browse/LUCENE-6087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless updated LUCENE-6087: --- Attachment: LUCENE-6087.patch Simple patch + test; I think it's ready. SearcherManager should accept foreign DirectoryReader on init - Key: LUCENE-6087 URL: https://issues.apache.org/jira/browse/LUCENE-6087 Project: Lucene - Core Issue Type: Improvement Reporter: Michael McCandless Assignee: Michael McCandless Fix For: Trunk, 5.x Attachments: LUCENE-6087.patch Today you init SearcherManager either with a dir or an IndexWriter, but since we have a useful FilterDirectoryReader class to wrap the sub-readers, it's useful for apps to also pass their own wrapped DirectoryReader and have SearcherManager reopen from that. -- 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-5.x - Build # 690 - Failure
I committed a fix: the test got MockRandomMP, causing O(N^2) merging Mike McCandless http://blog.mikemccandless.com On Mon, Dec 1, 2014 at 5:14 PM, Michael McCandless luc...@mikemccandless.com wrote: I'll dig. Mike McCandless http://blog.mikemccandless.com On Mon, Dec 1, 2014 at 5:12 PM, Apache Jenkins Server jenk...@builds.apache.org wrote: Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-5.x/690/ 2 tests failed. REGRESSION: org.apache.lucene.index.TestDemoParallelLeafReader.testRandomMultipleSchemaGensSameField Error Message: Test abandoned because suite timeout was reached. Stack Trace: java.lang.Exception: Test abandoned because suite timeout was reached. at __randomizedtesting.SeedInfo.seed([1A30B36FF7E830A0]:0) FAILED: junit.framework.TestSuite.org.apache.lucene.index.TestDemoParallelLeafReader Error Message: Suite timeout exceeded (= 720 msec). Stack Trace: java.lang.Exception: Suite timeout exceeded (= 720 msec). at __randomizedtesting.SeedInfo.seed([1A30B36FF7E830A0]:0) Build Log: [...truncated 1679 lines...] [junit4] Suite: org.apache.lucene.index.TestDemoParallelLeafReader [junit4] 2 ??? 01, 2014 10:21:13 ? com.carrotsearch.randomizedtesting.ThreadLeakControl$2 evaluate [junit4] 2 WARNING: Suite execution timed out: org.apache.lucene.index.TestDemoParallelLeafReader [junit4] 2 jstack at approximately timeout time [junit4] 2 TEST-TestDemoParallelLeafReader.testRandomMultipleSchemaGensSameField-seed#[1A30B36FF7E830A0] ID=22 RUNNABLE [junit4] 2at sun.nio.fs.UnixNativeDispatcher.open0(Native Method) [junit4] 2at sun.nio.fs.UnixNativeDispatcher.open(UnixNativeDispatcher.java:71) [junit4] 2at sun.nio.fs.UnixChannelFactory.open(UnixChannelFactory.java:258) [junit4] 2at sun.nio.fs.UnixChannelFactory.newFileChannel(UnixChannelFactory.java:136) [junit4] 2at sun.nio.fs.UnixChannelFactory.newFileChannel(UnixChannelFactory.java:149) [junit4] 2at sun.nio.fs.UnixFileSystemProvider.newFileChannel(UnixFileSystemProvider.java:175) [junit4] 2at org.apache.lucene.mockfile.FilterFileSystemProvider.newFileChannel(FilterFileSystemProvider.java:180) [junit4] 2at org.apache.lucene.mockfile.DisableFsyncFS.newFileChannel(DisableFsyncFS.java:46) [junit4] 2at org.apache.lucene.mockfile.FilterFileSystemProvider.newFileChannel(FilterFileSystemProvider.java:180) [junit4] 2at org.apache.lucene.mockfile.HandleTrackingFS.newFileChannel(HandleTrackingFS.java:151) [junit4] 2at org.apache.lucene.mockfile.FilterFileSystemProvider.newFileChannel(FilterFileSystemProvider.java:180) [junit4] 2at org.apache.lucene.mockfile.HandleTrackingFS.newFileChannel(HandleTrackingFS.java:151) [junit4] 2at java.nio.channels.FileChannel.open(FileChannel.java:287) [junit4] 2at java.nio.channels.FileChannel.open(FileChannel.java:334) [junit4] 2at org.apache.lucene.store.MMapDirectory.openInput(MMapDirectory.java:205) [junit4] 2at org.apache.lucene.store.FilterDirectory.openInput(FilterDirectory.java:80) [junit4] 2at org.apache.lucene.store.MockDirectoryWrapper.openInput(MockDirectoryWrapper.java:654) [junit4] 2- locked org.apache.lucene.store.MockDirectoryWrapper@3f04f430 [junit4] 2at org.apache.lucene.store.FilterDirectory.openInput(FilterDirectory.java:80) [junit4] 2at org.apache.lucene.codecs.lucene50.Lucene50CompoundFormat.write(Lucene50CompoundFormat.java:91) [junit4] 2at org.apache.lucene.index.IndexWriter.createCompoundFile(IndexWriter.java:4504) [junit4] 2at org.apache.lucene.index.DocumentsWriterPerThread.sealFlushedSegment(DocumentsWriterPerThread.java:509) [junit4] 2at org.apache.lucene.index.DocumentsWriterPerThread.flush(DocumentsWriterPerThread.java:476) [junit4] 2at org.apache.lucene.index.DocumentsWriter.doFlush(DocumentsWriter.java:514) [junit4] 2at org.apache.lucene.index.DocumentsWriter.postUpdate(DocumentsWriter.java:379) [junit4] 2at org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:478) [junit4] 2at org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1398) [junit4] 2at org.apache.lucene.index.IndexWriter.addDocument(IndexWriter.java:1133) [junit4] 2at org.apache.lucene.index.IndexWriter.addDocument(IndexWriter.java:1118) [junit4] 2at org.apache.lucene.index.TestDemoParallelLeafReader$3.reindex(TestDemoParallelLeafReader.java:823) [junit4] 2at org.apache.lucene.index.TestDemoParallelLeafReader$ReindexingReader.getParallelLeafReader(TestDemoParallelLeafReader.java:394)
[jira] [Updated] (SOLR-6559) Create an endpoint /update/xml/docs endpoint to do custom xml indexing
[ https://issues.apache.org/jira/browse/SOLR-6559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anurag Sharma updated SOLR-6559: Attachment: SOLR-6559.patch Attached unit test demonstrates flattening capabilities of XPathRecordReader. For /update/xml/docs endpoint should we keep the XPath syntax and also support /update/json/docs format for indexing? Create an endpoint /update/xml/docs endpoint to do custom xml indexing -- Key: SOLR-6559 URL: https://issues.apache.org/jira/browse/SOLR-6559 Project: Solr Issue Type: Bug Reporter: Noble Paul Assignee: Noble Paul Attachments: SOLR-6559.patch Just the way we have an json end point create an xml end point too. use the XPathRecordReader in DIH to do the same . The syntax would require slight tweaking to match the params of /update/json/docs -- 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-5873) AssertionError in ToChildBlockJoinScorer.advance
[
https://issues.apache.org/jira/browse/LUCENE-5873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231270#comment-14231270
]
Mikhail Khludnev commented on LUCENE-5873:
--
bq. The contract of advance is to return the next matching doc ID on or after
the target, so it feels wrong to restrict the values that are legal as targets?
note: the assert was introduced long ago, see
[commit|https://github.com/apache/lucene-solr/commit/9b6fb299586226dc46865ebaba98ce58c9b89f3c].
the reasoning is that parents are orthogonal to children (until LUCENE-5816).
here the advance() contact contradicts with ToChildBJQ ones. eg if we have
parent with doc num 10, and call toChildBJQ.advance(10). What it needs to
return?
* it can't return parent doc 10 - that violates the ToChildBJQ contract,
* it can't return any child docs because they are 10, however it's expected
that DISI.advance(10) 10
* it can't return anything from the next block, because it leads to
undetermined behavior (mind that 10 is not a literally 10, but q=foo:bar,
which yields 10)
obviously if we can't resolve contradiction, we throw exception.
AssertionError in ToChildBlockJoinScorer.advance
Key: LUCENE-5873
URL: https://issues.apache.org/jira/browse/LUCENE-5873
Project: Lucene - Core
Issue Type: Bug
Reporter: Varun Thacker
Priority: Minor
Attachments: LUCENE-5873.patch, LUCENE-5873.patch
When using ToChildBJQ and searching via IndexSearcher.search(Query query,
Filter filter, int n) if we provide a filter which matches both parent and
child documents we get this error
{noformat}
java.lang.AssertionError
at
__randomizedtesting.SeedInfo.seed([C346722DC1E4810C:A08F176AE828FA1D]:0)
at
org.apache.lucene.search.join.ToChildBlockJoinQuery$ToChildBlockJoinScorer.advance(ToChildBlockJoinQuery.java:286)
at
org.apache.lucene.search.FilteredQuery$LeapFrogScorer.advanceToNextCommonDoc(FilteredQuery.java:274)
at
org.apache.lucene.search.FilteredQuery$LeapFrogScorer.nextDoc(FilteredQuery.java:286)
at
org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll(Weight.java:192)
at
org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:163)
at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:35)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:614)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:483)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:440)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:273)
at
org.apache.lucene.search.join.TestBlockJoinValidation.testValidationForToChildBjqWithChildFilterQuery(TestBlockJoinValidation.java:124)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
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.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:110)
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
[jira] [Commented] (LUCENE-5873) AssertionError in ToChildBlockJoinScorer.advance
[
https://issues.apache.org/jira/browse/LUCENE-5873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231276#comment-14231276
]
Adrien Grand commented on LUCENE-5873:
--
But isn't it relying too much on the way that intersections with filters are
implemented? For instance if we suddenly replace the initial advance after a
match to use advance(docId() + 1) instead if nextDoc() then it would fail for
this query? This example is a bit trivial, but I believe similar things could
happen if we start having more sophisticated intersections with filters (and
eg. decide to split the filter in two, first intersect with the fast part of
the filter and then only use the (slow) 2nd part of the filter to confirm
matches).
bq. What it needs to return?
Why can't it return the first child from the next block that the parent scorer
matches? It is already something that can happen if you advance to the last
child of a block that happens to not match the {{acceptDocs}}.
I think it's also a bit confusing that this query can be used alone on its own
(nextDoc works fine and will make sure to skip parent documents), but if you
want to filter it then the filter needs to match child docs only?
AssertionError in ToChildBlockJoinScorer.advance
Key: LUCENE-5873
URL: https://issues.apache.org/jira/browse/LUCENE-5873
Project: Lucene - Core
Issue Type: Bug
Reporter: Varun Thacker
Priority: Minor
Attachments: LUCENE-5873.patch, LUCENE-5873.patch
When using ToChildBJQ and searching via IndexSearcher.search(Query query,
Filter filter, int n) if we provide a filter which matches both parent and
child documents we get this error
{noformat}
java.lang.AssertionError
at
__randomizedtesting.SeedInfo.seed([C346722DC1E4810C:A08F176AE828FA1D]:0)
at
org.apache.lucene.search.join.ToChildBlockJoinQuery$ToChildBlockJoinScorer.advance(ToChildBlockJoinQuery.java:286)
at
org.apache.lucene.search.FilteredQuery$LeapFrogScorer.advanceToNextCommonDoc(FilteredQuery.java:274)
at
org.apache.lucene.search.FilteredQuery$LeapFrogScorer.nextDoc(FilteredQuery.java:286)
at
org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll(Weight.java:192)
at
org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:163)
at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:35)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:614)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:483)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:440)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:273)
at
org.apache.lucene.search.join.TestBlockJoinValidation.testValidationForToChildBjqWithChildFilterQuery(TestBlockJoinValidation.java:124)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
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.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:110)
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
[jira] [Commented] (LUCENE-6087) SearcherManager should accept foreign DirectoryReader on init
[ https://issues.apache.org/jira/browse/LUCENE-6087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231281#comment-14231281 ] Adrien Grand commented on LUCENE-6087: -- +1 SearcherManager should accept foreign DirectoryReader on init - Key: LUCENE-6087 URL: https://issues.apache.org/jira/browse/LUCENE-6087 Project: Lucene - Core Issue Type: Improvement Reporter: Michael McCandless Assignee: Michael McCandless Fix For: Trunk, 5.x Attachments: LUCENE-6087.patch Today you init SearcherManager either with a dir or an IndexWriter, but since we have a useful FilterDirectoryReader class to wrap the sub-readers, it's useful for apps to also pass their own wrapped DirectoryReader and have SearcherManager reopen from that. -- 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-5873) AssertionError in ToChildBlockJoinScorer.advance
[
https://issues.apache.org/jira/browse/LUCENE-5873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231284#comment-14231284
]
Mikhail Khludnev commented on LUCENE-5873:
--
bq. Why can't it return the first child from the next block that the parent
scorer matches?
let's we have two parents matches foo:bar with numbers 10 and 20. the
suggestion implies that we return child 11. but if these blocks will be
rearranged at the next pass, this logic returns different docs. random tests
will fail.
AssertionError in ToChildBlockJoinScorer.advance
Key: LUCENE-5873
URL: https://issues.apache.org/jira/browse/LUCENE-5873
Project: Lucene - Core
Issue Type: Bug
Reporter: Varun Thacker
Priority: Minor
Attachments: LUCENE-5873.patch, LUCENE-5873.patch
When using ToChildBJQ and searching via IndexSearcher.search(Query query,
Filter filter, int n) if we provide a filter which matches both parent and
child documents we get this error
{noformat}
java.lang.AssertionError
at
__randomizedtesting.SeedInfo.seed([C346722DC1E4810C:A08F176AE828FA1D]:0)
at
org.apache.lucene.search.join.ToChildBlockJoinQuery$ToChildBlockJoinScorer.advance(ToChildBlockJoinQuery.java:286)
at
org.apache.lucene.search.FilteredQuery$LeapFrogScorer.advanceToNextCommonDoc(FilteredQuery.java:274)
at
org.apache.lucene.search.FilteredQuery$LeapFrogScorer.nextDoc(FilteredQuery.java:286)
at
org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll(Weight.java:192)
at
org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:163)
at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:35)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:614)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:483)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:440)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:273)
at
org.apache.lucene.search.join.TestBlockJoinValidation.testValidationForToChildBjqWithChildFilterQuery(TestBlockJoinValidation.java:124)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
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.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:110)
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
[jira] [Commented] (LUCENE-5873) AssertionError in ToChildBlockJoinScorer.advance
[
https://issues.apache.org/jira/browse/LUCENE-5873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231289#comment-14231289
]
Adrien Grand commented on LUCENE-5873:
--
Then maybe the issue is within the test? I mean this would be an issue with any
query, right? So either the test needs to not rely on index order, or it needs
to explicitely use a LogMergePolicy?
AssertionError in ToChildBlockJoinScorer.advance
Key: LUCENE-5873
URL: https://issues.apache.org/jira/browse/LUCENE-5873
Project: Lucene - Core
Issue Type: Bug
Reporter: Varun Thacker
Priority: Minor
Attachments: LUCENE-5873.patch, LUCENE-5873.patch
When using ToChildBJQ and searching via IndexSearcher.search(Query query,
Filter filter, int n) if we provide a filter which matches both parent and
child documents we get this error
{noformat}
java.lang.AssertionError
at
__randomizedtesting.SeedInfo.seed([C346722DC1E4810C:A08F176AE828FA1D]:0)
at
org.apache.lucene.search.join.ToChildBlockJoinQuery$ToChildBlockJoinScorer.advance(ToChildBlockJoinQuery.java:286)
at
org.apache.lucene.search.FilteredQuery$LeapFrogScorer.advanceToNextCommonDoc(FilteredQuery.java:274)
at
org.apache.lucene.search.FilteredQuery$LeapFrogScorer.nextDoc(FilteredQuery.java:286)
at
org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll(Weight.java:192)
at
org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:163)
at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:35)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:614)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:483)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:440)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:273)
at
org.apache.lucene.search.join.TestBlockJoinValidation.testValidationForToChildBjqWithChildFilterQuery(TestBlockJoinValidation.java:124)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
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.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:110)
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
[jira] [Commented] (SOLR-6802) Solr AnalyticsQuery API returns analytics by documents that don't match query
[
https://issues.apache.org/jira/browse/SOLR-6802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231290#comment-14231290
]
Daulet Kadirbekov commented on SOLR-6802:
-
Yes, I am using pluggable analytic stuff.
Field 'host' or field 'domain' are not multivalued.
I have create mini version of my analytics, with core. Name of file
Analytics_API_problem.rar.
You can download it by these link http://1drv.ms/15NsYul
How to run?
-copy \solr-4.10.2\contrib\custom package to your solr-4.10.2\contrib\ package
-copy \solr-4.10.2\example\solr\testcore to your \solr-4.10.2\example\solr\
package
-run solr
-Make solr query with fq field:{!resourceTestAnalytics}
In this core there are 550 documents.
150 of these is from domain:*nur.kz
100 of these is from domain:*azattyq.org
100 of these is from domain:*topnews.ru
200 of these is from domain:*tengrinews.kz
But solr analytics always returns for documents that don't match query
Example:
q=*:*
fq={!resourceTestAnalytics}
Result of response:
response: {
numFound: 550,
docs:[
domain: en.tengrinews.kz
domain: en.tengrinews.kz
domain: en.tengrinews.kz
...
domain: news.nur.kz
domain: news.nur.kz
domain: news.nur.kz
...
domain: www.azattyq.org
domain: www.azattyq.org
domain: www.azattyq.org
...
domain: www.topnews.ru
domain: www.topnews.ru
domain: www.topnews.ru
...
Result of analytics:
resources: {
en.tengrinews.kz: 550
},
You could watch my code in AnalyticsTest project.
Solr AnalyticsQuery API returns analytics by documents that don't match query
-
Key: SOLR-6802
URL: https://issues.apache.org/jira/browse/SOLR-6802
Project: Solr
Issue Type: Bug
Components: query parsers
Affects Versions: 4.10.2
Reporter: Daulet Kadirbekov
Priority: Critical
Solr AnalyticsQuery API returns analytics by documents that don't match query.
Example:
Solr query: domain:example.com
I looked for all documents by /select search handler and all of this
documents was belonged to example.com domain.
But when I looked in analytics for documents, I have found that there are
many documents which don't match query. But number of documents is the same.
--
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-6802) Solr AnalyticsQuery API returns analytics by documents that don't match query
[
https://issues.apache.org/jira/browse/SOLR-6802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231290#comment-14231290
]
Daulet Kadirbekov edited comment on SOLR-6802 at 12/2/14 10:45 AM:
---
Yes, I am using pluggable analytic stuff.
Field 'host' or field 'domain' are not multivalued.
I have create mini version of my analytics, with core. Name of file
Analytics_API_problem.rar.
You can download it by these link http://1drv.ms/15NsYul
How to run?
-copy \solr-4.10.2\contrib\custom package to your solr-4.10.2\contrib\ package
-copy \solr-4.10.2\example\solr\testcore to your \solr-4.10.2\example\solr\
package
-run solr
-Make solr query with fq field:
{!resourceTestAnalytics}
In this core there are 550 documents.
150 of these is from domain:*nur.kz
100 of these is from domain:*azattyq.org
100 of these is from domain:*topnews.ru
200 of these is from domain:*tengrinews.kz
But solr analytics always returns for documents that don't match query
Example:
q=*:*
fq={!resourceTestAnalytics}
Result of response:
response: {
numFound: 550,
docs:[
domain: en.tengrinews.kz
domain: en.tengrinews.kz
domain: en.tengrinews.kz
...
domain: news.nur.kz
domain: news.nur.kz
domain: news.nur.kz
...
domain: www.azattyq.org
domain: www.azattyq.org
domain: www.azattyq.org
...
domain: www.topnews.ru
domain: www.topnews.ru
domain: www.topnews.ru
...
Result of analytics:
resources: {
en.tengrinews.kz: 550
},
You could watch my code in AnalyticsTest project.
was (Author: d.kadirbekov):
Yes, I am using pluggable analytic stuff.
Field 'host' or field 'domain' are not multivalued.
I have create mini version of my analytics, with core. Name of file
Analytics_API_problem.rar.
You can download it by these link http://1drv.ms/15NsYul
How to run?
-copy \solr-4.10.2\contrib\custom package to your solr-4.10.2\contrib\ package
-copy \solr-4.10.2\example\solr\testcore to your \solr-4.10.2\example\solr\
package
-run solr
-Make solr query with fq field:{!resourceTestAnalytics}
In this core there are 550 documents.
150 of these is from domain:*nur.kz
100 of these is from domain:*azattyq.org
100 of these is from domain:*topnews.ru
200 of these is from domain:*tengrinews.kz
But solr analytics always returns for documents that don't match query
Example:
q=*:*
fq={!resourceTestAnalytics}
Result of response:
response: {
numFound: 550,
docs:[
domain: en.tengrinews.kz
domain: en.tengrinews.kz
domain: en.tengrinews.kz
...
domain: news.nur.kz
domain: news.nur.kz
domain: news.nur.kz
...
domain: www.azattyq.org
domain: www.azattyq.org
domain: www.azattyq.org
...
domain: www.topnews.ru
domain: www.topnews.ru
domain: www.topnews.ru
...
Result of analytics:
resources: {
en.tengrinews.kz: 550
},
You could watch my code in AnalyticsTest project.
Solr AnalyticsQuery API returns analytics by documents that don't match query
-
Key: SOLR-6802
URL: https://issues.apache.org/jira/browse/SOLR-6802
Project: Solr
Issue Type: Bug
Components: query parsers
Affects Versions: 4.10.2
Reporter: Daulet Kadirbekov
Priority: Critical
Solr AnalyticsQuery API returns analytics by documents that don't match query.
Example:
Solr query: domain:example.com
I looked for all documents by /select search handler and all of this
documents was belonged to example.com domain.
But when I looked in analytics for documents, I have found that there are
many documents which don't match query. But number of documents is the same.
--
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-6802) Solr AnalyticsQuery API returns analytics by documents that don't match query
[
https://issues.apache.org/jira/browse/SOLR-6802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231290#comment-14231290
]
Daulet Kadirbekov edited comment on SOLR-6802 at 12/2/14 10:45 AM:
---
Yes, I am using pluggable analytic stuff.
Field 'host' or field 'domain' are not multivalued.
I have create mini version of my analytics, with core. Name of file
Analytics_API_problem.rar.
You can download it by these link http://1drv.ms/15NsYul
How to run?
-copy \solr-4.10.2\contrib\custom package to your solr-4.10.2\contrib\ package
-copy \solr-4.10.2\example\solr\testcore to your \solr-4.10.2\example\solr\
package
-run solr
-Make solr query with fq field:{!resourceTestAnalytics}
In this core there are 550 documents.
150 of these is from domain:*nur.kz
100 of these is from domain:*azattyq.org
100 of these is from domain:*topnews.ru
200 of these is from domain:*tengrinews.kz
But solr analytics always returns for documents that don't match query
Example:
q=*:*
fq={!resourceTestAnalytics}
Result of response:
response: {
numFound: 550,
docs:[
domain: en.tengrinews.kz
domain: en.tengrinews.kz
domain: en.tengrinews.kz
...
domain: news.nur.kz
domain: news.nur.kz
domain: news.nur.kz
...
domain: www.azattyq.org
domain: www.azattyq.org
domain: www.azattyq.org
...
domain: www.topnews.ru
domain: www.topnews.ru
domain: www.topnews.ru
...
Result of analytics:
resources: {
en.tengrinews.kz: 550
},
You could watch my code in AnalyticsTest project.
was (Author: d.kadirbekov):
Yes, I am using pluggable analytic stuff.
Field 'host' or field 'domain' are not multivalued.
I have create mini version of my analytics, with core. Name of file
Analytics_API_problem.rar.
You can download it by these link http://1drv.ms/15NsYul
How to run?
-copy \solr-4.10.2\contrib\custom package to your solr-4.10.2\contrib\ package
-copy \solr-4.10.2\example\solr\testcore to your \solr-4.10.2\example\solr\
package
-run solr
-Make solr query with fq field:
{!resourceTestAnalytics}
In this core there are 550 documents.
150 of these is from domain:*nur.kz
100 of these is from domain:*azattyq.org
100 of these is from domain:*topnews.ru
200 of these is from domain:*tengrinews.kz
But solr analytics always returns for documents that don't match query
Example:
q=*:*
fq={!resourceTestAnalytics}
Result of response:
response: {
numFound: 550,
docs:[
domain: en.tengrinews.kz
domain: en.tengrinews.kz
domain: en.tengrinews.kz
...
domain: news.nur.kz
domain: news.nur.kz
domain: news.nur.kz
...
domain: www.azattyq.org
domain: www.azattyq.org
domain: www.azattyq.org
...
domain: www.topnews.ru
domain: www.topnews.ru
domain: www.topnews.ru
...
Result of analytics:
resources: {
en.tengrinews.kz: 550
},
You could watch my code in AnalyticsTest project.
Solr AnalyticsQuery API returns analytics by documents that don't match query
-
Key: SOLR-6802
URL: https://issues.apache.org/jira/browse/SOLR-6802
Project: Solr
Issue Type: Bug
Components: query parsers
Affects Versions: 4.10.2
Reporter: Daulet Kadirbekov
Priority: Critical
Solr AnalyticsQuery API returns analytics by documents that don't match query.
Example:
Solr query: domain:example.com
I looked for all documents by /select search handler and all of this
documents was belonged to example.com domain.
But when I looked in analytics for documents, I have found that there are
many documents which don't match query. But number of documents is the same.
--
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-6802) Solr AnalyticsQuery API returns analytics by documents that don't match query
[
https://issues.apache.org/jira/browse/SOLR-6802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231290#comment-14231290
]
Daulet Kadirbekov edited comment on SOLR-6802 at 12/2/14 10:46 AM:
---
Yes, I am using pluggable analytic stuff.
Field 'host' or field 'domain' are not multivalued.
I have create mini version of my analytics, with core. Name of file
Analytics_API_problem.rar.
You can download it by these link http://1drv.ms/15NsYul
How to run?
-copy \solr-4.10.2\contrib\custom package to your solr-4.10.2\contrib\ package
-copy \solr-4.10.2\example\solr\testcore to your \solr-4.10.2\example\solr\
package
-run solr
-Make solr query with fq field:{!resourceTestAnalytics}
In this core there are 550 documents.
150 of these is from domain:*nur.kz
100 of these is from domain:*azattyq.org
100 of these is from domain:*topnews.ru
200 of these is from domain:*tengrinews.kz
But solr analytics always returns for documents that don't match query
Example:
q='*:*'
fq={!resourceTestAnalytics}
Result of response:
response: {
numFound: 550,
docs:[
domain: en.tengrinews.kz
domain: en.tengrinews.kz
domain: en.tengrinews.kz
...
domain: news.nur.kz
domain: news.nur.kz
domain: news.nur.kz
...
domain: www.azattyq.org
domain: www.azattyq.org
domain: www.azattyq.org
...
domain: www.topnews.ru
domain: www.topnews.ru
domain: www.topnews.ru
...
Result of analytics:
resources: {
en.tengrinews.kz: 550
},
You could watch my code in AnalyticsTest project.
was (Author: d.kadirbekov):
Yes, I am using pluggable analytic stuff.
Field 'host' or field 'domain' are not multivalued.
I have create mini version of my analytics, with core. Name of file
Analytics_API_problem.rar.
You can download it by these link http://1drv.ms/15NsYul
How to run?
-copy \solr-4.10.2\contrib\custom package to your solr-4.10.2\contrib\ package
-copy \solr-4.10.2\example\solr\testcore to your \solr-4.10.2\example\solr\
package
-run solr
-Make solr query with fq field:{!resourceTestAnalytics}
In this core there are 550 documents.
150 of these is from domain:*nur.kz
100 of these is from domain:*azattyq.org
100 of these is from domain:*topnews.ru
200 of these is from domain:*tengrinews.kz
But solr analytics always returns for documents that don't match query
Example:
q=*:*
fq={!resourceTestAnalytics}
Result of response:
response: {
numFound: 550,
docs:[
domain: en.tengrinews.kz
domain: en.tengrinews.kz
domain: en.tengrinews.kz
...
domain: news.nur.kz
domain: news.nur.kz
domain: news.nur.kz
...
domain: www.azattyq.org
domain: www.azattyq.org
domain: www.azattyq.org
...
domain: www.topnews.ru
domain: www.topnews.ru
domain: www.topnews.ru
...
Result of analytics:
resources: {
en.tengrinews.kz: 550
},
You could watch my code in AnalyticsTest project.
Solr AnalyticsQuery API returns analytics by documents that don't match query
-
Key: SOLR-6802
URL: https://issues.apache.org/jira/browse/SOLR-6802
Project: Solr
Issue Type: Bug
Components: query parsers
Affects Versions: 4.10.2
Reporter: Daulet Kadirbekov
Priority: Critical
Solr AnalyticsQuery API returns analytics by documents that don't match query.
Example:
Solr query: domain:example.com
I looked for all documents by /select search handler and all of this
documents was belonged to example.com domain.
But when I looked in analytics for documents, I have found that there are
many documents which don't match query. But number of documents is the same.
--
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-6802) Solr AnalyticsQuery API returns analytics by documents that don't match query
[
https://issues.apache.org/jira/browse/SOLR-6802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231290#comment-14231290
]
Daulet Kadirbekov edited comment on SOLR-6802 at 12/2/14 10:52 AM:
---
Yes, I am using pluggable analytic stuff.
Field 'host' or field 'domain' are not multivalued.
I have create mini version of my analytics, with core. Name of file
Analytics_API_problem.rar.
You can download it by these link http://1drv.ms/15NsYul
How to run?
-copy \solr-4.10.2\contrib\custom package to your solr-4.10.2\contrib\ package
-copy \solr-4.10.2\example\solr\testcore to your \solr-4.10.2\example\solr\
package
-run solr
-Make solr query with fq field:{!resourceTestAnalytics}
In this core there are 550 documents.
150 of these is from domain:*nur.kz
100 of these is from domain:*azattyq.org
100 of these is from domain:*topnews.ru
200 of these is from domain:*tengrinews.kz
But solr analytics always returns for documents that don't match query
Example:
q=*:*
fq={!resourceTestAnalytics}
Result of response:
response: {
numFound: 550,
docs:[
domain: en.tengrinews.kz
domain: en.tengrinews.kz
domain: en.tengrinews.kz
...
domain: news.nur.kz
domain: news.nur.kz
domain: news.nur.kz
...
domain: www.azattyq.org
domain: www.azattyq.org
domain: www.azattyq.org
...
domain: www.topnews.ru
domain: www.topnews.ru
domain: www.topnews.ru
...
Result of analytics:
resources: {
en.tengrinews.kz: 550
},
You could watch my code in AnalyticsTest project.
was (Author: d.kadirbekov):
Yes, I am using pluggable analytic stuff.
Field 'host' or field 'domain' are not multivalued.
I have create mini version of my analytics, with core. Name of file
Analytics_API_problem.rar.
You can download it by these link http://1drv.ms/15NsYul
How to run?
-copy \solr-4.10.2\contrib\custom package to your solr-4.10.2\contrib\ package
-copy \solr-4.10.2\example\solr\testcore to your \solr-4.10.2\example\solr\
package
-run solr
-Make solr query with fq field:{!resourceTestAnalytics}
In this core there are 550 documents.
150 of these is from domain:*nur.kz
100 of these is from domain:*azattyq.org
100 of these is from domain:*topnews.ru
200 of these is from domain:*tengrinews.kz
But solr analytics always returns for documents that don't match query
Example:
q=_*:*_
fq={!resourceTestAnalytics}
Result of response:
response: {
numFound: 550,
docs:[
domain: en.tengrinews.kz
domain: en.tengrinews.kz
domain: en.tengrinews.kz
...
domain: news.nur.kz
domain: news.nur.kz
domain: news.nur.kz
...
domain: www.azattyq.org
domain: www.azattyq.org
domain: www.azattyq.org
...
domain: www.topnews.ru
domain: www.topnews.ru
domain: www.topnews.ru
...
Result of analytics:
resources: {
en.tengrinews.kz: 550
},
You could watch my code in AnalyticsTest project.
Solr AnalyticsQuery API returns analytics by documents that don't match query
-
Key: SOLR-6802
URL: https://issues.apache.org/jira/browse/SOLR-6802
Project: Solr
Issue Type: Bug
Components: query parsers
Affects Versions: 4.10.2
Reporter: Daulet Kadirbekov
Priority: Critical
Solr AnalyticsQuery API returns analytics by documents that don't match query.
Example:
Solr query: domain:example.com
I looked for all documents by /select search handler and all of this
documents was belonged to example.com domain.
But when I looked in analytics for documents, I have found that there are
many documents which don't match query. But number of documents is the same.
--
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-6583) Resuming connection with ZooKeeper causes log replay
[
https://issues.apache.org/jira/browse/SOLR-6583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231304#comment-14231304
]
Yago Riveiro commented on SOLR-6583:
This is happening in Solr 4.6.1 too.
{code}
ERROR - app2 - 2014-12-01 21:30:42.820; org.apache.solr.update.UpdateLog; Error
inspecting tlog
tlog{file=/solr/node/collections/collection1_shard2_replica1/data/tlog/tlog.0001284
refcount=2}
{code}
Resuming connection with ZooKeeper causes log replay
Key: SOLR-6583
URL: https://issues.apache.org/jira/browse/SOLR-6583
Project: Solr
Issue Type: Bug
Components: SolrCloud
Affects Versions: 4.10.1
Reporter: Shalin Shekhar Mangar
Assignee: Shalin Shekhar Mangar
Priority: Minor
Fix For: 5.0, Trunk
If a node is partitioned from ZooKeeper for an extended period of time then
upon resuming connection, the node re-registers itself causing
recoverFromLog() method to be executed which fails with the following
exception:
{code}
8091124 [Thread-71] ERROR org.apache.solr.update.UpdateLog – Error
inspecting tlog
tlog{file=/home/ubuntu/shalin-lusolr/solr/example/solr/collection_5x3_shard5_replica3/data/tlog/tlog.0009869
refcount=2}
java.nio.channels.ClosedChannelException
at sun.nio.ch.FileChannelImpl.ensureOpen(FileChannelImpl.java:99)
at sun.nio.ch.FileChannelImpl.read(FileChannelImpl.java:678)
at
org.apache.solr.update.ChannelFastInputStream.readWrappedStream(TransactionLog.java:784)
at
org.apache.solr.common.util.FastInputStream.refill(FastInputStream.java:89)
at
org.apache.solr.common.util.FastInputStream.read(FastInputStream.java:125)
at java.io.InputStream.read(InputStream.java:101)
at
org.apache.solr.update.TransactionLog.endsWithCommit(TransactionLog.java:218)
at org.apache.solr.update.UpdateLog.recoverFromLog(UpdateLog.java:800)
at org.apache.solr.cloud.ZkController.register(ZkController.java:834)
at org.apache.solr.cloud.ZkController$1.command(ZkController.java:271)
at
org.apache.solr.common.cloud.ConnectionManager$1$1.run(ConnectionManager.java:166)
8091125 [Thread-71] ERROR org.apache.solr.update.UpdateLog – Error
inspecting tlog
tlog{file=/home/ubuntu/shalin-lusolr/solr/example/solr/collection_5x3_shard5_replica3/data/tlog/tlog.0009870
refcount=2}
java.nio.channels.ClosedChannelException
at sun.nio.ch.FileChannelImpl.ensureOpen(FileChannelImpl.java:99)
at sun.nio.ch.FileChannelImpl.read(FileChannelImpl.java:678)
at
org.apache.solr.update.ChannelFastInputStream.readWrappedStream(TransactionLog.java:784)
at
org.apache.solr.common.util.FastInputStream.refill(FastInputStream.java:89)
at
org.apache.solr.common.util.FastInputStream.read(FastInputStream.java:125)
at java.io.InputStream.read(InputStream.java:101)
at
org.apache.solr.update.TransactionLog.endsWithCommit(TransactionLog.java:218)
at org.apache.solr.update.UpdateLog.recoverFromLog(UpdateLog.java:800)
at org.apache.solr.cloud.ZkController.register(ZkController.java:834)
at org.apache.solr.cloud.ZkController$1.command(ZkController.java:271)
at
org.apache.solr.common.cloud.ConnectionManager$1$1.run(ConnectionManager.java:166)
{code}
This is because the recoverFromLog uses transaction log references that were
collected at startup and are no longer valid.
We shouldn't even be running recoverFromLog code for ZK re-connect.
--
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-5873) AssertionError in ToChildBlockJoinScorer.advance
[
https://issues.apache.org/jira/browse/LUCENE-5873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231313#comment-14231313
]
Mikhail Khludnev commented on LUCENE-5873:
--
in this case i'd rather blame an undetermined query behavior, which is
confirmed by test. I suppose all queries are agnostic to the document order
with a fairly limited number of explicit exclusions: parent and children in
BJQs and EarlyTermination ones. Giving this, depending on blocks order seems
wrong to me.
AssertionError in ToChildBlockJoinScorer.advance
Key: LUCENE-5873
URL: https://issues.apache.org/jira/browse/LUCENE-5873
Project: Lucene - Core
Issue Type: Bug
Reporter: Varun Thacker
Priority: Minor
Attachments: LUCENE-5873.patch, LUCENE-5873.patch
When using ToChildBJQ and searching via IndexSearcher.search(Query query,
Filter filter, int n) if we provide a filter which matches both parent and
child documents we get this error
{noformat}
java.lang.AssertionError
at
__randomizedtesting.SeedInfo.seed([C346722DC1E4810C:A08F176AE828FA1D]:0)
at
org.apache.lucene.search.join.ToChildBlockJoinQuery$ToChildBlockJoinScorer.advance(ToChildBlockJoinQuery.java:286)
at
org.apache.lucene.search.FilteredQuery$LeapFrogScorer.advanceToNextCommonDoc(FilteredQuery.java:274)
at
org.apache.lucene.search.FilteredQuery$LeapFrogScorer.nextDoc(FilteredQuery.java:286)
at
org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll(Weight.java:192)
at
org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:163)
at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:35)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:614)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:483)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:440)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:273)
at
org.apache.lucene.search.join.TestBlockJoinValidation.testValidationForToChildBjqWithChildFilterQuery(TestBlockJoinValidation.java:124)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
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.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:110)
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
[jira] [Created] (SOLR-6812) distrib.singlePass does not work for expand-request
Per Steffensen created SOLR-6812: Summary: distrib.singlePass does not work for expand-request Key: SOLR-6812 URL: https://issues.apache.org/jira/browse/SOLR-6812 Project: Solr Issue Type: Bug Components: multicore, search Reporter: Per Steffensen Using distrib.singlePass does not work for expand-requests. -- 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-6812) distrib.singlePass does not work for expand-request
[
https://issues.apache.org/jira/browse/SOLR-6812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Per Steffensen updated SOLR-6812:
-
Attachment: test_that_reveals_the_problem.patch
Attached patch (branch_5x) that change an existing test to reveal the problem.
Apply the patch and run {{DistributedExpandComponentTest}}
Probably not just want to commit the changed test after a fix of the problem,
but maybe we want to add the test somewhere else.
distrib.singlePass does not work for expand-request
---
Key: SOLR-6812
URL: https://issues.apache.org/jira/browse/SOLR-6812
Project: Solr
Issue Type: Bug
Components: multicore, search
Reporter: Per Steffensen
Labels: distributed_search, search
Attachments: test_that_reveals_the_problem.patch
Using distrib.singlePass does not work for expand-requests.
--
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-5873) AssertionError in ToChildBlockJoinScorer.advance
[
https://issues.apache.org/jira/browse/LUCENE-5873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231324#comment-14231324
]
Adrien Grand commented on LUCENE-5873:
--
ok
AssertionError in ToChildBlockJoinScorer.advance
Key: LUCENE-5873
URL: https://issues.apache.org/jira/browse/LUCENE-5873
Project: Lucene - Core
Issue Type: Bug
Reporter: Varun Thacker
Priority: Minor
Attachments: LUCENE-5873.patch, LUCENE-5873.patch
When using ToChildBJQ and searching via IndexSearcher.search(Query query,
Filter filter, int n) if we provide a filter which matches both parent and
child documents we get this error
{noformat}
java.lang.AssertionError
at
__randomizedtesting.SeedInfo.seed([C346722DC1E4810C:A08F176AE828FA1D]:0)
at
org.apache.lucene.search.join.ToChildBlockJoinQuery$ToChildBlockJoinScorer.advance(ToChildBlockJoinQuery.java:286)
at
org.apache.lucene.search.FilteredQuery$LeapFrogScorer.advanceToNextCommonDoc(FilteredQuery.java:274)
at
org.apache.lucene.search.FilteredQuery$LeapFrogScorer.nextDoc(FilteredQuery.java:286)
at
org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll(Weight.java:192)
at
org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:163)
at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:35)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:614)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:483)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:440)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:273)
at
org.apache.lucene.search.join.TestBlockJoinValidation.testValidationForToChildBjqWithChildFilterQuery(TestBlockJoinValidation.java:124)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
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.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:110)
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
[jira] [Updated] (SOLR-6812) distrib.singlePass does not work for expand-request
[
https://issues.apache.org/jira/browse/SOLR-6812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Per Steffensen updated SOLR-6812:
-
Attachment: fix.patch
Attached a fix to the problem. Problem is that {{ExpandComponent}} kinda
detects that it is supposed to do its thing for shard-searches, by seeing if
ids-param is there. It is not in case of {{distrib.singlePass}}.
Patch works on purpose instead, because that is really whats controlling the
things in {{QueryComponent}}. So not purpose is distributed in the
shard-requests.
distrib.singlePass does not work for expand-request
---
Key: SOLR-6812
URL: https://issues.apache.org/jira/browse/SOLR-6812
Project: Solr
Issue Type: Bug
Components: multicore, search
Reporter: Per Steffensen
Labels: distributed_search, search
Attachments: fix.patch, test_that_reveals_the_problem.patch
Using distrib.singlePass does not work for expand-requests.
--
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-6796) distrib.singlePass does not return correct set of fields for multi-fl-parameter requests
[ https://issues.apache.org/jira/browse/SOLR-6796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231325#comment-14231325 ] Per Steffensen commented on SOLR-6796: -- Maybe I can convince you to take a look at SOLR-6812 also, [~shalinmangar]? distrib.singlePass does not return correct set of fields for multi-fl-parameter requests Key: SOLR-6796 URL: https://issues.apache.org/jira/browse/SOLR-6796 Project: Solr Issue Type: Bug Components: multicore, search Affects Versions: 5.0 Reporter: Per Steffensen Assignee: Shalin Shekhar Mangar Labels: distributed_search, search Attachments: fix.patch, fix.patch, fix.patch, fix.patch, test_that_reveals_the_problem.patch If I pass distrib.singlePass in a request that also has two fl-parameters, in some cases, I will not get the expected set of fields back for the returned documents -- 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-5873) AssertionError in ToChildBlockJoinScorer.advance
[
https://issues.apache.org/jira/browse/LUCENE-5873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231331#comment-14231331
]
Michael McCandless commented on LUCENE-5873:
bq. Giving this, depending on blocks order seems wrong to me.
I'm confused here: who is depending on block order?
AssertionError in ToChildBlockJoinScorer.advance
Key: LUCENE-5873
URL: https://issues.apache.org/jira/browse/LUCENE-5873
Project: Lucene - Core
Issue Type: Bug
Reporter: Varun Thacker
Priority: Minor
Attachments: LUCENE-5873.patch, LUCENE-5873.patch
When using ToChildBJQ and searching via IndexSearcher.search(Query query,
Filter filter, int n) if we provide a filter which matches both parent and
child documents we get this error
{noformat}
java.lang.AssertionError
at
__randomizedtesting.SeedInfo.seed([C346722DC1E4810C:A08F176AE828FA1D]:0)
at
org.apache.lucene.search.join.ToChildBlockJoinQuery$ToChildBlockJoinScorer.advance(ToChildBlockJoinQuery.java:286)
at
org.apache.lucene.search.FilteredQuery$LeapFrogScorer.advanceToNextCommonDoc(FilteredQuery.java:274)
at
org.apache.lucene.search.FilteredQuery$LeapFrogScorer.nextDoc(FilteredQuery.java:286)
at
org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll(Weight.java:192)
at
org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:163)
at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:35)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:614)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:483)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:440)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:273)
at
org.apache.lucene.search.join.TestBlockJoinValidation.testValidationForToChildBjqWithChildFilterQuery(TestBlockJoinValidation.java:124)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
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.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:110)
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
[jira] [Commented] (LUCENE-6087) SearcherManager should accept foreign DirectoryReader on init
[ https://issues.apache.org/jira/browse/LUCENE-6087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231333#comment-14231333 ] Simon Willnauer commented on LUCENE-6087: - +1 ;) thanks mike SearcherManager should accept foreign DirectoryReader on init - Key: LUCENE-6087 URL: https://issues.apache.org/jira/browse/LUCENE-6087 Project: Lucene - Core Issue Type: Improvement Reporter: Michael McCandless Assignee: Michael McCandless Fix For: Trunk, 5.x Attachments: LUCENE-6087.patch Today you init SearcherManager either with a dir or an IndexWriter, but since we have a useful FilterDirectoryReader class to wrap the sub-readers, it's useful for apps to also pass their own wrapped DirectoryReader and have SearcherManager reopen from that. -- 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-5873) AssertionError in ToChildBlockJoinScorer.advance
[
https://issues.apache.org/jira/browse/LUCENE-5873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231336#comment-14231336
]
Mikhail Khludnev commented on LUCENE-5873:
--
bq. I'm confused here: who is depending on block order?
the proposed
[behaviour|https://issues.apache.org/jira/browse/LUCENE-5873?focusedCommentId=14231284page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14231284]
I think we come to the agreement. Thanks, gentlemen!
AssertionError in ToChildBlockJoinScorer.advance
Key: LUCENE-5873
URL: https://issues.apache.org/jira/browse/LUCENE-5873
Project: Lucene - Core
Issue Type: Bug
Reporter: Varun Thacker
Priority: Minor
Attachments: LUCENE-5873.patch, LUCENE-5873.patch
When using ToChildBJQ and searching via IndexSearcher.search(Query query,
Filter filter, int n) if we provide a filter which matches both parent and
child documents we get this error
{noformat}
java.lang.AssertionError
at
__randomizedtesting.SeedInfo.seed([C346722DC1E4810C:A08F176AE828FA1D]:0)
at
org.apache.lucene.search.join.ToChildBlockJoinQuery$ToChildBlockJoinScorer.advance(ToChildBlockJoinQuery.java:286)
at
org.apache.lucene.search.FilteredQuery$LeapFrogScorer.advanceToNextCommonDoc(FilteredQuery.java:274)
at
org.apache.lucene.search.FilteredQuery$LeapFrogScorer.nextDoc(FilteredQuery.java:286)
at
org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll(Weight.java:192)
at
org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:163)
at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:35)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:614)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:483)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:440)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:273)
at
org.apache.lucene.search.join.TestBlockJoinValidation.testValidationForToChildBjqWithChildFilterQuery(TestBlockJoinValidation.java:124)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
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.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:110)
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
[jira] [Commented] (LUCENE-5205) SpanQueryParser with recursion, analysis and syntax very similar to classic QueryParser
[ https://issues.apache.org/jira/browse/LUCENE-5205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231355#comment-14231355 ] Modassar Ather commented on LUCENE-5205: A query like following is throwing Exception. Query: field: (term1* term2*) term3*~5 AND (field: (term4 OR term5 OR term6...termN)) where N a couple of thousand e.g 6000-8000. Exception: Exception in thread main java.lang.StackOverflowError at java.util.regex.Pattern$GroupHead.match(Pattern.java:4554) at java.util.regex.Pattern$Loop.match(Pattern.java:4683) at java.util.regex.Pattern$GroupTail.match(Pattern.java:4615) at java.util.regex.Pattern$BranchConn.match(Pattern.java:4466) at java.util.regex.Pattern$CharProperty.match(Pattern.java:3694) at java.util.regex.Pattern$Branch.match(Pattern.java:4502) at java.util.regex.Pattern$GroupHead.match(Pattern.java:4556) at java.util.regex.Pattern$Loop.match(Pattern.java:4683) Kindly let me know if I am using query in a wrong way. NOTE: A space between the field: and query is added to avoid transformation to smileys. SpanQueryParser with recursion, analysis and syntax very similar to classic QueryParser --- Key: LUCENE-5205 URL: https://issues.apache.org/jira/browse/LUCENE-5205 Project: Lucene - Core Issue Type: Improvement Components: core/queryparser Reporter: Tim Allison Labels: patch Attachments: LUCENE-5205-cleanup-tests.patch, LUCENE-5205-date-pkg-prvt.patch, LUCENE-5205.patch.gz, LUCENE-5205.patch.gz, LUCENE-5205_dateTestReInitPkgPrvt.patch, LUCENE-5205_improve_stop_word_handling.patch, LUCENE-5205_smallTestMods.patch, LUCENE_5205.patch, SpanQueryParser_v1.patch.gz, patch.txt This parser extends QueryParserBase and includes functionality from: * Classic QueryParser: most of its syntax * SurroundQueryParser: recursive parsing for near and not clauses. * ComplexPhraseQueryParser: can handle near queries that include multiterms (wildcard, fuzzy, regex, prefix), * AnalyzingQueryParser: has an option to analyze multiterms. At a high level, there's a first pass BooleanQuery/field parser and then a span query parser handles all terminal nodes and phrases. Same as classic syntax: * term: test * fuzzy: roam~0.8, roam~2 * wildcard: te?t, test*, t*st * regex: /\[mb\]oat/ * phrase: jakarta apache * phrase with slop: jakarta apache~3 * default or clause: jakarta apache * grouping or clause: (jakarta apache) * boolean and +/-: (lucene OR apache) NOT jakarta; +lucene +apache -jakarta * multiple fields: title:lucene author:hatcher Main additions in SpanQueryParser syntax vs. classic syntax: * Can require in order for phrases with slop with the \~ operator: jakarta apache\~3 * Can specify not near: fever bieber!\~3,10 :: find fever but not if bieber appears within 3 words before or 10 words after it. * Fully recursive phrasal queries with \[ and \]; as in: \[\[jakarta apache\]~3 lucene\]\~4 :: find jakarta within 3 words of apache, and that hit has to be within four words before lucene * Can also use \[\] for single level phrasal queries instead of as in: \[jakarta apache\] * Can use or grouping clauses in phrasal queries: apache (lucene solr)\~3 :: find apache and then either lucene or solr within three words. * Can use multiterms in phrasal queries: jakarta\~1 ap*che\~2 * Did I mention full recursion: \[\[jakarta\~1 ap*che\]\~2 (solr~ /l\[ou\]\+\[cs\]\[en\]\+/)]\~10 :: Find something like jakarta within two words of ap*che and that hit has to be within ten words of something like solr or that lucene regex. * Can require at least x number of hits at boolean level: apache AND (lucene solr tika)~2 * Can use negative only query: -jakarta :: Find all docs that don't contain jakarta * Can use an edit distance 2 for fuzzy query via SlowFuzzyQuery (beware of potential performance issues!). Trivial additions: * Can specify prefix length in fuzzy queries: jakarta~1,2 (edit distance =1, prefix =2) * Can specifiy Optimal String Alignment (OSA) vs Levenshtein for distance =2: (jakarta~1 (OSA) vs jakarta~1(Levenshtein) This parser can be very useful for concordance tasks (see also LUCENE-5317 and LUCENE-5318) and for analytical search. Until LUCENE-2878 is closed, this might have a use for fans of SpanQuery. Most of the documentation is in the javadoc for SpanQueryParser. Any and all feedback is welcome. Thank you. Until this is added to the Lucene project, I've added a standalone lucene-addons repo (with jars compiled for the latest stable build of Lucene) on [github|https://github.com/tballison/lucene-addons]. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SOLR-6813) distrib.singlePass does not work for expand-request - start/rows included
Per Steffensen created SOLR-6813: Summary: distrib.singlePass does not work for expand-request - start/rows included Key: SOLR-6813 URL: https://issues.apache.org/jira/browse/SOLR-6813 Project: Solr Issue Type: Bug Components: multicore, search Reporter: Per Steffensen Using distrib.singlePass does not work for expand-requests. Even after the fix provided to SOLR-6812, it does not work for requests where you add start and/or rows. -- 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-6813) distrib.singlePass does not work for expand-request - start/rows included
[ https://issues.apache.org/jira/browse/SOLR-6813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Per Steffensen updated SOLR-6813: - Attachment: test_that_reveals_the_problem.patch Attached patch (branch_5x) that change an existing test to reveal the problem. Apply the patch and run DistributedExpandComponentTest Probably not just want to commit the changed test after a fix of the problem, but maybe we want to add the test somewhere else. distrib.singlePass does not work for expand-request - start/rows included - Key: SOLR-6813 URL: https://issues.apache.org/jira/browse/SOLR-6813 Project: Solr Issue Type: Bug Components: multicore, search Reporter: Per Steffensen Labels: distributed_search, search Attachments: test_that_reveals_the_problem.patch Using distrib.singlePass does not work for expand-requests. Even after the fix provided to SOLR-6812, it does not work for requests where you add start and/or rows. -- 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-6813) distrib.singlePass does not work for expand-request - start/rows included
[
https://issues.apache.org/jira/browse/SOLR-6813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231428#comment-14231428
]
Per Steffensen commented on SOLR-6813:
--
Unlike for SOLR-6812 (and SOLR-6795 and SOLR-6796) I am not going to provide a
fix here, because I really do not know enough about expand-requests to be able
to say which response is actually the correct one - {{controlRsp}} or {{rsp}}
in {{BaseDistributedSearchTestCase.query}} when doing the modified request from
{{test_that_reveals_the_problem.patch}}
distrib.singlePass does not work for expand-request - start/rows included
-
Key: SOLR-6813
URL: https://issues.apache.org/jira/browse/SOLR-6813
Project: Solr
Issue Type: Bug
Components: multicore, search
Reporter: Per Steffensen
Labels: distributed_search, search
Attachments: test_that_reveals_the_problem.patch
Using distrib.singlePass does not work for expand-requests. Even after the
fix provided to SOLR-6812, it does not work for requests where you add start
and/or rows.
--
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-6591) Cluster state updates can be lost on exception in main queue loop
[
https://issues.apache.org/jira/browse/SOLR-6591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shalin Shekhar Mangar resolved SOLR-6591.
-
Resolution: Fixed
Fix Version/s: 5.0
Cluster state updates can be lost on exception in main queue loop
-
Key: SOLR-6591
URL: https://issues.apache.org/jira/browse/SOLR-6591
Project: Solr
Issue Type: Bug
Components: SolrCloud
Affects Versions: Trunk
Reporter: Shalin Shekhar Mangar
Assignee: Shalin Shekhar Mangar
Fix For: 5.0, Trunk
Attachments: SOLR-6591-constructStateFix.patch,
SOLR-6591-ignore-no-collection-path.patch, SOLR-6591-no-mixed-batches.patch,
SOLR-6591.patch
I found this bug while going through the failure on jenkins:
https://builds.apache.org/job/Lucene-Solr-NightlyTests-trunk/648/
{code}
2 tests failed.
REGRESSION:
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testDistribSearch
Error Message:
Error CREATEing SolrCore 'halfcollection_shard1_replica1': Unable to create
core [halfcollection_shard1_replica1] Caused by: Could not get shard id for
core: halfcollection_shard1_replica1
Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException: Error
CREATEing SolrCore 'halfcollection_shard1_replica1': Unable to create core
[halfcollection_shard1_replica1] Caused by: Could not get shard id for core:
halfcollection_shard1_replica1
at
org.apache.solr.client.solrj.impl.HttpSolrServer.executeMethod(HttpSolrServer.java:570)
at
org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:215)
at
org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:211)
at
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testErrorHandling(CollectionsAPIDistributedZkTest.java:583)
at
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.doTest(CollectionsAPIDistributedZkTest.java:205)
at
org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:869)
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)
{code}
--
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-6796) distrib.singlePass does not return correct set of fields for multi-fl-parameter requests
[ https://issues.apache.org/jira/browse/SOLR-6796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231325#comment-14231325 ] Per Steffensen edited comment on SOLR-6796 at 12/2/14 12:55 PM: Maybe I can convince you to take a look at SOLR-6812 also, [~shalinmangar]? And maybe SOLR-6813? :-) I know I am pushing it now :-) was (Author: steff1193): Maybe I can convince you to take a look at SOLR-6812 also, [~shalinmangar]? distrib.singlePass does not return correct set of fields for multi-fl-parameter requests Key: SOLR-6796 URL: https://issues.apache.org/jira/browse/SOLR-6796 Project: Solr Issue Type: Bug Components: multicore, search Affects Versions: 5.0 Reporter: Per Steffensen Assignee: Shalin Shekhar Mangar Labels: distributed_search, search Attachments: fix.patch, fix.patch, fix.patch, fix.patch, test_that_reveals_the_problem.patch If I pass distrib.singlePass in a request that also has two fl-parameters, in some cases, I will not get the expected set of fields back for the returned documents -- 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-6476) Create a bulk mode for schema API
[
https://issues.apache.org/jira/browse/SOLR-6476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231432#comment-14231432
]
ASF subversion and git services commented on SOLR-6476:
---
Commit 1642862 from [~noble.paul] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1642862 ]
SOLR-6476 refactored bulk schema APIs and other read REST APIs to use standard
RequestHandler mechanism
Create a bulk mode for schema API
-
Key: SOLR-6476
URL: https://issues.apache.org/jira/browse/SOLR-6476
Project: Solr
Issue Type: New Feature
Components: Schema and Analysis
Reporter: Noble Paul
Assignee: Noble Paul
Labels: managedResource
Fix For: 5.0, Trunk
Attachments: SOLR-6476.patch, SOLR-6476.patch, SOLR-6476.patch,
SOLR-6476.patch, SOLR-6476.patch, SOLR-6476.patch, SOLR-6476.patch,
SOLR-6476.patch
The current schema API does one operation at a time and the normal usecase is
that users add multiple fields/fieldtypes/copyFields etc in one shot.
example
{code}
curl http://localhost:8983/solr/collection1/schema -H
'Content-type:application/json' -d '{
add-field: {
name:sell-by,
type:tdate,
stored:true
},
add-field:{
name:catchall,
type:text_general,
stored:false
}
}
{code}
or
{code}
curl http://localhost:8983/solr/collection1/schema -H
'Content-type:application/json' -d '{
add-field:[ {
name:sell-by,
type:tdate,
stored:true
},
{
name:catchall,
type:text_general,
stored:false
}]
}
{code}
--
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-6796) distrib.singlePass does not return correct set of fields for multi-fl-parameter requests
[ https://issues.apache.org/jira/browse/SOLR-6796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar updated SOLR-6796: Attachment: SOLR-6796.patch Patch which combines the test and fix given by Per. I moved the test to DistributedQueryComponentOptimizationTest. I'll commit once the test suite passes. distrib.singlePass does not return correct set of fields for multi-fl-parameter requests Key: SOLR-6796 URL: https://issues.apache.org/jira/browse/SOLR-6796 Project: Solr Issue Type: Bug Components: multicore, search Affects Versions: 5.0 Reporter: Per Steffensen Assignee: Shalin Shekhar Mangar Labels: distributed_search, search Attachments: SOLR-6796.patch, fix.patch, fix.patch, fix.patch, fix.patch, test_that_reveals_the_problem.patch If I pass distrib.singlePass in a request that also has two fl-parameters, in some cases, I will not get the expected set of fields back for the returned documents -- 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-6796) distrib.singlePass does not return correct set of fields for multi-fl-parameter requests
[ https://issues.apache.org/jira/browse/SOLR-6796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231448#comment-14231448 ] Shalin Shekhar Mangar commented on SOLR-6796: - I'll take a look at SOLR-6812 and SOLR-6813 too but I know very little about ExpandComponent so if things get too hairy, I'll probably defer to someone else. distrib.singlePass does not return correct set of fields for multi-fl-parameter requests Key: SOLR-6796 URL: https://issues.apache.org/jira/browse/SOLR-6796 Project: Solr Issue Type: Bug Components: multicore, search Affects Versions: 5.0 Reporter: Per Steffensen Assignee: Shalin Shekhar Mangar Labels: distributed_search, search Attachments: SOLR-6796.patch, fix.patch, fix.patch, fix.patch, fix.patch, test_that_reveals_the_problem.patch If I pass distrib.singlePass in a request that also has two fl-parameters, in some cases, I will not get the expected set of fields back for the returned documents -- 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-5205) SpanQueryParser with recursion, analysis and syntax very similar to classic QueryParser
[ https://issues.apache.org/jira/browse/LUCENE-5205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231476#comment-14231476 ] Tim Allison commented on LUCENE-5205: - Will look into it. To confirm, you have a query with 6000-8000 terms that you are OR'ing together? [~dsmiley], do I remember correctly that you recently added a query type for lots of terms? SpanQueryParser with recursion, analysis and syntax very similar to classic QueryParser --- Key: LUCENE-5205 URL: https://issues.apache.org/jira/browse/LUCENE-5205 Project: Lucene - Core Issue Type: Improvement Components: core/queryparser Reporter: Tim Allison Labels: patch Attachments: LUCENE-5205-cleanup-tests.patch, LUCENE-5205-date-pkg-prvt.patch, LUCENE-5205.patch.gz, LUCENE-5205.patch.gz, LUCENE-5205_dateTestReInitPkgPrvt.patch, LUCENE-5205_improve_stop_word_handling.patch, LUCENE-5205_smallTestMods.patch, LUCENE_5205.patch, SpanQueryParser_v1.patch.gz, patch.txt This parser extends QueryParserBase and includes functionality from: * Classic QueryParser: most of its syntax * SurroundQueryParser: recursive parsing for near and not clauses. * ComplexPhraseQueryParser: can handle near queries that include multiterms (wildcard, fuzzy, regex, prefix), * AnalyzingQueryParser: has an option to analyze multiterms. At a high level, there's a first pass BooleanQuery/field parser and then a span query parser handles all terminal nodes and phrases. Same as classic syntax: * term: test * fuzzy: roam~0.8, roam~2 * wildcard: te?t, test*, t*st * regex: /\[mb\]oat/ * phrase: jakarta apache * phrase with slop: jakarta apache~3 * default or clause: jakarta apache * grouping or clause: (jakarta apache) * boolean and +/-: (lucene OR apache) NOT jakarta; +lucene +apache -jakarta * multiple fields: title:lucene author:hatcher Main additions in SpanQueryParser syntax vs. classic syntax: * Can require in order for phrases with slop with the \~ operator: jakarta apache\~3 * Can specify not near: fever bieber!\~3,10 :: find fever but not if bieber appears within 3 words before or 10 words after it. * Fully recursive phrasal queries with \[ and \]; as in: \[\[jakarta apache\]~3 lucene\]\~4 :: find jakarta within 3 words of apache, and that hit has to be within four words before lucene * Can also use \[\] for single level phrasal queries instead of as in: \[jakarta apache\] * Can use or grouping clauses in phrasal queries: apache (lucene solr)\~3 :: find apache and then either lucene or solr within three words. * Can use multiterms in phrasal queries: jakarta\~1 ap*che\~2 * Did I mention full recursion: \[\[jakarta\~1 ap*che\]\~2 (solr~ /l\[ou\]\+\[cs\]\[en\]\+/)]\~10 :: Find something like jakarta within two words of ap*che and that hit has to be within ten words of something like solr or that lucene regex. * Can require at least x number of hits at boolean level: apache AND (lucene solr tika)~2 * Can use negative only query: -jakarta :: Find all docs that don't contain jakarta * Can use an edit distance 2 for fuzzy query via SlowFuzzyQuery (beware of potential performance issues!). Trivial additions: * Can specify prefix length in fuzzy queries: jakarta~1,2 (edit distance =1, prefix =2) * Can specifiy Optimal String Alignment (OSA) vs Levenshtein for distance =2: (jakarta~1 (OSA) vs jakarta~1(Levenshtein) This parser can be very useful for concordance tasks (see also LUCENE-5317 and LUCENE-5318) and for analytical search. Until LUCENE-2878 is closed, this might have a use for fans of SpanQuery. Most of the documentation is in the javadoc for SpanQueryParser. Any and all feedback is welcome. Thank you. Until this is added to the Lucene project, I've added a standalone lucene-addons repo (with jars compiled for the latest stable build of Lucene) on [github|https://github.com/tballison/lucene-addons]. -- 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] (LUCENE-5205) SpanQueryParser with recursion, analysis and syntax very similar to classic QueryParser
[ https://issues.apache.org/jira/browse/LUCENE-5205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231476#comment-14231476 ] Tim Allison edited comment on LUCENE-5205 at 12/2/14 1:39 PM: -- Will look into it. To confirm, you have a query with 6000-8000 terms that you are OR'ing together? [~dsmiley], do I remember correctly that you recently added a query type for efficiently searching lots of terms? was (Author: talli...@mitre.org): Will look into it. To confirm, you have a query with 6000-8000 terms that you are OR'ing together? [~dsmiley], do I remember correctly that you recently added a query type for lots of terms? SpanQueryParser with recursion, analysis and syntax very similar to classic QueryParser --- Key: LUCENE-5205 URL: https://issues.apache.org/jira/browse/LUCENE-5205 Project: Lucene - Core Issue Type: Improvement Components: core/queryparser Reporter: Tim Allison Labels: patch Attachments: LUCENE-5205-cleanup-tests.patch, LUCENE-5205-date-pkg-prvt.patch, LUCENE-5205.patch.gz, LUCENE-5205.patch.gz, LUCENE-5205_dateTestReInitPkgPrvt.patch, LUCENE-5205_improve_stop_word_handling.patch, LUCENE-5205_smallTestMods.patch, LUCENE_5205.patch, SpanQueryParser_v1.patch.gz, patch.txt This parser extends QueryParserBase and includes functionality from: * Classic QueryParser: most of its syntax * SurroundQueryParser: recursive parsing for near and not clauses. * ComplexPhraseQueryParser: can handle near queries that include multiterms (wildcard, fuzzy, regex, prefix), * AnalyzingQueryParser: has an option to analyze multiterms. At a high level, there's a first pass BooleanQuery/field parser and then a span query parser handles all terminal nodes and phrases. Same as classic syntax: * term: test * fuzzy: roam~0.8, roam~2 * wildcard: te?t, test*, t*st * regex: /\[mb\]oat/ * phrase: jakarta apache * phrase with slop: jakarta apache~3 * default or clause: jakarta apache * grouping or clause: (jakarta apache) * boolean and +/-: (lucene OR apache) NOT jakarta; +lucene +apache -jakarta * multiple fields: title:lucene author:hatcher Main additions in SpanQueryParser syntax vs. classic syntax: * Can require in order for phrases with slop with the \~ operator: jakarta apache\~3 * Can specify not near: fever bieber!\~3,10 :: find fever but not if bieber appears within 3 words before or 10 words after it. * Fully recursive phrasal queries with \[ and \]; as in: \[\[jakarta apache\]~3 lucene\]\~4 :: find jakarta within 3 words of apache, and that hit has to be within four words before lucene * Can also use \[\] for single level phrasal queries instead of as in: \[jakarta apache\] * Can use or grouping clauses in phrasal queries: apache (lucene solr)\~3 :: find apache and then either lucene or solr within three words. * Can use multiterms in phrasal queries: jakarta\~1 ap*che\~2 * Did I mention full recursion: \[\[jakarta\~1 ap*che\]\~2 (solr~ /l\[ou\]\+\[cs\]\[en\]\+/)]\~10 :: Find something like jakarta within two words of ap*che and that hit has to be within ten words of something like solr or that lucene regex. * Can require at least x number of hits at boolean level: apache AND (lucene solr tika)~2 * Can use negative only query: -jakarta :: Find all docs that don't contain jakarta * Can use an edit distance 2 for fuzzy query via SlowFuzzyQuery (beware of potential performance issues!). Trivial additions: * Can specify prefix length in fuzzy queries: jakarta~1,2 (edit distance =1, prefix =2) * Can specifiy Optimal String Alignment (OSA) vs Levenshtein for distance =2: (jakarta~1 (OSA) vs jakarta~1(Levenshtein) This parser can be very useful for concordance tasks (see also LUCENE-5317 and LUCENE-5318) and for analytical search. Until LUCENE-2878 is closed, this might have a use for fans of SpanQuery. Most of the documentation is in the javadoc for SpanQueryParser. Any and all feedback is welcome. Thank you. Until this is added to the Lucene project, I've added a standalone lucene-addons repo (with jars compiled for the latest stable build of Lucene) on [github|https://github.com/tballison/lucene-addons]. -- 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-4792) stop shipping a war in 5.0
[ https://issues.apache.org/jira/browse/SOLR-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231479#comment-14231479 ] Mark Miller commented on SOLR-4792: --- My point is - we have had a discussion, we have had a vote, the WAR is gone. If someone wants to re hash things but is not willing to dig up the previous discussion and vote, that is up to them, but I don't have al lot to comment on then. Anyone can add any links to this issue. I'm not looking to have this fight yet again, and so I'm just going to make sure official WAR support is removed for 5x and go back to my regularly scheduled programming. stop shipping a war in 5.0 -- Key: SOLR-4792 URL: https://issues.apache.org/jira/browse/SOLR-4792 Project: Solr Issue Type: Task Components: Build Reporter: Robert Muir Assignee: Mark Miller Fix For: 5.0, Trunk Attachments: SOLR-4792.patch see the vote on the developer list. This is the first step: if we stop shipping a war then we are free to do anything we want. -- 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-6796) distrib.singlePass does not return correct set of fields for multi-fl-parameter requests
[ https://issues.apache.org/jira/browse/SOLR-6796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231502#comment-14231502 ] ASF subversion and git services commented on SOLR-6796: --- Commit 1642873 from sha...@apache.org in branch 'dev/trunk' [ https://svn.apache.org/r1642873 ] SOLR-6796: distrib.singlePass does not return correct set of fields for multi-fl-parameter requests distrib.singlePass does not return correct set of fields for multi-fl-parameter requests Key: SOLR-6796 URL: https://issues.apache.org/jira/browse/SOLR-6796 Project: Solr Issue Type: Bug Components: multicore, search Affects Versions: 5.0 Reporter: Per Steffensen Assignee: Shalin Shekhar Mangar Labels: distributed_search, search Attachments: SOLR-6796.patch, fix.patch, fix.patch, fix.patch, fix.patch, test_that_reveals_the_problem.patch If I pass distrib.singlePass in a request that also has two fl-parameters, in some cases, I will not get the expected set of fields back for the returned documents -- 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-6796) distrib.singlePass does not return correct set of fields for multi-fl-parameter requests
[ https://issues.apache.org/jira/browse/SOLR-6796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231505#comment-14231505 ] ASF subversion and git services commented on SOLR-6796: --- Commit 1642874 from sha...@apache.org in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1642874 ] SOLR-6796: distrib.singlePass does not return correct set of fields for multi-fl-parameter requests distrib.singlePass does not return correct set of fields for multi-fl-parameter requests Key: SOLR-6796 URL: https://issues.apache.org/jira/browse/SOLR-6796 Project: Solr Issue Type: Bug Components: multicore, search Affects Versions: 5.0 Reporter: Per Steffensen Assignee: Shalin Shekhar Mangar Labels: distributed_search, search Attachments: SOLR-6796.patch, fix.patch, fix.patch, fix.patch, fix.patch, test_that_reveals_the_problem.patch If I pass distrib.singlePass in a request that also has two fl-parameters, in some cases, I will not get the expected set of fields back for the returned documents -- 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-6796) distrib.singlePass does not return correct set of fields for multi-fl-parameter requests
[ https://issues.apache.org/jira/browse/SOLR-6796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231521#comment-14231521 ] ASF subversion and git services commented on SOLR-6796: --- Commit 1642876 from sha...@apache.org in branch 'dev/branches/lucene_solr_4_10' [ https://svn.apache.org/r1642876 ] SOLR-6796: distrib.singlePass does not return correct set of fields for multi-fl-parameter requests distrib.singlePass does not return correct set of fields for multi-fl-parameter requests Key: SOLR-6796 URL: https://issues.apache.org/jira/browse/SOLR-6796 Project: Solr Issue Type: Bug Components: multicore, search Affects Versions: 5.0 Reporter: Per Steffensen Assignee: Shalin Shekhar Mangar Labels: distributed_search, search Attachments: SOLR-6796.patch, fix.patch, fix.patch, fix.patch, fix.patch, test_that_reveals_the_problem.patch If I pass distrib.singlePass in a request that also has two fl-parameters, in some cases, I will not get the expected set of fields back for the returned documents -- 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-6796) distrib.singlePass does not return correct set of fields for multi-fl-parameter requests
[ https://issues.apache.org/jira/browse/SOLR-6796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar resolved SOLR-6796. - Resolution: Fixed Thanks Per! distrib.singlePass does not return correct set of fields for multi-fl-parameter requests Key: SOLR-6796 URL: https://issues.apache.org/jira/browse/SOLR-6796 Project: Solr Issue Type: Bug Components: multicore, search Affects Versions: 4.10.2, 5.0 Reporter: Per Steffensen Assignee: Shalin Shekhar Mangar Labels: distributed_search, search Fix For: 4.10.3, 5.0, Trunk Attachments: SOLR-6796.patch, fix.patch, fix.patch, fix.patch, fix.patch, test_that_reveals_the_problem.patch If I pass distrib.singlePass in a request that also has two fl-parameters, in some cases, I will not get the expected set of fields back for the returned documents -- 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-6796) distrib.singlePass does not return correct set of fields for multi-fl-parameter requests
[ https://issues.apache.org/jira/browse/SOLR-6796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar updated SOLR-6796: Affects Version/s: 4.10.2 Fix Version/s: Trunk 5.0 4.10.3 distrib.singlePass does not return correct set of fields for multi-fl-parameter requests Key: SOLR-6796 URL: https://issues.apache.org/jira/browse/SOLR-6796 Project: Solr Issue Type: Bug Components: multicore, search Affects Versions: 4.10.2, 5.0 Reporter: Per Steffensen Assignee: Shalin Shekhar Mangar Labels: distributed_search, search Fix For: 4.10.3, 5.0, Trunk Attachments: SOLR-6796.patch, fix.patch, fix.patch, fix.patch, fix.patch, test_that_reveals_the_problem.patch If I pass distrib.singlePass in a request that also has two fl-parameters, in some cases, I will not get the expected set of fields back for the returned documents -- 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-4792) stop shipping a war in 5.0
[ https://issues.apache.org/jira/browse/SOLR-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231524#comment-14231524 ] Jayson Minard commented on SOLR-4792: - Mark: so final understanding: WAR gone from maven, WAR gone from dist, but will remain in server/web-apps correct? stop shipping a war in 5.0 -- Key: SOLR-4792 URL: https://issues.apache.org/jira/browse/SOLR-4792 Project: Solr Issue Type: Task Components: Build Reporter: Robert Muir Assignee: Mark Miller Fix For: 5.0, Trunk Attachments: SOLR-4792.patch see the vote on the developer list. This is the first step: if we stop shipping a war then we are free to do anything we want. -- 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-6559) Create an endpoint /update/xml/docs endpoint to do custom xml indexing
[ https://issues.apache.org/jira/browse/SOLR-6559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231532#comment-14231532 ] Noble Paul commented on SOLR-6559: -- It is OK to stick to XPath syntax . Because we don't want to reeducate the users. What is your preference? Create an endpoint /update/xml/docs endpoint to do custom xml indexing -- Key: SOLR-6559 URL: https://issues.apache.org/jira/browse/SOLR-6559 Project: Solr Issue Type: Bug Reporter: Noble Paul Assignee: Noble Paul Attachments: SOLR-6559.patch Just the way we have an json end point create an xml end point too. use the XPathRecordReader in DIH to do the same . The syntax would require slight tweaking to match the params of /update/json/docs -- 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-5205) SpanQueryParser with recursion, analysis and syntax very similar to classic QueryParser
[ https://issues.apache.org/jira/browse/LUCENE-5205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231544#comment-14231544 ] David Smiley commented on LUCENE-5205: -- On the Solr end, I added a terms QParser that in turn uses one of the 4 differing options at the Lucene layer. The option likely most suitable is a Lucene TermsFilter. SpanQueryParser with recursion, analysis and syntax very similar to classic QueryParser --- Key: LUCENE-5205 URL: https://issues.apache.org/jira/browse/LUCENE-5205 Project: Lucene - Core Issue Type: Improvement Components: core/queryparser Reporter: Tim Allison Labels: patch Attachments: LUCENE-5205-cleanup-tests.patch, LUCENE-5205-date-pkg-prvt.patch, LUCENE-5205.patch.gz, LUCENE-5205.patch.gz, LUCENE-5205_dateTestReInitPkgPrvt.patch, LUCENE-5205_improve_stop_word_handling.patch, LUCENE-5205_smallTestMods.patch, LUCENE_5205.patch, SpanQueryParser_v1.patch.gz, patch.txt This parser extends QueryParserBase and includes functionality from: * Classic QueryParser: most of its syntax * SurroundQueryParser: recursive parsing for near and not clauses. * ComplexPhraseQueryParser: can handle near queries that include multiterms (wildcard, fuzzy, regex, prefix), * AnalyzingQueryParser: has an option to analyze multiterms. At a high level, there's a first pass BooleanQuery/field parser and then a span query parser handles all terminal nodes and phrases. Same as classic syntax: * term: test * fuzzy: roam~0.8, roam~2 * wildcard: te?t, test*, t*st * regex: /\[mb\]oat/ * phrase: jakarta apache * phrase with slop: jakarta apache~3 * default or clause: jakarta apache * grouping or clause: (jakarta apache) * boolean and +/-: (lucene OR apache) NOT jakarta; +lucene +apache -jakarta * multiple fields: title:lucene author:hatcher Main additions in SpanQueryParser syntax vs. classic syntax: * Can require in order for phrases with slop with the \~ operator: jakarta apache\~3 * Can specify not near: fever bieber!\~3,10 :: find fever but not if bieber appears within 3 words before or 10 words after it. * Fully recursive phrasal queries with \[ and \]; as in: \[\[jakarta apache\]~3 lucene\]\~4 :: find jakarta within 3 words of apache, and that hit has to be within four words before lucene * Can also use \[\] for single level phrasal queries instead of as in: \[jakarta apache\] * Can use or grouping clauses in phrasal queries: apache (lucene solr)\~3 :: find apache and then either lucene or solr within three words. * Can use multiterms in phrasal queries: jakarta\~1 ap*che\~2 * Did I mention full recursion: \[\[jakarta\~1 ap*che\]\~2 (solr~ /l\[ou\]\+\[cs\]\[en\]\+/)]\~10 :: Find something like jakarta within two words of ap*che and that hit has to be within ten words of something like solr or that lucene regex. * Can require at least x number of hits at boolean level: apache AND (lucene solr tika)~2 * Can use negative only query: -jakarta :: Find all docs that don't contain jakarta * Can use an edit distance 2 for fuzzy query via SlowFuzzyQuery (beware of potential performance issues!). Trivial additions: * Can specify prefix length in fuzzy queries: jakarta~1,2 (edit distance =1, prefix =2) * Can specifiy Optimal String Alignment (OSA) vs Levenshtein for distance =2: (jakarta~1 (OSA) vs jakarta~1(Levenshtein) This parser can be very useful for concordance tasks (see also LUCENE-5317 and LUCENE-5318) and for analytical search. Until LUCENE-2878 is closed, this might have a use for fans of SpanQuery. Most of the documentation is in the javadoc for SpanQueryParser. Any and all feedback is welcome. Thank you. Until this is added to the Lucene project, I've added a standalone lucene-addons repo (with jars compiled for the latest stable build of Lucene) on [github|https://github.com/tballison/lucene-addons]. -- 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-4792) stop shipping a war in 5.0
[ https://issues.apache.org/jira/browse/SOLR-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231545#comment-14231545 ] ASF subversion and git services commented on SOLR-4792: --- Commit 1642879 from [~markrmil...@gmail.com] in branch 'dev/trunk' [ https://svn.apache.org/r1642879 ] SOLR-4792: Remove WAR file from dist directory. stop shipping a war in 5.0 -- Key: SOLR-4792 URL: https://issues.apache.org/jira/browse/SOLR-4792 Project: Solr Issue Type: Task Components: Build Reporter: Robert Muir Assignee: Mark Miller Fix For: 5.0, Trunk Attachments: SOLR-4792.patch see the vote on the developer list. This is the first step: if we stop shipping a war then we are free to do anything we want. -- 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-4792) stop shipping a war in 5.0
[ https://issues.apache.org/jira/browse/SOLR-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231546#comment-14231546 ] ASF subversion and git services commented on SOLR-4792: --- Commit 1642880 from [~markrmil...@gmail.com] in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1642880 ] SOLR-4792: Remove WAR file from dist directory. stop shipping a war in 5.0 -- Key: SOLR-4792 URL: https://issues.apache.org/jira/browse/SOLR-4792 Project: Solr Issue Type: Task Components: Build Reporter: Robert Muir Assignee: Mark Miller Fix For: 5.0, Trunk Attachments: SOLR-4792.patch see the vote on the developer list. This is the first step: if we stop shipping a war then we are free to do anything we want. -- 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-4792) stop shipping a war in 5.0
[ https://issues.apache.org/jira/browse/SOLR-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231548#comment-14231548 ] Mark Miller commented on SOLR-4792: --- bq. so final understanding: WAR gone from maven, WAR gone from dist, but will remain in server/web-apps That's how I intend to leave this issue. [~thetaphi], I think if you want to discuss further changes, we should do it in a new issue and leave this one at this. stop shipping a war in 5.0 -- Key: SOLR-4792 URL: https://issues.apache.org/jira/browse/SOLR-4792 Project: Solr Issue Type: Task Components: Build Reporter: Robert Muir Assignee: Mark Miller Fix For: 5.0, Trunk Attachments: SOLR-4792.patch see the vote on the developer list. This is the first step: if we stop shipping a war then we are free to do anything we want. -- 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: Why do we have a CoreAdminHandler#Load action?
Hmmm, this looks odd, indeed. Perhaps it was an incomplete attempt to fix up the fact that after you UNLOAD a core, it's not obvious that CREATE (or maybe RELOAD?) would get the core back. But it doesn't seem to do anything so even if someone uses it, nothing happens which is A Bad Thing. Removing it would cause anyone using it now to have an error they didn't have before, but I'm hard-pressed to believe that that's really worse than failing silently as it does at present. Counter-prorposal: Leave it in and have it call CREATE with minimal parameters and add LOAD to the docs. That said, I'm not able to do the actual work right now so whatever you decide. Erick On Mon, Dec 1, 2014 at 6:58 PM, Varun Thacker varunthacker1...@gmail.com wrote: Is there a reason why we have a switch condition to LOAD in code? Can we remove otherwise. -- Regards, Varun Thacker http://www.vthacker.in/ - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6087) SearcherManager should accept foreign DirectoryReader on init
[ https://issues.apache.org/jira/browse/LUCENE-6087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231564#comment-14231564 ] ASF subversion and git services commented on LUCENE-6087: - Commit 1642887 from [~mikemccand] in branch 'dev/trunk' [ https://svn.apache.org/r1642887 ] LUCENE-6087: allow custom DirectoryReader to SearcherManager SearcherManager should accept foreign DirectoryReader on init - Key: LUCENE-6087 URL: https://issues.apache.org/jira/browse/LUCENE-6087 Project: Lucene - Core Issue Type: Improvement Reporter: Michael McCandless Assignee: Michael McCandless Fix For: Trunk, 5.x Attachments: LUCENE-6087.patch Today you init SearcherManager either with a dir or an IndexWriter, but since we have a useful FilterDirectoryReader class to wrap the sub-readers, it's useful for apps to also pass their own wrapped DirectoryReader and have SearcherManager reopen from that. -- 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-6087) SearcherManager should accept foreign DirectoryReader on init
[ https://issues.apache.org/jira/browse/LUCENE-6087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231566#comment-14231566 ] ASF subversion and git services commented on LUCENE-6087: - Commit 1642891 from [~mikemccand] in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1642891 ] LUCENE-6087: allow custom DirectoryReader to SearcherManager SearcherManager should accept foreign DirectoryReader on init - Key: LUCENE-6087 URL: https://issues.apache.org/jira/browse/LUCENE-6087 Project: Lucene - Core Issue Type: Improvement Reporter: Michael McCandless Assignee: Michael McCandless Fix For: Trunk, 5.x Attachments: LUCENE-6087.patch Today you init SearcherManager either with a dir or an IndexWriter, but since we have a useful FilterDirectoryReader class to wrap the sub-readers, it's useful for apps to also pass their own wrapped DirectoryReader and have SearcherManager reopen from that. -- 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-6087) SearcherManager should accept foreign DirectoryReader on init
[ https://issues.apache.org/jira/browse/LUCENE-6087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless resolved LUCENE-6087. Resolution: Fixed SearcherManager should accept foreign DirectoryReader on init - Key: LUCENE-6087 URL: https://issues.apache.org/jira/browse/LUCENE-6087 Project: Lucene - Core Issue Type: Improvement Reporter: Michael McCandless Assignee: Michael McCandless Fix For: Trunk, 5.x Attachments: LUCENE-6087.patch Today you init SearcherManager either with a dir or an IndexWriter, but since we have a useful FilterDirectoryReader class to wrap the sub-readers, it's useful for apps to also pass their own wrapped DirectoryReader and have SearcherManager reopen from that. -- 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-6075) SimpleRateLimiter cast overflow results in Thread.sleep exception
[ https://issues.apache.org/jira/browse/LUCENE-6075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231579#comment-14231579 ] Boaz Leskes commented on LUCENE-6075: - Yeah, that's the tricky part which made me wonder (as opposed to a suggestion :)) The only thought I had is maintaining a last update time stamp (on top on lastNS) and if that goes backwards, adapt for it? I'm not sure how often this happens in practice though. From the reaction, I judge that it's not really often and we just have stepped into a very rare case. I'm OK with leaving as is. Thx for the fix! SimpleRateLimiter cast overflow results in Thread.sleep exception - Key: LUCENE-6075 URL: https://issues.apache.org/jira/browse/LUCENE-6075 Project: Lucene - Core Issue Type: Bug Components: core/store Reporter: Boaz Leskes Assignee: Michael McCandless Fix For: 4.10.3, Trunk, 5.x Attachments: LUCENE-6075.patch SimpleRateLimiter.pause() uses an uncheck cast of longs to ints: Thread.sleep((int) (pauseNS/100), (int) (pauseNS % 100)); Although we check that pauseNS is positive, however if it's large enough the cast to int produces a negative value, causing Thread.sleep to throw an exception. We should protect for it. -- 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-6812) distrib.singlePass does not work for expand-request
[
https://issues.apache.org/jira/browse/SOLR-6812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231323#comment-14231323
]
Per Steffensen edited comment on SOLR-6812 at 12/2/14 3:09 PM:
---
Attached a fix to the problem. Problem is that {{ExpandComponent}} kinda
detects that it is supposed to do its thing for shard-searches, by seeing if
ids-param is there. It is not in case of {{distrib.singlePass}}.
Patch works on purpose instead, because that is really whats controlling the
things in {{QueryComponent}}. So now purpose is distributed in the
shard-requests.
was (Author: steff1193):
Attached a fix to the problem. Problem is that {{ExpandComponent}} kinda
detects that it is supposed to do its thing for shard-searches, by seeing if
ids-param is there. It is not in case of {{distrib.singlePass}}.
Patch works on purpose instead, because that is really whats controlling the
things in {{QueryComponent}}. So not purpose is distributed in the
shard-requests.
distrib.singlePass does not work for expand-request
---
Key: SOLR-6812
URL: https://issues.apache.org/jira/browse/SOLR-6812
Project: Solr
Issue Type: Bug
Components: multicore, search
Reporter: Per Steffensen
Labels: distributed_search, search
Attachments: fix.patch, test_that_reveals_the_problem.patch
Using distrib.singlePass does not work for expand-requests.
--
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-4799) SQLEntityProcessor for zipper join
[
https://issues.apache.org/jira/browse/SOLR-4799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231599#comment-14231599
]
Noble Paul commented on SOLR-4799:
--
Isn't only relevant for {{SqlEntityProcessor}} ? can zipper be initialized at
{{SqlEntityProcessor}} instead of {{EntityProcessorBase}} ?
SQLEntityProcessor for zipper join
--
Key: SOLR-4799
URL: https://issues.apache.org/jira/browse/SOLR-4799
Project: Solr
Issue Type: New Feature
Components: contrib - DataImportHandler
Reporter: Mikhail Khludnev
Priority: Minor
Labels: DIH, dataimportHandler, dih
Attachments: SOLR-4799.patch, SOLR-4799.patch, SOLR-4799.patch,
SOLR-4799.patch, SOLR-4799.patch
DIH is mostly considered as a playground tool, and real usages end up with
SolrJ. I want to contribute few improvements target DIH performance.
This one provides performant approach for joining SQL Entities with miserable
memory at contrast to
http://wiki.apache.org/solr/DataImportHandler#CachedSqlEntityProcessor
The idea is:
* parent table is explicitly ordered by it’s PK in SQL
* children table is explicitly ordered by parent_id FK in SQL
* children entity processor joins ordered resultsets by ‘zipper’ algorithm.
Do you think it’s worth to contribute it into DIH?
cc: [~goksron] [~jdyer]
--
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-4799) SQLEntityProcessor for zipper join
[ https://issues.apache.org/jira/browse/SOLR-4799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231640#comment-14231640 ] James Dyer commented on SOLR-4799: -- Let me mention that with SOLR-2943, you can read back cached data in key order, which would allow you to zipper-join anything that can be previously cached. While this is not a committed feature, it demonstrates that you can have entities other than SQL with the keys in the correct order for joining. So if possible, I wouldn't make this just for SQL. SQLEntityProcessor for zipper join -- Key: SOLR-4799 URL: https://issues.apache.org/jira/browse/SOLR-4799 Project: Solr Issue Type: New Feature Components: contrib - DataImportHandler Reporter: Mikhail Khludnev Priority: Minor Labels: DIH, dataimportHandler, dih Attachments: SOLR-4799.patch, SOLR-4799.patch, SOLR-4799.patch, SOLR-4799.patch, SOLR-4799.patch DIH is mostly considered as a playground tool, and real usages end up with SolrJ. I want to contribute few improvements target DIH performance. This one provides performant approach for joining SQL Entities with miserable memory at contrast to http://wiki.apache.org/solr/DataImportHandler#CachedSqlEntityProcessor The idea is: * parent table is explicitly ordered by it’s PK in SQL * children table is explicitly ordered by parent_id FK in SQL * children entity processor joins ordered resultsets by ‘zipper’ algorithm. Do you think it’s worth to contribute it into DIH? cc: [~goksron] [~jdyer] -- 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-6732) Back-compat break for LIR state in 4.10.2
[ https://issues.apache.org/jira/browse/SOLR-6732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231650#comment-14231650 ] ASF subversion and git services commented on SOLR-6732: --- Commit 1642917 from [~thelabdude] in branch 'dev/trunk' [ https://svn.apache.org/r1642917 ] SOLR-6732: back compat support needed in trunk and 5x to support upgrades from 4.10.1 to 5x Back-compat break for LIR state in 4.10.2 - Key: SOLR-6732 URL: https://issues.apache.org/jira/browse/SOLR-6732 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.10.2 Reporter: Shalin Shekhar Mangar Assignee: Timothy Potter Priority: Blocker Fix For: 4.10.3 Attachments: SOLR-6732.patch, SOLR-6732.patch We changed the LIR state to be kept as a map but it is not back-compatible. The problem is that we're checking for map or string after parsing JSON but if the key has down as a string then json parsing will fail. This was introduced in SOLR-6511. This error will prevent anyone from upgrading to 4.10.2 http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201411.mbox/%3c54636ed2.8040...@cytainment.de%3E -- 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-6085) Add back SI.attributes (safely)
[ https://issues.apache.org/jira/browse/LUCENE-6085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231660#comment-14231660 ] ASF subversion and git services commented on LUCENE-6085: - Commit 1642919 from [~rcmuir] in branch 'dev/trunk' [ https://svn.apache.org/r1642919 ] LUCENE-6085: add back SI.attributes Add back SI.attributes (safely) --- Key: LUCENE-6085 URL: https://issues.apache.org/jira/browse/LUCENE-6085 Project: Lucene - Core Issue Type: Bug Reporter: Robert Muir Attachments: LUCENE-6085.patch We removed this for two reasons: * nothing was using it * the map is unsafe if a codec tried to write to it during in-place dv update. But Adrien has a real use case (LUCENE-5914), and I think we can just add some safety for the updates case (e.g. if the map is unmodifiable then the trap will not exist, any put() will throw exception). In general, we should have more safety in SI anyway (diagnostics map, too). -- 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-6732) Back-compat break for LIR state in 4.10.2
[ https://issues.apache.org/jira/browse/SOLR-6732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231664#comment-14231664 ] ASF subversion and git services commented on SOLR-6732: --- Commit 1642920 from [~thelabdude] in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1642920 ] SOLR-6732: back compat support needed in trunk and 5x to support upgrades from 4.10.1 to 5x Back-compat break for LIR state in 4.10.2 - Key: SOLR-6732 URL: https://issues.apache.org/jira/browse/SOLR-6732 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.10.2 Reporter: Shalin Shekhar Mangar Assignee: Timothy Potter Priority: Blocker Fix For: 4.10.3 Attachments: SOLR-6732.patch, SOLR-6732.patch We changed the LIR state to be kept as a map but it is not back-compatible. The problem is that we're checking for map or string after parsing JSON but if the key has down as a string then json parsing will fail. This was introduced in SOLR-6511. This error will prevent anyone from upgrading to 4.10.2 http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201411.mbox/%3c54636ed2.8040...@cytainment.de%3E -- 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-6732) Back-compat break for LIR state in 4.10.2
[ https://issues.apache.org/jira/browse/SOLR-6732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Potter updated SOLR-6732: - Fix Version/s: 5.0 Back-compat break for LIR state in 4.10.2 - Key: SOLR-6732 URL: https://issues.apache.org/jira/browse/SOLR-6732 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.10.2 Reporter: Shalin Shekhar Mangar Assignee: Timothy Potter Priority: Blocker Fix For: 4.10.3, 5.0 Attachments: SOLR-6732.patch, SOLR-6732.patch We changed the LIR state to be kept as a map but it is not back-compatible. The problem is that we're checking for map or string after parsing JSON but if the key has down as a string then json parsing will fail. This was introduced in SOLR-6511. This error will prevent anyone from upgrading to 4.10.2 http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201411.mbox/%3c54636ed2.8040...@cytainment.de%3E -- 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-4799) SQLEntityProcessor for zipper join
[ https://issues.apache.org/jira/browse/SOLR-4799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231681#comment-14231681 ] Noble Paul commented on SOLR-4799: -- If that is the case please change the title/description to match that SQLEntityProcessor for zipper join -- Key: SOLR-4799 URL: https://issues.apache.org/jira/browse/SOLR-4799 Project: Solr Issue Type: New Feature Components: contrib - DataImportHandler Reporter: Mikhail Khludnev Priority: Minor Labels: DIH, dataimportHandler, dih Attachments: SOLR-4799.patch, SOLR-4799.patch, SOLR-4799.patch, SOLR-4799.patch, SOLR-4799.patch DIH is mostly considered as a playground tool, and real usages end up with SolrJ. I want to contribute few improvements target DIH performance. This one provides performant approach for joining SQL Entities with miserable memory at contrast to http://wiki.apache.org/solr/DataImportHandler#CachedSqlEntityProcessor The idea is: * parent table is explicitly ordered by it’s PK in SQL * children table is explicitly ordered by parent_id FK in SQL * children entity processor joins ordered resultsets by ‘zipper’ algorithm. Do you think it’s worth to contribute it into DIH? cc: [~goksron] [~jdyer] -- 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] (LUCENE-6088) Make TermsFilter implement Accountable
Adrien Grand created LUCENE-6088: Summary: Make TermsFilter implement Accountable Key: LUCENE-6088 URL: https://issues.apache.org/jira/browse/LUCENE-6088 Project: Lucene - Core Issue Type: Improvement Reporter: Adrien Grand Assignee: Adrien Grand Priority: Minor Terms filters can sometimes be massive. Having their memory usage exposed can be useful eg. for the FilterCache. -- 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-6088) Make TermsFilter implement Accountable
[ https://issues.apache.org/jira/browse/LUCENE-6088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrien Grand updated LUCENE-6088: - Attachment: LUCENE-6088.patch Here is a patch. Make TermsFilter implement Accountable -- Key: LUCENE-6088 URL: https://issues.apache.org/jira/browse/LUCENE-6088 Project: Lucene - Core Issue Type: Improvement Reporter: Adrien Grand Assignee: Adrien Grand Priority: Minor Attachments: LUCENE-6088.patch Terms filters can sometimes be massive. Having their memory usage exposed can be useful eg. for the FilterCache. -- 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] [Assigned] (SOLR-6776) Data lost when use SoftCommit and TLog
[
https://issues.apache.org/jira/browse/SOLR-6776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yonik Seeley reassigned SOLR-6776:
--
Assignee: Yonik Seeley
Data lost when use SoftCommit and TLog
--
Key: SOLR-6776
URL: https://issues.apache.org/jira/browse/SOLR-6776
Project: Solr
Issue Type: Bug
Affects Versions: 4.10
Reporter: yuanyun.cn
Assignee: Yonik Seeley
Labels: softCommit, updateLog
Fix For: 4.10.3
We enabled update log and change autoCommit to some bigger value 10 mins.
After restart, we push one doc with softCommit=true
http://localhost:8983/solr/update?stream.body=adddocfield
name=idid1/field/doc/addsoftCommit=true
Then we kill the java process after a min.
After restart, Tlog failed to replay with following exception, and there is
no data in solr.
6245 [coreLoadExecutor-5-thread-1] ERROR org.apache.solr.update.UpdateLog û
Failure to open existing log file (non fatal)
E:\jeffery\src\apache\solr\4.10.2\solr-4.10.2\example\solr\collection1\data\t
log\tlog.000:org.apache.solr.common.SolrException:
java.io.EOFException
at
org.apache.solr.update.TransactionLog.init(TransactionLog.java:181)
at org.apache.solr.update.UpdateLog.init(UpdateLog.java:261)
at org.apache.solr.update.UpdateHandler.init(UpdateHandler.java:134)
at org.apache.solr.update.UpdateHandler.init(UpdateHandler.java:94)
at
org.apache.solr.update.DirectUpdateHandler2.init(DirectUpdateHandler2.java:100)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown
Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown
Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at org.apache.solr.core.SolrCore.createInstance(SolrCore.java:550)
at
org.apache.solr.core.SolrCore.createUpdateHandler(SolrCore.java:620)
at org.apache.solr.core.SolrCore.init(SolrCore.java:835)
at org.apache.solr.core.SolrCore.init(SolrCore.java:646)
at org.apache.solr.core.CoreContainer.create(CoreContainer.java:491)
at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:255)
at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:249)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.io.EOFException
at
org.apache.solr.common.util.FastInputStream.readUnsignedByte(FastInputStream.java:73)
at
org.apache.solr.common.util.FastInputStream.readInt(FastInputStream.java:216)
at
org.apache.solr.update.TransactionLog.readHeader(TransactionLog.java:268)
at
org.apache.solr.update.TransactionLog.init(TransactionLog.java:159)
... 19 more
Check the code: seems this is related with:
org.apache.solr.update.processor.RunUpdateProcessor, in processCommit, it
sets changesSinceCommit=false(even we are using softCommit)
So in finish, updateLog.finish will not be called.
public void finish() throws IOException {
if (changesSinceCommit updateHandler.getUpdateLog() != null) {
updateHandler.getUpdateLog().finish(null);
}
super.finish();
}
To fix this issue: I have to change RunUpdateProcessor.processCommit like
below:
if (!cmd.softCommit) {
changesSinceCommit = false;
}
--
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-MAVEN] Lucene-Solr-Maven-5.x #775: POMs out of sync
Build: https://builds.apache.org/job/Lucene-Solr-Maven-5.x/775/ 4 tests failed. FAILED: org.apache.solr.hadoop.MapReduceIndexerToolArgumentParserTest.org.apache.solr.hadoop.MapReduceIndexerToolArgumentParserTest Error Message: null Stack Trace: java.lang.AssertionError: null at __randomizedtesting.SeedInfo.seed([E94CED32E81D5C63]:0) at org.apache.lucene.util.TestRuleTemporaryFilesCleanup.before(TestRuleTemporaryFilesCleanup.java:105) at com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.before(TestRuleAdapter.java:26) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:35) 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) REGRESSION: org.apache.solr.hadoop.MorphlineGoLiveMiniMRTest.testDistribSearch Error Message: org.apache.solr.client.solrj.SolrServerException: IOException occured when talking to server at: https://127.0.0.1:13965/s_jke/om/collection1 Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException: org.apache.solr.client.solrj.SolrServerException: IOException occured when talking to server at: https://127.0.0.1:13965/s_jke/om/collection1 at __randomizedtesting.SeedInfo.seed([8BE2C56AE9066521:A044B729E59051D]:0) at org.apache.solr.client.solrj.impl.HttpSolrServer.executeMethod(HttpSolrServer.java:569) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:215) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:211) at org.apache.solr.client.solrj.request.QueryRequest.process(QueryRequest.java:91) at org.apache.solr.client.solrj.SolrServer.query(SolrServer.java:301) at org.apache.solr.hadoop.MorphlineGoLiveMiniMRTest.doTest(MorphlineGoLiveMiniMRTest.java:410) FAILED: org.apache.solr.hadoop.MorphlineBasicMiniMRTest.testPathParts Error Message: Test abandoned because suite timeout was reached. Stack Trace: java.lang.Exception: Test abandoned because suite timeout was reached. at __randomizedtesting.SeedInfo.seed([1184ED5621F08419]:0) FAILED: org.apache.solr.hadoop.MorphlineBasicMiniMRTest.org.apache.solr.hadoop.MorphlineBasicMiniMRTest Error Message: Suite timeout exceeded (= 720 msec). Stack Trace: java.lang.Exception: Suite timeout exceeded (= 720 msec). at __randomizedtesting.SeedInfo.seed([1184ED5621F08419]:0) Build Log: [...truncated 53867 lines...] BUILD FAILED /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-5.x/build.xml:552: The following error occurred while executing this line: /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-5.x/build.xml:204: The following error occurred while executing this line: : Java returned: 1 Total time: 382 minutes 17 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] [Commented] (SOLR-6755) ClassCastException from CloudMLTQParserTest
[
https://issues.apache.org/jira/browse/SOLR-6755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231714#comment-14231714
]
Anshum Gupta commented on SOLR-6755:
I haven't been able to reproduce this one even after running it all night.
Also, considering there's no variable involved in the test, the result should
be always be the same.
I'm going to add some extra logging in there and wait for the next Jenkins
failure to be able to debug.
ClassCastException from CloudMLTQParserTest
---
Key: SOLR-6755
URL: https://issues.apache.org/jira/browse/SOLR-6755
Project: Solr
Issue Type: Bug
Reporter: Hoss Man
Assignee: Anshum Gupta
The seed doesn't reproduce for me, but the ClassCastException seems hinky and
worth looking into...
{noformat}
[junit4] 2 NOTE: reproduce with: ant test
-Dtestcase=CloudMLTQParserTest -Dtests.method=testDistribSearch
-Dtests.seed=3AE918BB008859A6 -Dtests.multiplier=3 -Dtests.slow=true
-Dtests.locale=iw -Dtests.timezone=America/Indiana/Vincennes
-Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1
[junit4] ERROR 50.7s J1 | CloudMLTQParserTest.testDistribSearch
[junit4] Throwable #1: java.lang.ClassCastException: java.lang.String
cannot be cast to java.util.ArrayList
[junit4] at
__randomizedtesting.SeedInfo.seed([3AE918BB008859A6:BB0F96A377D7399A]:0)
[junit4] at
org.apache.solr.search.mlt.CloudMLTQParserTest.doTest(CloudMLTQParserTest.java:124)
[junit4] at
org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:869)
[junit4] at java.lang.Thread.run(Thread.java:745)
{noformat}
http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/11466/consoleText
Java: 64bit/jdk1.7.0_67 -XX:-UseCompressedOops -XX:+UseG1GC (asserts: true)
At revision 1640267
--
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-6085) Add back SI.attributes (safely)
[ https://issues.apache.org/jira/browse/LUCENE-6085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231726#comment-14231726 ] ASF subversion and git services commented on LUCENE-6085: - Commit 1642943 from [~rcmuir] in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1642943 ] LUCENE-6085: add back SI.attributes Add back SI.attributes (safely) --- Key: LUCENE-6085 URL: https://issues.apache.org/jira/browse/LUCENE-6085 Project: Lucene - Core Issue Type: Bug Reporter: Robert Muir Fix For: 5.0, Trunk Attachments: LUCENE-6085.patch We removed this for two reasons: * nothing was using it * the map is unsafe if a codec tried to write to it during in-place dv update. But Adrien has a real use case (LUCENE-5914), and I think we can just add some safety for the updates case (e.g. if the map is unmodifiable then the trap will not exist, any put() will throw exception). In general, we should have more safety in SI anyway (diagnostics map, too). -- 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-6085) Add back SI.attributes (safely)
[ https://issues.apache.org/jira/browse/LUCENE-6085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir resolved LUCENE-6085. - Resolution: Fixed Fix Version/s: Trunk 5.0 Add back SI.attributes (safely) --- Key: LUCENE-6085 URL: https://issues.apache.org/jira/browse/LUCENE-6085 Project: Lucene - Core Issue Type: Bug Reporter: Robert Muir Fix For: 5.0, Trunk Attachments: LUCENE-6085.patch We removed this for two reasons: * nothing was using it * the map is unsafe if a codec tried to write to it during in-place dv update. But Adrien has a real use case (LUCENE-5914), and I think we can just add some safety for the updates case (e.g. if the map is unmodifiable then the trap will not exist, any put() will throw exception). In general, we should have more safety in SI anyway (diagnostics map, too). -- 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-6776) Data lost when use SoftCommit and TLog
[
https://issues.apache.org/jira/browse/SOLR-6776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231728#comment-14231728
]
ASF subversion and git services commented on SOLR-6776:
---
Commit 1642946 from [~yo...@apache.org] in branch 'dev/trunk'
[ https://svn.apache.org/r1642946 ]
SOLR-6776: only clear changesSinceCommit on a hard commit so tlog will still be
flushed on a softCommit
Data lost when use SoftCommit and TLog
--
Key: SOLR-6776
URL: https://issues.apache.org/jira/browse/SOLR-6776
Project: Solr
Issue Type: Bug
Affects Versions: 4.10
Reporter: yuanyun.cn
Assignee: Yonik Seeley
Labels: softCommit, updateLog
Fix For: 4.10.3
We enabled update log and change autoCommit to some bigger value 10 mins.
After restart, we push one doc with softCommit=true
http://localhost:8983/solr/update?stream.body=adddocfield
name=idid1/field/doc/addsoftCommit=true
Then we kill the java process after a min.
After restart, Tlog failed to replay with following exception, and there is
no data in solr.
6245 [coreLoadExecutor-5-thread-1] ERROR org.apache.solr.update.UpdateLog û
Failure to open existing log file (non fatal)
E:\jeffery\src\apache\solr\4.10.2\solr-4.10.2\example\solr\collection1\data\t
log\tlog.000:org.apache.solr.common.SolrException:
java.io.EOFException
at
org.apache.solr.update.TransactionLog.init(TransactionLog.java:181)
at org.apache.solr.update.UpdateLog.init(UpdateLog.java:261)
at org.apache.solr.update.UpdateHandler.init(UpdateHandler.java:134)
at org.apache.solr.update.UpdateHandler.init(UpdateHandler.java:94)
at
org.apache.solr.update.DirectUpdateHandler2.init(DirectUpdateHandler2.java:100)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown
Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown
Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at org.apache.solr.core.SolrCore.createInstance(SolrCore.java:550)
at
org.apache.solr.core.SolrCore.createUpdateHandler(SolrCore.java:620)
at org.apache.solr.core.SolrCore.init(SolrCore.java:835)
at org.apache.solr.core.SolrCore.init(SolrCore.java:646)
at org.apache.solr.core.CoreContainer.create(CoreContainer.java:491)
at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:255)
at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:249)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.io.EOFException
at
org.apache.solr.common.util.FastInputStream.readUnsignedByte(FastInputStream.java:73)
at
org.apache.solr.common.util.FastInputStream.readInt(FastInputStream.java:216)
at
org.apache.solr.update.TransactionLog.readHeader(TransactionLog.java:268)
at
org.apache.solr.update.TransactionLog.init(TransactionLog.java:159)
... 19 more
Check the code: seems this is related with:
org.apache.solr.update.processor.RunUpdateProcessor, in processCommit, it
sets changesSinceCommit=false(even we are using softCommit)
So in finish, updateLog.finish will not be called.
public void finish() throws IOException {
if (changesSinceCommit updateHandler.getUpdateLog() != null) {
updateHandler.getUpdateLog().finish(null);
}
super.finish();
}
To fix this issue: I have to change RunUpdateProcessor.processCommit like
below:
if (!cmd.softCommit) {
changesSinceCommit = false;
}
--
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-6776) Data lost when use SoftCommit and TLog
[
https://issues.apache.org/jira/browse/SOLR-6776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231732#comment-14231732
]
ASF subversion and git services commented on SOLR-6776:
---
Commit 1642950 from [~yo...@apache.org] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1642950 ]
SOLR-6776: only clear changesSinceCommit on a hard commit so tlog will still be
flushed on a softCommit
Data lost when use SoftCommit and TLog
--
Key: SOLR-6776
URL: https://issues.apache.org/jira/browse/SOLR-6776
Project: Solr
Issue Type: Bug
Affects Versions: 4.10
Reporter: yuanyun.cn
Assignee: Yonik Seeley
Labels: softCommit, updateLog
Fix For: 4.10.3
We enabled update log and change autoCommit to some bigger value 10 mins.
After restart, we push one doc with softCommit=true
http://localhost:8983/solr/update?stream.body=adddocfield
name=idid1/field/doc/addsoftCommit=true
Then we kill the java process after a min.
After restart, Tlog failed to replay with following exception, and there is
no data in solr.
6245 [coreLoadExecutor-5-thread-1] ERROR org.apache.solr.update.UpdateLog û
Failure to open existing log file (non fatal)
E:\jeffery\src\apache\solr\4.10.2\solr-4.10.2\example\solr\collection1\data\t
log\tlog.000:org.apache.solr.common.SolrException:
java.io.EOFException
at
org.apache.solr.update.TransactionLog.init(TransactionLog.java:181)
at org.apache.solr.update.UpdateLog.init(UpdateLog.java:261)
at org.apache.solr.update.UpdateHandler.init(UpdateHandler.java:134)
at org.apache.solr.update.UpdateHandler.init(UpdateHandler.java:94)
at
org.apache.solr.update.DirectUpdateHandler2.init(DirectUpdateHandler2.java:100)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown
Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown
Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at org.apache.solr.core.SolrCore.createInstance(SolrCore.java:550)
at
org.apache.solr.core.SolrCore.createUpdateHandler(SolrCore.java:620)
at org.apache.solr.core.SolrCore.init(SolrCore.java:835)
at org.apache.solr.core.SolrCore.init(SolrCore.java:646)
at org.apache.solr.core.CoreContainer.create(CoreContainer.java:491)
at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:255)
at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:249)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.io.EOFException
at
org.apache.solr.common.util.FastInputStream.readUnsignedByte(FastInputStream.java:73)
at
org.apache.solr.common.util.FastInputStream.readInt(FastInputStream.java:216)
at
org.apache.solr.update.TransactionLog.readHeader(TransactionLog.java:268)
at
org.apache.solr.update.TransactionLog.init(TransactionLog.java:159)
... 19 more
Check the code: seems this is related with:
org.apache.solr.update.processor.RunUpdateProcessor, in processCommit, it
sets changesSinceCommit=false(even we are using softCommit)
So in finish, updateLog.finish will not be called.
public void finish() throws IOException {
if (changesSinceCommit updateHandler.getUpdateLog() != null) {
updateHandler.getUpdateLog().finish(null);
}
super.finish();
}
To fix this issue: I have to change RunUpdateProcessor.processCommit like
below:
if (!cmd.softCommit) {
changesSinceCommit = false;
}
--
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-6776) Data lost when use SoftCommit and TLog
[
https://issues.apache.org/jira/browse/SOLR-6776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231733#comment-14231733
]
ASF subversion and git services commented on SOLR-6776:
---
Commit 1642951 from [~yo...@apache.org] in branch
'dev/branches/lucene_solr_4_10'
[ https://svn.apache.org/r1642951 ]
SOLR-6776: only clear changesSinceCommit on a hard commit so tlog will still be
flushed on a softCommit
Data lost when use SoftCommit and TLog
--
Key: SOLR-6776
URL: https://issues.apache.org/jira/browse/SOLR-6776
Project: Solr
Issue Type: Bug
Affects Versions: 4.10
Reporter: yuanyun.cn
Assignee: Yonik Seeley
Labels: softCommit, updateLog
Fix For: 4.10.3
We enabled update log and change autoCommit to some bigger value 10 mins.
After restart, we push one doc with softCommit=true
http://localhost:8983/solr/update?stream.body=adddocfield
name=idid1/field/doc/addsoftCommit=true
Then we kill the java process after a min.
After restart, Tlog failed to replay with following exception, and there is
no data in solr.
6245 [coreLoadExecutor-5-thread-1] ERROR org.apache.solr.update.UpdateLog û
Failure to open existing log file (non fatal)
E:\jeffery\src\apache\solr\4.10.2\solr-4.10.2\example\solr\collection1\data\t
log\tlog.000:org.apache.solr.common.SolrException:
java.io.EOFException
at
org.apache.solr.update.TransactionLog.init(TransactionLog.java:181)
at org.apache.solr.update.UpdateLog.init(UpdateLog.java:261)
at org.apache.solr.update.UpdateHandler.init(UpdateHandler.java:134)
at org.apache.solr.update.UpdateHandler.init(UpdateHandler.java:94)
at
org.apache.solr.update.DirectUpdateHandler2.init(DirectUpdateHandler2.java:100)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown
Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown
Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at org.apache.solr.core.SolrCore.createInstance(SolrCore.java:550)
at
org.apache.solr.core.SolrCore.createUpdateHandler(SolrCore.java:620)
at org.apache.solr.core.SolrCore.init(SolrCore.java:835)
at org.apache.solr.core.SolrCore.init(SolrCore.java:646)
at org.apache.solr.core.CoreContainer.create(CoreContainer.java:491)
at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:255)
at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:249)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.io.EOFException
at
org.apache.solr.common.util.FastInputStream.readUnsignedByte(FastInputStream.java:73)
at
org.apache.solr.common.util.FastInputStream.readInt(FastInputStream.java:216)
at
org.apache.solr.update.TransactionLog.readHeader(TransactionLog.java:268)
at
org.apache.solr.update.TransactionLog.init(TransactionLog.java:159)
... 19 more
Check the code: seems this is related with:
org.apache.solr.update.processor.RunUpdateProcessor, in processCommit, it
sets changesSinceCommit=false(even we are using softCommit)
So in finish, updateLog.finish will not be called.
public void finish() throws IOException {
if (changesSinceCommit updateHandler.getUpdateLog() != null) {
updateHandler.getUpdateLog().finish(null);
}
super.finish();
}
To fix this issue: I have to change RunUpdateProcessor.processCommit like
below:
if (!cmd.softCommit) {
changesSinceCommit = false;
}
--
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] (SOLR-6776) Data lost when use SoftCommit and TLog
[
https://issues.apache.org/jira/browse/SOLR-6776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yonik Seeley closed SOLR-6776.
--
Resolution: Fixed
Committed. Thanks!
Data lost when use SoftCommit and TLog
--
Key: SOLR-6776
URL: https://issues.apache.org/jira/browse/SOLR-6776
Project: Solr
Issue Type: Bug
Affects Versions: 4.10
Reporter: yuanyun.cn
Assignee: Yonik Seeley
Labels: softCommit, updateLog
Fix For: 4.10.3
We enabled update log and change autoCommit to some bigger value 10 mins.
After restart, we push one doc with softCommit=true
http://localhost:8983/solr/update?stream.body=adddocfield
name=idid1/field/doc/addsoftCommit=true
Then we kill the java process after a min.
After restart, Tlog failed to replay with following exception, and there is
no data in solr.
6245 [coreLoadExecutor-5-thread-1] ERROR org.apache.solr.update.UpdateLog û
Failure to open existing log file (non fatal)
E:\jeffery\src\apache\solr\4.10.2\solr-4.10.2\example\solr\collection1\data\t
log\tlog.000:org.apache.solr.common.SolrException:
java.io.EOFException
at
org.apache.solr.update.TransactionLog.init(TransactionLog.java:181)
at org.apache.solr.update.UpdateLog.init(UpdateLog.java:261)
at org.apache.solr.update.UpdateHandler.init(UpdateHandler.java:134)
at org.apache.solr.update.UpdateHandler.init(UpdateHandler.java:94)
at
org.apache.solr.update.DirectUpdateHandler2.init(DirectUpdateHandler2.java:100)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown
Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown
Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at org.apache.solr.core.SolrCore.createInstance(SolrCore.java:550)
at
org.apache.solr.core.SolrCore.createUpdateHandler(SolrCore.java:620)
at org.apache.solr.core.SolrCore.init(SolrCore.java:835)
at org.apache.solr.core.SolrCore.init(SolrCore.java:646)
at org.apache.solr.core.CoreContainer.create(CoreContainer.java:491)
at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:255)
at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:249)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.io.EOFException
at
org.apache.solr.common.util.FastInputStream.readUnsignedByte(FastInputStream.java:73)
at
org.apache.solr.common.util.FastInputStream.readInt(FastInputStream.java:216)
at
org.apache.solr.update.TransactionLog.readHeader(TransactionLog.java:268)
at
org.apache.solr.update.TransactionLog.init(TransactionLog.java:159)
... 19 more
Check the code: seems this is related with:
org.apache.solr.update.processor.RunUpdateProcessor, in processCommit, it
sets changesSinceCommit=false(even we are using softCommit)
So in finish, updateLog.finish will not be called.
public void finish() throws IOException {
if (changesSinceCommit updateHandler.getUpdateLog() != null) {
updateHandler.getUpdateLog().finish(null);
}
super.finish();
}
To fix this issue: I have to change RunUpdateProcessor.processCommit like
below:
if (!cmd.softCommit) {
changesSinceCommit = false;
}
--
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-6653) bin/solr start script should return error code 0 when something fails
[
https://issues.apache.org/jira/browse/SOLR-6653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231740#comment-14231740
]
ASF subversion and git services commented on SOLR-6653:
---
Commit 1642952 from [~thelabdude] in branch 'dev/trunk'
[ https://svn.apache.org/r1642952 ]
SOLR-6653: should return error code 0 when something fails
bin/solr start script should return error code 0 when something fails
--
Key: SOLR-6653
URL: https://issues.apache.org/jira/browse/SOLR-6653
Project: Solr
Issue Type: Bug
Components: scripts and tools
Affects Versions: 4.10.1
Reporter: Jan Høydahl
Assignee: Timothy Potter
Labels: bin/solr
In order to be able to include {{bin/solr}} in scripts, it should be possible
to test the return value for success or failure. Examples:
{noformat}
jan:solr janhoy$ bin/solr start
Waiting to see Solr listening on port 8983 [/]
Started Solr server on port 8983 (pid=47354). Happy searching!
jan:solr janhoy$ echo $?
0
jan:solr janhoy$ bin/solr start
Solr already running on port 8983 (pid: 47354)!
Please use the 'restart' command if you want to restart this node.
jan:solr janhoy$ echo $?
0
{noformat}
The last command should return status 1
{noformat}
jan:solr janhoy$ bin/solr stop -p 1234
No process found for Solr node running on port 1234
jan:solr janhoy$ echo $?
0
{noformat}
Same here. Probably other places too.
--
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-6653) bin/solr start script should return error code 0 when something fails
[
https://issues.apache.org/jira/browse/SOLR-6653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231742#comment-14231742
]
ASF subversion and git services commented on SOLR-6653:
---
Commit 1642953 from [~thelabdude] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1642953 ]
SOLR-6653: should return error code 0 when something fails
bin/solr start script should return error code 0 when something fails
--
Key: SOLR-6653
URL: https://issues.apache.org/jira/browse/SOLR-6653
Project: Solr
Issue Type: Bug
Components: scripts and tools
Affects Versions: 4.10.1
Reporter: Jan Høydahl
Assignee: Timothy Potter
Labels: bin/solr
In order to be able to include {{bin/solr}} in scripts, it should be possible
to test the return value for success or failure. Examples:
{noformat}
jan:solr janhoy$ bin/solr start
Waiting to see Solr listening on port 8983 [/]
Started Solr server on port 8983 (pid=47354). Happy searching!
jan:solr janhoy$ echo $?
0
jan:solr janhoy$ bin/solr start
Solr already running on port 8983 (pid: 47354)!
Please use the 'restart' command if you want to restart this node.
jan:solr janhoy$ echo $?
0
{noformat}
The last command should return status 1
{noformat}
jan:solr janhoy$ bin/solr stop -p 1234
No process found for Solr node running on port 1234
jan:solr janhoy$ echo $?
0
{noformat}
Same here. Probably other places too.
--
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-Tests-5.x-Java7 - Build # 2267 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/2267/
1 tests failed.
FAILED: org.apache.lucene.spatial.prefix.DateNRStrategyTest.testContains {#9
seed=[801EEB0A7D92DF9E:7325FAA06CA28D9F]}
Error Message:
[Contains] Shouldn't match I#1:465172-01 Q:[465172 TO 465172-01]
Stack Trace:
java.lang.AssertionError: [Contains] Shouldn't match I#1:465172-01 Q:[465172 TO
465172-01]
at
__randomizedtesting.SeedInfo.seed([801EEB0A7D92DF9E:7325FAA06CA28D9F]:0)
at org.junit.Assert.fail(Assert.java:93)
at
org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.fail(RandomSpatialOpStrategyTestCase.java:126)
at
org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.testOperation(RandomSpatialOpStrategyTestCase.java:115)
at
org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.testOperationRandomShapes(RandomSpatialOpStrategyTestCase.java:62)
at
org.apache.lucene.spatial.prefix.DateNRStrategyTest.testContains(DateNRStrategyTest.java:65)
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: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 7762 lines...]
[junit4] Suite:
Re: svn commit: r1641902 - in /lucene/dev/trunk/lucene: core/src/test/org/apache/lucene/index/TestIndexWriter.java test-framework/src/java/org/apache/lucene/mockfile/FilterFileSystem.java test-framewo
: I'll fix the message to make it clear you are not running on WINDOWS : but rather our WindowsFS. thanks. : I agree we should strive to have our tests be portable across OS's ... : : But unfortunately this test case is for a nasty corruption bug : (LUCENE-5574) that can't happen on Windows... I don't really understand how that statment relates to either of my questions? Currently, if i a non-windows user runs all tests on their machine the framework will select windowsfs as a mock file system roughly 1/10th of the test runs (9/10 * 1/10). With your latest commit, this test -- knowing that it is useless on windows *OR* the mock windowsfs -- jumps through hoops to ask TestUtil.isWindowsFS(dir) ? ... and if the answer is true, it does nothing (via: assumeFalse) my question: rather then assumeFalse() ~1/10 of the time (even when the underlying OS/FS is *NOT* windows) why not unwrap that (mock) windowsfs and still run the test using the real file system? Wouldn't that be trivial to do? It doesn't seem any more complicated then what you had to add to implement isWindowsFS ... can't we just change those isWindowsFS boolean methods to something that returns the actual WindowsFS instance and calls getDelegate() on it? -Hoss http://www.lucidworks.com/ - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: svn commit: r1641902 - in /lucene/dev/trunk/lucene: core/src/test/org/apache/lucene/index/TestIndexWriter.java test-framework/src/java/org/apache/lucene/mockfile/FilterFileSystem.java test-framewo
On Tue, Dec 2, 2014 at 12:01 PM, Chris Hostetter hossman_luc...@fucit.org wrote: my question: rather then assumeFalse() ~1/10 of the time (even when the underlying OS/FS is *NOT* windows) why not unwrap that (mock) windowsfs and still run the test using the real file system? Wouldn't that be trivial to do? It doesn't seem any more complicated then what you had to add to implement isWindowsFS ... can't we just change those isWindowsFS boolean methods to something that returns the actual WindowsFS instance and calls getDelegate() on it? Personally i am against this, we shouldn't make this method public! The test has a problem in that it does not work on windows, but the test framework doesnt need to become flaky to cater to this kind of stuff. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6554) Speed up overseer operations for collections with stateFormat 1
[ https://issues.apache.org/jira/browse/SOLR-6554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231762#comment-14231762 ] Shalin Shekhar Mangar commented on SOLR-6554: - There is one problem in my current implementation. Earlier, the work queue was guaranteed to have only those items which had been processed but not written to ZK. This condition is not true anymore after my refactoring because the batching logic is inside ZkStateWriter and it will write to ZK without the Overseer knowing about it. Speed up overseer operations for collections with stateFormat 1 - Key: SOLR-6554 URL: https://issues.apache.org/jira/browse/SOLR-6554 Project: Solr Issue Type: Improvement Components: SolrCloud Affects Versions: 5.0, Trunk Reporter: Shalin Shekhar Mangar Attachments: SOLR-6554-batching-refactor.patch, SOLR-6554-batching-refactor.patch, SOLR-6554-batching-refactor.patch, SOLR-6554-batching-refactor.patch, SOLR-6554.patch, SOLR-6554.patch, SOLR-6554.patch, SOLR-6554.patch, SOLR-6554.patch, SOLR-6554.patch, SOLR-6554.patch, SOLR-6554.patch Right now (after SOLR-5473 was committed), a node watches a collection only if stateFormat=1 or if that node hosts at least one core belonging to that collection. This means that a node which is the overseer operates on all collections but watches only a few. So any read goes directly to zookeeper which slows down overseer operations. Let's have the overseer node watch all collections always and never remove those watches (except when the collection itself is deleted). -- 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] (LUCENE-6089) Tune CompressionMode.HIGH_COMPRESSION
Robert Muir created LUCENE-6089: --- Summary: Tune CompressionMode.HIGH_COMPRESSION Key: LUCENE-6089 URL: https://issues.apache.org/jira/browse/LUCENE-6089 Project: Lucene - Core Issue Type: Bug Reporter: Robert Muir Patch to apply the parameters Adrien proposed on LUCENE-5914. These make this option a lot less costly on CPU and actually compress better too. This only impacts tests. -- 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-6089) Tune CompressionMode.HIGH_COMPRESSION
[ https://issues.apache.org/jira/browse/LUCENE-6089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-6089: Attachment: LUCENE-6089.patch Tune CompressionMode.HIGH_COMPRESSION - Key: LUCENE-6089 URL: https://issues.apache.org/jira/browse/LUCENE-6089 Project: Lucene - Core Issue Type: Bug Reporter: Robert Muir Attachments: LUCENE-6089.patch Patch to apply the parameters Adrien proposed on LUCENE-5914. These make this option a lot less costly on CPU and actually compress better too. This only impacts tests. -- 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-6089) Tune CompressionMode.HIGH_COMPRESSION
[ https://issues.apache.org/jira/browse/LUCENE-6089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231784#comment-14231784 ] Adrien Grand commented on LUCENE-6089: -- +1 Tune CompressionMode.HIGH_COMPRESSION - Key: LUCENE-6089 URL: https://issues.apache.org/jira/browse/LUCENE-6089 Project: Lucene - Core Issue Type: Bug Reporter: Robert Muir Attachments: LUCENE-6089.patch Patch to apply the parameters Adrien proposed on LUCENE-5914. These make this option a lot less costly on CPU and actually compress better too. This only impacts tests. -- 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-6756) The cloud-dev scripts do not seem to work with the new example layout.
[ https://issues.apache.org/jira/browse/SOLR-6756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231801#comment-14231801 ] ASF subversion and git services commented on SOLR-6756: --- Commit 1642963 from [~markrmil...@gmail.com] in branch 'dev/trunk' [ https://svn.apache.org/r1642963 ] SOLR-6756: A first pass at making the cloud-dev scripts work again. The cloud-dev scripts do not seem to work with the new example layout. -- Key: SOLR-6756 URL: https://issues.apache.org/jira/browse/SOLR-6756 Project: Solr Issue Type: Bug Reporter: Mark Miller Assignee: Mark Miller Fix For: Trunk -- 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-6756) The cloud-dev scripts do not seem to work with the new example layout.
[ https://issues.apache.org/jira/browse/SOLR-6756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231813#comment-14231813 ] ASF subversion and git services commented on SOLR-6756: --- Commit 1642964 from [~markrmil...@gmail.com] in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1642964 ] SOLR-6756: A first pass at making the cloud-dev scripts work again. The cloud-dev scripts do not seem to work with the new example layout. -- Key: SOLR-6756 URL: https://issues.apache.org/jira/browse/SOLR-6756 Project: Solr Issue Type: Bug Reporter: Mark Miller Assignee: Mark Miller Fix For: Trunk -- 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-6653) bin/solr start script should return error code 0 when something fails
[
https://issues.apache.org/jira/browse/SOLR-6653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231822#comment-14231822
]
ASF subversion and git services commented on SOLR-6653:
---
Commit 1642967 from [~thelabdude] in branch 'dev/branches/lucene_solr_4_10'
[ https://svn.apache.org/r1642967 ]
SOLR-6653: should return error code 0 when something fails
bin/solr start script should return error code 0 when something fails
--
Key: SOLR-6653
URL: https://issues.apache.org/jira/browse/SOLR-6653
Project: Solr
Issue Type: Bug
Components: scripts and tools
Affects Versions: 4.10.1
Reporter: Jan Høydahl
Assignee: Timothy Potter
Labels: bin/solr
In order to be able to include {{bin/solr}} in scripts, it should be possible
to test the return value for success or failure. Examples:
{noformat}
jan:solr janhoy$ bin/solr start
Waiting to see Solr listening on port 8983 [/]
Started Solr server on port 8983 (pid=47354). Happy searching!
jan:solr janhoy$ echo $?
0
jan:solr janhoy$ bin/solr start
Solr already running on port 8983 (pid: 47354)!
Please use the 'restart' command if you want to restart this node.
jan:solr janhoy$ echo $?
0
{noformat}
The last command should return status 1
{noformat}
jan:solr janhoy$ bin/solr stop -p 1234
No process found for Solr node running on port 1234
jan:solr janhoy$ echo $?
0
{noformat}
Same here. Probably other places too.
--
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-6581) Prepare CollapsingQParserPlugin and ExpandComponent for 5.0
[ https://issues.apache.org/jira/browse/SOLR-6581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein updated SOLR-6581: - Attachment: SOLR-6581.patch Prepare CollapsingQParserPlugin and ExpandComponent for 5.0 --- Key: SOLR-6581 URL: https://issues.apache.org/jira/browse/SOLR-6581 Project: Solr Issue Type: Bug Reporter: Joel Bernstein Assignee: Joel Bernstein Priority: Minor Fix For: 5.0 Attachments: SOLR-6581.patch There were changes made to the CollapsingQParserPlugin and ExpandComponent in the 5x branch that were driven by changes to the Lucene Collectors API and DocValues API. This ticket is to review the 5x implementation and make any changes necessary in preparation for a 5.0 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-6604) distributed expand=truefl=key NPE fix, expand=truedistrib.singlePass=true consideration
[ https://issues.apache.org/jira/browse/SOLR-6604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231838#comment-14231838 ] Christine Poerschke commented on SOLR-6604: --- Linking SOLR-6604 and SOLR-6812 which both concern distrib.singlePass and expand. distributed expand=truefl=key NPE fix, expand=truedistrib.singlePass=true consideration - Key: SOLR-6604 URL: https://issues.apache.org/jira/browse/SOLR-6604 Project: Solr Issue Type: Bug Reporter: Christine Poerschke Priority: Minor select?expand=truefl=key hits NPE in ExpandComponent.handleResponse when the responses of the EXECUTE_QUERY contain no expanded element despite the requests' purpose including PURPOSE_GET_FIELDS select?expand=truedistrib.singlePass=true works but relies on other preceding components triggering a GET_FIELDS stage -- 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-6768) Creating examples fails when Solr runs in foreground mode
[ https://issues.apache.org/jira/browse/SOLR-6768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Potter resolved SOLR-6768. -- Resolution: Fixed Fix Version/s: 4.10.3 Assignee: Timothy Potter Fixed as part of SOLR-6653 Creating examples fails when Solr runs in foreground mode - Key: SOLR-6768 URL: https://issues.apache.org/jira/browse/SOLR-6768 Project: Solr Issue Type: Bug Components: scripts and tools Affects Versions: Trunk Reporter: Alexandre Rafalovitch Assignee: Timothy Potter Priority: Minor Fix For: 4.10.3 Using configuration introduced in SOLR-3619, the following command will get locked up: bq. bin/solr start -f -e techproducts Solr will start in the foreground, so the core will not be created. Then, when Solr is shutdown, the commands to create and populate the core are run and an error is thrown. Perhaps the example creating code should cross-check for that flag and complain/abort to avoid confusion. -- 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-6653) bin/solr start script should return error code 0 when something fails
[
https://issues.apache.org/jira/browse/SOLR-6653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy Potter resolved SOLR-6653.
--
Resolution: Fixed
Fix Version/s: 5.0
4.10.3
bin/solr start script should return error code 0 when something fails
--
Key: SOLR-6653
URL: https://issues.apache.org/jira/browse/SOLR-6653
Project: Solr
Issue Type: Bug
Components: scripts and tools
Affects Versions: 4.10.1
Reporter: Jan Høydahl
Assignee: Timothy Potter
Labels: bin/solr
Fix For: 4.10.3, 5.0
In order to be able to include {{bin/solr}} in scripts, it should be possible
to test the return value for success or failure. Examples:
{noformat}
jan:solr janhoy$ bin/solr start
Waiting to see Solr listening on port 8983 [/]
Started Solr server on port 8983 (pid=47354). Happy searching!
jan:solr janhoy$ echo $?
0
jan:solr janhoy$ bin/solr start
Solr already running on port 8983 (pid: 47354)!
Please use the 'restart' command if you want to restart this node.
jan:solr janhoy$ echo $?
0
{noformat}
The last command should return status 1
{noformat}
jan:solr janhoy$ bin/solr stop -p 1234
No process found for Solr node running on port 1234
jan:solr janhoy$ echo $?
0
{noformat}
Same here. Probably other places too.
--
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-6653) bin/solr start script should return error code 0 when something fails
[
https://issues.apache.org/jira/browse/SOLR-6653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231845#comment-14231845
]
Timothy Potter commented on SOLR-6653:
--
[~yo...@apache.org] I fixed the issue you mentioned in SOLR-4792 as part of
this work. Now you can do:
{code}
cp -rp server s1
cd s1
../bin/solr start -e techproducts -d .
{code}
bin/solr start script should return error code 0 when something fails
--
Key: SOLR-6653
URL: https://issues.apache.org/jira/browse/SOLR-6653
Project: Solr
Issue Type: Bug
Components: scripts and tools
Affects Versions: 4.10.1
Reporter: Jan Høydahl
Assignee: Timothy Potter
Labels: bin/solr
Fix For: 4.10.3, 5.0
In order to be able to include {{bin/solr}} in scripts, it should be possible
to test the return value for success or failure. Examples:
{noformat}
jan:solr janhoy$ bin/solr start
Waiting to see Solr listening on port 8983 [/]
Started Solr server on port 8983 (pid=47354). Happy searching!
jan:solr janhoy$ echo $?
0
jan:solr janhoy$ bin/solr start
Solr already running on port 8983 (pid: 47354)!
Please use the 'restart' command if you want to restart this node.
jan:solr janhoy$ echo $?
0
{noformat}
The last command should return status 1
{noformat}
jan:solr janhoy$ bin/solr stop -p 1234
No process found for Solr node running on port 1234
jan:solr janhoy$ echo $?
0
{noformat}
Same here. Probably other places too.
--
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
