So, actually, it turns out that's not exactly the command I typed. I
actually typed:
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'
That is, I left out a pair of quotation marks, so my document was not a
valid JSON document. If I add them in, it works.
This was not the same problem I originally encountered, then, because the
"expected_binaries" error occurred with correct, programmatically-generated
JSON.
On Wed, Apr 17, 2013 at 4:54 PM, Rob Speer <r...@luminoso.com> wrote:
> 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
