[jira] [Commented] (SOLR-5623) Better diagnosis of RuntimeExceptions in analysis
[ https://issues.apache.org/jira/browse/SOLR-5623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13891973#comment-13891973 ] ASF subversion and git services commented on SOLR-5623: --- Commit 1564700 from sha...@apache.org in branch 'dev/trunk' [ https://svn.apache.org/r1564700 ] SOLR-5623: Use root locale in String.format and do not wrap SolrExceptions Better diagnosis of RuntimeExceptions in analysis - Key: SOLR-5623 URL: https://issues.apache.org/jira/browse/SOLR-5623 Project: Solr Issue Type: Bug Affects Versions: 4.6.1 Reporter: Benson Margulies Assignee: Benson Margulies Fix For: 5.0, 4.7 Attachments: SOLR-5623-nowrap.patch, SOLR-5623-nowrap.patch If an analysis component (tokenizer, filter, etc) gets really into a hissy fit and throws a RuntimeException, the resulting log traffic is less than informative, lacking any pointer to the doc under discussion (in the doc case). It would be more better if there was a catch/try shortstop that logged this more informatively. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5623) Better diagnosis of RuntimeExceptions in analysis
[ https://issues.apache.org/jira/browse/SOLR-5623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13891976#comment-13891976 ] ASF subversion and git services commented on SOLR-5623: --- Commit 1564701 from sha...@apache.org in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1564701 ] SOLR-5623: Use root locale in String.format and do not wrap SolrExceptions Better diagnosis of RuntimeExceptions in analysis - Key: SOLR-5623 URL: https://issues.apache.org/jira/browse/SOLR-5623 Project: Solr Issue Type: Bug Affects Versions: 4.6.1 Reporter: Benson Margulies Assignee: Benson Margulies Fix For: 5.0, 4.7 Attachments: SOLR-5623-nowrap.patch, SOLR-5623-nowrap.patch If an analysis component (tokenizer, filter, etc) gets really into a hissy fit and throws a RuntimeException, the resulting log traffic is less than informative, lacking any pointer to the doc under discussion (in the doc case). It would be more better if there was a catch/try shortstop that logged this more informatively. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5623) Better diagnosis of RuntimeExceptions in analysis
[ https://issues.apache.org/jira/browse/SOLR-5623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13892044#comment-13892044 ] ASF subversion and git services commented on SOLR-5623: --- Commit 1564737 from sha...@apache.org in branch 'dev/trunk' [ https://svn.apache.org/r1564737 ] SOLR-5623: Added svn:eol-style Better diagnosis of RuntimeExceptions in analysis - Key: SOLR-5623 URL: https://issues.apache.org/jira/browse/SOLR-5623 Project: Solr Issue Type: Bug Affects Versions: 4.6.1 Reporter: Benson Margulies Assignee: Benson Margulies Fix For: 5.0, 4.7 Attachments: SOLR-5623-nowrap.patch, SOLR-5623-nowrap.patch If an analysis component (tokenizer, filter, etc) gets really into a hissy fit and throws a RuntimeException, the resulting log traffic is less than informative, lacking any pointer to the doc under discussion (in the doc case). It would be more better if there was a catch/try shortstop that logged this more informatively. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5623) Better diagnosis of RuntimeExceptions in analysis
[ https://issues.apache.org/jira/browse/SOLR-5623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13892045#comment-13892045 ] ASF subversion and git services commented on SOLR-5623: --- Commit 1564741 from sha...@apache.org in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1564741 ] SOLR-5623: Added svn:eol-style Better diagnosis of RuntimeExceptions in analysis - Key: SOLR-5623 URL: https://issues.apache.org/jira/browse/SOLR-5623 Project: Solr Issue Type: Bug Affects Versions: 4.6.1 Reporter: Benson Margulies Assignee: Benson Margulies Fix For: 5.0, 4.7 Attachments: SOLR-5623-nowrap.patch, SOLR-5623-nowrap.patch If an analysis component (tokenizer, filter, etc) gets really into a hissy fit and throws a RuntimeException, the resulting log traffic is less than informative, lacking any pointer to the doc under discussion (in the doc case). It would be more better if there was a catch/try shortstop that logged this more informatively. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5623) Better diagnosis of RuntimeExceptions in analysis
[ https://issues.apache.org/jira/browse/SOLR-5623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13892049#comment-13892049 ] Benson Margulies commented on SOLR-5623: [~shalinmangar] Apparently I haven't learned to read the output of ant test very well, and fooled myself into believing that all as well. Thanks for cleaning up after me. Better diagnosis of RuntimeExceptions in analysis - Key: SOLR-5623 URL: https://issues.apache.org/jira/browse/SOLR-5623 Project: Solr Issue Type: Bug Affects Versions: 4.6.1 Reporter: Benson Margulies Assignee: Benson Margulies Fix For: 5.0, 4.7 Attachments: SOLR-5623-nowrap.patch, SOLR-5623-nowrap.patch If an analysis component (tokenizer, filter, etc) gets really into a hissy fit and throws a RuntimeException, the resulting log traffic is less than informative, lacking any pointer to the doc under discussion (in the doc case). It would be more better if there was a catch/try shortstop that logged this more informatively. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5623) Better diagnosis of RuntimeExceptions in analysis
[ https://issues.apache.org/jira/browse/SOLR-5623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13892054#comment-13892054 ] Shalin Shekhar Mangar commented on SOLR-5623: - No problem, it happens to all of us. I've been guilty of it more often than others I think. Running the test suite is not enough, you need 'ant precommit' to pass as well. Better diagnosis of RuntimeExceptions in analysis - Key: SOLR-5623 URL: https://issues.apache.org/jira/browse/SOLR-5623 Project: Solr Issue Type: Bug Affects Versions: 4.6.1 Reporter: Benson Margulies Assignee: Benson Margulies Fix For: 5.0, 4.7 Attachments: SOLR-5623-nowrap.patch, SOLR-5623-nowrap.patch If an analysis component (tokenizer, filter, etc) gets really into a hissy fit and throws a RuntimeException, the resulting log traffic is less than informative, lacking any pointer to the doc under discussion (in the doc case). It would be more better if there was a catch/try shortstop that logged this more informatively. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5623) Better diagnosis of RuntimeExceptions in analysis
[ https://issues.apache.org/jira/browse/SOLR-5623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13892309#comment-13892309 ] ASF subversion and git services commented on SOLR-5623: --- Commit 1564831 from hoss...@apache.org in branch 'dev/trunk' [ https://svn.apache.org/r1564831 ] SOLR-5623: revert r1564739, shalin already fixed the bug that caused these failures, but Uwe didn't know that Better diagnosis of RuntimeExceptions in analysis - Key: SOLR-5623 URL: https://issues.apache.org/jira/browse/SOLR-5623 Project: Solr Issue Type: Bug Affects Versions: 4.6.1 Reporter: Benson Margulies Assignee: Benson Margulies Fix For: 5.0, 4.7 Attachments: SOLR-5623-nowrap.patch, SOLR-5623-nowrap.patch If an analysis component (tokenizer, filter, etc) gets really into a hissy fit and throws a RuntimeException, the resulting log traffic is less than informative, lacking any pointer to the doc under discussion (in the doc case). It would be more better if there was a catch/try shortstop that logged this more informatively. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5623) Better diagnosis of RuntimeExceptions in analysis
[ https://issues.apache.org/jira/browse/SOLR-5623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13892313#comment-13892313 ] ASF subversion and git services commented on SOLR-5623: --- Commit 1564834 from hoss...@apache.org in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1564834 ] SOLR-5623: revert r1564739, shalin already fixed the bug that caused these failures, but Uwe didn't know that (merge r1564831) Better diagnosis of RuntimeExceptions in analysis - Key: SOLR-5623 URL: https://issues.apache.org/jira/browse/SOLR-5623 Project: Solr Issue Type: Bug Affects Versions: 4.6.1 Reporter: Benson Margulies Assignee: Benson Margulies Fix For: 5.0, 4.7 Attachments: SOLR-5623-nowrap.patch, SOLR-5623-nowrap.patch If an analysis component (tokenizer, filter, etc) gets really into a hissy fit and throws a RuntimeException, the resulting log traffic is less than informative, lacking any pointer to the doc under discussion (in the doc case). It would be more better if there was a catch/try shortstop that logged this more informatively. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5623) Better diagnosis of RuntimeExceptions in analysis
[ https://issues.apache.org/jira/browse/SOLR-5623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13890835#comment-13890835 ] Hoss Man commented on SOLR-5623: +1 Better diagnosis of RuntimeExceptions in analysis - Key: SOLR-5623 URL: https://issues.apache.org/jira/browse/SOLR-5623 Project: Solr Issue Type: Bug Reporter: Benson Margulies Assignee: Benson Margulies If an analysis component (tokenizer, filter, etc) gets really into a hissy fit and throws a RuntimeException, the resulting log traffic is less than informative, lacking any pointer to the doc under discussion (in the doc case). It would be more better if there was a catch/try shortstop that logged this more informatively. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5623) Better diagnosis of RuntimeExceptions in analysis
[ https://issues.apache.org/jira/browse/SOLR-5623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13891512#comment-13891512 ] Benson Margulies commented on SOLR-5623: trunk patch 1564584. Better diagnosis of RuntimeExceptions in analysis - Key: SOLR-5623 URL: https://issues.apache.org/jira/browse/SOLR-5623 Project: Solr Issue Type: Bug Reporter: Benson Margulies Assignee: Benson Margulies If an analysis component (tokenizer, filter, etc) gets really into a hissy fit and throws a RuntimeException, the resulting log traffic is less than informative, lacking any pointer to the doc under discussion (in the doc case). It would be more better if there was a catch/try shortstop that logged this more informatively. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5623) Better diagnosis of RuntimeExceptions in analysis
[ https://issues.apache.org/jira/browse/SOLR-5623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13886068#comment-13886068 ] Benson Margulies commented on SOLR-5623: [~hossman_luc...@fucit.org] have you looked at my revs? Better diagnosis of RuntimeExceptions in analysis - Key: SOLR-5623 URL: https://issues.apache.org/jira/browse/SOLR-5623 Project: Solr Issue Type: Bug Reporter: Benson Margulies Assignee: Benson Margulies If an analysis component (tokenizer, filter, etc) gets really into a hissy fit and throws a RuntimeException, the resulting log traffic is less than informative, lacking any pointer to the doc under discussion (in the doc case). It would be more better if there was a catch/try shortstop that logged this more informatively. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5623) Better diagnosis of RuntimeExceptions in analysis
[ https://issues.apache.org/jira/browse/SOLR-5623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875702#comment-13875702 ] Benson Margulies commented on SOLR-5623: OK, pushed changes as per remarks. Better diagnosis of RuntimeExceptions in analysis - Key: SOLR-5623 URL: https://issues.apache.org/jira/browse/SOLR-5623 Project: Solr Issue Type: Bug Reporter: Benson Margulies If an analysis component (tokenizer, filter, etc) gets really into a hissy fit and throws a RuntimeException, the resulting log traffic is less than informative, lacking any pointer to the doc under discussion (in the doc case). It would be more better if there was a catch/try shortstop that logged this more informatively. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5623) Better diagnosis of RuntimeExceptions in analysis
[
https://issues.apache.org/jira/browse/SOLR-5623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875045#comment-13875045
]
Hoss Man commented on SOLR-5623:
bq. In general whats happening here is not happening inside indexwriter, its
happening in the analysis chain. I think solr or other applications is the
right place to add additional debugging information (such as a unique ID for
the document) because only it has that additional context to ensure its what is
useful to get to the bottom.
Agreed ... but it would be nice if (in addition to application concepts like
the uniqueKey of the doc) the exceptions could be annotated with information
like what field name was associated with the runtime exception -- I don't think
there's currently anyway for code above IndexWriter to do that is there?
The flip side though is that having this kind of logic in IndexWriter (or
DocInverterPerField, or wherever under the covers) to wrap any arbitrary
Runtime exception (maybe IllegalArgumentEx, maybe ArrayOutOfBounds, etc...)
with some kind of generic LuceneAnalysisRuntimeException that contains a
getField method seems like a really bad idea since it would hide (via
wrapping) the true underlying exception type. We do this a lot in Solr since
ultimately we're always going to need to propagate a SolrException with a
status code to the remote client -- but i don't think anything else in Lucene
Core wraps exceptions like this.
I don't know of any sane way to deal with this kind of problem -- just pointing
out that knowing the field name that caused the problem seems equally important
to knowing the uniqueKey. (in case anybody else has any good ideas).
In any case, we can make progress on the fairly easy part: annotating with the
unqieuKey in Solr...
Benson, comments on your current pull request:
* there's some cut/paste comments/javadocs in the test configs/classes that
need corrected
* considering things like SOLR-4992, i don't think adding a catch (Throwable
t) is a good idea ... i would constrain this to RuntimeException
* take a look at AddUpdateCommand.getPrintableId
* your try/catch/wrap block is only arround one code path that calls
IndexWriter.updateDocument\* ... there are others. The most
straightforward/safe approach would probably be to refactor the entire
{{addDoc(AddUpdateCommand)}} method along the lines of...{code}
public int addDoc(AddUpdateCommand cmd) throws IOException {
try {
return addDocInternal(cmd)
} catch (...) {
...
}
}
// nocommit: javadocs as to purpose
private int addDocInternal(AddUpdateCommand cmd) throws IOException {
...
}
{code}
* this recipe is a bit cleaner for the type of assertion you are doing...{code}
try {
doSomethingThatShouldThrowAndException();
fail(didn't get expected exception);
} catch (ExpectedExceptionType e) {
assertStuffAbout(e);
}
{code}
Better diagnosis of RuntimeExceptions in analysis
-
Key: SOLR-5623
URL: https://issues.apache.org/jira/browse/SOLR-5623
Project: Solr
Issue Type: Bug
Reporter: Benson Margulies
If an analysis component (tokenizer, filter, etc) gets really into a hissy
fit and throws a RuntimeException, the resulting log traffic is less than
informative, lacking any pointer to the doc under discussion (in the doc
case). It would be more better if there was a catch/try shortstop that logged
this more informatively.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5623) Better diagnosis of RuntimeExceptions in analysis
[ https://issues.apache.org/jira/browse/SOLR-5623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13868265#comment-13868265 ] Benson Margulies commented on SOLR-5623: [~hossman_luc...@fucit.org] https://github.com/apache/lucene-solr/pull/18 shows the failing test case. How do I make a test that asserts facts about logging? I can certainly use this to make some improvements to the logging, but I don't know how to automate proving that I did it? Better diagnosis of RuntimeExceptions in analysis - Key: SOLR-5623 URL: https://issues.apache.org/jira/browse/SOLR-5623 Project: Solr Issue Type: Bug Reporter: Benson Margulies If an analysis component (tokenizer, filter, etc) gets really into a hissy fit and throws a RuntimeException, the resulting log traffic is less than informative, lacking any pointer to the doc under discussion (in the doc case). It would be more better if there was a catch/try shortstop that logged this more informatively. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5623) Better diagnosis of RuntimeExceptions in analysis
[ https://issues.apache.org/jira/browse/SOLR-5623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13868323#comment-13868323 ] Hoss Man commented on SOLR-5623: bq. How do I make a test that asserts facts about logging? That's what i was mentioning in the email thread -- i don't know of anyway to assert that something is logged, but you can assert that adding a document results in an exception being thrown to the client which matches a specified expression (which is probably the most important thing in this situation anyway) and then that should also result in the exception being logged. There's probably some way we could setup a MockLogListener or something in the test framework, and tell it what to pay attention to and assert that it sees those exceptions after the appropriate client calls -- but we don't have anything like that and of the top of my head i don't know how to do it. Better diagnosis of RuntimeExceptions in analysis - Key: SOLR-5623 URL: https://issues.apache.org/jira/browse/SOLR-5623 Project: Solr Issue Type: Bug Reporter: Benson Margulies If an analysis component (tokenizer, filter, etc) gets really into a hissy fit and throws a RuntimeException, the resulting log traffic is less than informative, lacking any pointer to the doc under discussion (in the doc case). It would be more better if there was a catch/try shortstop that logged this more informatively. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5623) Better diagnosis of RuntimeExceptions in analysis
[ https://issues.apache.org/jira/browse/SOLR-5623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13868325#comment-13868325 ] Benson Margulies commented on SOLR-5623: OK. Does it make sense to adopt the idea that 'if there is an ID field with a value, include that in the exception? Better diagnosis of RuntimeExceptions in analysis - Key: SOLR-5623 URL: https://issues.apache.org/jira/browse/SOLR-5623 Project: Solr Issue Type: Bug Reporter: Benson Margulies If an analysis component (tokenizer, filter, etc) gets really into a hissy fit and throws a RuntimeException, the resulting log traffic is less than informative, lacking any pointer to the doc under discussion (in the doc case). It would be more better if there was a catch/try shortstop that logged this more informatively. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5623) Better diagnosis of RuntimeExceptions in analysis
[ https://issues.apache.org/jira/browse/SOLR-5623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13868347#comment-13868347 ] Benson Margulies commented on SOLR-5623: [~rcmuir] The identity of the field we are processing is known down in Lucene core. What do you think about wrapping generic Throwables in org.apache.lucene.index.DocInverterPerField.processFields in some specific runtime exception that carries the field name? Then I can in turn make it into a Solr exception in DirectUpdateHandler2. Better diagnosis of RuntimeExceptions in analysis - Key: SOLR-5623 URL: https://issues.apache.org/jira/browse/SOLR-5623 Project: Solr Issue Type: Bug Reporter: Benson Margulies If an analysis component (tokenizer, filter, etc) gets really into a hissy fit and throws a RuntimeException, the resulting log traffic is less than informative, lacking any pointer to the doc under discussion (in the doc case). It would be more better if there was a catch/try shortstop that logged this more informatively. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5623) Better diagnosis of RuntimeExceptions in analysis
[ https://issues.apache.org/jira/browse/SOLR-5623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13868354#comment-13868354 ] Robert Muir commented on SOLR-5623: --- Benson I don't know about that, its pretty tricky. Especially this particular place in the code, I think we should keep as simple as possible and not be messing with such exceptions. There is already plenty complexity here (aborting vs non-aborting exceptions) and so on for lucene to deal with. In general whats happening here is not happening inside indexwriter, its happening in the analysis chain. I think solr or other applications is the right place to add additional debugging information (such as a unique ID for the document) because only it has that additional context to ensure its what is useful to get to the bottom. Better diagnosis of RuntimeExceptions in analysis - Key: SOLR-5623 URL: https://issues.apache.org/jira/browse/SOLR-5623 Project: Solr Issue Type: Bug Reporter: Benson Margulies If an analysis component (tokenizer, filter, etc) gets really into a hissy fit and throws a RuntimeException, the resulting log traffic is less than informative, lacking any pointer to the doc under discussion (in the doc case). It would be more better if there was a catch/try shortstop that logged this more informatively. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5623) Better diagnosis of RuntimeExceptions in analysis
[ https://issues.apache.org/jira/browse/SOLR-5623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13868359#comment-13868359 ] Benson Margulies commented on SOLR-5623: OK, we can log and return the ID and not the field name, and that's already an improvement, so I'll stick with that. Better diagnosis of RuntimeExceptions in analysis - Key: SOLR-5623 URL: https://issues.apache.org/jira/browse/SOLR-5623 Project: Solr Issue Type: Bug Reporter: Benson Margulies If an analysis component (tokenizer, filter, etc) gets really into a hissy fit and throws a RuntimeException, the resulting log traffic is less than informative, lacking any pointer to the doc under discussion (in the doc case). It would be more better if there was a catch/try shortstop that logged this more informatively. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5623) Better diagnosis of RuntimeExceptions in analysis
[ https://issues.apache.org/jira/browse/SOLR-5623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13868364#comment-13868364 ] Robert Muir commented on SOLR-5623: --- I'm not completely opposed to it for the record, i'm just saying i dont know about it. At the very least ill say, i'd be less opposed in trunk because the logic there it is simpler (due to java7 try-with: no boolean success/success2 heh). Still, as an API i dont like the fact that we'd be wrapping some specific exception with a bogus-generic one... Better diagnosis of RuntimeExceptions in analysis - Key: SOLR-5623 URL: https://issues.apache.org/jira/browse/SOLR-5623 Project: Solr Issue Type: Bug Reporter: Benson Margulies If an analysis component (tokenizer, filter, etc) gets really into a hissy fit and throws a RuntimeException, the resulting log traffic is less than informative, lacking any pointer to the doc under discussion (in the doc case). It would be more better if there was a catch/try shortstop that logged this more informatively. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5623) Better diagnosis of RuntimeExceptions in analysis
[
https://issues.apache.org/jira/browse/SOLR-5623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13868368#comment-13868368
]
Benson Margulies commented on SOLR-5623:
Here's another ouch.
Doc for Document#get says:
{code}
/** Returns the string value of the field with the given name if any exist in
* this document, or null. If multiple fields exist with this name, this
* method returns the first value added. If only binary fields with this name
* exist, returns null.
* For {@link IntField}, {@link LongField}, {@link
* FloatField} and {@link DoubleField} it returns the string value of the
number. If you want
* the actual numeric field instance back, use {@link #getField}.
*/
{code}
But given a Solr field like the following, with a value of '1', I end up with
\u0080\u\u0001. It doesn't appear to be an IntField, just a Field. What am
I missing?
{code}
field name=id type=sint indexed=true stored=true
multiValued=false/
{code}
Better diagnosis of RuntimeExceptions in analysis
-
Key: SOLR-5623
URL: https://issues.apache.org/jira/browse/SOLR-5623
Project: Solr
Issue Type: Bug
Reporter: Benson Margulies
If an analysis component (tokenizer, filter, etc) gets really into a hissy
fit and throws a RuntimeException, the resulting log traffic is less than
informative, lacking any pointer to the doc under discussion (in the doc
case). It would be more better if there was a catch/try shortstop that logged
this more informatively.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5623) Better diagnosis of RuntimeExceptions in analysis
[ https://issues.apache.org/jira/browse/SOLR-5623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13868374#comment-13868374 ] Benson Margulies commented on SOLR-5623: Back to the exception decoration problem: There's a general design puzzle here: an outer function knows something that an inner function does not, and the catcher of the exception wants to know both. I share your distaste for the obvious Java solution of endless exception wrapping. Another option is to log, but does the Lucene code log things? I'm working against trunk because I don't know any better. I'm inclined to stay out at the Solr level for now, and maybe make another patch for this idea in the core later. Better diagnosis of RuntimeExceptions in analysis - Key: SOLR-5623 URL: https://issues.apache.org/jira/browse/SOLR-5623 Project: Solr Issue Type: Bug Reporter: Benson Margulies If an analysis component (tokenizer, filter, etc) gets really into a hissy fit and throws a RuntimeException, the resulting log traffic is less than informative, lacking any pointer to the doc under discussion (in the doc case). It would be more better if there was a catch/try shortstop that logged this more informatively. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5623) Better diagnosis of RuntimeExceptions in analysis
[ https://issues.apache.org/jira/browse/SOLR-5623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13868400#comment-13868400 ] Benson Margulies commented on SOLR-5623: I think the patch request is now good to go, again sticking with a Solr change and considering a Lucene change later on. Better diagnosis of RuntimeExceptions in analysis - Key: SOLR-5623 URL: https://issues.apache.org/jira/browse/SOLR-5623 Project: Solr Issue Type: Bug Reporter: Benson Margulies If an analysis component (tokenizer, filter, etc) gets really into a hissy fit and throws a RuntimeException, the resulting log traffic is less than informative, lacking any pointer to the doc under discussion (in the doc case). It would be more better if there was a catch/try shortstop that logged this more informatively. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
