Hi Evan,
Thanks -- that resulted in a list that looks like:
{ok,[<<128,0,0,0>>,
<<128,1,0,0>>,
<<128,2,0,0>>,
<<128,3,0,0>>,
<<128,4,0,0>>,
<<128,5,0,0>>,
... etc ...
That confirms my suspicions that the Java client is mangling the keys
while processing them as unicode strings, because if I print out the
values of the characters of the string there, I get:
65533,0,0,0
65533,1,0,0
65533,2,0,0
etc
On 06/11/13 15:57, Evan Vigil-McClanahan wrote:
Since we're talking about indices:
you can attach to the console with `riak attach` (then detach with
control-d (1.3 and below) or control-c (1.4+) note that this is can
kill your node on older versions, so be careful to use the correct
one). Then edit the below to match up with your query, and then paste
it in (note that all the period below are intentional and required):
{ok, C} = riak:local_client().
{ok, Query} = riak_index:to_index_query(<<"fieldname_bin">>,
[<<"begin_point">>, <<"end_point">>]).
C:get_index(<<"bucket_name">>, Query).
If you need to adjust the Query because of a typo or something, just
do f(Query). to unbind it.
fieldname_bin is the binary index or whatever you're searching for. If
you were using $key, your Query might look something like this:
([email protected])17> {ok, Query} =
riak_index:to_index_query(<<"$key">>, [<<"">>,
<<255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255>>]).
{ok,{range,<<"$key">>,<<>>,<<"ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ">>}}
([email protected])20> C:put(riak_object:new(<<"test">>, <<"b">>, <<"c">>)).
ok
([email protected])21> C:get_index(<<"test">>, Query).
{ok,[<<"b">>]}
This should get you a list of keys in erlang binary format, which will
look something like <<"asdasdasd">> or <<44,0,32,130>> if there are
unprintable characters in the string.
On Tue, Nov 5, 2013 at 4:40 PM, Toby Corkindale
<[email protected]> wrote:
On 06/11/13 11:30, Evan Vigil-McClanahan wrote:
You can replace int_to_bin with int_to_str to make it easier to debug
in the future, I suppose. I am not sure how to get them to be fetched
as bytes, without may altering the client.
You could just attach to the console and run whatever listing command
you're running there, which would give you the answer as unfiltered
erlang binaries, which are easy to understand.
Ah, I'm really not familiar enough with Erlang and Riak to be doing that.
Which API applies to console commands? I'll take a look. (Is it just the
same as the Erlang client?)
Is this easily replicable on a new cluster?
I think it should be -- the only difference over default configuration is
that LevelDB is configured as the default backend.
Run basho_bench with the pbc-client test to generate the initial keys and
you should be set.
T
On Tue, Nov 5, 2013 at 4:17 PM, Toby Corkindale
<[email protected]> wrote:
Hi Evan,
These keys were originally created by basho-bench, using:
{key_generator, {int_to_bin, {uniform_int, 10000}}}.
Of the 10k keys, it seems half could be removed, but not the other half.
Now I've tried storing keys with the same key as the un-deleteable ones,
waiting a minute, and then deleting them again.. this isn't seeming to
help!
I don't know if it's significant, but I'm working with the Java client
here
(protocol buffers). I note that the bad keys are basically just bytes,
not
actual ascii strings, and they do contain nulls.
Actually, here's something I just noticed -- the keys I'm getting from
the
index are repeating! It's the same 39 keys, repeated 128 times.
O.o
Are there any known bugs in the PBC interface when it comes to binary
keys?
I know the HTTP interface just crashes out completely.
I'm fetching the keys in a manner that returns strings; is there a way to
fetch them as bytes? Maybe that would work better; I'm wondering if the
client is attempting to convert the bytes into unicode strings and
dropping
invalid characters?
On 05/11/13 03:44, Evan Vigil-McClanahan wrote:
Hi Toby.
It's possible, since they're stored separately, that the objects were
deleted but the indices were left in place because of some error (e.g.
the operation failed for some reason between the object removal and
the index removal). One of the things on the feature list for the
next release is AAE of index values, which should take care of this
case. This is really rare, but not unknown. It'd be interesting to
know how you ended up with so many.
In the mean time, the only way I can think of to get rid of them
(other than deleting them from the console, which would require taking
nodes down and a lot of manual effort), would be to write another
value that would have the same index, then delete it, which should
normally succeed.
I'll ask around to see if there is anything that might work better.
_______________________________________________
riak-users mailing list
[email protected]
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
