Oh right, and here's the error I get over HTTP when I run the second
command:
> PUT /riak/test-search/doc9?returnbody=true HTTP/1.1
> User-Agent: curl/7.27.0
> Host: riak.lumi:8098
> Accept: */*
> Content-Type: application/json
> Content-Length: 39
>
< HTTP/1.1 500 Internal Server Error
< Vary: Accept-Encoding
< Server: MochiWeb/1.1 WebMachine/1.9.2 (someone had painted it blue)
< Date: Wed, 17 Apr 2013 20:42:25 GMT
< Content-Type: text/html
< Content-Length: 1190
<
<html><head><title>500 Internal Server
Error</title></head><body><h1>Internal Server Error</h1>The server
encountered an error while processing this request:<br><pre>{error,
{error,badarg,
[{erlang,iolist_to_binary,
[{hook_crashed,
{riak_search_kv_hook,precommit,error,function_clause}}],
[]},
{wrq,append_to_response_body,2,[{file,"src/wrq.erl"},{line,205}]},
{riak_kv_wm_object,handle_common_error,3,
[{file,"src/riak_kv_wm_object.erl"},{line,998}]},
{webmachine_resource,resource_call,3,
[{file,"src/webmachine_resource.erl"},{line,183}]},
{webmachine_resource,do,3,
[{file,"src/webmachine_resource.erl"},{line,141}]},
{webmachine_decision_core,resource_call,1,
[{file,"src/webmachine_decision_core.erl"},{line,48}]},
{webmachine_decision_core,accept_helper,0,
[{file,"src/webmachine_decision_core.erl"},{line,606}]},
{webmachine_decision_core,decision,1,
[{file,"src/webmachine_decision_core.erl"},{line,577}]}]}}</pre><P><HR><ADDRESS>mochiweb+webmachine
web server</ADDRESS></body></html>
On Wed, Apr 17, 2013 at 4:51 PM, Rob Speer <r...@luminoso.com> wrote:
> 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'
>
>
> 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.
>
> 16:42:24 <{mochiweb_acceptor,init,3}> {riak_solr_xml_xform,xform,
> [<<"<?xml version=\"1.0\"
> ?><delete><id>uuid-10f1a788ead64125bd7251ffc5308882</id></delete>">>]}
>
> 16:42:24 <{mochiweb_acceptor,init,3}> {riak_solr_xml_xform,xform,1} -> {ok,
>
> delete,
>
> [{<<"id">>,
>
> <<"uuid-10f1a788ead64125bd7251ffc5308882">>}]}
>
>
>
>
> On Tue, Apr 16, 2013 at 2:55 PM, Ryan Zezeski <rzeze...@basho.com> wrote:
>
>> Rob,
>>
>> I don't know what the exact data is. The thing is that it doesn't seem to
>>> cause an error on the client side; it just shows up in the server logs to
>>> be noticed later.
>>>
>>
>> A non-2XX response will be returned. Verify that the response is 200.
>> If it isn't log an error in your app with the exact data passed.
>>
>>
>>> I have a suspicion, though. Is it possible that when I set one of the
>>> search fields to the empty string, some protocol along the way turns that
>>> into the empty list, which then fails the type-check?
>>>
>>
>> This is my initial suspicion as well. If you can figure out the data
>> causing the issue then run that redbug line while inserting the data. From
>> the output of that I should be able to figure out what is happening.
>>
>> -Z
>>
>
>
_______________________________________________
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
