This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-02-06
Channels
- # aatree (1)
- # alda (9)
- # beginners (63)
- # boot (124)
- # braid-chat (8)
- # cider (44)
- # cljs-dev (44)
- # clojure (79)
- # clojure-dev (1)
- # clojure-russia (47)
- # clojurescript (105)
- # community-development (16)
- # cursive (3)
- # datavis (1)
- # datomic (54)
- # editors (10)
- # editors-rus (10)
- # emacs (18)
- # garden (1)
- # hoplon (5)
- # jobs (1)
- # ldnclj (6)
- # lein-figwheel (2)
- # luminus (1)
- # off-topic (29)
- # om (49)
- # overtone (5)
- # parinfer (12)
- # proton (2)
- # re-frame (5)
- # reagent (6)
- # ring-swagger (1)
- # slack-help (3)
- # spacemacs (1)
- # yada (42)
right- they dispatch a function to the same thread pool; however, my understanding- not tested but easily testable-is that the function that is executed in the agent case is transaction aware, while the function that is executed in the future case is not.
Ah. Good to hear my hunch wasn't completely nuts...
the idea is that the state encapsulated by an agent can participate in transactions
there is no state associated with a future
very interesting situation, though, thanks for bringing it up
It's not as esoteric as it might sound. Basically, I'm working with SQS (amazon's queue service).
After you take a message off the queue, you need to tell the queueu to delete the message to confirm that you handled it successfully.
So I take a message.
I update local state in a transaction.
But SQS does not guarantee in order delivery.
So I explicitly do not want to receive out-of-order deliveries. I will fail to ACK those, and then they will timeout and get redelivered later.
So when I update local state, I check if the message is in order. If it is, local state changes in a transaction and then I want to delete the message in SQS (that's my side-effect).
If the message is out of order, then I don't change local state, and I don't want to delete the message.
yes, got it, very nice.
So I want this side-effect (ACKing the message) only when the transaction succeeds and when the local state actually changes.
But to define a transaction I need to switch from an atom
to an agent
to get dosync
. And then I need to introduce this spurious agent
just to get send-off
. So I suspect I'm making this harder than necessary.
well, these semantics- distributed consensus- are very difficult to maintain. e.g., in the case you're describing, the delete at SQS initiated by your agent fn may fail, which would result in redelivery of an otherwise in-order message.
it just depends how much it matters
Yes, I haven't even opened the mental can of worms of what if the delete-message fails to deliver. In truth this system has low concurrecny requirements, so I'm going to call it "correct enough" if I handle out-of-order correctly.
Would be more fun to work on something that justified perfect correctness.
have you read the raft paper?
if you enjoy these problems, check out https://ramcloud.stanford.edu/raft.pdf and https://raft.github.io/
Looks like fun. Maybe I can find a peice of work that justified digging into it.
hey @cddr if you have them as command line utilities you can do something like this: http://blog.jayfields.com/2012/10/clojure-lein-tar.html
@jonahbenton: (btw, realized I was being an idiot re the agent and send-off. Can just return a value from the dosync form and conditionally use a future or whatever. No need to kickoff the side effect inside the transaction.)
hey @alexisgallagher: hmm...do you have multiple threads processing these SQS messages, or just one thread?
I'll need to support multiple threads eventually
just a suggestion- if throughput matters it will be best to minimize the rate of redeliveries, so it may be more efficient and simpler overall to let one thread service SQS, do your own reordering of received messages, and then use send-off to both process the reordered messages and to ack SQS.
but the dosync + agent approach sounded ok- the problem with just returning a value from dosync is that unless the value that's being returned is a ref participating in the transaction and indicating success or failure, you don't know whether the transaction committed
@jonahbenton: good point. I hadn't thought of that. An exception could stop the transaction. But what else?
Hey folks. I've been working on some tooling for using samza from clojure. Would be interested to hear what you think. https://github.com/cddr/samza-config/
well...that's it, an exception or deliberate abort. the implementation works extremely hard to deliver on transactional semantics. which comes of course with tradeoffs- operations that involve transactions are orders of magnitude more expensive than those that don't. you're in effect asking to incur an extreme cost in order to get a specific set of semantics and behaviors. so- if the problem really requires transactional semantics, then the expensive tool being utilized to deliver on it should be employed in the way it was designed. if those semantics are not that important- which means- if the problem has other solutions that don't require transactional updates in a concurrent context- then transactions aren't needed
(let [r (map->Foo {:a 1 😛 2}), {:keys [a b]} r, f1 [a b], {:strs [a b]} r, f2 [a b]] [f1 f2])
(let [r (map->Foo {"a" 1 "b" 2}), {:keys [a b]} r, f1 [a b], {:strs [a b]} r, f2 [a b]] [f1 f2])
boot.user=> (def x (map->Foo {"a" 1 "b" 2}))
#'boot.user/x
boot.user=> x
<#C053K90BR>.user.Foo{:a nil, :b nil, "a" 1, "b" 2}
Hi! Can anybody help with ztellman's gloss? When using header frame is it possible to pass parsed frame down to codec that is chosen to be next?
hey @von_zeppelin can you say a little more about what exactly you're looking to do?
@jonahbenton: I want to parse messages of a protocol in which every message starts with a predefined header, the header contains message type and current transaction id. With gloss/header it is easy to organize selection of the next codec based on type read from msg header, but I also want to pass tx id to the next codec, for example. Is it possible to do?
hey @von_zeppelin: i was considering gloss for a project, wound up not using it, so with the caveat that i don't have my hands that dirty with it- isn't it the case that when you provide gloss with a header for use in decoding data, you're providing it with instructions to decode both the header and the body data, so you'll get both data structures?
am not sure i'm following what you mean by "pass tx id to the next codec"?
@jonahbenton: What I meant is the following: we parsed some initial amount of bytes to decide what codec to use next, the next codec will start from the remaining bytes chunk, but initial amount of bytes also contained some useful info that I want to pass to the next codec, not only the remaining bytes
@jonahbenton: Thanks for your answer anyway. What lib did you choose in the end?
@von_zeppelin: header will pass the decoded header data to the function you provide, and that function is expected to return the codec to use with the remaining bytes. If you need to have the structure of the next codec be dependent on the header data- that looks straightforward, just extract the data you need and then generate the structure to provide to compile-file. However, if you need to have the next codec return a data structure that includes both data from the part of the stream it is responsible for decoding, AND data from the preceding block- to my eyes there doesn't seem to be a way to do that. Is that what you found?
@jonahbenton: Yes, the latter case
@von_zeppelin: we wound up rolling our own, we were dealing with an ancient bank communication protocol that we had to both read and write and my partner found some oddities that obviated any benefits from gloss. my recollection is that we had come into it with the understanding that our responses would precisely match the format of the data we received; however, we discovered that there were more exceptions than adherents to this
@jonahbenton: OK, thank you for help!
good luck!
just curious- why do you need to annotate the next frame with extra data? can't your data consumer do that?
At the end I want to have a parsed record that will also have as a field the current transaction id read from header
gotcha- and you don't want to reduce over the plain data structures gloss would hand back?
I'm using Emacs with Cider, clj-refactor, paredit and rainbow-delimiters. It is pretty nice if you are comfortable with Emacs