I'm uneducated here since I've not used Erlang in any real capacity. I
thought that typically if A sent a message to B that caused B to raise
an exception, that B would send an exception back to A and that A would
error out. Thus, the client is blamed for the exception. Is this
correct? In clojure, I would have written this pattern via populating
channels with exceptions:
server -> receive-channel ->
deserialize-or-throw-if-exception-on-channel -> client-receive-channel.
The deserialize-or-throw-if-exception-on-channel would be in a go block,
which would error out before the client sees anything. If a supervisor
wants to restart that it would be their business. In the event that
every 100th RPC call receives one of these exceptions, eventually every
client would die, or their supervisors would restart them.
I'm wondering if maybe I have different expectations of RPC from
Timothy. I would like to view RPC as inherently unreliable. "send"
would have many different options -- send and pray, send and wait for
ack, send and return control before you've finished serializing, etc.
"receive" could be async, could be blocking, could require a UUID it's
looking for a response to, could have a timeout, could have a timeout
function, etc.
What would OTP look like over channels?
-ToBeReplaced
On 08/02/2013 10:16 AM, Marc Hämmerle wrote:
On Erlang: sometimes you *want* to block on a node and wait for the
answer of a remote node. It's implemented as message passing under the
hood - the process gets de-scheduled, restarted in case of crash if
you want et al. - but the semantics are clearly sequential and
blocking. Erlang obviously also has benefits in that area with OTP
supervision and the lightweight processes - but doesn't core.async
have at least the last one too?
Take a look into Basho's riak_core
(https://github.com/basho/riak_core) and other distributed systems
written in Erlang: heavy use of RPC calls.
So I'd say on RPC: clearly depends on your needs and is not
automatically bad.
Marc
On 2 August 2013 15:46, Timothy Baldridge <tbaldri...@gmail.com
<mailto:tbaldri...@gmail.com>> wrote:
RPC ties a local process (and all the memory its currently using)
to a remote process. It glosses over the fact that that the link
between these two processes is quite unreliable. In his thesis,
Joe Armstrong also points that this system is not only susceptible
to hardware/network failure, it's also very susceptible to
programming failures. A bug in your code could cause every 100th
RPC call to fail, for example.
So instead of all of this, Erlang (or actually Erlang's OTP
libraries) proposes a different view:
1) all messages are sent async and unreliable. This is the way
networks are designed anyways, if you sent a message to a remote
system and it gets thrown into a queue, you really don't know what
happens to that message in the end, except by asking the remote
system again, and again until you finally get an ACK.
2) If we follow the above model, then we can start programming in
a fail-fast mode. This is what OTP is based on. Supervisor
processes that reset dead sub processes. This is also why I'm not
a fan of populating error messages across channels. Instead,
errors should kill go blocks, and then those blocks should be
restarted by supervisors.
So RPC assumes that every call will succeed. Message passing
systems assume that it's kind-of-sort-of-not-really-likely that
your message will arrive at the remote system. It's a pessimistic
view of the world. And with the systems I work with, this is the
best approach.
So I guess this is a super long way of saying I love the OTP style
and would love to see it ported to core.async. But RPC is not the
way, blocking send/recv is not the way. To get reliable systems
you need your system to always be capable of forward progress, and
having a local process tightly coupled to a remote process will
not get you there.
Timothy
On Thu, Aug 1, 2013 at 1:55 PM, ToBeReplaced
<toberepla...@gmail.com <mailto:toberepla...@gmail.com>> wrote:
A client could use a timeout channel as its receive channel to
get timeouts on a blocking call, though I don't think that's
the right way to do it. Alternatively, implementing a
blocking call with an optional timeout wouldn't be difficult,
it just can't be the default.
I think if you disallowed nil as a response, then it would be
easy to use a variety of different blocking calls -- wait
forever, wait 30 seconds, wait until (f) returns truthy, etc.
-ToBeReplaced
On 08/01/2013 03:36 PM, Cedric Greevey wrote:
On Thu, Aug 1, 2013 at 1:09 PM, <toberepla...@gmail.com
<mailto:toberepla...@gmail.com>> wrote:
There would be no intent to solve the messenger problem
explicitly -- those semantics are up to the user. By
default, in the case of server death, the client side
will just no longer receive responses on its
receive-channel. In the case of a blocking call, this
means that the client side will hang.
Ugh. At the *very* least it should eventually return with
some kind of a timeout exception.
--
--
You received this message because you are subscribed to the
Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
<mailto:clojure@googlegroups.com>
Note that posts from new members are moderated - please be
patient with your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
<mailto:clojure+unsubscr...@googlegroups.com>
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to a
topic in the Google Groups "Clojure" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/clojure/P95cOfuXBUs/unsubscribe.
To unsubscribe from this group and all its topics, send an
email to clojure+unsubscr...@googlegroups.com
<mailto:clojure+unsubscr...@googlegroups.com>.
For more options, visit https://groups.google.com/groups/opt_out.
--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
<mailto:clojure@googlegroups.com>
Note that posts from new members are moderated - please be
patient with your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
<mailto:clojure%2bunsubscr...@googlegroups.com>
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the
Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from
it, send an email to clojure+unsubscr...@googlegroups.com
<mailto:clojure%2bunsubscr...@googlegroups.com>.
For more options, visit https://groups.google.com/groups/opt_out.
--
“One of the main causes of the fall of the Roman Empire was
that–lacking zero–they had no way to indicate successful
termination of their C programs.”
(Robert Firth)
--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
<mailto:clojure@googlegroups.com>
Note that posts from new members are moderated - please be patient
with your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
<mailto:clojure%2bunsubscr...@googlegroups.com>
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to clojure+unsubscr...@googlegroups.com
<mailto:clojure%2bunsubscr...@googlegroups.com>.
For more options, visit https://groups.google.com/groups/opt_out.
--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient
with your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to a topic in the
Google Groups "Clojure" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/clojure/P95cOfuXBUs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
