When I was dealing with Redis a lot, there was a concept of a command pipeline. It was really a client-side only construct, what it meant is you could shove a series of commands over the wire without waiting for a response, and the server would respond in order. So instead of this:
GET -> <- result 1 PUT -> <- result 2 EXPIRE -> <- result 3 As long as your operations didn't depend on each other, you could just do this: GET -> PUT -> EXPIRE -> <- result 1 <- result 2 <- result 3 You're just shoving multiple requests over the wire in order without waiting for any responses, then when the responses come back, you handle them in order. I can't think of any reason Curator's async operations shouldn't work this way. On Wed, Sep 16, 2015 at 1:41 PM, Jordan Zimmerman < [email protected]> wrote: > I know that the async operation responses in Zk are single threaded and > that, on the server, ZK needs to maintain order of operations. This is why > I was thinking the multi-transactions might help. > > -JZ > > > > On September 16, 2015 at 12:34:14 PM, Scott Blum ([email protected]) > wrote: > > How does that stuff work there? > >
