Re: Delayed events processing / queue (anti-)pattern

Yeah that's the one :) sorry, was on my phone and didn't want to look up the exact name. Cheers, Thunder On Mar 27, 2015 6:17 AM, "Brice Dutheil" wrote: > Would it help here to not actually issue a delete statement but instead > use date based compaction and a dynamically calculated ttl that is

Re: Delayed events processing / queue (anti-)pattern

Would it help here to not actually issue a delete statement but instead use date based compaction and a dynamically calculated ttl that is some safe distance in the future from your key? I’m not sure about about this part *date based compaction*, do you mean DateTieredCompationStrategy ? Anyway w

Re: Delayed events processing / queue (anti-)pattern

Interesting thought, that should work indeed, I'll evaluate both options and provide an update here once I have results. Best regards, Robin Verlangen *Chief Data Architect* W http://www.robinverlangen.nl E ro...@us2.nl *What is CloudPelican? * Discla

Re: Delayed events processing / queue (anti-)pattern

Would it help here to not actually issue a delete statement but instead use date based compaction and a dynamically calculated ttl that is some safe distance in the future from your key? Just a thought. -Thunder On Mar 25, 2015 11:07 AM, "Robert Coli" wrote: > On Wed, Mar 25, 2015 at 12:45 AM,

Re: Delayed events processing / queue (anti-)pattern

On Wed, Mar 25, 2015 at 12:45 AM, Robin Verlangen wrote: > @Robert: can you elaborate a bit more on the "not ideal" parts? In my case > I will be throwing away the rows (thus the points in time that are "now in > the past"), which will create tombstones which are compacted away. > "Not ideal" is

Re: Delayed events processing / queue (anti-)pattern

Hi there, @Robert: can you elaborate a bit more on the "not ideal" parts? In my case I will be throwing away the rows (thus the points in time that are "now in the past"), which will create tombstones which are compacted away. @DuyHai: that was exactly what I had in mind and from a C* point of vi

Re: Delayed events processing / queue (anti-)pattern

Some ideas I throw in here: "The delay Y will be at least 1 minute, and at most 90 days with a resolution per minute" --> Use the delay (with format MMDDHHMM as integer) as your partition key. Example: today March 24th at 12:00 (201502241200) you need to delay 3 actions, action A in exact 3 d

Re: Delayed events processing / queue (anti-)pattern

On Tue, Mar 24, 2015 at 5:05 AM, Robin Verlangen wrote: > - for every point in the future there are probably hundreds of actions > which have to be processed > - all actions for a point in time will be processed at once (thus not > removing action by action as a typical queue would do) > - once a

Delayed events processing / queue (anti-)pattern

Hi there, I'm working on a project that needs delayed event processing. Example: Today a certain set of conditions X is met, and in 7 days and 12 hours (delay Y) we want to take action Z. The set of conditions X is out of the scope of this problem. The delay Y will be at least 1 minute, and at m