<div dir="ltr">Assuming your Erlang node handles the RPC call from the Java node with a gen_server, why not respond with {no_reply, ...} to the Java-server, send an asynchronous request to the C-server, handle the response in a handle_info, and then reply to the Java-server with gen_server:reply/2? This way, you leave all the timeout handling to the Java-node.<br>
<br>The issue with this approach is that you must find a way to preserve the From argument to your handle_call callback, so that you can pass it on to gen_server:reply/2 at a later stage, but that might be an easier problem to solve.<br>
<br>//Daniel<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jan 17, 2014 at 10:17 AM, David Welton <span dir="ltr"><<a href="mailto:davidnwelton@gmail.com" target="_blank">davidnwelton@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
I am working with a system that looks like this:<br>
<br>
C node <=======> Erlang <========> Java Node<br>
<br>
And we're looking at good ways to integrate everything.<br>
<br>
For instance, we want the Java node to be able to do a simple query<br>
that ends up getting some data from the C node, say, the version it's<br>
running or something like that.<br>
<br>
Since the Java code needs to be simple, we want to do the equivalent<br>
of rpc:call(hw_server, get_version, []) and wait for the answer. It<br>
shouldn't take long, and timeouts or whatever can be handled by Java<br>
in that case.<br>
<br>
However, to interact with the C node, the gen_server that manages it<br>
would want to do something like:<br>
<br>
{any, 'c@node'} ! get_version<br>
<br>
And then get the answer via handle_info.<br>
<br>
But if we're going to transform what is essentiall a 'call' -<br>
hw_server:get_version() - into a cast/response, somewhere there's got<br>
to be a receive.  For instance:<br>
<br>
get_version() -><br>
   Ref = make_ref(),<br>
   gen_server:cast(hw_server, {get_version, Ref}),<br>
   receive<br>
      {Ref, version, Version} -><br>
          Version<br>
    end<br>
<br>
This feels like I've left OTP behind though.<br>
<br>
We could put the receive in the handle_cast for the gen_server, but<br>
then that's going to block the whole thing on one call, which strikes<br>
me as a bad idea, although I guess it could also be used to protect<br>
the C node if it were unable to process more than one thing at once.<br>
<br>
Another approach would be to further work with our Java guy to have<br>
him send and receive the messages, but we were kind of hoping to hide<br>
some of the complexity from that part of the system.<br>
<br>
Thank you,<br>
<span class="HOEnZb"><font color="#888888">--<br>
David N. Welton<br>
<br>
<a href="http://www.welton.it/davidw/" target="_blank">http://www.welton.it/davidw/</a><br>
<br>
<a href="http://www.dedasys.com/" target="_blank">http://www.dedasys.com/</a><br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</font></span></blockquote></div><br></div>