<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>