curator-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Blum <dragonsi...@gmail.com>
Subject Re: tree cache load time
Date Wed, 16 Sep 2015 18:41:53 GMT
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 <
jordan@jordanzimmerman.com> 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 (dragonsinth@gmail.com)
> wrote:
>
> How does that stuff work there?
>
>

Mime
View raw message