<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 01/29/2015 09:15 AM, Matthieu Tourne
wrote:<br>
</div>
<blockquote
cite="mid:CAAGYmFdqNdi2nRntwApLjViVRWf=0TwiHmL09UQUCe4Qd=SJBg@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, Jan 28, 2015 at 9:59 PM,
Michael Truog <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:mjtruog@gmail.com" target="_blank">mjtruog@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><span class="">
<div>On 01/28/2015 07:19 PM, Matthieu Tourne wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hi,
<div><br>
</div>
<div>I started using py_interface as a layer to do
rpc into an Erlang system, receive and send
message, and eventually provide functionality to
the that Erlang system.</div>
<div><br>
</div>
<div>One of the functions on the Erlang side would
be :</div>
<div><br>
</div>
<div>handle_call({subscribe, Channel}, From,
State) -></div>
<div> %% Saves From as a subscriber of this
channel into the State</div>
<div> %% When something will arrive on the
Channel From will get a message.</div>
<div><br>
</div>
<div>The problem is when I'm sending an rpc:call
via py_interface (a call message on the rex
mailbox essentially). It seems that the pid
associated to that rpc essentially disappears
right when the rpc is completed.</div>
<div><br>
</div>
<div>As I gathered from this example [1], an
alternative way to do this would be to rewrite
my handle_call this way : </div>
<div><br>
</div>
<div>handle_call({subscribe, Channel,
SubscribingPid}, _From, State) -><br>
</div>
<div> %% Saves SubscribingPid instead of From.</div>
<div><br>
</div>
<div>And I would pass in the Pid of an active
mailbox from my py_interface hidden node.</div>
<div><br>
</div>
<div>My question is two fold, would there be a way
to keep a live Pid in the system (maybe [2]
answers this problem as a byproduct), for longer
than getting a result to that rpc call.</div>
<div>Or would a proper way to do this be to have a
proxy process to make the link between rpc's and
a live mailbox in my hidden node.</div>
<div>Also, is a hidden node the best way of
achieving all of this ?</div>
</div>
</blockquote>
</span> py_interface makes the running Python
interpreter into a hidden node, similar to a cnode (<a
moz-do-not-send="true"
href="http://www.erlang.org/doc/tutorial/cnode.html"
target="_blank">http://www.erlang.org/doc/tutorial/cnode.html</a>),
just using Python source code (like jinterface does with
Java source code). You could probably modify the
py_interface source code to run as an Erlang port (<a
moz-do-not-send="true"
href="http://www.erlang.org/doc/tutorial/c_port.html"
target="_blank">http://www.erlang.org/doc/tutorial/c_port.html</a>).
In both cases, all Python usage will have a single
connection bottleneck (a single socket for a cnode and a
single pair of pipes for a port). Depending on the
Python source code, you could argue that it will never
matter due to the global interpreter lock.<br>
<br>
However, if you do care about Python latency, it is more
efficient to use the Python CloudI API. To do RPC you
would send a service request to another CloudI service
(based on your example, an Erlang CloudI service). An
example of a Python service is at <a
moz-do-not-send="true"
href="http://cloudi.org/#Python" target="_blank">http://cloudi.org/#Python</a>
to show how a service request can be handled in Python
(adding a send_sync CloudI API function call (<a
moz-do-not-send="true"
href="http://cloudi.org/api.html#1_send_sync"
target="_blank">http://cloudi.org/api.html#1_send_sync</a>)
would be the same as doing RPC). The Python CloudI API
is implemented only in Python in the cloudi module and
with Python/C integration in the cloudi_c module (the
quickest Python integration).<span class=""><br>
<br>
</span></div>
</blockquote>
<div><br>
</div>
<div>I was actually looking at CloudI just yesterday! </div>
<div>It looks very interesting, and seems to work like magic
in my use case [1] :)</div>
<div><br>
</div>
<div>I would have couple questions about it, what powers the
api system ? </div>
<div>Reading the code briefly I saw some Erlang external
term format, but it wasn't clear which channel the
protocol used (socket, pipes, etc ).</div>
</div>
</div>
</div>
</blockquote>
The Erlang external term format is used for sending a CloudI service
request to the Erlang VM from an external service. For an external
service the service configuration sets the count_thread (number of
threads to use for CloudI API objects concurrently) and
count_process (number of OS processes for the external service
instance, each using the same number of threads). When an external
service is started, count_thread * count_process sockets are
created, so there is concurrent usage of the CloudI API among all
external service threads. The socket type (i.e., 'protocol'
described at <a class="moz-txt-link-freetext" href="http://cloudi.org/api.html#2_services_add">http://cloudi.org/api.html#2_services_add</a>) is either
inet tcp (tcp), unix domain socket tcp (local or default), or inet
udp (udp (only really used for testing)).<br>
<blockquote
cite="mid:CAAGYmFdqNdi2nRntwApLjViVRWf=0TwiHmL09UQUCe4Qd=SJBg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>Also I was wondering if everything would need to become
a cloudi_service to be consumed seamlessly by an external
API, I'm working with existing code that already has a lot
of gen_server patterns, if I have to layer on top this
could be a burden.</div>
</div>
</div>
</div>
</blockquote>
Anything that handles CloudI service requests needs to be a CloudI
service. External Erlang source code can use the cloudi module to
send to CloudI services without being services (it can just be a
normal Erlang process that keeps the Context data created by
cloudi:new/0)<br>
<blockquote
cite="mid:CAAGYmFdqNdi2nRntwApLjViVRWf=0TwiHmL09UQUCe4Qd=SJBg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>Finally not running on windows could be a problem, but
I'm guessing I could rip out just CloudI API part of
CloudI (it's a big repo) and make sure that works.</div>
</div>
</div>
</div>
</blockquote>
The CloudI source code is portable, so making it work on Windows
shouldn't be a problem. However, the main reason I have avoided
trying to make Windows work is just due to no one using Windows for
anything fault-tolerant (due to Window's historical instability) or
any serious server usage. I understand people have tried to (like
the London Stock Exchange:
<a class="moz-txt-link-freetext" href="http://www.computerworld.com/article/2467082/data-center/london-stock-exchange-to-abandon-failed-windows-platform.html">http://www.computerworld.com/article/2467082/data-center/london-stock-exchange-to-abandon-failed-windows-platform.html</a>
and the Microsoft sponsored work with MPI clusters on Windows). If
Windows was somehow important for testing, CloudI could be used on
Windows. The simplest approach would likely be with Cygwin, but I
have not attempted that yet.<br>
<blockquote
cite="mid:CAAGYmFdqNdi2nRntwApLjViVRWf=0TwiHmL09UQUCe4Qd=SJBg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
</div>
[1] <a moz-do-not-send="true"
href="https://github.com/CloudI/CloudI/tree/develop/doc#python">https://github.com/CloudI/CloudI/tree/develop/doc#python</a></div>
</div>
</blockquote>
<br>
</body>
</html>