Ordering in distributed systems is usually a best-effort and only primitive
that is required is “happen-before”. I have seen “happen-before” sequencing
being implemented in distributed systems using “barriers”. DRBD is a good
example of such a system. Another example of that model is the block s
Here is the ticket https://issues.apache.org/jira/browse/MESOS-3929, it'd
be great if a committer would go ahead and add a description to it.
On Sun, Nov 15, 2015 at 5:18 PM, Vinod Kone wrote:
> sounds good. so lets create a submit_reviews.py that calls into
> apply_reviews.py. that way the form
We can't only look at comment formatting in a vacuum, since our comments
live with the code. For example, when you look at the following two
comments along with the surrounding code:
(1)
https://github.com/apache/mesos/blob/0.26.0-rc1/src/master/allocator/mesos/hierarchical.cpp#L364
(2)
https://gi
I'm a -1 on the syntax: I'm not sure why the syntax is being proposed when
folks are free to add one or more tickets in the content of the TODO, much
in the same way as comments are written in general. When optional, there is
also the inconsistency of TODO syntax across the code base which seems
un
sounds good. so lets create a submit_reviews.py that calls into
apply_reviews.py. that way the former will only be useful for committers.
On Sun, Nov 15, 2015 at 7:50 AM, Alex Rukletsov wrote:
> Another use case for apply-reviews is rebasing own changes on top of a
> not-yet-committed chain (sim
I remember Jenkins could execute post-build task after build successfully,
maybe we could configure it as a post tasks in
https://builds.apache.org/job/Mesos/ ?
On Sun, Nov 15, 2015 at 11:50 PM, Alex Rukletsov
wrote:
> Another use case for apply-reviews is rebasing own changes on top of a
> not-
Another use case for apply-reviews is rebasing own changes on top of a
not-yet-committed chain (similar to Isabel's use case).
On Sun, Nov 15, 2015 at 4:44 PM, Benjamin Mahler
wrote:
> I also use apply-reviews as an aid for code reviewing. Glad to see others
> are doing this since IMHO just look
I also use apply-reviews as an aid for code reviewing. Glad to see others
are doing this since IMHO just looking at diffs rather than the final
product can be limiting.
On Thu, Nov 12, 2015 at 11:57 AM, Isabel Jimenez <
contact.isabeljime...@gmail.com> wrote:
> I also like to apply reviews, speci
Having ordered delivery as defined by Akka [1] and Erlang [2] is definitely
useful, we've made several assumptions around it, despite knowing that it
is not guaranteed due to the subtleties around link-less sends and link
breakage that you covered in (a) and (b).
The memory overhead of storing all
Good point -- following what Erlang and Akka provide (ordering but not
reliability) is probably a reasonable starting-point.
I suggested earlier that this would require doing our own
retransmission logic (which would be pretty unfortunate), but on
reflection that is obviously not true. We can inst
As I know, Akka could guaranteed message ordering for per sender-receiver
pair, but not guaranteed message delivery. Erlang also similar to this. I
think if to implement own sequencing, acking, and retransmission logic,
this work nearly to reimplement a TCP stack. To implement a new TCP-like
stack
Hi folks,
We should clarify $SUBJECT. My understanding of the current situation is:
(1) For local messages (dispatch(), send() to a local process),
ordered delivery is guaranteed.
(2) For remote messages, ordered delivery is *not* guaranteed.
(3) Despite #2, in many cases messages from one proc
12 matches
Mail list logo
