Re: The JSON of death

I don't know why this kills Riak (probably shouldn't), but the cause is that it is actually malformed JSON, because it contains a bad UTF-8 sequence. On Thu, Jun 16, 2011 at 6:09 PM, Sylvain Niles wrote: > So we've been encountering some input that has json which is parsed > just fine by ruby but

The JSON of death

So we've been encountering some input that has json which is parsed just fine by ruby but causes riak map reduce to die a horrible death. Running Riak 0.14.2 with json2.js updated to the latest from github (thanks for that suggestion Dan) Steps to reproduce: bin/riak attach Badstuff = <<123,34,

Re: Problem with deleting keys

However this problem does get solved it needs to be backend agnostic and function at the riak level. -Alexander On Thu, Jun 16, 2011 at 14:02, Nico Meyer wrote: > Expiry time in bitcask is a global setting at the moment, not per key. But > even if it where different, this should behave exactly th

Solr Search

Is there a target ETA as to when https://issues.basho.com/show_bug.cgi?id=867 will be resolved? I've really been pushing RiakSearch here for a project but not being able to correctly sort on something other than score is going to prevent us from using it. Thanks, Jason __

Re: Problem with deleting keys

On Thu, Jun 16, 2011 at 10:24 AM, Andrew Thompson wrote: > On Thu, Jun 16, 2011 at 09:24:28AM -0700, David Leimbach wrote: > > Riak doesn't have tombstones (as far as I know) so, you have to make sure > > all your nodes are up to do a delete. This, to me, seems like a > misfeature. > > > > Please

Re: Problem with deleting keys

Expiry time in bitcask is a global setting at the moment, not per key. But even if it where different, this should behave exactly the same as outright deletion (what else is expires now supposed to mean?). Hence the same problems as David observed in the first place. Which makes me think, actu

Re: Problem with deleting keys

Actually it would be nicer if my account would be the whole story, but we may be getting there at some point ;-) Am 16.06.2011 19:25, schrieb Greg Nelson: ...you shrug, replace it with a new one, and then trigger read-repair on all keys that were on the node, then go about your business. ;-)

Re: Problem with deleting keys

Agreed, if that's going to continue to play well with index/search, etc. Is everything involved with those operations distributed as well? On 6/16/2011 12:23 PM, Nico Meyer wrote: I don't see any reason to only restore one node of your cluster. That is the whole point of a replicated datastore

Re: Problem with deleting keys

In 0.14, would it be reasonable for the application to write its own special tombstone marker while at the same time setting an expiry time (== now) on the object? (Assuming bitcask backend...) On Thursday, June 16, 2011 at 10:24 AM, Andrew Thompson wrote: > On Thu, Jun 16, 2011 at 09:24:28AM -

Re: Problem with deleting keys

...you shrug, replace it with a new one, and then trigger read-repair on all keys that were on the node, then go about your business. ;-) On Thursday, June 16, 2011 at 10:23 AM, Nico Meyer wrote: > I don't see any reason to only restore one node of your cluster. > That is the whole point of a re

Re: Problem with deleting keys

On Thu, Jun 16, 2011 at 09:24:28AM -0700, David Leimbach wrote: > Riak doesn't have tombstones (as far as I know) so, you have to make sure > all your nodes are up to do a delete. This, to me, seems like a misfeature. > Please read my other responses in this thread, riak absolutely *does* have t

Re: Problem with deleting keys

I don't see any reason to only restore one node of your cluster. That is the whole point of a replicated datastore. If you loose a node, you shrug, replace it with a new one and go about your business. Am 16.06.2011 19:21, schrieb Les Mikesell: But we expect something different in the case wher

Re: Problem with deleting keys

But we expect something different in the case where a value was updated and the more current value is available on other nodes. Restoring an old value don't matter then. On 6/16/2011 12:07 PM, David Leimbach wrote: Or any data from backup? :-) On Thu, Jun 16, 2011 at 10:04 AM, Nico Meyer ma

Re: Problem with deleting keys

I see you get my point ;-) Am 16.06.2011 19:07, schrieb David Leimbach: Or any data from backup? :-) On Thu, Jun 16, 2011 at 10:04 AM, Nico Meyer > wrote: Yes, but the same is true if you restore a relational DB from backup :-D Am 16.06.2011 18:49,

Re: Problem with deleting keys

On Thu, Jun 16, 2011 at 09:19:51AM -0700, Greg Nelson wrote: > "A tombstone > is put and then an async get is fired off and if the async get finds all > the primary nodes in the preflist are up, it does the delete. If not, > the next time the key is fetched, it does the same check again and will >

Re: Correct way to use pbc/mapreduce to do multiget where keys and bucket names are binary values?

Well that figures. In micro benchmarks (always unreliable), the two are not even close . The 20 separate gets blow the map reduce multiget out of the water. With info likely in os disk cache, we see: 20 gets including forking/joining: ~25ms total single map reduce multiget using erlang: ~250ms

Re: Problem with deleting keys

On Thu, Jun 16, 2011 at 06:09:37PM +0200, Kresten Krab Thorup wrote: > > On Jun 16, 2011, at 5:53 PM, Andrew Thompson wrote: > > > I've also > > added a 'deletedvclock' GET option to change the return behaviour for > > when a tombstone is found to instead return {deleted, VClock} so you can > > s

