Try upgrading to 1.2.2. There was streaming bug that could cause bootstrap
to fail.
On Friday, March 15, 2013, Daning Wang wrote:
> I tried to add new node to ring, it is supposed to be fast in 1.2(256
> tokens on each node), but it is 8+ hours now. after showing bootstraping,
> now cpu usage is
On Sat, Mar 16, 2013 at 3:21 PM, Josh Dzielak wrote:
> Ahh right on. I'm already using wide rows with a similar row key heuristic
> (basically MMDDHH, pulled from the event_time). So I think I'm good
> there but hadn't thought about using a mod instead - any in-practice
> advantages to that?
Ahh right on. I'm already using wide rows with a similar row key heuristic
(basically MMDDHH, pulled from the event_time). So I think I'm good there
but hadn't thought about using a mod instead - any in-practice advantages to
that?
Excited to try composite columns for this- sounds ideal. Ha
On Sat, Mar 16, 2013 at 2:50 PM, Josh Dzielak wrote:
> Thanks Philip. I see where you are coming from; that'd be much simpler and
> avoid these bumps.
>
> The only downside is that I'd have to separately maintain an index of event
> timestamps that reflected when they happened according to the cli
Thanks Philip. I see where you are coming from; that'd be much simpler and
avoid these bumps.
The only downside is that I'd have to separately maintain an index of event
timestamps that reflected when they happened according to the client. That way
when the client asks for 'events last Wednesda
On Sat, Mar 16, 2013 at 2:40 PM, Philip O'Toole wrote:
> It is a mistake, IMHO, to use the timestamp contained within the event
> to generate the time-based UUID. While it will work, it suffers from
> exactly the problem you describe. Instead, use the clock of the host
> system to generate the ti
On Sat, Mar 16, 2013 at 2:31 PM, Ariel Weisberg wrote:
> Hi,
>
> This has been solved a couple of times, and always pretty much the same way.
> Encode the id of the worker generating the id into the timestamp, and as you
> mentioned, maintain a counter for each millisecond.
>
> https://github.com/
On Sat, Mar 16, 2013 at 2:24 PM, Josh Dzielak wrote:
> I have a system where a client sends me arbitrary JSON events containing a
> timestamp at millisecond resolution. The timestamp is used to generate
> column names of type TimeUUIDType.
>
> The problem I run into is this - if I client sends me
Thanks Ariel. That works in the case where the timestamp is always increasing,
i.e. the monotonically increasing clock.
The problem for me is that the timestamps can be provided by the client, and
they may be in the past or the future (I only generate the timestamp using the
current time if n
Hi,
This has been solved a couple of times, and always pretty much the same
way. Encode the id of the worker generating the id into the timestamp,
and as you mentioned, maintain a counter for each millisecond.
[1]https://github.com/twitter/snowflake
[2]https://github.com/VoltDB/voltdb/blob/m
I have a system where a client sends me arbitrary JSON events containing a
timestamp at millisecond resolution. The timestamp is used to generate column
names of type TimeUUIDType.
The problem I run into is this - if I client sends me 2 events with the same
timestamp, the TimeUUID that gets gen
11 matches
Mail list logo
