Live data from Hacker News

Introducing Chronos: A Replacement for Cron

nerds.airbnb.com

31–40 of 63 posts

Re: Introducing Chronos: A Replacement for Cron

#31
post #19

so... cron's a 200kb self contained C program, super simple, does one thing, and does it well. Chronos is built on top of frameworks, needs a few services to run. Certainly it has value, but marketing it as a cron replacement is wrong imo. Chronos is one of these "web-server-service-tool" thingie, but no, it's not cron.

Ding!

Complex, interdependent systems without slack. Now add production pressures. You have all the ingredients of a "Normal Accident"[1].

You should do the opposite of this.

[1] http://en.wikipedia.org/wiki/Normal_Accidents

Re: Introducing Chronos: A Replacement for Cron

#32
post #22

This is almost like saying "A Replacement for Gravity". The benefit having something so simple and singular in function with no dependencies is that there's so little to break. While I appreciate the need for having something with more capability, calling it a "replacement" is a bit facetious. I wish them success and call it an airplane. I'll stick to my hang glider.

What the ops team isn't telling them (DevOps only goes so far) is that there's a cron job on each node which periodically bounces the Chronos processes (and its 50 dependencies) in order to mitigate memory leaks.

Re: Introducing Chronos: A Replacement for Cron

#33
post #26
post #24

Earlier quoted context omitted.

I don't think it's uncommon at all to roll your own job scheduler. I know I've done it at the last two places I have worked, though neither had nearly as fancy a front-end as Chronos appears to have. This particular scheduler (Chronos) looks like a cross between traditional cron and HPC cluster job scheduling systems (a la Sun Grid Engine). It looks like a really cool project.

That depends on what you mean by job scheduling, right? Lots of people would call Resque a job scheduling system, but they still reach for cron when they want to run something every 5 minutes.

I'm about as unaware of the Ruby ecosystem as anyone who regularly reads HN can be, so while I've heard of Resque I'm not really sure where it fits in.

I suppose the definition of job scheduling is dependent on what your workload entails. Is it something you expect to complete in less than a second, a minute, or a big resource intensive HPC job you expect to run for hours? What sorts of dependencies do you have between the things you want to run? Will it run in the main event loop, separate thread, separate process, or on a separate host? I think this will reflect in the tool you choose for scheduling, or cause you to write your own.

It sounds to me like the target workload for Chronos is big slow batch jobs (ETL, data analysis). HPC job schedulers take care of things like resource management (run this job on this machine because it has the lowest load) and dependency management (don't run job b until job a completes), whereas cron handles running periodic tasks and that's about it. Chronos is nice because it looks like it is combining the two and includes a nice looking web based control panel to boot.

Re: Introducing Chronos: A Replacement for Cron

#34
post #27

Earlier quoted context omitted.

Don't suppose you could be convinced to release that scheduling daemon as open source, could you?

Seems like it's all downside and not much upside; it's an unambitious little C project that would mostly give people an opportunity to write blog posts about my C programming style. :) I'm not saying I'll never publish code, just that I've become choosy about it in my advancing years.

We wrote a small C program that serves as a scheduling daemon with Redis; we have a keyspace in Redis that can be used to schedule millisecond-granular periodic or one-shot tasks with a flexible "Chronic"-like specification syntax.

Please open source this. Projects like these are some of the most valuable ones. It's a generalized solution to a very common problem. In fact, what you've described is one of the most elegant designs for this type of problem. It enables any program to schedule other programs just by using a standard Redis interface, for example. Almost every programming language already has a Redis library, meaning it's effectively zero additional work to use your system. Something like your project is sorely needed.

If you want help with documentation, I'm happy to offer it.

Seems like it's all downside and not much upside; it's an unambitious little C project that would mostly give people an opportunity to write blog posts about my C programming style. :)

So was Unix, originally. Those who would deride elegant design due to the choice of language are both short-sighted and mean, and aren't worth worrying about. I know how hard that can be to deal with -- people's negativity tends to bother me a lot, too -- but the world needs more production-grade solutions to real problems. It sounds like your solution has been in use for some time now, and has proven itself effective in the field.

Re: Introducing Chronos: A Replacement for Cron

#35
post #27

Earlier quoted context omitted.

Don't suppose you could be convinced to release that scheduling daemon as open source, could you?

Seems like it's all downside and not much upside; it's an unambitious little C project that would mostly give people an opportunity to write blog posts about my C programming style. :) I'm not saying I'll never publish code, just that I've become choosy about it in my advancing years.

My C is terrible, probably far worse than you perceive yours to be.

I'm sorry you feel that way. I hope you change your mind, advancing years or no.

I'm with Sillysaurus, this is a great solution to a common problem.

Pawn off the code onto me and I'll publish it under my name if you're that worried about getting bad publicity. :P

Re: Introducing Chronos: A Replacement for Cron

#36
post #27

Earlier quoted context omitted.

Seems like it's all downside and not much upside; it's an unambitious little C project that would mostly give people an opportunity to write blog posts about my C programming style. :) I'm not saying I'll never publish code, just that I've become choosy about it in my advancing years.

My C is terrible, probably far worse than you perceive yours to be. I'm sorry you feel that way. I hope you change your mind, advancing years or no. I'm with Sillysaurus, this is a great solution to a common problem. Pawn off the code onto me and I'll publish it under my name if you're that worried about getting bad publicity. :P

I actually feel very good about my C code; C is my native language. I just feel very bad about the Internet. :)

Re: Introducing Chronos: A Replacement for Cron

#37
post #27

Earlier quoted context omitted.

Seems like it's all downside and not much upside; it's an unambitious little C project that would mostly give people an opportunity to write blog posts about my C programming style. :) I'm not saying I'll never publish code, just that I've become choosy about it in my advancing years.

We wrote a small C program that serves as a scheduling daemon with Redis; we have a keyspace in Redis that can be used to schedule millisecond-granular periodic or one-shot tasks with a flexible "Chronic"-like specification syntax. Please open source this. Projects like these are some of the most valuable ones. It's a generalized solution to a very common problem. In fact, what you've described is one of the most ele…

ok ok ok ok but I'm going to do it pseudonymously :).

Re: Introducing Chronos: A Replacement for Cron

#39
post #28
post #21

Earlier quoted context omitted.

> It is hugely more convenient and usable than cron. Once you have it, you immediately spot lots of opportunities to factor systems into scheduled jobs that you might have avoided doing if it meant you had to deal with cron. That's actually pretty interesting. Can you give a few examples that fall out of having a more fine grained (millisecond) resolution?

One example that jumps to mind was that I was able to rip out several hundred lines of fiddley retry and backoff code and replace it with fine-grain-timed repeating events. One advantage to doing this in Redis was that our events aren't just "run a program" (though we can do that); we can also push onto a queue that consumers BLPOP from, or send a pubsub message to a bunch of consumers, or increment counters. later M…

You will get said timer support in Redis 2.8 with the ability to subscribe to keyspace events, which includes keys expiring (with millisecond resolution). https://github.com/antirez/redis/issues/594

  psubscribe __keyevent@0__:expired cron_*

  psetex cron_run-me-in-1s 1000 0
Post reply on HN