Re: Problem with deleting keys

Or any data from backup? :-) On Thu, Jun 16, 2011 at 10:04 AM, Nico Meyer wrote: > Yes, but the same is true if you restore a relational DB from backup :-D > > Am 16.06.2011 18:49, schrieb Les Mikesell: > > On 6/16/2011 10:22 AM, Nico Meyer wrote: >> >>> >>> >> >> >> Btw, this whole issue is n

Re: Problem with deleting keys

On Thu, Jun 16, 2011 at 9:49 AM, Les Mikesell wrote: > On 6/16/2011 10:22 AM, Nico Meyer wrote: > >> >> > > > Btw, this whole issue is not really Riak specific. It is essentially a >> consequence of eventual consistency, where you have to make a trade off >> between the amount of bookkeeping inf

Re: Problem with deleting keys

Yes, but the same is true if you restore a relational DB from backup :-D Am 16.06.2011 18:49, schrieb Les Mikesell: On 6/16/2011 10:22 AM, Nico Meyer wrote: Btw, this whole issue is not really Riak specific. It is essentially a consequence of eventual consistency, where you have to make a

Re: Correct way to use pbc/mapreduce to do multiget where keys and bucket names are binary values?

Thanks for the info. As a note, I found that the javascript function was having trouble return binary values. I followed your suggestion and am now using the following function. (Here for others.) -module(multiget). -export([key_value/3]). key_value({error, notfound}, _KD, _) -> none; key_

Re: Problem with deleting keys

On 6/16/2011 10:22 AM, Nico Meyer wrote: Btw, this whole issue is not really Riak specific. It is essentially a consequence of eventual consistency, where you have to make a trade off between the amount of bookkeeping information you want to store and the maximum amount of time (or number o

Re: Problem with deleting keys

On Thu, Jun 16, 2011 at 2:57 AM, Nico Meyer wrote: > Hello David, > > this behaviour is quite expected if you think about how Riak works. > Assuming you use the default replication factor of n=3, each key is stored > on all of your three nodes. If you delete a key while one node (let's call > it

Re: Problem with deleting keys

"A tombstone is put and then an async get is fired off and if the async get finds all the primary nodes in the preflist are up, it does the delete. If not, the next time the key is fetched, it does the same check again and will do the delete then if the downed node is up." What if the key is never

Re: Problem with deleting keys

Sorry, didn't see your mail in time. This is essentially what i was talking about in my other mail. So all is good then :-). Cheers, Nico Am 16.06.2011 17:53, schrieb Andrew Thompson: On Thu, Jun 16, 2011 at 08:40:45AM -0700, Greg Nelson wrote: Well, it is kind of Riak specific. An impleme

Re: Problem with deleting keys

If all primary nodes are up, the problem is nonexistent. You could certainly implement any number of solutions inside Riak, but I cannot see that there is 'one right way(tm)' to do it. In such cases I am all in favor of providing all the needed primitives to implement whatever is best for your a

Re: Problem with deleting keys

On Jun 16, 2011, at 5:53 PM, Andrew Thompson wrote: > I've also > added a 'deletedvclock' GET option to change the return behaviour for > when a tombstone is found to instead return {deleted, VClock} so you can > safely override a tombstone, instead of triggering a merge (or creating > siblings).

Re: Problem with deleting keys

On Thu, Jun 16, 2011 at 08:40:45AM -0700, Greg Nelson wrote: > Well, it is kind of Riak specific. An implementation that treated DELETEs > like PUTs (tombstones w/ vector clocks for ordering), then this would not be > an issue, right? When no primary nodes are down, the tombstones can be > physi

Re: Problem with deleting keys

Well, it is kind of Riak specific. An implementation that treated DELETEs like PUTs (tombstones w/ vector clocks for ordering), then this would not be an issue, right? When no primary nodes are down, the tombstones can be physically deleted on the backend. A logical delete could never reappear i

Re: Problem with deleting keys

The problem with unreachable nodes still remains, since you don't know how long they will be gone. The only 'safe' minimum time to keep deleted values is forever. This can be easily emulated in the application layer by using a special value (or use Riak metadata for example). So it essentially a

Re: Problem with deleting keys

...when doing a delete, Riak actually stores a "deleted" record, but then it is too eagerly deleting it for real after that. There should be a configurable "zombie time" between requesting a delete and the "deleted record" being deleted for real; so that the deleted record's vector clock will sh

Re: Correct way to use pbc/mapreduce to do multiget where keys and bucket names are binary values?

Hi Jaques, Sorry for the slow reply. I think this one just slipped by me. Ok. answers inline below: On 14 Jun 2011, at 18:26, Jacques wrote: > Does anybody have any insight on my questions below? > > Thanks, > Jacques > > > On Tue, Jun 7, 2011 at 6:12 PM, Jacques wrote: > I've been workin

Re: Problem with deleting keys

Hello David, this behaviour is quite expected if you think about how Riak works. Assuming you use the default replication factor of n=3, each key is stored on all of your three nodes. If you delete a key while one node (let's call it A) is down, the key is deleted from the two nodes that are s