This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-11-04
Channels
- # beginners (46)
- # boot (65)
- # cider (8)
- # cljs-dev (5)
- # cljsrn (4)
- # clojure (50)
- # clojure-conj (2)
- # clojure-france (1)
- # clojure-greece (18)
- # clojure-russia (8)
- # clojure-spec (39)
- # clojure-uk (36)
- # clojurescript (36)
- # clr (16)
- # component (2)
- # cursive (6)
- # datascript (3)
- # datomic (31)
- # devcards (2)
- # editors-rus (1)
- # emacs (15)
- # events (2)
- # figwheel (1)
- # funcool (24)
- # garden (3)
- # hoplon (22)
- # instaparse (15)
- # leiningen (3)
- # luminus (4)
- # om (59)
- # onyx (24)
- # overtone (1)
- # pedestal (3)
- # planck (18)
- # prelude (1)
- # protorepl (2)
- # re-frame (5)
- # rum (1)
- # sql (1)
- # uncomplicate (1)
- # untangled (66)
- # vim (18)
- # yada (4)
Hey guys 🙂 Is there a way to make an output task (writing to datomic), just keep retrying till it succeeds? The issue we have is that our transactor occasionally fails over, or transactions time out. What happens is the segment is retried, but it's retried from the back of the queue, so it will possibly overwrite values calculated by newer tasks, since we always use the datomic database at the time of the datom we are processing. Basically, I need to output task to keep retrying a failed write, until it succeeds, because if datomic is down we are screwed anyway till's back up.
Or is there a way to keep it retrying at the front of the queue, before anything else?
@greywolve There’s not a way to do front-retries because ordering isn’t guaranteed. Suppose you could modify the output plugin to spin-retry on failure. How many times do you retry? How long is too long to wait?
I think one could violate progress by accident doing that. Perhaps we could think of a way to handle this in the application design?
Tutorial progress update: https://colinhicks.github.io/onyx-blueprint/resources/public/tutorial.html
@colinhicks Ohhhh man. This is amazing.
Dude, this is incredible work
I am more than happy to jump on board and write a section. Mannn.
Thanks! And go for it! For content, I'm mostly just clipping together your work in learn-onyx and the user guide.
This is great. Do you have plans for things you want to do next so we don’t cross over?
Mind if I tweet the link out (noting that it’s WIP) to stir some contributors? 🙂
I'll put up an issue for a content outline. Totally fine to tweet.
Do you have a Twitter handle? I see many Colin Hicks 🙂
I traded my twitter acct for a nice bottle of wine, in 2009
Smart man.
Well that pretty much made my day 😛
I'm pretty excited about combining (tick job-env)
with the graph visualization. We should be able to show in-flight segments on the edges and nodes.
Will be fun to do that for ABS, once that comes along ... https://adriancolyer.files.wordpress.com/2015/08/flink-abs.png
I actually stripped out the entire streaming engine from local-rt. It doesn’t need it to run. 🙂
We could certainly build something like that on the side for learning though.
Ah, gotcha. Definitely plenty of opportunities for teaching tools, here. I've tried to write the core code (`onyx-blueprint` ns) in a way that is extensible beyond the tutorial. Not sure if I said it before here, but an onyx-fiddle could be built by leveraging this.
This stuff is just so good.
Yea very impressive work
We could probably do well by sticking a few paragraphs of intro text on top (I can write that) and talk about the maturity a bit. Still get asked about that a lot despite all the testing we have in place.