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. Is this easily replicable on a new cluster? 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. >> >> On Sun, Nov 3, 2013 at 7:40 PM, Toby Corkindale >> <[email protected]> wrote: >>> >>> On 01/11/13 14:04, Toby Corkindale wrote: >>>> >>>> >>>> Hi, >>>> I have around 5000 keys which just won't die. >>>> No matter how many times I delete them, they still show up in the 2i >>>> $bucket=_ index. >>>> >>>> Actually attempting to retrieve the keys results in a not-found - even >>>> >>>> if I've requested that tombstones be returned. >>>> >>>> I'm interested to know what is going on here? >>> >>> >>> >>> Anyone? >>> >>> Should I report this as a bug against 1.4.2? >>> >>> >>> _______________________________________________ >>> riak-users mailing list >>> [email protected] >>> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com > > _______________________________________________ riak-users mailing list [email protected] http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
