lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Miller (JIRA)" <j...@apache.org>
Subject [jira] Commented: (SOLR-1817) Fix Solr error reporting to work correctly with multicore
Date Wed, 17 Mar 2010 00:35:27 GMT

    [ https://issues.apache.org/jira/browse/SOLR-1817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12846240#action_12846240
] 

Mark Miller commented on SOLR-1817:
-----------------------------------

bq. In either case: why do we need to specificly test for "admin" shouldn't that code path
just fall through regardless of the patch? ie:

Just a simple way to get what I needed working. I use that corename later to get the exceptions
for the core. The second code block below that comes later.
So normally, any core that cannot be found, it will then look for the "" core. This includes
when you goto solr/admin. When you try to go to solr/admin it first tries to
get the admin core - when it cannot find it, it falls into the first block below and gets
the "" core. This is so that it can put it in the request for the jsp to access. Then when
it doesn't find the handler, it just falls through and the jsp ends up handling it. But that
fall through only makes sense when the path is solr/admin. It just didn't hurt when it
was /solr/somecorethatdoesntexist - cause you end up with a 404 anyway - so it doesn't matter
that the wrong core was put into the request.

{code}
if (core == null && errors == null) { 
  corename=""; 
  core=cores.getCore(corename); 
}
{code}


{code}
List<Throwable> errors = cores.getSevereErrors(corename);
{code}

So it doesn't really affect anything if you only drop in there and get the "" if the core
it was looking for was admin. *but* with my current logic - if you have multiple cores, and
the "" core could not load (so it has errors), and you then try and go to solr/corethatdoesnotexist
- if it drops into that first block and sets the corename to "", later it will print the ""
core errors. When you really wanted to see a 404.

So its a simple work around for that - and because that first block was only helpful in the
solr/admin case, it should still work.

I don't know that this is all how things should end up - I think this was all originally kind
of messy - like I said, my first step was getting every url to do what I would expect given
a combination of default cores and other cores, and one or the other not working - and trying
to access cores that don't exist.

Hope thats a better explanation.

> Fix Solr error reporting to work correctly with multicore
> ---------------------------------------------------------
>
>                 Key: SOLR-1817
>                 URL: https://issues.apache.org/jira/browse/SOLR-1817
>             Project: Solr
>          Issue Type: Bug
>    Affects Versions: 1.4
>            Reporter: Mark Miller
>            Priority: Minor
>             Fix For: 1.5
>
>         Attachments: SOLR-1817.patch, SOLR-1817.patch, SOLR-1817.patch
>
>
> Here is a rough patch that attempts to fix how error reporting works with multi-core
(not in terms of logs, but what you see on an http request).
> The patch is not done - more to consider and havn't worked with how this changes solrconfigs
abortOnConfigurationError, but the basics are here.
> If you attempt to access the path of a core that could not load, you are shown the errors
that kept the core from properly loading.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message