"expected_binaries" error in search

Ryan Zezeski rzezeski at basho.com
Mon Apr 22 17:11:42 EDT 2013


Rob,

I reproduced this at the command line. Here I'm storing two documents, with
> IDs 'doc8' and 'doc9', into a search-enabled bucket named 'test-search'.
>
> # This command works, even though 'lsh' is empty. I believe this is
> because I've never put a field named 'lsh' in this bucket, 'test-search'.
> curl -v -XPUT -H "Content-Type: application/json" -d '{"terms": "empty|en
> string|en test|en", "lsh": "", "segments": "d do doc docs"}' '
> http://riak.lumi:8098/riak/test-search/doc8?returnbody=true'
>
> # However, if I use the empty string for a field that has ever been
> indexed before, *then* I get a crash.
> curl -v -XPUT -H "Content-Type: application/json" -d '{"terms": "",
> "segments": "d do doc docs"}' '
> http://riak.lumi:8098/riak/test-search/doc9?returnbody=true'
>

I copy/pasted your commands and could not reproduce.  Both docs indexed
correctly and were returned when running the following search.  However,
the reason this works is because it's going through KV and using the commit
hook to index.  The error you originally pasted is from data being indexed
via the Riak Search Solr endpoint.  They are two different things.

As it turns out there is a bug(?) in the Solr end-point.  It doesn't like
empty fields.  E.g. if I send the following XML I can reproduce the error.

---
<?xml version="1.0" encoding="UTF-8"?>
<add>
  <doc>
    <id>docA</id>
    <field name="terms">empty|en string|en test|en</field>
    <field name="lsh"></field>
    <field name="segments">d do doc docs</field>
  </doc>
</add>
---

To confirm, here's what I see in the log:

2013-04-22 17:02:56.394 [error]
<0.4452.0>@riak_solr_indexer_wm:malformed_request:37 Unable to parse
request: {expected_binaries,<<"lsh">>,[]}

I filed an issue: https://github.com/basho/riak_search/issues/141



>
> As requested, I typed that redbug command into the Erlang console, and at
> the moment of the crash I get some output. The output baffles me, though.
> The included ID is in the style of ID we use for actual documents, which
> are stored in totally different buckets, and which I didn't refer to at all
> in my testing.
>

My guess is you tested this on the system while other writes were coming
in.  This is what redbug is picking up.

-Z
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.basho.com/pipermail/riak-users_lists.basho.com/attachments/20130422/7ffbebe3/attachment.html>


More information about the riak-users mailing list