[JENKINS] Lucene-Solr-4.x-Windows (64bit/jdk1.7.0_60-ea-b10) - Build # 3807 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Windows/3807/ Java: 64bit/jdk1.7.0_60-ea-b10 -XX:+UseCompressedOops -XX:+UseParallelGC 1 tests failed. FAILED: org.apache.solr.schema.TestCloudManagedSchema.testDistribSearch Error Message: java.util.concurrent.TimeoutException: Could not connect to ZooKeeper 127.0.0.1:61147 within 45000 ms Stack Trace: org.apache.solr.common.SolrException: java.util.concurrent.TimeoutException: Could not connect to ZooKeeper 127.0.0.1:61147 within 45000 ms at org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:150) at org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:101) at org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:91) at org.apache.solr.cloud.AbstractZkTestCase.buildZooKeeper(AbstractZkTestCase.java:91) at org.apache.solr.cloud.AbstractZkTestCase.buildZooKeeper(AbstractZkTestCase.java:85) at org.apache.solr.cloud.AbstractDistribZkTestBase.setUp(AbstractDistribZkTestBase.java:75) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.setUp(AbstractFullDistribZkTestBase.java:201) 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:1617) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:860) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:876) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java: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:70) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:359) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:783) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:443) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:835) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:737) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:771) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:782) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) 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 org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.j
Solr: Are tokenizers/analysers/filters self descriptory?
Hello, I am thinking of new interfaces to compose analyzer chains. And I already have all the valid analyzers/tokenizers/filters/etc ( http://www.solr-start.com/info/analyzers/ ). But I just realized that I also need the parameters that actually define the behavior. Normally, they are defined in the schema.xml by a human. But if I wanted to do a - say - web interface, those params would need to be auto-discoverable to make the UI truly useful. I had a quick look at the source and there does not seem to be any self-description. Just popping the parameters of the stack and throwing exceptions of they fail. Did I miss something? Does this exist as part of some other (schema validation?) code? Or, if it does not exist, does anybody (else) sees value in that? Or are there there barriers to making it useful? Regards, Alex. Personal website: http://www.outerthoughts.com/ LinkedIn: http://www.linkedin.com/in/alexandrerafalovitch - Time is the quality of nature that keeps events from happening all at once. Lately, it doesn't seem to be working. (Anonymous - via GTD book) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5896) Create and edit a CWiki page that describes UpdateRequestProcessors, especially FieldMutatingUpdateProcessors
[ https://issues.apache.org/jira/browse/SOLR-5896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13944308#comment-13944308 ] Alexandre Rafalovitch commented on SOLR-5896: - My current attempt at the full catalogue is at: http://www.solr-start.com/info/update-request-processors/ There is a couple of issues I saw when I built it: * Fairly deep inheritance hierarchy (which is the main reason this jira exists, I guess) * Location of non-core URPs to ensure the jars are on the library path (only a couple of classes to date) * Javadocs, as non-core URPs are not just in different packages, they are in different javadoc sets altogether and cannot be discovered when browsing Javadoc by parent page * Short names (solr.X), also for core- vs. non-core- components Incidentally, all of the above problems (and a couple more) are even more present for the Analyzers, Tokenizers and Filters. That's why I built: http://www.solr-start.com/info/analyzers/ Both of the resources above (and several others coming later) and built by reverse engineering the production release, looking at the jars and javadocs. Basically, brute-forcing the results from the ground-truth as opposed to trying to figure out the quirks of the build-system and source-control. > Create and edit a CWiki page that describes UpdateRequestProcessors, > especially FieldMutatingUpdateProcessors > - > > Key: SOLR-5896 > URL: https://issues.apache.org/jira/browse/SOLR-5896 > Project: Solr > Issue Type: Improvement > Components: documentation >Affects Versions: 4.8, 5.0 >Reporter: Erick Erickson >Assignee: Erick Erickson > > The capabilities here aren't really documented as a group anywhere I could > see in the official pages, there are a couple of references to them but > nothing that really serves draws attention. These need to be documented. > Where does it make sense to put this? It doesn't really fit under > "Understanding Analyzers, Tokenizers, and Filters", except kinda since they > can be used to alter how data gets indexed, think of the > Parse[Date|Int|Float..] factories. > Straw-man: add child pages to "Understanding Analyzers, Tokenizers, and > Filters" for "What is an UpdateRequestProcessor", "UpdateRequestProcessors", > and probably something like "How to configure your UpdateRequestProcessor". > Or??? -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-5228) Don't require or be inside of -- or that be inside of
[
https://issues.apache.org/jira/browse/SOLR-5228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13944292#comment-13944292
]
Erick Erickson edited comment on SOLR-5228 at 3/23/14 1:44 AM:
---
Hmm, I guess the discussion has been about whether it makes sense to ever pull
out the old-style /schema/fields or /schema/types sections. Deprecating them is
certainly reasonable, but I'd balk at dis-allowing them. Your suggestion
doesn't dis-allow them though.
Thinking about it some more, my patch allows definitions like
{code}
...
{code}
or
{code}
...
{code}
or, for that matter, something like
{code}
...
{code}
to be defined in schema.xml. Blech. I haven't a clue how Solr would behave in
these cases.. and there's always case N+1.
Looks like I'm talking myself into adopting your suggestion.
was (Author: erickerickson):
Hmm, I guess the discussion has been about whether it makes sense to ever pull
out the old-style /schema/fields or /schema/types sections. Deprecating them is
certainly reasonable, but I'd balk at dis-allowing them. Your suggestion
doesn't dis-allow them though.
Thinking about it some more, my patch allows definitions like
...
or
...
or, for that matter, something like
...
to be defined in schema.xml. Blech. I haven't a clue how Solr would behave in
these cases.. and there's always case N+1.
Looks like I'm talking myself into adopting your suggestion.
> Don't require or be inside of -- or that
> be inside of
> -
>
> Key: SOLR-5228
> URL: https://issues.apache.org/jira/browse/SOLR-5228
> Project: Solr
> Issue Type: Improvement
> Components: Schema and Analysis
>Reporter: Hoss Man
>Assignee: Erick Erickson
> Attachments: SOLR-5228.patch
>
>
> On the solr-user mailing list, Nutan recently mentioned spending days trying
> to track down a problem that turned out to be because he had attempted to add
> a {{}} that was outside of the {{}} block in his
> schema.xml -- Solr was just silently ignoring it.
> We have made improvements in other areas of config validation by generating
> statup errors when tags/attributes are found that are not expected -- but in
> this case i think we should just stop expecting/requiring that the
> {{}} and {{}} tags will be used to group these sorts of
> things. I think schema.xml parsing should just start ignoring them and only
> care about finding the {{}}, {{}}, and {{}}
> tags wherever they may be.
> If people want to keep using them, fine. If people want to mix fieldTypes
> and fields side by side (perhaps specify a fieldType, then list all the
> fields using it) fine. I don't see any value in forcing people to use them,
> but we definitely shouldn't leave things the way they are with otherwise
> perfectly valid field/type declarations being silently ignored.
> ---
> I'll take this on unless i see any objections.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5228) Don't require or be inside of -- or that be inside of
[
https://issues.apache.org/jira/browse/SOLR-5228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13944292#comment-13944292
]
Erick Erickson commented on SOLR-5228:
--
Hmm, I guess the discussion has been about whether it makes sense to ever pull
out the old-style /schema/fields or /schema/types sections. Deprecating them is
certainly reasonable, but I'd balk at dis-allowing them. Your suggestion
doesn't dis-allow them though.
Thinking about it some more, my patch allows definitions like
...
or
...
or, for that matter, something like
...
to be defined in schema.xml. Blech. I haven't a clue how Solr would behave in
these cases.. and there's always case N+1.
Looks like I'm talking myself into adopting your suggestion.
> Don't require or be inside of -- or that
> be inside of
> -
>
> Key: SOLR-5228
> URL: https://issues.apache.org/jira/browse/SOLR-5228
> Project: Solr
> Issue Type: Improvement
> Components: Schema and Analysis
>Reporter: Hoss Man
>Assignee: Erick Erickson
> Attachments: SOLR-5228.patch
>
>
> On the solr-user mailing list, Nutan recently mentioned spending days trying
> to track down a problem that turned out to be because he had attempted to add
> a {{}} that was outside of the {{}} block in his
> schema.xml -- Solr was just silently ignoring it.
> We have made improvements in other areas of config validation by generating
> statup errors when tags/attributes are found that are not expected -- but in
> this case i think we should just stop expecting/requiring that the
> {{}} and {{}} tags will be used to group these sorts of
> things. I think schema.xml parsing should just start ignoring them and only
> care about finding the {{}}, {{}}, and {{}}
> tags wherever they may be.
> If people want to keep using them, fine. If people want to mix fieldTypes
> and fields side by side (perhaps specify a fieldType, then list all the
> fields using it) fine. I don't see any value in forcing people to use them,
> but we definitely shouldn't leave things the way they are with otherwise
> perfectly valid field/type declarations being silently ignored.
> ---
> I'll take this on unless i see any objections.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-5228) Don't require or be inside of -- or that be inside of
[
https://issues.apache.org/jira/browse/SOLR-5228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13944282#comment-13944282
]
Steve Rowe edited comment on SOLR-5228 at 3/23/14 12:27 AM:
Hi Erick,
Patch looks fine, except, as Robert said earlier:
{quote}
Can we just go the simple route of deprecating 'fields' and 'types' in 4.x
(throw error in 5.x), and in 4.x also allow field/fieldtypes to be "top-level"
in the schema.
I think this is ultimately simpler than just willy-nilly allowing shit to be
nested underneath anywhere: thats hard to maintain:
{quote}
Your XPath changes in {{IndexSchema}} willy-nilly allow (dynamic)field /
fieldType to be nested underneath anywhere:
{noformat}
465: // ../fieldType or fieldtype
466: expression = "//" + FIELD_TYPE + XPATH_OR + "//" +
FIELD_TYPE.toLowerCase(Locale.ROOT);
[...]
638: // ../field | /schema/dynamicField
639: String expression = "//" + FIELD + XPATH_OR + "//" + DYNAMIC_FIELD;
640: NodeList nodes = (NodeList)xpath.evaluate(expression, document,
XPathConstants.NODESET);
{noformat}
I think we should keep the old XPath and *add* ones allowing top-level
versions, something like (untested) the following (after putting back the TYPES
constant):
*edit* reordered the XPath alternatives to have the old-school versions last
{noformat}
466: // /schema/fieldtype | /schema/fieldType |
/schema/types/fieldtype | /schema/types/fieldType
467: expression = stepsToPath(SCHEMA, FIELD_TYPE.toLowerCase(Locale.ROOT))
// backcompat(?)
468: + XPATH_OR + stepsToPath(SCHEMA, FIELD_TYPE)
469: + XPATH_OR + stepsToPath(SCHEMA, TYPES,
FIELD_TYPE.toLowerCase(Locale.ROOT))
470: + XPATH_OR + stepsToPath(SCHEMA, TYPES, FIELD_TYPE);
[...]
642: // /schema/field | /schema/dynamicField |
/schema/fields/field | /schema/fields/dynamicField
643: String expression = stepsToPath(SCHEMA, FIELD)
644:+ XPATH_OR + stepsToPath(SCHEMA, DYNAMIC_FIELD)
645:+ XPATH_OR + stepsToPath(SCHEMA, FIELDS, FIELD)
646:+ XPATH_OR + stepsToPath(SCHEMA, FIELDS, DYNAMIC_FIELD);
{noformat}
was (Author: steve_rowe):
Hi Erick,
Patch looks fine, except, as Robert said earlier:
{quote}
Can we just go the simple route of deprecating 'fields' and 'types' in 4.x
(throw error in 5.x), and in 4.x also allow field/fieldtypes to be "top-level"
in the schema.
I think this is ultimately simpler than just willy-nilly allowing shit to be
nested underneath anywhere: thats hard to maintain:
{quote}
Your XPath changes in {{IndexSchema}} willy-nilly allow (dynamic)field /
fieldType to be nested underneath anywhere:
{noformat}
465: // ../fieldType or fieldtype
466: expression = "//" + FIELD_TYPE + XPATH_OR + "//" +
FIELD_TYPE.toLowerCase(Locale.ROOT);
[...]
638: // ../field | /schema/dynamicField
639: String expression = "//" + FIELD + XPATH_OR + "//" + DYNAMIC_FIELD;
640: NodeList nodes = (NodeList)xpath.evaluate(expression, document,
XPathConstants.NODESET);
{noformat}
I think we should keep the old XPath and *add* ones allowing top-level
versions, something like (untested) the following (after putting back the TYPES
constant):
{noformat}
466: // /schema/fieldtype | /schema/fieldType |
/schema/types/fieldtype | /schema/types/fieldType
467: expression = stepsToPath(SCHEMA, TYPES,
FIELD_TYPE.toLowerCase(Locale.ROOT)) // backcompat(?)
468: + XPATH_OR + stepsToPath(SCHEMA, TYPES, FIELD_TYPE)
469: + XPATH_OR + stepsToPath(SCHEMA, FIELD_TYPE.toLowerCase(Locale.ROOT))
470: + XPATH_OR + stepsToPath(SCHEMA, FIELD_TYPE);
[...]
642: // /schema/field | /schema/dynamicField |
/schema/fields/field | /schema/fields/dynamicField
643: String expression = stepsToPath(SCHEMA, FIELDS, FIELD)
644:+ XPATH_OR + stepsToPath(SCHEMA, FIELDS, DYNAMIC_FIELD)
645:+ XPATH_OR + stepsToPath(SCHEMA, FIELD)
646:+ XPATH_OR + stepsToPath(SCHEMA, DYNAMIC_FIELD);
{noformat}
> Don't require or be inside of -- or that
> be inside of
> -
>
> Key: SOLR-5228
> URL: https://issues.apache.org/jira/browse/SOLR-5228
> Project: Solr
> Issue Type: Improvement
> Components: Schema and Analysis
>Reporter: Hoss Man
>Assignee: Erick Erickson
> Attachments: SOLR-5228.patch
>
>
> On the solr-user mailing list, Nutan recently mentioned spending days trying
> to track down a problem that turned out to be because he had attempted to add
> a {{}} that was outside of the {{}} block in his
> schema.xml -- Solr was just silently ignoring it.
> We have made improvements in other areas of config validation by generating
> statup errors when tags/attributes are found that are not expected -- but in
> this case i
[jira] [Commented] (SOLR-5228) Don't require or be inside of -- or that be inside of
[
https://issues.apache.org/jira/browse/SOLR-5228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13944282#comment-13944282
]
Steve Rowe commented on SOLR-5228:
--
Hi Erick,
Patch looks fine, except, as Robert said earlier:
{quote}
Can we just go the simple route of deprecating 'fields' and 'types' in 4.x
(throw error in 5.x), and in 4.x also allow field/fieldtypes to be "top-level"
in the schema.
I think this is ultimately simpler than just willy-nilly allowing shit to be
nested underneath anywhere: thats hard to maintain:
{quote}
Your XPath changes in {{IndexSchema}} willy-nilly allow (dynamic)field /
fieldType to be nested underneath anywhere:
{noformat}
465: // ../fieldType or fieldtype
466: expression = "//" + FIELD_TYPE + XPATH_OR + "//" +
FIELD_TYPE.toLowerCase(Locale.ROOT);
[...]
638: // ../field | /schema/dynamicField
639: String expression = "//" + FIELD + XPATH_OR + "//" + DYNAMIC_FIELD;
640: NodeList nodes = (NodeList)xpath.evaluate(expression, document,
XPathConstants.NODESET);
{noformat}
I think we should keep the old XPath and *add* ones allowing top-level
versions, something like (untested) the following (after putting back the TYPES
constant):
{noformat}
466: // /schema/fieldtype | /schema/fieldType |
/schema/types/fieldtype | /schema/types/fieldType
467: expression = stepsToPath(SCHEMA, TYPES,
FIELD_TYPE.toLowerCase(Locale.ROOT)) // backcompat(?)
468: + XPATH_OR + stepsToPath(SCHEMA, TYPES, FIELD_TYPE)
469: + XPATH_OR + stepsToPath(SCHEMA, FIELD_TYPE.toLowerCase(Locale.ROOT))
470: + XPATH_OR + stepsToPath(SCHEMA, FIELD_TYPE);
[...]
642: // /schema/field | /schema/dynamicField |
/schema/fields/field | /schema/fields/dynamicField
643: String expression = stepsToPath(SCHEMA, FIELDS, FIELD)
644:+ XPATH_OR + stepsToPath(SCHEMA, FIELDS, DYNAMIC_FIELD)
645:+ XPATH_OR + stepsToPath(SCHEMA, FIELD)
646:+ XPATH_OR + stepsToPath(SCHEMA, DYNAMIC_FIELD);
{noformat}
> Don't require or be inside of -- or that
> be inside of
> -
>
> Key: SOLR-5228
> URL: https://issues.apache.org/jira/browse/SOLR-5228
> Project: Solr
> Issue Type: Improvement
> Components: Schema and Analysis
>Reporter: Hoss Man
>Assignee: Erick Erickson
> Attachments: SOLR-5228.patch
>
>
> On the solr-user mailing list, Nutan recently mentioned spending days trying
> to track down a problem that turned out to be because he had attempted to add
> a {{}} that was outside of the {{}} block in his
> schema.xml -- Solr was just silently ignoring it.
> We have made improvements in other areas of config validation by generating
> statup errors when tags/attributes are found that are not expected -- but in
> this case i think we should just stop expecting/requiring that the
> {{}} and {{}} tags will be used to group these sorts of
> things. I think schema.xml parsing should just start ignoring them and only
> care about finding the {{}}, {{}}, and {{}}
> tags wherever they may be.
> If people want to keep using them, fine. If people want to mix fieldTypes
> and fields side by side (perhaps specify a fieldType, then list all the
> fields using it) fine. I don't see any value in forcing people to use them,
> but we definitely shouldn't leave things the way they are with otherwise
> perfectly valid field/type declarations being silently ignored.
> ---
> I'll take this on unless i see any objections.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5228) Don't require or be inside of -- or that be inside of
[
https://issues.apache.org/jira/browse/SOLR-5228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson updated SOLR-5228:
-
Attachment: SOLR-5228.patch
Decided to work up a patch to see what it would take. Was a little surprised by
some of the work with the schema api, had to modify a few tests:
[~steve_rowe] - if you have a chance, please see if I've done violence to the
managed schema code I changed. There were a few changes both to code and tests.
All:
The "FIELDS" static in IndexSchema.java turns out to be overloaded a bit in
case you're wondering why I took "types" out but left "fields" in. It's used to
put together output packets as well as parse the schema.xml file.
Finally, I just took some of the and tags out of some of the
stock test files on the theory that would test code more randomly than I would.
For the final patch, I'll take the and tags out of the stock
distro schema.xml file(s).
Let me know if there are objections, I'll commit next week if not. I hear what
Robert and Tomas are saying, but in this case I don't think the hassle to the
users of enforcing these tag's absence is worth it. And it would be more work
for the devs I think.
> Don't require or be inside of -- or that
> be inside of
> -
>
> Key: SOLR-5228
> URL: https://issues.apache.org/jira/browse/SOLR-5228
> Project: Solr
> Issue Type: Improvement
> Components: Schema and Analysis
>Reporter: Hoss Man
>Assignee: Erick Erickson
> Attachments: SOLR-5228.patch
>
>
> On the solr-user mailing list, Nutan recently mentioned spending days trying
> to track down a problem that turned out to be because he had attempted to add
> a {{}} that was outside of the {{}} block in his
> schema.xml -- Solr was just silently ignoring it.
> We have made improvements in other areas of config validation by generating
> statup errors when tags/attributes are found that are not expected -- but in
> this case i think we should just stop expecting/requiring that the
> {{}} and {{}} tags will be used to group these sorts of
> things. I think schema.xml parsing should just start ignoring them and only
> care about finding the {{}}, {{}}, and {{}}
> tags wherever they may be.
> If people want to keep using them, fine. If people want to mix fieldTypes
> and fields side by side (perhaps specify a fieldType, then list all the
> fields using it) fine. I don't see any value in forcing people to use them,
> but we definitely shouldn't leave things the way they are with otherwise
> perfectly valid field/type declarations being silently ignored.
> ---
> I'll take this on unless i see any objections.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5528) Add context to AnalyzingInfixSuggester
[ https://issues.apache.org/jira/browse/LUCENE-5528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Areek Zillur updated LUCENE-5528: - Attachment: LUCENE-5528-1.patch > Add context to AnalyzingInfixSuggester > -- > > Key: LUCENE-5528 > URL: https://issues.apache.org/jira/browse/LUCENE-5528 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Michael McCandless >Assignee: Michael McCandless > Fix For: 4.8, 5.0 > > Attachments: LUCENE-5528-1.patch, LUCENE-5528-1.patch, > LUCENE-5528-1.patch, LUCENE-5528-1.patch, LUCENE-5528.patch, > LUCENE-5528.patch, contextInputIteratImpl.patch > > > Spinoff from LUCENE-5350. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-5228) Don't require or be inside of -- or that be inside of
[
https://issues.apache.org/jira/browse/SOLR-5228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson reassigned SOLR-5228:
Assignee: Erick Erickson (was: Hoss Man)
> Don't require or be inside of -- or that
> be inside of
> -
>
> Key: SOLR-5228
> URL: https://issues.apache.org/jira/browse/SOLR-5228
> Project: Solr
> Issue Type: Improvement
> Components: Schema and Analysis
>Reporter: Hoss Man
>Assignee: Erick Erickson
>
> On the solr-user mailing list, Nutan recently mentioned spending days trying
> to track down a problem that turned out to be because he had attempted to add
> a {{}} that was outside of the {{}} block in his
> schema.xml -- Solr was just silently ignoring it.
> We have made improvements in other areas of config validation by generating
> statup errors when tags/attributes are found that are not expected -- but in
> this case i think we should just stop expecting/requiring that the
> {{}} and {{}} tags will be used to group these sorts of
> things. I think schema.xml parsing should just start ignoring them and only
> care about finding the {{}}, {{}}, and {{}}
> tags wherever they may be.
> If people want to keep using them, fine. If people want to mix fieldTypes
> and fields side by side (perhaps specify a fieldType, then list all the
> fields using it) fine. I don't see any value in forcing people to use them,
> but we definitely shouldn't leave things the way they are with otherwise
> perfectly valid field/type declarations being silently ignored.
> ---
> I'll take this on unless i see any objections.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5551) Fix warnings in the ant build
[ https://issues.apache.org/jira/browse/LUCENE-5551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13944269#comment-13944269 ] Shawn Heisey commented on LUCENE-5551: -- bq. I would suggest to disable the warning in the eclipse config file in dev-tools/eclipse! Eclipse actually does ignore redundant casts by default. The ant build generates warnings. In order to find them I had to switch the eclipse setting from 'ignore' to 'error' which produced over 300 errors. I opened all those files, and after supressing or fixing, I changed it to warning to see what I missed. > Fix warnings in the ant build > - > > Key: LUCENE-5551 > URL: https://issues.apache.org/jira/browse/LUCENE-5551 > Project: Lucene - Core > Issue Type: Improvement > Components: general/build >Affects Versions: 4.8 >Reporter: Shawn Heisey > Fix For: 5.0 > > Attachments: LUCENE-5551-fix-fallthrough.patch, > LUCENE-5551-redundant-casts.patch, LUCENE-5551-redundant-casts.patch > > > The build produces a lot of warnings. LUCENE-5130 aims to fail the build on > certain warnings, but until we actually eliminate those warnings from the > code, failing the build is premature. > This issue is concerned with fixing or suppressing warnings reported by the > ant build, anything further than that may need one or more separate issues. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5528) Add context to AnalyzingInfixSuggester
[ https://issues.apache.org/jira/browse/LUCENE-5528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Areek Zillur updated LUCENE-5528: - Attachment: LUCENE-5528-1.patch Updated patch (LUCENE-5528-1.patch): - removed unused imports (my bad!) - updated InputIteration.context() docs to record that it can return null - minor formatting fixes (as suggested) Thanks Michael for the review! That is awesome, I played around with the jirasearch to see the functionality for myself. > Add context to AnalyzingInfixSuggester > -- > > Key: LUCENE-5528 > URL: https://issues.apache.org/jira/browse/LUCENE-5528 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Michael McCandless >Assignee: Michael McCandless > Fix For: 4.8, 5.0 > > Attachments: LUCENE-5528-1.patch, LUCENE-5528-1.patch, > LUCENE-5528-1.patch, LUCENE-5528.patch, LUCENE-5528.patch, > contextInputIteratImpl.patch > > > Spinoff from LUCENE-5350. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-5552) Upgrade JFlex version from 1.5.0 to 1.5.1
[ https://issues.apache.org/jira/browse/LUCENE-5552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Rowe resolved LUCENE-5552. Resolution: Fixed Committed to trunk and branch_4x. > Upgrade JFlex version from 1.5.0 to 1.5.1 > - > > Key: LUCENE-5552 > URL: https://issues.apache.org/jira/browse/LUCENE-5552 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/analysis >Reporter: Steve Rowe >Assignee: Steve Rowe >Priority: Minor > Fix For: 4.8, 5.0 > > Attachments: LUCENE-5552.patch > > > JFlex 1.5.1, just released, fixes a 1.5.0 bug in the JFlex version in > generated code: it included the "-SNAPSHOT" suffix. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5552) Upgrade JFlex version from 1.5.0 to 1.5.1
[ https://issues.apache.org/jira/browse/LUCENE-5552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13944225#comment-13944225 ] Steve Rowe commented on LUCENE-5552: bq. JFlex's failure to detect class comments when annotations intervene, which triggers JFlex to auto-generate an additional class comment containing the full path to the .jflex file I filed a JFlex tracker issue: https://sourceforge.net/p/jflex/bugs/127/ > Upgrade JFlex version from 1.5.0 to 1.5.1 > - > > Key: LUCENE-5552 > URL: https://issues.apache.org/jira/browse/LUCENE-5552 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/analysis >Reporter: Steve Rowe >Assignee: Steve Rowe >Priority: Minor > Fix For: 4.8, 5.0 > > Attachments: LUCENE-5552.patch > > > JFlex 1.5.1, just released, fixes a 1.5.0 bug in the JFlex version in > generated code: it included the "-SNAPSHOT" suffix. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-5551) Fix warnings in the ant build
[ https://issues.apache.org/jira/browse/LUCENE-5551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13944216#comment-13944216 ] Shawn Heisey edited comment on LUCENE-5551 at 3/22/14 8:19 PM: --- New version of the redundant casts patch. It's a lot smaller because I suppressed quite a lot this time. I did make some changes where the cast seemed completely unnecessary. A lot of those were casts from a parameterized type to same parameterized type, but some of them were for primitive types where there seemed to be no danger of ambiguity. There are three classes that I know of where the warnings remain. All of them are generated code. These are two instances of QueryParserTokenManager (one in classic, one in surround) and StandardSyntaxParserTokenManager. As always, feel free to object to any of the changes and request that they be suppressed instead. was (Author: elyograg): New version of the redundant casts patch. It's a lot smaller because I suppressed quite a lot this time. I did make some changes where the cast seemed completely unnecessary. A lot of those were casts from a parameterized type to same parameterized type, but some of them were for primitive types where there seemed to be no danger of ambiguity. As always, feel free to object to any of the changes and request that they be suppressed instead. > Fix warnings in the ant build > - > > Key: LUCENE-5551 > URL: https://issues.apache.org/jira/browse/LUCENE-5551 > Project: Lucene - Core > Issue Type: Improvement > Components: general/build >Affects Versions: 4.8 >Reporter: Shawn Heisey > Fix For: 5.0 > > Attachments: LUCENE-5551-fix-fallthrough.patch, > LUCENE-5551-redundant-casts.patch, LUCENE-5551-redundant-casts.patch > > > The build produces a lot of warnings. LUCENE-5130 aims to fail the build on > certain warnings, but until we actually eliminate those warnings from the > code, failing the build is premature. > This issue is concerned with fixing or suppressing warnings reported by the > ant build, anything further than that may need one or more separate issues. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5551) Fix warnings in the ant build
[ https://issues.apache.org/jira/browse/LUCENE-5551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shawn Heisey updated LUCENE-5551: - Attachment: LUCENE-5551-redundant-casts.patch New version of the redundant casts patch. It's a lot smaller because I suppressed quite a lot this time. I did make some changes where the cast seemed completely unnecessary. A lot of those were casts from a parameterized type to same parameterized type, but some of them were for primitive types where there seemed to be no danger of ambiguity. As always, feel free to object to any of the changes and request that they be suppressed instead. > Fix warnings in the ant build > - > > Key: LUCENE-5551 > URL: https://issues.apache.org/jira/browse/LUCENE-5551 > Project: Lucene - Core > Issue Type: Improvement > Components: general/build >Affects Versions: 4.8 >Reporter: Shawn Heisey > Fix For: 5.0 > > Attachments: LUCENE-5551-fix-fallthrough.patch, > LUCENE-5551-redundant-casts.patch, LUCENE-5551-redundant-casts.patch > > > The build produces a lot of warnings. LUCENE-5130 aims to fail the build on > certain warnings, but until we actually eliminate those warnings from the > code, failing the build is premature. > This issue is concerned with fixing or suppressing warnings reported by the > ant build, anything further than that may need one or more separate issues. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5749) Implement an Overseer status API
[ https://issues.apache.org/jira/browse/SOLR-5749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar updated SOLR-5749: Attachment: SOLR-5749.patch Refactored the stats class a bit - replaced the multiple maps with a single one containing a custom class. > Implement an Overseer status API > > > Key: SOLR-5749 > URL: https://issues.apache.org/jira/browse/SOLR-5749 > Project: Solr > Issue Type: Sub-task > Components: SolrCloud >Reporter: Shalin Shekhar Mangar > Fix For: 5.0 > > Attachments: SOLR-5749.patch, SOLR-5749.patch, SOLR-5749.patch, > SOLR-5749.patch, SOLR-5749.patch, SOLR-5749.patch > > > Right now there is little to no information exposed about the overseer from > SolrCloud. > I propose that we have an API for overseer status which can return: > # Past N commands executed (grouped by command type) > # Status (queue-size, current overseer leader node) > # Overseer log -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5552) Upgrade JFlex version from 1.5.0 to 1.5.1
[ https://issues.apache.org/jira/browse/LUCENE-5552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13944205#comment-13944205 ] ASF subversion and git services commented on LUCENE-5552: - Commit 1580299 from [~steve_rowe] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1580299 ] LUCENE-5552: Upgrade JFlex version from 1.5.0 to 1.5.1; also, move @Deprecated class annotation on *TokenizerImplXX.jflex prior to the class comments to workaround JFlex's failure to detect class comments when annotations intervene, which triggers JFlex to auto-generate an additional class comment containing the full path to the .jflex file, which disrupts the use of 'ant regenerate' under different base directories. (merged trunk r1580275) > Upgrade JFlex version from 1.5.0 to 1.5.1 > - > > Key: LUCENE-5552 > URL: https://issues.apache.org/jira/browse/LUCENE-5552 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/analysis >Reporter: Steve Rowe >Assignee: Steve Rowe >Priority: Minor > Fix For: 4.8, 5.0 > > Attachments: LUCENE-5552.patch > > > JFlex 1.5.1, just released, fixes a 1.5.0 bug in the JFlex version in > generated code: it included the "-SNAPSHOT" suffix. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5895) JavaBinLoader hides IOExceptions
[
https://issues.apache.org/jira/browse/SOLR-5895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13944195#comment-13944195
]
ASF subversion and git services commented on SOLR-5895:
---
Commit 1580293 from sha...@apache.org in branch 'dev/branches/lucene_solr_4_7'
[ https://svn.apache.org/r1580293 ]
SOLR-5895: JavaBinLoader hides IOExceptions
> JavaBinLoader hides IOExceptions
>
>
> Key: SOLR-5895
> URL: https://issues.apache.org/jira/browse/SOLR-5895
> Project: Solr
> Issue Type: Bug
>Reporter: Mike Sokolov
>Assignee: Shalin Shekhar Mangar
> Fix For: 5.0, 4.7.1
>
>
> An IOException raised during analysis is swallowed by JavabinLoader, so the
> underlying cause is not visible in the logs, or to the client. Proposed fix
> is to change
> {code}
> throw new SolrException(SolrException.ErrorCode.SERVER_ERROR, "ERROR adding
> document " + document);
> {code}
> to
> {code}
> throw new SolrException(SolrException.ErrorCode.SERVER_ERROR, "ERROR adding
> document " + document, e);
> {code}
> on line 99 in JavaBinLoader.java
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-5895) JavaBinLoader hides IOExceptions
[
https://issues.apache.org/jira/browse/SOLR-5895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shalin Shekhar Mangar resolved SOLR-5895.
-
Resolution: Fixed
Fix Version/s: 4.7.1
5.0
Thanks Mike!
> JavaBinLoader hides IOExceptions
>
>
> Key: SOLR-5895
> URL: https://issues.apache.org/jira/browse/SOLR-5895
> Project: Solr
> Issue Type: Bug
>Reporter: Mike Sokolov
>Assignee: Shalin Shekhar Mangar
> Fix For: 5.0, 4.7.1
>
>
> An IOException raised during analysis is swallowed by JavabinLoader, so the
> underlying cause is not visible in the logs, or to the client. Proposed fix
> is to change
> {code}
> throw new SolrException(SolrException.ErrorCode.SERVER_ERROR, "ERROR adding
> document " + document);
> {code}
> to
> {code}
> throw new SolrException(SolrException.ErrorCode.SERVER_ERROR, "ERROR adding
> document " + document, e);
> {code}
> on line 99 in JavaBinLoader.java
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5895) JavaBinLoader hides IOExceptions
[
https://issues.apache.org/jira/browse/SOLR-5895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13944192#comment-13944192
]
ASF subversion and git services commented on SOLR-5895:
---
Commit 1580290 from sha...@apache.org in branch 'dev/trunk'
[ https://svn.apache.org/r1580290 ]
SOLR-5895: JavaBinLoader hides IOExceptions
> JavaBinLoader hides IOExceptions
>
>
> Key: SOLR-5895
> URL: https://issues.apache.org/jira/browse/SOLR-5895
> Project: Solr
> Issue Type: Bug
>Reporter: Mike Sokolov
>Assignee: Shalin Shekhar Mangar
>
> An IOException raised during analysis is swallowed by JavabinLoader, so the
> underlying cause is not visible in the logs, or to the client. Proposed fix
> is to change
> {code}
> throw new SolrException(SolrException.ErrorCode.SERVER_ERROR, "ERROR adding
> document " + document);
> {code}
> to
> {code}
> throw new SolrException(SolrException.ErrorCode.SERVER_ERROR, "ERROR adding
> document " + document, e);
> {code}
> on line 99 in JavaBinLoader.java
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5895) JavaBinLoader hides IOExceptions
[
https://issues.apache.org/jira/browse/SOLR-5895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13944194#comment-13944194
]
ASF subversion and git services commented on SOLR-5895:
---
Commit 1580291 from sha...@apache.org in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1580291 ]
SOLR-5895: JavaBinLoader hides IOExceptions
> JavaBinLoader hides IOExceptions
>
>
> Key: SOLR-5895
> URL: https://issues.apache.org/jira/browse/SOLR-5895
> Project: Solr
> Issue Type: Bug
>Reporter: Mike Sokolov
>Assignee: Shalin Shekhar Mangar
>
> An IOException raised during analysis is swallowed by JavabinLoader, so the
> underlying cause is not visible in the logs, or to the client. Proposed fix
> is to change
> {code}
> throw new SolrException(SolrException.ErrorCode.SERVER_ERROR, "ERROR adding
> document " + document);
> {code}
> to
> {code}
> throw new SolrException(SolrException.ErrorCode.SERVER_ERROR, "ERROR adding
> document " + document, e);
> {code}
> on line 99 in JavaBinLoader.java
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-5895) JavaBinLoader hides IOExceptions
[
https://issues.apache.org/jira/browse/SOLR-5895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shalin Shekhar Mangar reassigned SOLR-5895:
---
Assignee: Shalin Shekhar Mangar
> JavaBinLoader hides IOExceptions
>
>
> Key: SOLR-5895
> URL: https://issues.apache.org/jira/browse/SOLR-5895
> Project: Solr
> Issue Type: Bug
>Reporter: Mike Sokolov
>Assignee: Shalin Shekhar Mangar
>
> An IOException raised during analysis is swallowed by JavabinLoader, so the
> underlying cause is not visible in the logs, or to the client. Proposed fix
> is to change
> {code}
> throw new SolrException(SolrException.ErrorCode.SERVER_ERROR, "ERROR adding
> document " + document);
> {code}
> to
> {code}
> throw new SolrException(SolrException.ErrorCode.SERVER_ERROR, "ERROR adding
> document " + document, e);
> {code}
> on line 99 in JavaBinLoader.java
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5545) Add ExpressionRescorer
[ https://issues.apache.org/jira/browse/LUCENE-5545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13944183#comment-13944183 ] Shalin Shekhar Mangar commented on LUCENE-5545: --- +1 This is neat! > Add ExpressionRescorer > -- > > Key: LUCENE-5545 > URL: https://issues.apache.org/jira/browse/LUCENE-5545 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Michael McCandless >Assignee: Michael McCandless > Fix For: 4.8, 5.0 > > Attachments: LUCENE-5545.patch, LUCENE-5545.patch, LUCENE-5545.patch, > LUCENE-5545.patch > > > In LUCENE-5489 we added QueryRescorer, to rescore first-pass hits using > scores from a (usually) more expensive second-pass query. > I think we should also add ExpressionRescorer, to compute the second pass > score using an arbitrary JS expression. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5545) Add ExpressionRescorer
[ https://issues.apache.org/jira/browse/LUCENE-5545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13944179#comment-13944179 ] Michael McCandless commented on LUCENE-5545: bq. I think you can remove the comment in QueryRescorer to add an ExpressionRescorer? Woops, thanks for catching! I'll remove it. > Add ExpressionRescorer > -- > > Key: LUCENE-5545 > URL: https://issues.apache.org/jira/browse/LUCENE-5545 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Michael McCandless >Assignee: Michael McCandless > Fix For: 4.8, 5.0 > > Attachments: LUCENE-5545.patch, LUCENE-5545.patch, LUCENE-5545.patch, > LUCENE-5545.patch > > > In LUCENE-5489 we added QueryRescorer, to rescore first-pass hits using > scores from a (usually) more expensive second-pass query. > I think we should also add ExpressionRescorer, to compute the second pass > score using an arbitrary JS expression. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5552) Upgrade JFlex version from 1.5.0 to 1.5.1
[ https://issues.apache.org/jira/browse/LUCENE-5552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13944178#comment-13944178 ] ASF subversion and git services commented on LUCENE-5552: - Commit 1580275 from [~steve_rowe] in branch 'dev/trunk' [ https://svn.apache.org/r1580275 ] LUCENE-5552: Upgrade JFlex version from 1.5.0 to 1.5.1 > Upgrade JFlex version from 1.5.0 to 1.5.1 > - > > Key: LUCENE-5552 > URL: https://issues.apache.org/jira/browse/LUCENE-5552 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/analysis >Reporter: Steve Rowe >Assignee: Steve Rowe >Priority: Minor > Fix For: 4.8, 5.0 > > Attachments: LUCENE-5552.patch > > > JFlex 1.5.1, just released, fixes a 1.5.0 bug in the JFlex version in > generated code: it included the "-SNAPSHOT" suffix. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5552) Upgrade JFlex version from 1.5.0 to 1.5.1
[ https://issues.apache.org/jira/browse/LUCENE-5552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Rowe updated LUCENE-5552: --- Attachment: LUCENE-5552.patch Patch. Committing shortly. > Upgrade JFlex version from 1.5.0 to 1.5.1 > - > > Key: LUCENE-5552 > URL: https://issues.apache.org/jira/browse/LUCENE-5552 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/analysis >Reporter: Steve Rowe >Assignee: Steve Rowe >Priority: Minor > Fix For: 4.8, 5.0 > > Attachments: LUCENE-5552.patch > > > JFlex 1.5.1, just released, fixes a 1.5.0 bug in the JFlex version in > generated code: it included the "-SNAPSHOT" suffix. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-5552) Upgrade JFlex version from 1.5.0 to 1.5.1
Steve Rowe created LUCENE-5552: -- Summary: Upgrade JFlex version from 1.5.0 to 1.5.1 Key: LUCENE-5552 URL: https://issues.apache.org/jira/browse/LUCENE-5552 Project: Lucene - Core Issue Type: Improvement Components: modules/analysis Reporter: Steve Rowe Assignee: Steve Rowe Priority: Minor Fix For: 4.8, 5.0 JFlex 1.5.1, just released, fixes a 1.5.0 bug in the JFlex version in generated code: it included the "-SNAPSHOT" suffix. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5512) Remove redundant typing (diamond operator) in trunk
[ https://issues.apache.org/jira/browse/LUCENE-5512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13944170#comment-13944170 ] ASF subversion and git services commented on LUCENE-5512: - Commit 1580271 from [~steve_rowe] in branch 'dev/trunk' [ https://svn.apache.org/r1580271 ] LUCENE-5512: remove redundant typing (diamond operator) > Remove redundant typing (diamond operator) in trunk > --- > > Key: LUCENE-5512 > URL: https://issues.apache.org/jira/browse/LUCENE-5512 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Robert Muir > Fix For: 4.8, 5.0 > > Attachments: LUCENE-5512.patch, LUCENE-5512.patch, LUCENE-5512.patch > > -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5512) Remove redundant typing (diamond operator) in trunk
[ https://issues.apache.org/jira/browse/LUCENE-5512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13944171#comment-13944171 ] ASF subversion and git services commented on LUCENE-5512: - Commit 1580272 from [~steve_rowe] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1580272 ] LUCENE-5512: remove redundant typing (diamond operator) > Remove redundant typing (diamond operator) in trunk > --- > > Key: LUCENE-5512 > URL: https://issues.apache.org/jira/browse/LUCENE-5512 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Robert Muir > Fix For: 4.8, 5.0 > > Attachments: LUCENE-5512.patch, LUCENE-5512.patch, LUCENE-5512.patch > > -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5545) Add ExpressionRescorer
[ https://issues.apache.org/jira/browse/LUCENE-5545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13944169#comment-13944169 ] Uwe Schindler commented on LUCENE-5545: --- +1 very nice! > Add ExpressionRescorer > -- > > Key: LUCENE-5545 > URL: https://issues.apache.org/jira/browse/LUCENE-5545 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Michael McCandless >Assignee: Michael McCandless > Fix For: 4.8, 5.0 > > Attachments: LUCENE-5545.patch, LUCENE-5545.patch, LUCENE-5545.patch, > LUCENE-5545.patch > > > In LUCENE-5489 we added QueryRescorer, to rescore first-pass hits using > scores from a (usually) more expensive second-pass query. > I think we should also add ExpressionRescorer, to compute the second pass > score using an arbitrary JS expression. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-5551) Fix warnings in the ant build
[
https://issues.apache.org/jira/browse/LUCENE-5551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13944161#comment-13944161
]
Uwe Schindler edited comment on LUCENE-5551 at 3/22/14 5:49 PM:
Sorry, I did not know that {{averages[block]}} or {{f}} in your example was a
float - I was expecting that it is an int, too! This makes it more crazy. We
should be really careful!
This just confirms my problem: The coder had an idea why he casted like that
:-) Redundant casting is not really a warning, it doesn't hide bugs, it makes
it explicit what was intended, so it is there for clarification. Just because
javac automatically casts something according to java standards, it does not
mean we should really take it as it is. I prefer explicit casts around
primitive types! It is like putting stress on words while having a talk.
I would suggest to disable the warning in the eclipse config file in
dev-tools/eclipse!
was (Author: thetaphi):
Sorry, I did not know that {{averages[block]}} or {{f}} in your example was a
float - I was expecting that it is an int, too! This makes it more crazy. We
should be really careful!
This just confirms my problem: The coder had an idea why he casted like that
:-) Redundant casting is not really a warning, it dont hide bugs, it makes it
explicit what was intended, so its just there for clarification. Just because
javac automatically casts something accoring to java standards, it does not
mean we should really take it as it is. I prefer explicit casts around
primitive types!
I would suggest to disable the warning in the eclipse config file in
dev-tools/eclipse!
> Fix warnings in the ant build
> -
>
> Key: LUCENE-5551
> URL: https://issues.apache.org/jira/browse/LUCENE-5551
> Project: Lucene - Core
> Issue Type: Improvement
> Components: general/build
>Affects Versions: 4.8
>Reporter: Shawn Heisey
> Fix For: 5.0
>
> Attachments: LUCENE-5551-fix-fallthrough.patch,
> LUCENE-5551-redundant-casts.patch
>
>
> The build produces a lot of warnings. LUCENE-5130 aims to fail the build on
> certain warnings, but until we actually eliminate those warnings from the
> code, failing the build is premature.
> This issue is concerned with fixing or suppressing warnings reported by the
> ant build, anything further than that may need one or more separate issues.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5545) Add ExpressionRescorer
[ https://issues.apache.org/jira/browse/LUCENE-5545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13944162#comment-13944162 ] Ryan Ernst commented on LUCENE-5545: +1 I think you can remove the comment in QueryRescorer to add an ExpressionRescorer? > Add ExpressionRescorer > -- > > Key: LUCENE-5545 > URL: https://issues.apache.org/jira/browse/LUCENE-5545 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Michael McCandless >Assignee: Michael McCandless > Fix For: 4.8, 5.0 > > Attachments: LUCENE-5545.patch, LUCENE-5545.patch, LUCENE-5545.patch, > LUCENE-5545.patch > > > In LUCENE-5489 we added QueryRescorer, to rescore first-pass hits using > scores from a (usually) more expensive second-pass query. > I think we should also add ExpressionRescorer, to compute the second pass > score using an arbitrary JS expression. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5551) Fix warnings in the ant build
[
https://issues.apache.org/jira/browse/LUCENE-5551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13944161#comment-13944161
]
Uwe Schindler commented on LUCENE-5551:
---
Sorry, I did not know that {{averages[block]}} or {{f}} in your example was a
float - I was expecting that it is an int, too! This makes it more crazy. We
should be really careful!
This just confirms my problem: The coder had an idea why he casted like that
:-) Redundant casting is not really a warning, it dont hide bugs, it makes it
explicit what was intended, so its just there for clarification. Just because
javac automatically casts something accoring to java standards, it does not
mean we should really take it as it is. I prefer explicit casts around
primitive types!
I would suggest to disable the warning in the eclipse config file in
dev-tools/eclipse!
> Fix warnings in the ant build
> -
>
> Key: LUCENE-5551
> URL: https://issues.apache.org/jira/browse/LUCENE-5551
> Project: Lucene - Core
> Issue Type: Improvement
> Components: general/build
>Affects Versions: 4.8
>Reporter: Shawn Heisey
> Fix For: 5.0
>
> Attachments: LUCENE-5551-fix-fallthrough.patch,
> LUCENE-5551-redundant-casts.patch
>
>
> The build produces a lot of warnings. LUCENE-5130 aims to fail the build on
> certain warnings, but until we actually eliminate those warnings from the
> code, failing the build is premature.
> This issue is concerned with fixing or suppressing warnings reported by the
> ant build, anything further than that may need one or more separate issues.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5551) Fix warnings in the ant build
[
https://issues.apache.org/jira/browse/LUCENE-5551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13944157#comment-13944157
]
Shawn Heisey commented on LUCENE-5551:
--
This specific example needs suppressing, because your preferred form will
change the result. Reducing the specific multiplication example you provided
from MonotonicAppendingLongBuffer to a compact test case:
{code}
int i = 5;
float f = 3.4F;
final long long1 = (long) (f * (long) i); // original
final long long2 = (long) (f * i); // what Eclipse wants
final long long3 = ((long) f * i); // Your form
System.out.println(long1); // prints 17
System.out.println(long2); // prints 17
System.out.println(long3); // prints 15
{code}
I think the chance of these warnings pointing to existing subtle bugs is very
small, but it's possible. My thought at this point is that I should just
suppress almost all of them that involve primitive types, and probably those
involving things objects like Float as well. I will review each one again and
ask questions if it becomes ambiguous.
> Fix warnings in the ant build
> -
>
> Key: LUCENE-5551
> URL: https://issues.apache.org/jira/browse/LUCENE-5551
> Project: Lucene - Core
> Issue Type: Improvement
> Components: general/build
>Affects Versions: 4.8
>Reporter: Shawn Heisey
> Fix For: 5.0
>
> Attachments: LUCENE-5551-fix-fallthrough.patch,
> LUCENE-5551-redundant-casts.patch
>
>
> The build produces a lot of warnings. LUCENE-5130 aims to fail the build on
> certain warnings, but until we actually eliminate those warnings from the
> code, failing the build is premature.
> This issue is concerned with fixing or suppressing warnings reported by the
> ant build, anything further than that may need one or more separate issues.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5356) more generic lucene-morfologik integration
[ https://issues.apache.org/jira/browse/LUCENE-5356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13944156#comment-13944156 ] Ahmet Arslan commented on LUCENE-5356: -- Hi [~hlavki] , is it possible to use morfologik to convert https://github.com/coltekin/TRmorph to java and create a stem filter? > more generic lucene-morfologik integration > -- > > Key: LUCENE-5356 > URL: https://issues.apache.org/jira/browse/LUCENE-5356 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/analysis >Affects Versions: 4.6 >Reporter: Michal Hlavac >Assignee: Dawid Weiss >Priority: Minor > Labels: newbie, patch > Fix For: 4.8, 5.0 > > Attachments: LUCENE-5356.patch, LUCENE-5356.patch, LUCENE-5356.patch > > > I have little proposal for morfologik lucene module. Current module is > tightly coupled with polish DICTIONARY enumeration. > But other people (like me) can build own dictionaries to FSA and use it with > lucene. > You can find proposal in attachment and also example usage in analyzer > (SlovakLemmaAnalyzer). > It uses dictionary property as String resource from classpath, not > enumeration. > One change is, that dictionary variable must be set in MofologikFilterFactory > (no default value). -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5551) Fix warnings in the ant build
[
https://issues.apache.org/jira/browse/LUCENE-5551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13944152#comment-13944152
]
Uwe Schindler commented on LUCENE-5551:
---
Thanks!
One additional thing: In most cases for maximum compatibility we need both
@SuppressWarnings: rawtypes and unchecked. The problem is eclipse's compiler
differs from Java 7's and (this was the problem earlier: Java 7's differed
significantly from Java 6's). So we had both.
As we are now only on Java 7, we can check this again: Try it with all
available compilers (including Java 8). For maximum safety, we should have both
({{"rawtypes", "unchecked"}} - although Eclipse complains on useless
SuppressWarnings).
As mentioned before: suppress warnings for redundant casts and keep them as
they are - I prefer to have them, code is better readable. Some of them are
fine in your patch (like the char -> int casts), but the int -> long ones are
too risky (because tests won't catch the bugs, as we don't have such large
indexes,...). There is a reason why Oracle's javac does not complain about
redundatnt casts (not even in Java 8). They are useful to clarify the
intentions of the coder - so suppress them if eclipse complains. Ideally we
should disable this warning in the eclipse configuration file generated by
{{ant eclipse}}.
> Fix warnings in the ant build
> -
>
> Key: LUCENE-5551
> URL: https://issues.apache.org/jira/browse/LUCENE-5551
> Project: Lucene - Core
> Issue Type: Improvement
> Components: general/build
>Affects Versions: 4.8
>Reporter: Shawn Heisey
> Fix For: 5.0
>
> Attachments: LUCENE-5551-fix-fallthrough.patch,
> LUCENE-5551-redundant-casts.patch
>
>
> The build produces a lot of warnings. LUCENE-5130 aims to fail the build on
> certain warnings, but until we actually eliminate those warnings from the
> code, failing the build is premature.
> This issue is concerned with fixing or suppressing warnings reported by the
> ant build, anything further than that may need one or more separate issues.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5551) Fix warnings in the ant build
[ https://issues.apache.org/jira/browse/LUCENE-5551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13944148#comment-13944148 ] Shawn Heisey commented on LUCENE-5551: -- I had wondered whether that was going too far. Your preferred form makes sense to me, so I'll make another pass at those warnings. > Fix warnings in the ant build > - > > Key: LUCENE-5551 > URL: https://issues.apache.org/jira/browse/LUCENE-5551 > Project: Lucene - Core > Issue Type: Improvement > Components: general/build >Affects Versions: 4.8 >Reporter: Shawn Heisey > Fix For: 5.0 > > Attachments: LUCENE-5551-fix-fallthrough.patch, > LUCENE-5551-redundant-casts.patch > > > The build produces a lot of warnings. LUCENE-5130 aims to fail the build on > certain warnings, but until we actually eliminate those warnings from the > code, failing the build is premature. > This issue is concerned with fixing or suppressing warnings reported by the > ant build, anything further than that may need one or more separate issues. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_51) - Build # 9875 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/9875/ Java: 32bit/jdk1.7.0_51 -server -XX:+UseConcMarkSweepGC 1 tests failed. REGRESSION: org.apache.solr.handler.clustering.DistributedClusteringComponentTest.testDistribSearch Error Message: Timeout occured while waiting response from server at: https://127.0.0.1:54918/_euu/c Stack Trace: org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting response from server at: https://127.0.0.1:54918/_euu/c at __randomizedtesting.SeedInfo.seed([E87EF7E50E77D2FF:699879FD7928B2C3]:0) at org.apache.solr.client.solrj.impl.HttpSolrServer.executeMethod(HttpSolrServer.java:512) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:203) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:199) at org.apache.solr.client.solrj.request.AbstractUpdateRequest.process(AbstractUpdateRequest.java:118) at org.apache.solr.client.solrj.SolrServer.add(SolrServer.java:116) at org.apache.solr.client.solrj.SolrServer.add(SolrServer.java:102) at org.apache.solr.BaseDistributedSearchTestCase.indexDoc(BaseDistributedSearchTestCase.java:441) at org.apache.solr.BaseDistributedSearchTestCase.index(BaseDistributedSearchTestCase.java:434) at org.apache.solr.handler.clustering.DistributedClusteringComponentTest.doTest(DistributedClusteringComponentTest.java:36) at org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:876) 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:1617) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:826) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:862) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:876) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java: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:70) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:359) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:783) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:443) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:835) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:737) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:771) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:782) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) 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.eval
[JENKINS] Lucene-Solr-4.x-Windows (32bit/jdk1.7.0_51) - Build # 3805 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Windows/3805/ Java: 32bit/jdk1.7.0_51 -server -XX:+UseConcMarkSweepGC 3 tests failed. REGRESSION: org.apache.solr.schema.TestCloudManagedSchema.testDistribSearch Error Message: java.util.concurrent.TimeoutException: Could not connect to ZooKeeper 127.0.0.1:54645 within 45000 ms Stack Trace: org.apache.solr.common.SolrException: java.util.concurrent.TimeoutException: Could not connect to ZooKeeper 127.0.0.1:54645 within 45000 ms at org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:150) at org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:101) at org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:91) at org.apache.solr.cloud.AbstractZkTestCase.buildZooKeeper(AbstractZkTestCase.java:91) at org.apache.solr.cloud.AbstractZkTestCase.buildZooKeeper(AbstractZkTestCase.java:85) at org.apache.solr.cloud.AbstractDistribZkTestBase.setUp(AbstractDistribZkTestBase.java:75) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.setUp(AbstractFullDistribZkTestBase.java:201) 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:1617) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:860) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:876) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java: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:70) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:359) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:783) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:443) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:835) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:737) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:771) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:782) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) 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 org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
[jira] [Commented] (SOLR-5228) Don't require or be inside of -- or that be inside of
[
https://issues.apache.org/jira/browse/SOLR-5228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13944098#comment-13944098
]
Erick Erickson commented on SOLR-5228:
--
Yonik hit it I think. There is no maintenance here after the change to support
both, this isn't at all like the back-compat issues faced in index support
between versions for instance.
I spend more time than I probably should on the user's list, I don't want to
spend
more of it explaining to people that we made a decision to change this and
caused their existing tools/environment/whatever to blow up.
> Don't require or be inside of -- or that
> be inside of
> -
>
> Key: SOLR-5228
> URL: https://issues.apache.org/jira/browse/SOLR-5228
> Project: Solr
> Issue Type: Improvement
> Components: Schema and Analysis
>Reporter: Hoss Man
>Assignee: Hoss Man
>
> On the solr-user mailing list, Nutan recently mentioned spending days trying
> to track down a problem that turned out to be because he had attempted to add
> a {{}} that was outside of the {{}} block in his
> schema.xml -- Solr was just silently ignoring it.
> We have made improvements in other areas of config validation by generating
> statup errors when tags/attributes are found that are not expected -- but in
> this case i think we should just stop expecting/requiring that the
> {{}} and {{}} tags will be used to group these sorts of
> things. I think schema.xml parsing should just start ignoring them and only
> care about finding the {{}}, {{}}, and {{}}
> tags wherever they may be.
> If people want to keep using them, fine. If people want to mix fieldTypes
> and fields side by side (perhaps specify a fieldType, then list all the
> fields using it) fine. I don't see any value in forcing people to use them,
> but we definitely shouldn't leave things the way they are with otherwise
> perfectly valid field/type declarations being silently ignored.
> ---
> I'll take this on unless i see any objections.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5545) Add ExpressionRescorer
[ https://issues.apache.org/jira/browse/LUCENE-5545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13944049#comment-13944049 ] Robert Muir commented on LUCENE-5545: - +1 > Add ExpressionRescorer > -- > > Key: LUCENE-5545 > URL: https://issues.apache.org/jira/browse/LUCENE-5545 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Michael McCandless >Assignee: Michael McCandless > Fix For: 4.8, 5.0 > > Attachments: LUCENE-5545.patch, LUCENE-5545.patch, LUCENE-5545.patch, > LUCENE-5545.patch > > > In LUCENE-5489 we added QueryRescorer, to rescore first-pass hits using > scores from a (usually) more expensive second-pass query. > I think we should also add ExpressionRescorer, to compute the second pass > score using an arbitrary JS expression. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5551) Fix warnings in the ant build
[ https://issues.apache.org/jira/browse/LUCENE-5551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13944045#comment-13944045 ] Uwe Schindler commented on LUCENE-5551: --- FYI, I generally prefer to add a suppress warnings for those cases and don't change code, because in many cases like this the person who wrote the code had some intention to have the casts like that. Esspecially when I wrote the code, I want it explicitly be sure and I have some things to express with my style of coding. This is why I don't like Eclipse: it wants to teach me how to code, but I have my own style of coding. Especially with casts. So I would prefer to let the long/int casts as they are. Especially if they are explicit. This is not a bug or warning, its just a different style. So -1 to change int/long casts. > Fix warnings in the ant build > - > > Key: LUCENE-5551 > URL: https://issues.apache.org/jira/browse/LUCENE-5551 > Project: Lucene - Core > Issue Type: Improvement > Components: general/build >Affects Versions: 4.8 >Reporter: Shawn Heisey > Fix For: 5.0 > > Attachments: LUCENE-5551-fix-fallthrough.patch, > LUCENE-5551-redundant-casts.patch > > > The build produces a lot of warnings. LUCENE-5130 aims to fail the build on > certain warnings, but until we actually eliminate those warnings from the > code, failing the build is premature. > This issue is concerned with fixing or suppressing warnings reported by the > ant build, anything further than that may need one or more separate issues. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5551) Fix warnings in the ant build
[
https://issues.apache.org/jira/browse/LUCENE-5551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13944041#comment-13944041
]
Uwe Schindler commented on LUCENE-5551:
---
in my opinion this should look like this:
{code:java}
final long base = minValues[block] + ((long) averages[block] * element);
{code}
> Fix warnings in the ant build
> -
>
> Key: LUCENE-5551
> URL: https://issues.apache.org/jira/browse/LUCENE-5551
> Project: Lucene - Core
> Issue Type: Improvement
> Components: general/build
>Affects Versions: 4.8
>Reporter: Shawn Heisey
> Fix For: 5.0
>
> Attachments: LUCENE-5551-fix-fallthrough.patch,
> LUCENE-5551-redundant-casts.patch
>
>
> The build produces a lot of warnings. LUCENE-5130 aims to fail the build on
> certain warnings, but until we actually eliminate those warnings from the
> code, failing the build is premature.
> This issue is concerned with fixing or suppressing warnings reported by the
> ant build, anything further than that may need one or more separate issues.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5551) Fix warnings in the ant build
[
https://issues.apache.org/jira/browse/LUCENE-5551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13944040#comment-13944040
]
Uwe Schindler commented on LUCENE-5551:
---
Hi,
we should craefull check all this. E.g., I have a problem with the following:
{noformat}
- final long base = minValues[block] + (long) (averages[block] * (long)
element);
+ final long base = minValues[block] + (long) (averages[block] * element);
{noformat}
The brackets are strange, because I dont know the data types are correct and if
the multiplication may overflow.
So please be careful!
> Fix warnings in the ant build
> -
>
> Key: LUCENE-5551
> URL: https://issues.apache.org/jira/browse/LUCENE-5551
> Project: Lucene - Core
> Issue Type: Improvement
> Components: general/build
>Affects Versions: 4.8
>Reporter: Shawn Heisey
> Fix For: 5.0
>
> Attachments: LUCENE-5551-fix-fallthrough.patch,
> LUCENE-5551-redundant-casts.patch
>
>
> The build produces a lot of warnings. LUCENE-5130 aims to fail the build on
> certain warnings, but until we actually eliminate those warnings from the
> code, failing the build is premature.
> This issue is concerned with fixing or suppressing warnings reported by the
> ant build, anything further than that may need one or more separate issues.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-4.x-Linux (32bit/jdk1.8.0) - Build # 9767 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/9767/ Java: 32bit/jdk1.8.0 -client -XX:+UseSerialGC 1 tests failed. REGRESSION: org.apache.solr.client.solrj.impl.CloudSolrServerTest.testDistribSearch Error Message: java.util.concurrent.TimeoutException: Could not connect to ZooKeeper 127.0.0.1:60055 within 45000 ms Stack Trace: org.apache.solr.common.SolrException: java.util.concurrent.TimeoutException: Could not connect to ZooKeeper 127.0.0.1:60055 within 45000 ms at __randomizedtesting.SeedInfo.seed([FF3FDD796E85901C:7ED9536119DAF020]:0) at org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:150) at org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:101) at org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:91) at org.apache.solr.cloud.AbstractZkTestCase.buildZooKeeper(AbstractZkTestCase.java:91) at org.apache.solr.cloud.AbstractZkTestCase.buildZooKeeper(AbstractZkTestCase.java:85) at org.apache.solr.cloud.AbstractDistribZkTestBase.setUp(AbstractDistribZkTestBase.java:75) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.setUp(AbstractFullDistribZkTestBase.java:201) at org.apache.solr.client.solrj.impl.CloudSolrServerTest.setUp(CloudSolrServerTest.java:93) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1617) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:860) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:876) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java: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:70) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:359) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:783) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:443) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:835) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:737) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:771) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:782) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) 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 org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.ut
[jira] [Commented] (LUCENE-5551) Fix warnings in the ant build
[ https://issues.apache.org/jira/browse/LUCENE-5551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13944033#comment-13944033 ] Michael McCandless commented on LUCENE-5551: +1, thanks Shawn! > Fix warnings in the ant build > - > > Key: LUCENE-5551 > URL: https://issues.apache.org/jira/browse/LUCENE-5551 > Project: Lucene - Core > Issue Type: Improvement > Components: general/build >Affects Versions: 4.8 >Reporter: Shawn Heisey > Fix For: 5.0 > > Attachments: LUCENE-5551-fix-fallthrough.patch, > LUCENE-5551-redundant-casts.patch > > > The build produces a lot of warnings. LUCENE-5130 aims to fail the build on > certain warnings, but until we actually eliminate those warnings from the > code, failing the build is premature. > This issue is concerned with fixing or suppressing warnings reported by the > ant build, anything further than that may need one or more separate issues. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5047) Trunk's NIOFSDir and MMapDir throw different Exception on file not found cases because of use of FileChannel.open()
[ https://issues.apache.org/jira/browse/LUCENE-5047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13944010#comment-13944010 ] ASF subversion and git services commented on LUCENE-5047: - Commit 1580192 from [~thetaphi] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1580192 ] LUCENE-5550: Merged revision(s) 1491222, 1491992 from lucene/dev/trunk: - fix test to catch also NoSuchFileException - LUCENE-5047: Handle NoSuchFileException of Java 7 like FileNotFoundException when opeining index files; document this in Directory > Trunk's NIOFSDir and MMapDir throw different Exception on file not found > cases because of use of FileChannel.open() > --- > > Key: LUCENE-5047 > URL: https://issues.apache.org/jira/browse/LUCENE-5047 > Project: Lucene - Core > Issue Type: Bug > Components: core/store >Affects Versions: 5.0 >Reporter: Uwe Schindler >Assignee: Uwe Schindler > Fix For: 4.8, 5.0 > > Attachments: LUCENE-5047.patch, LUCENE-5047.patch, LUCENE-5047.patch > > > In trunk, we use FileChannel.open() when opening files from NIOFSDir and > MMapDirectory. This new method (all new APIs in Java 7!) throw > java.nio.file.NoSuchFileException if a file does not exist. The old-style > FileNotFoundException is only thrown by old APIs. > We have to decide how to correctly document the expected behaviour in the > abstract Directory interface and how we fix this (Directory should clearly > state *which* IOException type is to be thrown if we really depend on the > specific type). > The new exceptions are more specific, so you get the most "correct" exception > (it may happen with old apis that you get FNFE if you open a file where you > have no access because it is locked...). With Java 7's FileChannel.open() you > get a separate and correct Exception. > A possible fix for now may be to try/catch for the new Exceptions in the 2 > directory impls (there is also a try-with-resources there) and rethrow as > FNFE. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-5550) Handle NoSuchFileException
[
https://issues.apache.org/jira/browse/LUCENE-5550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler resolved LUCENE-5550.
---
Resolution: Fixed
Assignee: Uwe Schindler
> Handle NoSuchFileException
> --
>
> Key: LUCENE-5550
> URL: https://issues.apache.org/jira/browse/LUCENE-5550
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Michael McCandless
>Assignee: Uwe Schindler
>Priority: Blocker
> Fix For: 4.8
>
> Attachments: LUCENE-5550.patch, LUCENE-5550.patch
>
>
> With Java 7 we now must handle either NoSuchFileException (thrown by nio) or
> FileNotFoundException (thrown by pre-nio io apis) coming out of some
> Directory methods.
> We did this on trunk already but we need to do it for 4.x as well...
> including fixing MockDirWrapper to randomly pick one to throw.
> Uwe said:
> I did a grep for NoSuchFileException on trunk and 4.x.
> In trunk we have many more of this Excepotion, especially also randomization
> in MockDirectory to throw this one or FNFE. We should backport those fixes:
> Branch_4x:
> ./lucene/core/src/java/org/apache/lucene/store/Directory.java: * (not
> {@code java.nio.file.NoSuchFileException} of Java 7).
> ./lucene/core/src/java/org/apache/lucene/store/Directory.java: * (not
> {@code java.nio.file.NoSuchFileException} of Java 7).
> ./lucene/core/src/java/org/apache/lucene/store/Directory.java: * (not
> {@code java.nio.file.NoSuchFileException} of Java 7).
> ./lucene/replicator/src/test/org/apache/lucene/replicator/LocalReplicatorTest.java:import
> java.nio.file.NoSuchFileException;
> ./lucene/replicator/src/test/org/apache/lucene/replicator/LocalReplicatorTest.java:
> } catch (FileNotFoundException | NoSuchFileException e) {
> Trunk:
> ./lucene/core/src/java/org/apache/lucene/index/DirectoryReader.java:import
> java.nio.file.NoSuchFileException;
> ./lucene/core/src/java/org/apache/lucene/index/DirectoryReader.java:}
> catch (FileNotFoundException | NoSuchFileException fnfe) {
> ./lucene/core/src/java/org/apache/lucene/index/IndexFileDeleter.java:import
> java.nio.file.NoSuchFileException;
> ./lucene/core/src/java/org/apache/lucene/index/IndexFileDeleter.java:
>} catch (FileNotFoundException | NoSuchFileException e) {
> ./lucene/core/src/java/org/apache/lucene/store/Directory.java:import
> java.nio.file.NoSuchFileException;
> ./lucene/core/src/java/org/apache/lucene/store/Directory.java: * Throws
> {@link FileNotFoundException} or {@link NoSuchFileException}
> ./lucene/core/src/java/org/apache/lucene/store/Directory.java: * Throws
> {@link FileNotFoundException} or {@link NoSuchFileException}
> ./lucene/core/src/java/org/apache/lucene/store/Directory.java: * Throws
> {@link FileNotFoundException} or {@link NoSuchFileException}
> ./lucene/core/src/test/org/apache/lucene/index/TestAddIndexes.java:import
> java.nio.file.NoSuchFileException;
> ./lucene/core/src/test/org/apache/lucene/index/TestAddIndexes.java: }
> else if (t instanceof FileNotFoundException || t instanceof
> NoSuchFileException) {
> ./lucene/core/src/test/org/apache/lucene/index/TestDirectoryReader.java:import
> java.nio.file.NoSuchFileException;
> ./lucene/core/src/test/org/apache/lucene/index/TestDirectoryReader.java:
> fail("opening DirectoryReader on empty directory failed to produce
> FileNotFoundException/NoSuchFileException");
> ./lucene/core/src/test/org/apache/lucene/index/TestDirectoryReader.java:}
> catch (FileNotFoundException | NoSuchFileException e) {
> ./lucene/core/src/test/org/apache/lucene/index/TestDirectoryReader.java:
> fail("expected FileNotFoundException/NoSuchFileException");
> ./lucene/core/src/test/org/apache/lucene/index/TestDirectoryReader.java:}
> catch (FileNotFoundException | NoSuchFileException e) {
> ./lucene/core/src/test/org/apache/lucene/index/TestDirectoryReader.java:
> fail("expected FileNotFoundException/NoSuchFileException");
> ./lucene/core/src/test/org/apache/lucene/index/TestDirectoryReader.java:}
> catch (FileNotFoundException | NoSuchFileException e) {
> ./lucene/core/src/test/org/apache/lucene/index/TestIndexWriterExceptions.java:import
> java.nio.file.NoSuchFileException;
> ./lucene/core/src/test/org/apache/lucene/index/TestIndexWriterExceptions.java:
> } catch (FileNotFoundException | NoSuchFileException ex) {
> ./lucene/core/src/test/org/apache/lucene/index/TestIndexWriterLockRelease.java:import
> java.nio.file.NoSuchFileException;
> ./lucene/core/src/test/org/apache/lucene/index/TestIndexWriterLockRelease.java:
> } catch (FileNotFoundException | NoSuchFileException e) {
> ./lucene/core/src/test/org/apache/lucene/index/TestIndexWriterLockRelease.java:
> } catch (FileNotFoundException | NoSuchFileException e1) {
> ./lucene/core/src/test/org/apache/
[jira] [Commented] (LUCENE-5550) Handle NoSuchFileException
[
https://issues.apache.org/jira/browse/LUCENE-5550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13944009#comment-13944009
]
ASF subversion and git services commented on LUCENE-5550:
-
Commit 1580192 from [~thetaphi] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1580192 ]
LUCENE-5550: Merged revision(s) 1491222, 1491992 from lucene/dev/trunk:
- fix test to catch also NoSuchFileException
- LUCENE-5047: Handle NoSuchFileException of Java 7 like FileNotFoundException
when opeining index files; document this in Directory
> Handle NoSuchFileException
> --
>
> Key: LUCENE-5550
> URL: https://issues.apache.org/jira/browse/LUCENE-5550
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Michael McCandless
>Priority: Blocker
> Fix For: 4.8
>
> Attachments: LUCENE-5550.patch, LUCENE-5550.patch
>
>
> With Java 7 we now must handle either NoSuchFileException (thrown by nio) or
> FileNotFoundException (thrown by pre-nio io apis) coming out of some
> Directory methods.
> We did this on trunk already but we need to do it for 4.x as well...
> including fixing MockDirWrapper to randomly pick one to throw.
> Uwe said:
> I did a grep for NoSuchFileException on trunk and 4.x.
> In trunk we have many more of this Excepotion, especially also randomization
> in MockDirectory to throw this one or FNFE. We should backport those fixes:
> Branch_4x:
> ./lucene/core/src/java/org/apache/lucene/store/Directory.java: * (not
> {@code java.nio.file.NoSuchFileException} of Java 7).
> ./lucene/core/src/java/org/apache/lucene/store/Directory.java: * (not
> {@code java.nio.file.NoSuchFileException} of Java 7).
> ./lucene/core/src/java/org/apache/lucene/store/Directory.java: * (not
> {@code java.nio.file.NoSuchFileException} of Java 7).
> ./lucene/replicator/src/test/org/apache/lucene/replicator/LocalReplicatorTest.java:import
> java.nio.file.NoSuchFileException;
> ./lucene/replicator/src/test/org/apache/lucene/replicator/LocalReplicatorTest.java:
> } catch (FileNotFoundException | NoSuchFileException e) {
> Trunk:
> ./lucene/core/src/java/org/apache/lucene/index/DirectoryReader.java:import
> java.nio.file.NoSuchFileException;
> ./lucene/core/src/java/org/apache/lucene/index/DirectoryReader.java:}
> catch (FileNotFoundException | NoSuchFileException fnfe) {
> ./lucene/core/src/java/org/apache/lucene/index/IndexFileDeleter.java:import
> java.nio.file.NoSuchFileException;
> ./lucene/core/src/java/org/apache/lucene/index/IndexFileDeleter.java:
>} catch (FileNotFoundException | NoSuchFileException e) {
> ./lucene/core/src/java/org/apache/lucene/store/Directory.java:import
> java.nio.file.NoSuchFileException;
> ./lucene/core/src/java/org/apache/lucene/store/Directory.java: * Throws
> {@link FileNotFoundException} or {@link NoSuchFileException}
> ./lucene/core/src/java/org/apache/lucene/store/Directory.java: * Throws
> {@link FileNotFoundException} or {@link NoSuchFileException}
> ./lucene/core/src/java/org/apache/lucene/store/Directory.java: * Throws
> {@link FileNotFoundException} or {@link NoSuchFileException}
> ./lucene/core/src/test/org/apache/lucene/index/TestAddIndexes.java:import
> java.nio.file.NoSuchFileException;
> ./lucene/core/src/test/org/apache/lucene/index/TestAddIndexes.java: }
> else if (t instanceof FileNotFoundException || t instanceof
> NoSuchFileException) {
> ./lucene/core/src/test/org/apache/lucene/index/TestDirectoryReader.java:import
> java.nio.file.NoSuchFileException;
> ./lucene/core/src/test/org/apache/lucene/index/TestDirectoryReader.java:
> fail("opening DirectoryReader on empty directory failed to produce
> FileNotFoundException/NoSuchFileException");
> ./lucene/core/src/test/org/apache/lucene/index/TestDirectoryReader.java:}
> catch (FileNotFoundException | NoSuchFileException e) {
> ./lucene/core/src/test/org/apache/lucene/index/TestDirectoryReader.java:
> fail("expected FileNotFoundException/NoSuchFileException");
> ./lucene/core/src/test/org/apache/lucene/index/TestDirectoryReader.java:}
> catch (FileNotFoundException | NoSuchFileException e) {
> ./lucene/core/src/test/org/apache/lucene/index/TestDirectoryReader.java:
> fail("expected FileNotFoundException/NoSuchFileException");
> ./lucene/core/src/test/org/apache/lucene/index/TestDirectoryReader.java:}
> catch (FileNotFoundException | NoSuchFileException e) {
> ./lucene/core/src/test/org/apache/lucene/index/TestIndexWriterExceptions.java:import
> java.nio.file.NoSuchFileException;
> ./lucene/core/src/test/org/apache/lucene/index/TestIndexWriterExceptions.java:
> } catch (FileNotFoundException | NoSuchFileException ex) {
> ./lucene/core/src/test/org/apache/lucene/index/TestIndexWriterLockRelease.java:import
> java.nio.
[jira] [Commented] (LUCENE-5550) Handle NoSuchFileException
[
https://issues.apache.org/jira/browse/LUCENE-5550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13944008#comment-13944008
]
Uwe Schindler commented on LUCENE-5550:
---
Hi I checked now the 2 diffs again, they are now 100% identical. Tests also
pass, I will commit this now.
> Handle NoSuchFileException
> --
>
> Key: LUCENE-5550
> URL: https://issues.apache.org/jira/browse/LUCENE-5550
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Michael McCandless
>Priority: Blocker
> Fix For: 4.8
>
> Attachments: LUCENE-5550.patch, LUCENE-5550.patch
>
>
> With Java 7 we now must handle either NoSuchFileException (thrown by nio) or
> FileNotFoundException (thrown by pre-nio io apis) coming out of some
> Directory methods.
> We did this on trunk already but we need to do it for 4.x as well...
> including fixing MockDirWrapper to randomly pick one to throw.
> Uwe said:
> I did a grep for NoSuchFileException on trunk and 4.x.
> In trunk we have many more of this Excepotion, especially also randomization
> in MockDirectory to throw this one or FNFE. We should backport those fixes:
> Branch_4x:
> ./lucene/core/src/java/org/apache/lucene/store/Directory.java: * (not
> {@code java.nio.file.NoSuchFileException} of Java 7).
> ./lucene/core/src/java/org/apache/lucene/store/Directory.java: * (not
> {@code java.nio.file.NoSuchFileException} of Java 7).
> ./lucene/core/src/java/org/apache/lucene/store/Directory.java: * (not
> {@code java.nio.file.NoSuchFileException} of Java 7).
> ./lucene/replicator/src/test/org/apache/lucene/replicator/LocalReplicatorTest.java:import
> java.nio.file.NoSuchFileException;
> ./lucene/replicator/src/test/org/apache/lucene/replicator/LocalReplicatorTest.java:
> } catch (FileNotFoundException | NoSuchFileException e) {
> Trunk:
> ./lucene/core/src/java/org/apache/lucene/index/DirectoryReader.java:import
> java.nio.file.NoSuchFileException;
> ./lucene/core/src/java/org/apache/lucene/index/DirectoryReader.java:}
> catch (FileNotFoundException | NoSuchFileException fnfe) {
> ./lucene/core/src/java/org/apache/lucene/index/IndexFileDeleter.java:import
> java.nio.file.NoSuchFileException;
> ./lucene/core/src/java/org/apache/lucene/index/IndexFileDeleter.java:
>} catch (FileNotFoundException | NoSuchFileException e) {
> ./lucene/core/src/java/org/apache/lucene/store/Directory.java:import
> java.nio.file.NoSuchFileException;
> ./lucene/core/src/java/org/apache/lucene/store/Directory.java: * Throws
> {@link FileNotFoundException} or {@link NoSuchFileException}
> ./lucene/core/src/java/org/apache/lucene/store/Directory.java: * Throws
> {@link FileNotFoundException} or {@link NoSuchFileException}
> ./lucene/core/src/java/org/apache/lucene/store/Directory.java: * Throws
> {@link FileNotFoundException} or {@link NoSuchFileException}
> ./lucene/core/src/test/org/apache/lucene/index/TestAddIndexes.java:import
> java.nio.file.NoSuchFileException;
> ./lucene/core/src/test/org/apache/lucene/index/TestAddIndexes.java: }
> else if (t instanceof FileNotFoundException || t instanceof
> NoSuchFileException) {
> ./lucene/core/src/test/org/apache/lucene/index/TestDirectoryReader.java:import
> java.nio.file.NoSuchFileException;
> ./lucene/core/src/test/org/apache/lucene/index/TestDirectoryReader.java:
> fail("opening DirectoryReader on empty directory failed to produce
> FileNotFoundException/NoSuchFileException");
> ./lucene/core/src/test/org/apache/lucene/index/TestDirectoryReader.java:}
> catch (FileNotFoundException | NoSuchFileException e) {
> ./lucene/core/src/test/org/apache/lucene/index/TestDirectoryReader.java:
> fail("expected FileNotFoundException/NoSuchFileException");
> ./lucene/core/src/test/org/apache/lucene/index/TestDirectoryReader.java:}
> catch (FileNotFoundException | NoSuchFileException e) {
> ./lucene/core/src/test/org/apache/lucene/index/TestDirectoryReader.java:
> fail("expected FileNotFoundException/NoSuchFileException");
> ./lucene/core/src/test/org/apache/lucene/index/TestDirectoryReader.java:}
> catch (FileNotFoundException | NoSuchFileException e) {
> ./lucene/core/src/test/org/apache/lucene/index/TestIndexWriterExceptions.java:import
> java.nio.file.NoSuchFileException;
> ./lucene/core/src/test/org/apache/lucene/index/TestIndexWriterExceptions.java:
> } catch (FileNotFoundException | NoSuchFileException ex) {
> ./lucene/core/src/test/org/apache/lucene/index/TestIndexWriterLockRelease.java:import
> java.nio.file.NoSuchFileException;
> ./lucene/core/src/test/org/apache/lucene/index/TestIndexWriterLockRelease.java:
> } catch (FileNotFoundException | NoSuchFileException e) {
> ./lucene/core/src/test/org/apache/lucene/index/TestIndexWriterLockRelease.java:
> } catch (FileNotFoundE
[jira] [Updated] (LUCENE-5551) Fix warnings in the ant build
[ https://issues.apache.org/jira/browse/LUCENE-5551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shawn Heisey updated LUCENE-5551: - Attachment: LUCENE-5551-redundant-casts.patch The redundant casts patch is quite large. All tests passed when I ran them. I think the patch is good, but another pair of eyes would be greatly appreciated. For the int/long -> float/double casts that Eclipse claimed were redundant, I double checked that Eclipse wasn't smoking crack before making changes. > Fix warnings in the ant build > - > > Key: LUCENE-5551 > URL: https://issues.apache.org/jira/browse/LUCENE-5551 > Project: Lucene - Core > Issue Type: Improvement > Components: general/build >Affects Versions: 4.8 >Reporter: Shawn Heisey > Fix For: 5.0 > > Attachments: LUCENE-5551-fix-fallthrough.patch, > LUCENE-5551-redundant-casts.patch > > > The build produces a lot of warnings. LUCENE-5130 aims to fail the build on > certain warnings, but until we actually eliminate those warnings from the > code, failing the build is premature. > This issue is concerned with fixing or suppressing warnings reported by the > ant build, anything further than that may need one or more separate issues. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5047) Trunk's NIOFSDir and MMapDir throw different Exception on file not found cases because of use of FileChannel.open()
[ https://issues.apache.org/jira/browse/LUCENE-5047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated LUCENE-5047: -- Fix Version/s: 4.8 > Trunk's NIOFSDir and MMapDir throw different Exception on file not found > cases because of use of FileChannel.open() > --- > > Key: LUCENE-5047 > URL: https://issues.apache.org/jira/browse/LUCENE-5047 > Project: Lucene - Core > Issue Type: Bug > Components: core/store >Affects Versions: 5.0 >Reporter: Uwe Schindler >Assignee: Uwe Schindler > Fix For: 4.8, 5.0 > > Attachments: LUCENE-5047.patch, LUCENE-5047.patch, LUCENE-5047.patch > > > In trunk, we use FileChannel.open() when opening files from NIOFSDir and > MMapDirectory. This new method (all new APIs in Java 7!) throw > java.nio.file.NoSuchFileException if a file does not exist. The old-style > FileNotFoundException is only thrown by old APIs. > We have to decide how to correctly document the expected behaviour in the > abstract Directory interface and how we fix this (Directory should clearly > state *which* IOException type is to be thrown if we really depend on the > specific type). > The new exceptions are more specific, so you get the most "correct" exception > (it may happen with old apis that you get FNFE if you open a file where you > have no access because it is locked...). With Java 7's FileChannel.open() you > get a separate and correct Exception. > A possible fix for now may be to try/catch for the new Exceptions in the 2 > directory impls (there is also a try-with-resources there) and rethrow as > FNFE. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5047) Trunk's NIOFSDir and MMapDir throw different Exception on file not found cases because of use of FileChannel.open()
[ https://issues.apache.org/jira/browse/LUCENE-5047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13944007#comment-13944007 ] Uwe Schindler commented on LUCENE-5047: --- I will backport this one with LUCENE-5550 to 4.x (we are on Java 7 now). > Trunk's NIOFSDir and MMapDir throw different Exception on file not found > cases because of use of FileChannel.open() > --- > > Key: LUCENE-5047 > URL: https://issues.apache.org/jira/browse/LUCENE-5047 > Project: Lucene - Core > Issue Type: Bug > Components: core/store >Affects Versions: 5.0 >Reporter: Uwe Schindler >Assignee: Uwe Schindler > Fix For: 4.8, 5.0 > > Attachments: LUCENE-5047.patch, LUCENE-5047.patch, LUCENE-5047.patch > > > In trunk, we use FileChannel.open() when opening files from NIOFSDir and > MMapDirectory. This new method (all new APIs in Java 7!) throw > java.nio.file.NoSuchFileException if a file does not exist. The old-style > FileNotFoundException is only thrown by old APIs. > We have to decide how to correctly document the expected behaviour in the > abstract Directory interface and how we fix this (Directory should clearly > state *which* IOException type is to be thrown if we really depend on the > specific type). > The new exceptions are more specific, so you get the most "correct" exception > (it may happen with old apis that you get FNFE if you open a file where you > have no access because it is locked...). With Java 7's FileChannel.open() you > get a separate and correct Exception. > A possible fix for now may be to try/catch for the new Exceptions in the 2 > directory impls (there is also a try-with-resources there) and rethrow as > FNFE. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5551) Fix warnings in the ant build
[ https://issues.apache.org/jira/browse/LUCENE-5551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shawn Heisey updated LUCENE-5551: - Attachment: LUCENE-5551-fix-fallthrough.patch For the fallthrough patch: HTMLStripCharFilter and UAX29URLEmailTokenizerImpl had applicable warnings, but they are generated from jflex. I removed the changes for these classes from the patch, but here's a summary: In HTMLStripCharFilter, I suppressed fallthrough on the nextChar() method. In UAX29URLEmailTokenizerImpl, I suppressed several "unused" warnings (not really necessary) and added break statements to a couple of cases. > Fix warnings in the ant build > - > > Key: LUCENE-5551 > URL: https://issues.apache.org/jira/browse/LUCENE-5551 > Project: Lucene - Core > Issue Type: Improvement > Components: general/build >Affects Versions: 4.8 >Reporter: Shawn Heisey > Fix For: 5.0 > > Attachments: LUCENE-5551-fix-fallthrough.patch > > > The build produces a lot of warnings. LUCENE-5130 aims to fail the build on > certain warnings, but until we actually eliminate those warnings from the > code, failing the build is premature. > This issue is concerned with fixing or suppressing warnings reported by the > ant build, anything further than that may need one or more separate issues. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5550) Handle NoSuchFileException
[
https://issues.apache.org/jira/browse/LUCENE-5550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-5550:
--
Attachment: LUCENE-5550.patch
Fixed patch. The problem with delegate vs. in was a change by [~jpountz] in a
later commit.
I wil now compare trunks vs. branch about occurences of this Java 7 exception
again and commit after running tests
> Handle NoSuchFileException
> --
>
> Key: LUCENE-5550
> URL: https://issues.apache.org/jira/browse/LUCENE-5550
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Michael McCandless
>Priority: Blocker
> Fix For: 4.8
>
> Attachments: LUCENE-5550.patch, LUCENE-5550.patch
>
>
> With Java 7 we now must handle either NoSuchFileException (thrown by nio) or
> FileNotFoundException (thrown by pre-nio io apis) coming out of some
> Directory methods.
> We did this on trunk already but we need to do it for 4.x as well...
> including fixing MockDirWrapper to randomly pick one to throw.
> Uwe said:
> I did a grep for NoSuchFileException on trunk and 4.x.
> In trunk we have many more of this Excepotion, especially also randomization
> in MockDirectory to throw this one or FNFE. We should backport those fixes:
> Branch_4x:
> ./lucene/core/src/java/org/apache/lucene/store/Directory.java: * (not
> {@code java.nio.file.NoSuchFileException} of Java 7).
> ./lucene/core/src/java/org/apache/lucene/store/Directory.java: * (not
> {@code java.nio.file.NoSuchFileException} of Java 7).
> ./lucene/core/src/java/org/apache/lucene/store/Directory.java: * (not
> {@code java.nio.file.NoSuchFileException} of Java 7).
> ./lucene/replicator/src/test/org/apache/lucene/replicator/LocalReplicatorTest.java:import
> java.nio.file.NoSuchFileException;
> ./lucene/replicator/src/test/org/apache/lucene/replicator/LocalReplicatorTest.java:
> } catch (FileNotFoundException | NoSuchFileException e) {
> Trunk:
> ./lucene/core/src/java/org/apache/lucene/index/DirectoryReader.java:import
> java.nio.file.NoSuchFileException;
> ./lucene/core/src/java/org/apache/lucene/index/DirectoryReader.java:}
> catch (FileNotFoundException | NoSuchFileException fnfe) {
> ./lucene/core/src/java/org/apache/lucene/index/IndexFileDeleter.java:import
> java.nio.file.NoSuchFileException;
> ./lucene/core/src/java/org/apache/lucene/index/IndexFileDeleter.java:
>} catch (FileNotFoundException | NoSuchFileException e) {
> ./lucene/core/src/java/org/apache/lucene/store/Directory.java:import
> java.nio.file.NoSuchFileException;
> ./lucene/core/src/java/org/apache/lucene/store/Directory.java: * Throws
> {@link FileNotFoundException} or {@link NoSuchFileException}
> ./lucene/core/src/java/org/apache/lucene/store/Directory.java: * Throws
> {@link FileNotFoundException} or {@link NoSuchFileException}
> ./lucene/core/src/java/org/apache/lucene/store/Directory.java: * Throws
> {@link FileNotFoundException} or {@link NoSuchFileException}
> ./lucene/core/src/test/org/apache/lucene/index/TestAddIndexes.java:import
> java.nio.file.NoSuchFileException;
> ./lucene/core/src/test/org/apache/lucene/index/TestAddIndexes.java: }
> else if (t instanceof FileNotFoundException || t instanceof
> NoSuchFileException) {
> ./lucene/core/src/test/org/apache/lucene/index/TestDirectoryReader.java:import
> java.nio.file.NoSuchFileException;
> ./lucene/core/src/test/org/apache/lucene/index/TestDirectoryReader.java:
> fail("opening DirectoryReader on empty directory failed to produce
> FileNotFoundException/NoSuchFileException");
> ./lucene/core/src/test/org/apache/lucene/index/TestDirectoryReader.java:}
> catch (FileNotFoundException | NoSuchFileException e) {
> ./lucene/core/src/test/org/apache/lucene/index/TestDirectoryReader.java:
> fail("expected FileNotFoundException/NoSuchFileException");
> ./lucene/core/src/test/org/apache/lucene/index/TestDirectoryReader.java:}
> catch (FileNotFoundException | NoSuchFileException e) {
> ./lucene/core/src/test/org/apache/lucene/index/TestDirectoryReader.java:
> fail("expected FileNotFoundException/NoSuchFileException");
> ./lucene/core/src/test/org/apache/lucene/index/TestDirectoryReader.java:}
> catch (FileNotFoundException | NoSuchFileException e) {
> ./lucene/core/src/test/org/apache/lucene/index/TestIndexWriterExceptions.java:import
> java.nio.file.NoSuchFileException;
> ./lucene/core/src/test/org/apache/lucene/index/TestIndexWriterExceptions.java:
> } catch (FileNotFoundException | NoSuchFileException ex) {
> ./lucene/core/src/test/org/apache/lucene/index/TestIndexWriterLockRelease.java:import
> java.nio.file.NoSuchFileException;
> ./lucene/core/src/test/org/apache/lucene/index/TestIndexWriterLockRelease.java:
> } catch (FileNotFoundException | NoSuchFileException e) {
> ./lucene/core/src/test/org/ap
[jira] [Created] (LUCENE-5551) Fix warnings in the ant build
Shawn Heisey created LUCENE-5551: Summary: Fix warnings in the ant build Key: LUCENE-5551 URL: https://issues.apache.org/jira/browse/LUCENE-5551 Project: Lucene - Core Issue Type: Improvement Components: general/build Affects Versions: 4.8 Reporter: Shawn Heisey Fix For: 5.0 The build produces a lot of warnings. LUCENE-5130 aims to fail the build on certain warnings, but until we actually eliminate those warnings from the code, failing the build is premature. This issue is concerned with fixing or suppressing warnings reported by the ant build, anything further than that may need one or more separate issues. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5550) Handle NoSuchFileException
[
https://issues.apache.org/jira/browse/LUCENE-5550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13943996#comment-13943996
]
Michael McCandless commented on LUCENE-5550:
+1, after fixing the in/delegate difference.
> Handle NoSuchFileException
> --
>
> Key: LUCENE-5550
> URL: https://issues.apache.org/jira/browse/LUCENE-5550
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Michael McCandless
>Priority: Blocker
> Fix For: 4.8
>
> Attachments: LUCENE-5550.patch
>
>
> With Java 7 we now must handle either NoSuchFileException (thrown by nio) or
> FileNotFoundException (thrown by pre-nio io apis) coming out of some
> Directory methods.
> We did this on trunk already but we need to do it for 4.x as well...
> including fixing MockDirWrapper to randomly pick one to throw.
> Uwe said:
> I did a grep for NoSuchFileException on trunk and 4.x.
> In trunk we have many more of this Excepotion, especially also randomization
> in MockDirectory to throw this one or FNFE. We should backport those fixes:
> Branch_4x:
> ./lucene/core/src/java/org/apache/lucene/store/Directory.java: * (not
> {@code java.nio.file.NoSuchFileException} of Java 7).
> ./lucene/core/src/java/org/apache/lucene/store/Directory.java: * (not
> {@code java.nio.file.NoSuchFileException} of Java 7).
> ./lucene/core/src/java/org/apache/lucene/store/Directory.java: * (not
> {@code java.nio.file.NoSuchFileException} of Java 7).
> ./lucene/replicator/src/test/org/apache/lucene/replicator/LocalReplicatorTest.java:import
> java.nio.file.NoSuchFileException;
> ./lucene/replicator/src/test/org/apache/lucene/replicator/LocalReplicatorTest.java:
> } catch (FileNotFoundException | NoSuchFileException e) {
> Trunk:
> ./lucene/core/src/java/org/apache/lucene/index/DirectoryReader.java:import
> java.nio.file.NoSuchFileException;
> ./lucene/core/src/java/org/apache/lucene/index/DirectoryReader.java:}
> catch (FileNotFoundException | NoSuchFileException fnfe) {
> ./lucene/core/src/java/org/apache/lucene/index/IndexFileDeleter.java:import
> java.nio.file.NoSuchFileException;
> ./lucene/core/src/java/org/apache/lucene/index/IndexFileDeleter.java:
>} catch (FileNotFoundException | NoSuchFileException e) {
> ./lucene/core/src/java/org/apache/lucene/store/Directory.java:import
> java.nio.file.NoSuchFileException;
> ./lucene/core/src/java/org/apache/lucene/store/Directory.java: * Throws
> {@link FileNotFoundException} or {@link NoSuchFileException}
> ./lucene/core/src/java/org/apache/lucene/store/Directory.java: * Throws
> {@link FileNotFoundException} or {@link NoSuchFileException}
> ./lucene/core/src/java/org/apache/lucene/store/Directory.java: * Throws
> {@link FileNotFoundException} or {@link NoSuchFileException}
> ./lucene/core/src/test/org/apache/lucene/index/TestAddIndexes.java:import
> java.nio.file.NoSuchFileException;
> ./lucene/core/src/test/org/apache/lucene/index/TestAddIndexes.java: }
> else if (t instanceof FileNotFoundException || t instanceof
> NoSuchFileException) {
> ./lucene/core/src/test/org/apache/lucene/index/TestDirectoryReader.java:import
> java.nio.file.NoSuchFileException;
> ./lucene/core/src/test/org/apache/lucene/index/TestDirectoryReader.java:
> fail("opening DirectoryReader on empty directory failed to produce
> FileNotFoundException/NoSuchFileException");
> ./lucene/core/src/test/org/apache/lucene/index/TestDirectoryReader.java:}
> catch (FileNotFoundException | NoSuchFileException e) {
> ./lucene/core/src/test/org/apache/lucene/index/TestDirectoryReader.java:
> fail("expected FileNotFoundException/NoSuchFileException");
> ./lucene/core/src/test/org/apache/lucene/index/TestDirectoryReader.java:}
> catch (FileNotFoundException | NoSuchFileException e) {
> ./lucene/core/src/test/org/apache/lucene/index/TestDirectoryReader.java:
> fail("expected FileNotFoundException/NoSuchFileException");
> ./lucene/core/src/test/org/apache/lucene/index/TestDirectoryReader.java:}
> catch (FileNotFoundException | NoSuchFileException e) {
> ./lucene/core/src/test/org/apache/lucene/index/TestIndexWriterExceptions.java:import
> java.nio.file.NoSuchFileException;
> ./lucene/core/src/test/org/apache/lucene/index/TestIndexWriterExceptions.java:
> } catch (FileNotFoundException | NoSuchFileException ex) {
> ./lucene/core/src/test/org/apache/lucene/index/TestIndexWriterLockRelease.java:import
> java.nio.file.NoSuchFileException;
> ./lucene/core/src/test/org/apache/lucene/index/TestIndexWriterLockRelease.java:
> } catch (FileNotFoundException | NoSuchFileException e) {
> ./lucene/core/src/test/org/apache/lucene/index/TestIndexWriterLockRelease.java:
> } catch (FileNotFoundException | NoSuchFileException e1) {
> ./lucene/core/src/test/org/apach
[jira] [Updated] (LUCENE-5550) Handle NoSuchFileException
[
https://issues.apache.org/jira/browse/LUCENE-5550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-5550:
--
Attachment: LUCENE-5550.patch
That's more or less this merge missing.
> Handle NoSuchFileException
> --
>
> Key: LUCENE-5550
> URL: https://issues.apache.org/jira/browse/LUCENE-5550
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Michael McCandless
>Priority: Blocker
> Fix For: 4.8
>
> Attachments: LUCENE-5550.patch
>
>
> With Java 7 we now must handle either NoSuchFileException (thrown by nio) or
> FileNotFoundException (thrown by pre-nio io apis) coming out of some
> Directory methods.
> We did this on trunk already but we need to do it for 4.x as well...
> including fixing MockDirWrapper to randomly pick one to throw.
> Uwe said:
> I did a grep for NoSuchFileException on trunk and 4.x.
> In trunk we have many more of this Excepotion, especially also randomization
> in MockDirectory to throw this one or FNFE. We should backport those fixes:
> Branch_4x:
> ./lucene/core/src/java/org/apache/lucene/store/Directory.java: * (not
> {@code java.nio.file.NoSuchFileException} of Java 7).
> ./lucene/core/src/java/org/apache/lucene/store/Directory.java: * (not
> {@code java.nio.file.NoSuchFileException} of Java 7).
> ./lucene/core/src/java/org/apache/lucene/store/Directory.java: * (not
> {@code java.nio.file.NoSuchFileException} of Java 7).
> ./lucene/replicator/src/test/org/apache/lucene/replicator/LocalReplicatorTest.java:import
> java.nio.file.NoSuchFileException;
> ./lucene/replicator/src/test/org/apache/lucene/replicator/LocalReplicatorTest.java:
> } catch (FileNotFoundException | NoSuchFileException e) {
> Trunk:
> ./lucene/core/src/java/org/apache/lucene/index/DirectoryReader.java:import
> java.nio.file.NoSuchFileException;
> ./lucene/core/src/java/org/apache/lucene/index/DirectoryReader.java:}
> catch (FileNotFoundException | NoSuchFileException fnfe) {
> ./lucene/core/src/java/org/apache/lucene/index/IndexFileDeleter.java:import
> java.nio.file.NoSuchFileException;
> ./lucene/core/src/java/org/apache/lucene/index/IndexFileDeleter.java:
>} catch (FileNotFoundException | NoSuchFileException e) {
> ./lucene/core/src/java/org/apache/lucene/store/Directory.java:import
> java.nio.file.NoSuchFileException;
> ./lucene/core/src/java/org/apache/lucene/store/Directory.java: * Throws
> {@link FileNotFoundException} or {@link NoSuchFileException}
> ./lucene/core/src/java/org/apache/lucene/store/Directory.java: * Throws
> {@link FileNotFoundException} or {@link NoSuchFileException}
> ./lucene/core/src/java/org/apache/lucene/store/Directory.java: * Throws
> {@link FileNotFoundException} or {@link NoSuchFileException}
> ./lucene/core/src/test/org/apache/lucene/index/TestAddIndexes.java:import
> java.nio.file.NoSuchFileException;
> ./lucene/core/src/test/org/apache/lucene/index/TestAddIndexes.java: }
> else if (t instanceof FileNotFoundException || t instanceof
> NoSuchFileException) {
> ./lucene/core/src/test/org/apache/lucene/index/TestDirectoryReader.java:import
> java.nio.file.NoSuchFileException;
> ./lucene/core/src/test/org/apache/lucene/index/TestDirectoryReader.java:
> fail("opening DirectoryReader on empty directory failed to produce
> FileNotFoundException/NoSuchFileException");
> ./lucene/core/src/test/org/apache/lucene/index/TestDirectoryReader.java:}
> catch (FileNotFoundException | NoSuchFileException e) {
> ./lucene/core/src/test/org/apache/lucene/index/TestDirectoryReader.java:
> fail("expected FileNotFoundException/NoSuchFileException");
> ./lucene/core/src/test/org/apache/lucene/index/TestDirectoryReader.java:}
> catch (FileNotFoundException | NoSuchFileException e) {
> ./lucene/core/src/test/org/apache/lucene/index/TestDirectoryReader.java:
> fail("expected FileNotFoundException/NoSuchFileException");
> ./lucene/core/src/test/org/apache/lucene/index/TestDirectoryReader.java:}
> catch (FileNotFoundException | NoSuchFileException e) {
> ./lucene/core/src/test/org/apache/lucene/index/TestIndexWriterExceptions.java:import
> java.nio.file.NoSuchFileException;
> ./lucene/core/src/test/org/apache/lucene/index/TestIndexWriterExceptions.java:
> } catch (FileNotFoundException | NoSuchFileException ex) {
> ./lucene/core/src/test/org/apache/lucene/index/TestIndexWriterLockRelease.java:import
> java.nio.file.NoSuchFileException;
> ./lucene/core/src/test/org/apache/lucene/index/TestIndexWriterLockRelease.java:
> } catch (FileNotFoundException | NoSuchFileException e) {
> ./lucene/core/src/test/org/apache/lucene/index/TestIndexWriterLockRelease.java:
> } catch (FileNotFoundException | NoSuchFileException e1) {
> ./lucene/core/src/test/org/apache/lucene/store/TestDirectory.java:imp
[jira] [Commented] (LUCENE-5528) Add context to AnalyzingInfixSuggester
[ https://issues.apache.org/jira/browse/LUCENE-5528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13943983#comment-13943983 ] Michael McCandless commented on LUCENE-5528: BTW I pushed this patch to the jirasearch "production" site (http://jirasearch.mikemccandless.com ) and it seems to be working very well! If you drill down on a specific project (Lucene, Solr, Tika) then the suggestions you see are only for that project. This also happens if you type the project name, e.g. "lucene word" shows only lucene issues/users containing word*, and "tika word" shows only tika issues/users with word* Nice to eat your own dog food ... > Add context to AnalyzingInfixSuggester > -- > > Key: LUCENE-5528 > URL: https://issues.apache.org/jira/browse/LUCENE-5528 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Michael McCandless >Assignee: Michael McCandless > Fix For: 4.8, 5.0 > > Attachments: LUCENE-5528-1.patch, LUCENE-5528-1.patch, > LUCENE-5528.patch, LUCENE-5528.patch, contextInputIteratImpl.patch > > > Spinoff from LUCENE-5350. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5528) Add context to AnalyzingInfixSuggester
[
https://issues.apache.org/jira/browse/LUCENE-5528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13943982#comment-13943982
]
Michael McCandless commented on LUCENE-5528:
Thanks Areek, new patch looks great! It's nice that
Document/ExpressionDictionary, and the wrapping InputIterators
(Sorted/Unsorted) handle contexts as well. I think it's close.
I noticed a lot of added but unused "import import
org.apache.lucene.util.BytesRefIterator;" lines.
Also, AnalyzingInfixSuggester calls InputIterator.contexts() regardless of
whether hasContexts return true or false; I think this is actually OK, but can
you update InputIterator's javadocs to state that this is allowed, and
contexts() is expected to return null even if hasContexts() had returned false?
Finally just a small whitespace issue: instead of:
{noformat}
if(iterator.hasContexts()) {
{noformat}
Can you do this:
{noformat}
if (iterator.hasContexts()) {
{noformat}
(i.e. just add space between "if" and "("). Thanks!
> Add context to AnalyzingInfixSuggester
> --
>
> Key: LUCENE-5528
> URL: https://issues.apache.org/jira/browse/LUCENE-5528
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 4.8, 5.0
>
> Attachments: LUCENE-5528-1.patch, LUCENE-5528-1.patch,
> LUCENE-5528.patch, LUCENE-5528.patch, contextInputIteratImpl.patch
>
>
> Spinoff from LUCENE-5350.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5545) Add ExpressionRescorer
[ https://issues.apache.org/jira/browse/LUCENE-5545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless updated LUCENE-5545: --- Attachment: LUCENE-5545.patch New patch, improving the tests, which found a problem (infinite loop!) with QueryRescorer, which I fixed by removing entirely the OnlyDocIDsFilter. Now I just interact directly w/ the Scorer per segment instead, and it also addresses the TODO about not creating lots of objects. I think it's ready. > Add ExpressionRescorer > -- > > Key: LUCENE-5545 > URL: https://issues.apache.org/jira/browse/LUCENE-5545 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Michael McCandless >Assignee: Michael McCandless > Fix For: 4.8, 5.0 > > Attachments: LUCENE-5545.patch, LUCENE-5545.patch, LUCENE-5545.patch, > LUCENE-5545.patch > > > In LUCENE-5489 we added QueryRescorer, to rescore first-pass hits using > scores from a (usually) more expensive second-pass query. > I think we should also add ExpressionRescorer, to compute the second pass > score using an arbitrary JS expression. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-5550) Handle NoSuchFileException
Michael McCandless created LUCENE-5550:
--
Summary: Handle NoSuchFileException
Key: LUCENE-5550
URL: https://issues.apache.org/jira/browse/LUCENE-5550
Project: Lucene - Core
Issue Type: Bug
Reporter: Michael McCandless
Priority: Blocker
Fix For: 4.8
With Java 7 we now must handle either NoSuchFileException (thrown by nio) or
FileNotFoundException (thrown by pre-nio io apis) coming out of some Directory
methods.
We did this on trunk already but we need to do it for 4.x as well... including
fixing MockDirWrapper to randomly pick one to throw.
Uwe said:
I did a grep for NoSuchFileException on trunk and 4.x.
In trunk we have many more of this Excepotion, especially also randomization in
MockDirectory to throw this one or FNFE. We should backport those fixes:
Branch_4x:
./lucene/core/src/java/org/apache/lucene/store/Directory.java: * (not {@code
java.nio.file.NoSuchFileException} of Java 7).
./lucene/core/src/java/org/apache/lucene/store/Directory.java: * (not {@code
java.nio.file.NoSuchFileException} of Java 7).
./lucene/core/src/java/org/apache/lucene/store/Directory.java: * (not {@code
java.nio.file.NoSuchFileException} of Java 7).
./lucene/replicator/src/test/org/apache/lucene/replicator/LocalReplicatorTest.java:import
java.nio.file.NoSuchFileException;
./lucene/replicator/src/test/org/apache/lucene/replicator/LocalReplicatorTest.java:
} catch (FileNotFoundException | NoSuchFileException e) {
Trunk:
./lucene/core/src/java/org/apache/lucene/index/DirectoryReader.java:import
java.nio.file.NoSuchFileException;
./lucene/core/src/java/org/apache/lucene/index/DirectoryReader.java:}
catch (FileNotFoundException | NoSuchFileException fnfe) {
./lucene/core/src/java/org/apache/lucene/index/IndexFileDeleter.java:import
java.nio.file.NoSuchFileException;
./lucene/core/src/java/org/apache/lucene/index/IndexFileDeleter.java:
} catch (FileNotFoundException | NoSuchFileException e) {
./lucene/core/src/java/org/apache/lucene/store/Directory.java:import
java.nio.file.NoSuchFileException;
./lucene/core/src/java/org/apache/lucene/store/Directory.java: * Throws
{@link FileNotFoundException} or {@link NoSuchFileException}
./lucene/core/src/java/org/apache/lucene/store/Directory.java: * Throws
{@link FileNotFoundException} or {@link NoSuchFileException}
./lucene/core/src/java/org/apache/lucene/store/Directory.java: * Throws
{@link FileNotFoundException} or {@link NoSuchFileException}
./lucene/core/src/test/org/apache/lucene/index/TestAddIndexes.java:import
java.nio.file.NoSuchFileException;
./lucene/core/src/test/org/apache/lucene/index/TestAddIndexes.java: } else
if (t instanceof FileNotFoundException || t instanceof NoSuchFileException) {
./lucene/core/src/test/org/apache/lucene/index/TestDirectoryReader.java:import
java.nio.file.NoSuchFileException;
./lucene/core/src/test/org/apache/lucene/index/TestDirectoryReader.java:
fail("opening DirectoryReader on empty directory failed to produce
FileNotFoundException/NoSuchFileException");
./lucene/core/src/test/org/apache/lucene/index/TestDirectoryReader.java:}
catch (FileNotFoundException | NoSuchFileException e) {
./lucene/core/src/test/org/apache/lucene/index/TestDirectoryReader.java:
fail("expected FileNotFoundException/NoSuchFileException");
./lucene/core/src/test/org/apache/lucene/index/TestDirectoryReader.java:}
catch (FileNotFoundException | NoSuchFileException e) {
./lucene/core/src/test/org/apache/lucene/index/TestDirectoryReader.java:
fail("expected FileNotFoundException/NoSuchFileException");
./lucene/core/src/test/org/apache/lucene/index/TestDirectoryReader.java:}
catch (FileNotFoundException | NoSuchFileException e) {
./lucene/core/src/test/org/apache/lucene/index/TestIndexWriterExceptions.java:import
java.nio.file.NoSuchFileException;
./lucene/core/src/test/org/apache/lucene/index/TestIndexWriterExceptions.java:
} catch (FileNotFoundException | NoSuchFileException ex) {
./lucene/core/src/test/org/apache/lucene/index/TestIndexWriterLockRelease.java:import
java.nio.file.NoSuchFileException;
./lucene/core/src/test/org/apache/lucene/index/TestIndexWriterLockRelease.java:
} catch (FileNotFoundException | NoSuchFileException e) {
./lucene/core/src/test/org/apache/lucene/index/TestIndexWriterLockRelease.java:
} catch (FileNotFoundException | NoSuchFileException e1) {
./lucene/core/src/test/org/apache/lucene/store/TestDirectory.java:import
java.nio.file.NoSuchFileException;
./lucene/core/src/test/org/apache/lucene/store/TestDirectory.java:
} catch (FileNotFoundException | NoSuchFileException e) {
./lucene/replicator/src/test/org/apache/lucene/replicator/LocalReplicatorTest.java:import
java.nio.file.NoSuchFileException;
./lucene/replicator/src/test/org/apache/lucene/replicator/LocalReplicatorTest.j
Re: svn commit: r1579669 - /lucene/dev/branches/branch_4x/lucene/replicator/src/test/org/apache/lucene/replicator/LocalReplicatorTest.java
OK: https://issues.apache.org/jira/browse/LUCENE-5550
Mike McCandless
http://blog.mikemccandless.com
On Sat, Mar 22, 2014 at 4:31 AM, Michael McCandless
wrote:
> Thanks Uwe, I'll open a 4.8 blocker for this...
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
>
> On Fri, Mar 21, 2014 at 7:04 PM, Uwe Schindler wrote:
>> Hi Mike,
>>
>> I did a grep for NoSuchFileException on trunk and 4.x.
>>
>> In trunk we have many more of this Excepotion, especially also randomization
>> in MockDirectory to throw this one or FNFE. We should backport those fixes:
>>
>> Branch_4x:
>> ./lucene/core/src/java/org/apache/lucene/store/Directory.java: * (not
>> {@code java.nio.file.NoSuchFileException} of Java 7).
>> ./lucene/core/src/java/org/apache/lucene/store/Directory.java: * (not
>> {@code java.nio.file.NoSuchFileException} of Java 7).
>> ./lucene/core/src/java/org/apache/lucene/store/Directory.java: * (not
>> {@code java.nio.file.NoSuchFileException} of Java 7).
>> ./lucene/replicator/src/test/org/apache/lucene/replicator/LocalReplicatorTest.java:import
>> java.nio.file.NoSuchFileException;
>> ./lucene/replicator/src/test/org/apache/lucene/replicator/LocalReplicatorTest.java:
>> } catch (FileNotFoundException | NoSuchFileException e) {
>>
>> Trunk:
>> ./lucene/core/src/java/org/apache/lucene/index/DirectoryReader.java:import
>> java.nio.file.NoSuchFileException;
>> ./lucene/core/src/java/org/apache/lucene/index/DirectoryReader.java:
>> } catch (FileNotFoundException | NoSuchFileException fnfe) {
>> ./lucene/core/src/java/org/apache/lucene/index/IndexFileDeleter.java:import
>> java.nio.file.NoSuchFileException;
>> ./lucene/core/src/java/org/apache/lucene/index/IndexFileDeleter.java:
>> } catch (FileNotFoundException | NoSuchFileException e) {
>> ./lucene/core/src/java/org/apache/lucene/store/Directory.java:import
>> java.nio.file.NoSuchFileException;
>> ./lucene/core/src/java/org/apache/lucene/store/Directory.java: *
>> Throws {@link FileNotFoundException} or {@link NoSuchFileException}
>> ./lucene/core/src/java/org/apache/lucene/store/Directory.java: * Throws
>> {@link FileNotFoundException} or {@link NoSuchFileException}
>> ./lucene/core/src/java/org/apache/lucene/store/Directory.java: * Throws
>> {@link FileNotFoundException} or {@link NoSuchFileException}
>> ./lucene/core/src/test/org/apache/lucene/index/TestAddIndexes.java:import
>> java.nio.file.NoSuchFileException;
>> ./lucene/core/src/test/org/apache/lucene/index/TestAddIndexes.java: }
>> else if (t instanceof FileNotFoundException || t instanceof
>> NoSuchFileException) {
>> ./lucene/core/src/test/org/apache/lucene/index/TestDirectoryReader.java:import
>> java.nio.file.NoSuchFileException;
>> ./lucene/core/src/test/org/apache/lucene/index/TestDirectoryReader.java:
>> fail("opening DirectoryReader on empty directory failed to produce
>> FileNotFoundException/NoSuchFileException");
>> ./lucene/core/src/test/org/apache/lucene/index/TestDirectoryReader.java:
>> } catch (FileNotFoundException | NoSuchFileException e) {
>> ./lucene/core/src/test/org/apache/lucene/index/TestDirectoryReader.java:
>> fail("expected FileNotFoundException/NoSuchFileException");
>> ./lucene/core/src/test/org/apache/lucene/index/TestDirectoryReader.java:
>> } catch (FileNotFoundException | NoSuchFileException e) {
>> ./lucene/core/src/test/org/apache/lucene/index/TestDirectoryReader.java:
>> fail("expected FileNotFoundException/NoSuchFileException");
>> ./lucene/core/src/test/org/apache/lucene/index/TestDirectoryReader.java:
>> } catch (FileNotFoundException | NoSuchFileException e) {
>> ./lucene/core/src/test/org/apache/lucene/index/TestIndexWriterExceptions.java:import
>> java.nio.file.NoSuchFileException;
>> ./lucene/core/src/test/org/apache/lucene/index/TestIndexWriterExceptions.java:
>> } catch (FileNotFoundException | NoSuchFileException ex) {
>> ./lucene/core/src/test/org/apache/lucene/index/TestIndexWriterLockRelease.java:import
>> java.nio.file.NoSuchFileException;
>> ./lucene/core/src/test/org/apache/lucene/index/TestIndexWriterLockRelease.java:
>> } catch (FileNotFoundException | NoSuchFileException e) {
>> ./lucene/core/src/test/org/apache/lucene/index/TestIndexWriterLockRelease.java:
>> } catch (FileNotFoundException | NoSuchFileException e1) {
>> ./lucene/core/src/test/org/apache/lucene/store/TestDirectory.java:import
>> java.nio.file.NoSuchFileException;
>> ./lucene/core/src/test/org/apache/lucene/store/TestDirectory.java:
>>} catch (FileNotFoundException | NoSuchFileException e) {
>> ./lucene/replicator/src/test/org/apache/lucene/replicator/LocalReplicatorTest.java:import
>> java.nio.file.NoSuchFileException;
>> ./lucene/replicator/src/test/org/apache/lucene/replicator/LocalReplicatorTest.java:
>> } catch (FileNotFoundException | NoSuchFileException e) {
>> ./lucene/test-framework/src/java/org/apache/lucene/store/MockDirectoryWrapper.java:im
Re: svn commit: r1579669 - /lucene/dev/branches/branch_4x/lucene/replicator/src/test/org/apache/lucene/replicator/LocalReplicatorTest.java
Thanks Uwe, I'll open a 4.8 blocker for this...
Mike McCandless
http://blog.mikemccandless.com
On Fri, Mar 21, 2014 at 7:04 PM, Uwe Schindler wrote:
> Hi Mike,
>
> I did a grep for NoSuchFileException on trunk and 4.x.
>
> In trunk we have many more of this Excepotion, especially also randomization
> in MockDirectory to throw this one or FNFE. We should backport those fixes:
>
> Branch_4x:
> ./lucene/core/src/java/org/apache/lucene/store/Directory.java: * (not
> {@code java.nio.file.NoSuchFileException} of Java 7).
> ./lucene/core/src/java/org/apache/lucene/store/Directory.java: * (not
> {@code java.nio.file.NoSuchFileException} of Java 7).
> ./lucene/core/src/java/org/apache/lucene/store/Directory.java: * (not
> {@code java.nio.file.NoSuchFileException} of Java 7).
> ./lucene/replicator/src/test/org/apache/lucene/replicator/LocalReplicatorTest.java:import
> java.nio.file.NoSuchFileException;
> ./lucene/replicator/src/test/org/apache/lucene/replicator/LocalReplicatorTest.java:
> } catch (FileNotFoundException | NoSuchFileException e) {
>
> Trunk:
> ./lucene/core/src/java/org/apache/lucene/index/DirectoryReader.java:import
> java.nio.file.NoSuchFileException;
> ./lucene/core/src/java/org/apache/lucene/index/DirectoryReader.java:}
> catch (FileNotFoundException | NoSuchFileException fnfe) {
> ./lucene/core/src/java/org/apache/lucene/index/IndexFileDeleter.java:import
> java.nio.file.NoSuchFileException;
> ./lucene/core/src/java/org/apache/lucene/index/IndexFileDeleter.java:
>} catch (FileNotFoundException | NoSuchFileException e) {
> ./lucene/core/src/java/org/apache/lucene/store/Directory.java:import
> java.nio.file.NoSuchFileException;
> ./lucene/core/src/java/org/apache/lucene/store/Directory.java: * Throws
> {@link FileNotFoundException} or {@link NoSuchFileException}
> ./lucene/core/src/java/org/apache/lucene/store/Directory.java: * Throws
> {@link FileNotFoundException} or {@link NoSuchFileException}
> ./lucene/core/src/java/org/apache/lucene/store/Directory.java: * Throws
> {@link FileNotFoundException} or {@link NoSuchFileException}
> ./lucene/core/src/test/org/apache/lucene/index/TestAddIndexes.java:import
> java.nio.file.NoSuchFileException;
> ./lucene/core/src/test/org/apache/lucene/index/TestAddIndexes.java: }
> else if (t instanceof FileNotFoundException || t instanceof
> NoSuchFileException) {
> ./lucene/core/src/test/org/apache/lucene/index/TestDirectoryReader.java:import
> java.nio.file.NoSuchFileException;
> ./lucene/core/src/test/org/apache/lucene/index/TestDirectoryReader.java:
> fail("opening DirectoryReader on empty directory failed to produce
> FileNotFoundException/NoSuchFileException");
> ./lucene/core/src/test/org/apache/lucene/index/TestDirectoryReader.java:}
> catch (FileNotFoundException | NoSuchFileException e) {
> ./lucene/core/src/test/org/apache/lucene/index/TestDirectoryReader.java:
> fail("expected FileNotFoundException/NoSuchFileException");
> ./lucene/core/src/test/org/apache/lucene/index/TestDirectoryReader.java:}
> catch (FileNotFoundException | NoSuchFileException e) {
> ./lucene/core/src/test/org/apache/lucene/index/TestDirectoryReader.java:
> fail("expected FileNotFoundException/NoSuchFileException");
> ./lucene/core/src/test/org/apache/lucene/index/TestDirectoryReader.java:}
> catch (FileNotFoundException | NoSuchFileException e) {
> ./lucene/core/src/test/org/apache/lucene/index/TestIndexWriterExceptions.java:import
> java.nio.file.NoSuchFileException;
> ./lucene/core/src/test/org/apache/lucene/index/TestIndexWriterExceptions.java:
> } catch (FileNotFoundException | NoSuchFileException ex) {
> ./lucene/core/src/test/org/apache/lucene/index/TestIndexWriterLockRelease.java:import
> java.nio.file.NoSuchFileException;
> ./lucene/core/src/test/org/apache/lucene/index/TestIndexWriterLockRelease.java:
> } catch (FileNotFoundException | NoSuchFileException e) {
> ./lucene/core/src/test/org/apache/lucene/index/TestIndexWriterLockRelease.java:
> } catch (FileNotFoundException | NoSuchFileException e1) {
> ./lucene/core/src/test/org/apache/lucene/store/TestDirectory.java:import
> java.nio.file.NoSuchFileException;
> ./lucene/core/src/test/org/apache/lucene/store/TestDirectory.java:
> } catch (FileNotFoundException | NoSuchFileException e) {
> ./lucene/replicator/src/test/org/apache/lucene/replicator/LocalReplicatorTest.java:import
> java.nio.file.NoSuchFileException;
> ./lucene/replicator/src/test/org/apache/lucene/replicator/LocalReplicatorTest.java:
> } catch (FileNotFoundException | NoSuchFileException e) {
> ./lucene/test-framework/src/java/org/apache/lucene/store/MockDirectoryWrapper.java:import
> java.nio.file.NoSuchFileException;
> ./lucene/test-framework/src/java/org/apache/lucene/store/MockDirectoryWrapper.java:
> throw randomState.nextBoolean() ? new FileNotFoundException("a random
> IOException (" + name + ")") : new NoSuc
Re: [JENKINS] Lucene-4x-Linux-Java7-64-test-only - Build # 16503 - Failure!
Argh, I committed a fix. Mike McCandless http://blog.mikemccandless.com On Fri, Mar 21, 2014 at 10:55 PM, wrote: > Build: builds.flonkings.com/job/Lucene-4x-Linux-Java7-64-test-only/16503/ > > 1 tests failed. > REGRESSION: org.apache.lucene.search.TestQueryRescorer.testCustomCombine > > Error Message: > expected:<[0]> but was:<[1]> > > Stack Trace: > org.junit.ComparisonFailure: expected:<[0]> but was:<[1]> > at > __randomizedtesting.SeedInfo.seed([3E72FA6DABDA8AF4:97374C43D2B2FBAA]:0) > at org.junit.Assert.assertEquals(Assert.java:125) > at org.junit.Assert.assertEquals(Assert.java:147) > at > org.apache.lucene.search.TestQueryRescorer.testCustomCombine(TestQueryRescorer.java:141) > 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:1617) > at > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:826) > at > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:862) > at > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:876) > at > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) > at > org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51) > at > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java: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:70) > at > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) > at > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) > at > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:359) > at > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:783) > at > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:443) > at > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:835) > at > com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:737) > at > com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:771) > at > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:782) > 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 > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43) > at > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) > at > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) > at > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) > at > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) > at > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:359) > at java.lang.Thread.run(Thread.java:724) > > > > > Build Log: > [...truncated 1411 lines...] >[junit4] Suite: org.apache.lucene.search.TestQueryRescorer >[junit4] 2> NOTE: reproduce with: ant test -Dtestcase=TestQueryRescorer > -Dtests.method=testCustomCombine -Dtests.seed=3E72FA6DABDA8AF4 > -Dtests.slow=true -Dtests.locale=hi_IN -Dtests.timezone=Asia/Ulan_Bator > -Dtests.file.encoding=
