Yeah, that's what I had coded previously. Sorry for all the back-and-forth
guys, I was trying to be lazy and reduce round-trips. I'll switch back to
this code. I appreciate the feedback!
On 3/1/12 3:27 PM, "Marshall McMullen" wrote:
>Yes, the results are guaranteed to be the same order of the re
Check is just handled the same as the other ops. In the
PrepRequestProcessor stage if the requested path doesn't exist, then it
aborts the multi with an error.
On Thu, Mar 1, 2012 at 11:25 PM, Ted Dunning wrote:
> Harrumph.
>
> The only good thing to say here is that, yes, there is a one to one
Yes, the results are guaranteed to be the same order of the requests.
However, the first one that fails will cause the entire multi to be
aborted. So, if say the first one fails, then you won't know if the others
after that would have failed.
I'd suggest doing something entire different, such as
Harrumph.
The only good thing to say here is that, yes, there is a one to one
correspondence between arguments and results in the returned list.
I will have to check the documentation to see if throwing an exception is the
correct thing to do for check. It surprises me a bit that you are seei
Right, I did this:
(psuedo-code)
List ops
For(path in paths)
ops.add( Op.check(path, -1) )
EndFor
List Results = Zk.multi(ops)
This causes an exception to be thrown on the first path that doesn't
exist. It doesn't return back a list with one OpResult flagged with an
error. I was under the impr
No. I meant one call full of checks and a second call with any necessary
creates.
Sent from my iPhone
On Mar 1, 2012, at 11:17 AM, "Shelley, Ryan" wrote:
> Ok, I tried this with the Op.create and found that it will throw a
> KeeperException on the first path that doesn't exist. It doesn't ret
No. Version number won't change the fact that I am spacy.
I meant the check op.
Sent from my iPhone
On Mar 1, 2012, at 10:13 AM, "Shelley, Ryan" wrote:
> I don't see an Op.exists() method. Check, Create, Delete and SetData. I'm
> on 3.4.3, if that makes a difference.
>
> On 2/29/12 7:16 PM,
Ok, I tried this with the Op.create and found that it will throw a
KeeperException on the first path that doesn't exist. It doesn't return
back an OpResult with an "error" type. I can still use this, and just
catch the exception and create the node in the exception, but I was under
the impression t
Perfect. Thanks so much!
On 3/1/12 10:15 AM, "Marshall McMullen"
wrote:
>Check() will check if it exists with the specified version number. If you
>give it -1 it won't compare the version number. So that's a basic Exists()
>call. Does that make sense?
>
>On Thu, Mar 1, 2012 at 6:13 PM, Shelley,
Check() will check if it exists with the specified version number. If you
give it -1 it won't compare the version number. So that's a basic Exists()
call. Does that make sense?
On Thu, Mar 1, 2012 at 6:13 PM, Shelley, Ryan wrote:
> I don't see an Op.exists() method. Check, Create, Delete and SetD
I don't see an Op.exists() method. Check, Create, Delete and SetData. I'm
on 3.4.3, if that makes a difference.
On 2/29/12 7:16 PM, "Ted Dunning" wrote:
>On Wed, Feb 29, 2012 at 7:04 PM, Marshall McMullen <
>marshall.mcmul...@gmail.com> wrote:
>
>> Yes, Ted's right. The multi has to fail as that
I think what I was getting at was a flag that simply says "It's ok to
already exists, just ignore it and continue." However, I'm doing the
approach you already suggested and checking each sub-path before adding
the Op to the list, and it works fine. I just wanted to make sure I wasn't
missing a bet
On Wed, Feb 29, 2012 at 7:04 PM, Marshall McMullen <
marshall.mcmul...@gmail.com> wrote:
> Yes, Ted's right. The multi has to fail as that's part of the contract it
> guarantees.
>
> The only thing you could do, which will significantly narrow the race
> condition, is as you're *building *the mult
Yes, Ted's right. The multi has to fail as that's part of the contract it
guarantees.
The only thing you could do, which will significantly narrow the race
condition, is as you're *building *the multi, check if the path already
exists. If so, then don't add the create op for that path into the mul
Yes. I don't know of a good race-free solution involving a single
multi-request.
On Wed, Feb 29, 2012 at 4:52 PM, Shelley, Ryan wrote:
> Thanks for that. Out of curiosity, in my prior example of creating a node
> at /lorem/ipsum/foo/bar, if I'm building the multi operation list and at
> the same
Thanks for that. Out of curiosity, in my prior example of creating a node
at /lorem/ipsum/foo/bar, if I'm building the multi operation list and at
the same time some other client creates /lorem before I execute the multi
operation, will the entire multi fail because /lorem already exists?
On 2/29/
http://zookeeper.apache.org/doc/r3.4.2/api/org/apache/zookeeper/ZooKeeper.html#multi(java.lang.Iterable)
The javadoc for Op does not appear for an unknown (to me) reason. Here it
is from org.apache.zookeeper.Op:
/**
* Represents a single operation in a multi-operation transaction. Each
operati
Can you reference some docs? I looked but couldn't find anything regarding
multi.
On 2/29/12 4:23 PM, "Ted Dunning" wrote:
>Well, in 3.4, you can use multi to do this.
>
>On Wed, Feb 29, 2012 at 4:08 PM, Shelley, Ryan
>wrote:
>
>> Is it possible to create all nodes in a path in one step?
>>
>> F
Well, in 3.4, you can use multi to do this.
On Wed, Feb 29, 2012 at 4:08 PM, Shelley, Ryan wrote:
> Is it possible to create all nodes in a path in one step?
>
> For example, my ZK is empty of any nodes. I want to create:
> /lorem/ipsum/foo/bar
>
> Do I have to create each segment with iterative
Is it possible to create all nodes in a path in one step?
For example, my ZK is empty of any nodes. I want to create: /lorem/ipsum/foo/bar
Do I have to create each segment with iterative calls to ZK, or is there an
easier way to build this?
20 matches
Mail list logo
