You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by Christopher Schultz <ch...@christopherschultz.net> on 2019/02/12 22:09:55 UTC
Get details about server-side errors
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hello, everyone.
I'm trying to get some information about a (fairly) simple case when a
user is searching using a wide-open query where they can type in
anything they want, including field-names. Of course, it's possible
that they will try to enter a field-name that does not exist and Solr
will complain, like this:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException:
Error from server at http://localhost:8983/solr/users: undefined field
bad_field
(This is what happens when I search my user database for "bad_field:foo"
.)
What is the best way to discover what happened on the server -- from a
code perspective. I can certainly read the above as a human and see
what the problem is. But my users won't understand (exactly) what that
means and I don't always have English-language searching my user databas
e.
Is there a way to check for "was the error a bad field name?" and
"what was the bad field name (or names) detected?"
I looked at javadoc and saw two hopefuls:
1. code -- unfortunately, this is the HTTP response code
2. metadata -- unfortunately, this just returns
{error-class=org.apache.solr.common.SolrException,root-error-class=org.a
pache.solr.common.SolrException},
which is already obvious from the exception type.
Is there something in SolrJ that I'm overlooking, here, or am I
limited to what I can parse out of the exception's "getMessage" string?
Thanks,
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlxjRDIACgkQHPApP6U8
pFihjBAAty32GuiOj8XnwJu55Y9tYWFoQOhNEEJEGmeh1mOv4fxj5D4Rh+7MXTJB
7APLZ5IlNjpGMQ5ygLpfFTrLIEljn/f/a8hRslH/g+H3p/y4EJgeyvbNHaQZdkuh
HlKQ9Z/M6HK+1KGvVNB+9onU3hs7+Tct7TjWO/cZ031CPovDknsYTbOBoLW+tszS
BrsR7up0s7AOWYNkXTu8i0tf6A6nkF8+YJvml2mxNvXUCZrhHh71eL3R+v1/zGun
6yYyGCPm5rO9Pkxq+It4Fo8pkvo3z6k65NAflMXsFcEwWaf/5OmzAjE+TrDdqfeQ
InKDsXj3w6ZOHOEWN/lq8kK1alZUP0i8MQJHpAXzlPL213joP9mN2AeNk7airIXE
hPPmUGKjOVlMDJg6ICJiPVibMjwLBiy68TQJj2DX+dMVeYTQSroPBw5VUJhrxinV
+4y6podDJ6xs+27LxfI8DZ8nGAZP/tFYMCLNIdnhOg682PfaiD3ZiDDu5dJvm871
7N0EK3oCkoAmQ3l7xQNtz/0nDdI5TKSOtI3KBXTY72/8dfZlSoE4kwmBh56SrKQJ
KNfT54Cj329p5qKoNBy1bKxw4GyUx0UbKQo8HyFqzK0gQHlH+23taq5IePhocW12
uUMGSvVUnm/E+C5w3OGLJ96Y6a3aiNUORinkTJePz+sJoUbCIwY=
=Ril5
-----END PGP SIGNATURE-----
Re: Get details about server-side errors
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Jason,
On 2/13/19 07:39, Jason Gerlowski wrote:
> Hey Chris,
>
> Unfortunately I think you covered the main/only options above.
>
> HTTP status code isn't the most useful, but it's worth pointing
> out that there are a few things you can do with it. Some status
> codes are easy to identify and come up with a good message to
> display to your end user e.g. 403 codes. But of course it doesn't
> do anything to help you disambiguate 400 error messages you get.
>
> Error handling has always been one of SolrJ's weak spots. One
> thing people have suggested before is adding some sort of enum to
> error responses that is less ambiguous and easier to interpret
> programmatically, but it's never been picked up. A bit more
> information on SOLR-7170. Feel free to vote for it or chime in
> there if you think that'd be an improvement.
I've added some comments and a proposed fix that meets *my* needs, but
I want to make sure that it will be useful for others (and not just my
specific use-case).
Thanks,
- -chris
> On Tue, Feb 12, 2019 at 5:09 PM Christopher Schultz
> <ch...@christopherschultz.net> wrote:
>>
> Hello, everyone.
>
> I'm trying to get some information about a (fairly) simple case
> when a user is searching using a wide-open query where they can
> type in anything they want, including field-names. Of course, it's
> possible that they will try to enter a field-name that does not
> exist and Solr will complain, like this:
>
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException:
>
>
Error from server at http://localhost:8983/solr/users: undefined field
> bad_field
>
> (This is what happens when I search my user database for
> "bad_field:foo" .)
>
> What is the best way to discover what happened on the server --
> from a code perspective. I can certainly read the above as a human
> and see what the problem is. But my users won't understand
> (exactly) what that means and I don't always have English-language
> searching my user databas e.
>
> Is there a way to check for "was the error a bad field name?" and
> "what was the bad field name (or names) detected?"
>
> I looked at javadoc and saw two hopefuls:
>
> 1. code -- unfortunately, this is the HTTP response code
>
> 2. metadata -- unfortunately, this just returns
> {error-class=org.apache.solr.common.SolrException,root-error-class=org
.a
>
>
pache.solr.common.SolrException},
> which is already obvious from the exception type.
>
> Is there something in SolrJ that I'm overlooking, here, or am I
> limited to what I can parse out of the exception's "getMessage"
> string?
>
> Thanks, -chris
>
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlxkPP8ACgkQHPApP6U8
pFiWkg/+Jd9kHBUc0dYPw9EqkiqjzKDc+/adtERK1TktD/GxYoJaXoKwkNeSt+5C
nOysBDwPoPBZELKmCQVDyyyIKrGfSYw2Pva0fDuMr1fKNoazf6I68/5BusjNf5iL
ETkPuCtGuV6fmETGnK9xLFKE41tTO2u32erWnCcxbBPC858qNhafYfO1UZ3lzjuj
kvuV81RESL4LQvbfx98FKxhgiHJGCV9maY4xFGQeNpI0nc3btnneAGfqUIBxJdhk
RT97PdMF1yZ37aLx4H4wUTtey8hAvJhHSpDg1fw+UDNoGXcefpTwh+KQMqK5D3Cg
QRLzdbzu2BR14saV2tkJ+lKbt0zvurYgOJ2J2CaCz2o44n0P82ll3hCnUCV8WfYW
G70iKi8+8y73jMCOYf5hPO3O5uUJXg3dpGjgaRHHzkoOks2A+3QEWlX0CWEyoO4U
Zg2avKpZNgHj6I5TxyiHD4EkhU3/e3GHbB4neUyvU36zpC6+g54a3CM7HoxWBTUn
NtU2C7jDHJozUnn1S3IGOIdwv5CJ7rJNfgp+m/BOw9xuF1g/Rt7QG68J5KK0/JQE
IL68zAQzWX/1KubIT3Ro5AD/2tR8CKXsCv72U8CdpjSQFFnV+6rFAvS2M7e1D6dm
Lj3yRS4EcKQEgYUKltyWGX2GqnLENGLOUa2wd3aiJY7kiOdNgrA=
=75gr
-----END PGP SIGNATURE-----
Re: Get details about server-side errors
Posted by Jason Gerlowski <ge...@gmail.com>.
Hey Chris,
Unfortunately I think you covered the main/only options above.
HTTP status code isn't the most useful, but it's worth pointing out
that there are a few things you can do with it. Some status codes are
easy to identify and come up with a good message to display to your
end user e.g. 403 codes. But of course it doesn't do anything to help
you disambiguate 400 error messages you get.
Error handling has always been one of SolrJ's weak spots. One thing
people have suggested before is adding some sort of enum to error
responses that is less ambiguous and easier to interpret
programmatically, but it's never been picked up. A bit more
information on SOLR-7170. Feel free to vote for it or chime in there
if you think that'd be an improvement.
But unfortunately there's nothing like this to help you out now, that
I know of at least.
Best,
Jason
On Tue, Feb 12, 2019 at 5:09 PM Christopher Schultz
<ch...@christopherschultz.net> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Hello, everyone.
>
> I'm trying to get some information about a (fairly) simple case when a
> user is searching using a wide-open query where they can type in
> anything they want, including field-names. Of course, it's possible
> that they will try to enter a field-name that does not exist and Solr
> will complain, like this:
>
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException:
> Error from server at http://localhost:8983/solr/users: undefined field
> bad_field
>
> (This is what happens when I search my user database for "bad_field:foo"
> .)
>
> What is the best way to discover what happened on the server -- from a
> code perspective. I can certainly read the above as a human and see
> what the problem is. But my users won't understand (exactly) what that
> means and I don't always have English-language searching my user databas
> e.
>
> Is there a way to check for "was the error a bad field name?" and
> "what was the bad field name (or names) detected?"
>
> I looked at javadoc and saw two hopefuls:
>
> 1. code -- unfortunately, this is the HTTP response code
>
> 2. metadata -- unfortunately, this just returns
> {error-class=org.apache.solr.common.SolrException,root-error-class=org.a
> pache.solr.common.SolrException},
> which is already obvious from the exception type.
>
> Is there something in SolrJ that I'm overlooking, here, or am I
> limited to what I can parse out of the exception's "getMessage" string?
>
> Thanks,
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlxjRDIACgkQHPApP6U8
> pFihjBAAty32GuiOj8XnwJu55Y9tYWFoQOhNEEJEGmeh1mOv4fxj5D4Rh+7MXTJB
> 7APLZ5IlNjpGMQ5ygLpfFTrLIEljn/f/a8hRslH/g+H3p/y4EJgeyvbNHaQZdkuh
> HlKQ9Z/M6HK+1KGvVNB+9onU3hs7+Tct7TjWO/cZ031CPovDknsYTbOBoLW+tszS
> BrsR7up0s7AOWYNkXTu8i0tf6A6nkF8+YJvml2mxNvXUCZrhHh71eL3R+v1/zGun
> 6yYyGCPm5rO9Pkxq+It4Fo8pkvo3z6k65NAflMXsFcEwWaf/5OmzAjE+TrDdqfeQ
> InKDsXj3w6ZOHOEWN/lq8kK1alZUP0i8MQJHpAXzlPL213joP9mN2AeNk7airIXE
> hPPmUGKjOVlMDJg6ICJiPVibMjwLBiy68TQJj2DX+dMVeYTQSroPBw5VUJhrxinV
> +4y6podDJ6xs+27LxfI8DZ8nGAZP/tFYMCLNIdnhOg682PfaiD3ZiDDu5dJvm871
> 7N0EK3oCkoAmQ3l7xQNtz/0nDdI5TKSOtI3KBXTY72/8dfZlSoE4kwmBh56SrKQJ
> KNfT54Cj329p5qKoNBy1bKxw4GyUx0UbKQo8HyFqzK0gQHlH+23taq5IePhocW12
> uUMGSvVUnm/E+C5w3OGLJ96Y6a3aiNUORinkTJePz+sJoUbCIwY=
> =Ril5
> -----END PGP SIGNATURE-----