[
https://issues.apache.org/jira/browse/SOLR-7441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14514438#comment-14514438
]
Gus Heck commented on SOLR-7441:
--------------------------------
I'm sure there are plenty of more important patches out there, but I'd be
interested to know if anyone has feedback on my patch.
To summarize the patch, I catch any exception, serialize it, toss it in the
maps with a special key (there seem to be a couple of those already). Then I
check for the presence of an exception on the other end, and deserialize/throw
rather than adding to the TreeSet when I find an exception. This is nice since
if you are running the code from your IDE while developing, it shows up in the
local output, and the stack trace becomes clickable (if your ide does that). In
normal production use, it will allow the exception to show up in the logs for
the client that made the request rather than showing up in the log of one of
the N nodes in the cluster. One could event catch and handle different
exceptions from the worker nodes differently. It does however leave the client
with an incomplete set of tuples, so perhaps those should be cleared when an
exception is found, or perhaps there should be best-effort & fail-fast modes,
with best-effort collecting a list of exceptions instead?
An additional enhancement might be to find a way to identify the node on which
this exception occurred and wrap the original exception in an exception with
the node identity information added to the message before serializing it, but I
thought of that after I submitted the patch and haven't actually gone back to
attempt it yet.
> Streaming aggregation error messages could use some improvement
> ---------------------------------------------------------------
>
> Key: SOLR-7441
> URL: https://issues.apache.org/jira/browse/SOLR-7441
> Project: Solr
> Issue Type: Improvement
> Affects Versions: 5.1
> Reporter: Erick Erickson
> Assignee: Joel Bernstein
> Priority: Minor
> Attachments: SOLR-7441.patch, SOLR-7441.patch
>
>
> It's harder than it could be to figure out what the error is when using
> Streaming Aggregation. For instance if you specify an fl parameter for a
> field that doesn't exist it's hard to figure out that's the cause. This is
> true even if you look in the Solr logs.
> I'm not quite sure whether it'd be possible to report this at the client
> level or not, but it seems at least we could repor something more helpful in
> the Solr logs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
