[erlang-questions] Mixing casts and calls

[Daniel Abrahamsson]

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.

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.

//Daniel


On Fri, Jan 17, 2014 at 10:17 AM, David Welton <davidnwelton@REDACTED>wrote:

> Hi,
>
> I am working with a system that looks like this:
>
> C node <=======> Erlang <========> Java Node
>
> And we're looking at good ways to integrate everything.
>
> For instance, we want the Java node to be able to do a simple query
> that ends up getting some data from the C node, say, the version it's
> running or something like that.
>
> Since the Java code needs to be simple, we want to do the equivalent
> of rpc:call(hw_server, get_version, []) and wait for the answer. It
> shouldn't take long, and timeouts or whatever can be handled by Java
> in that case.
>
> However, to interact with the C node, the gen_server that manages it
> would want to do something like:
>
> {any, 'c@REDACTED'} ! get_version
>
> And then get the answer via handle_info.
>
> But if we're going to transform what is essentiall a 'call' -
> hw_server:get_version() - into a cast/response, somewhere there's got
> to be a receive.  For instance:
>
> get_version() ->
>    Ref = make_ref(),
>    gen_server:cast(hw_server, {get_version, Ref}),
>    receive
>       {Ref, version, Version} ->
>           Version
>     end
>
> This feels like I've left OTP behind though.
>
> We could put the receive in the handle_cast for the gen_server, but
> then that's going to block the whole thing on one call, which strikes
> me as a bad idea, although I guess it could also be used to protect
> the C node if it were unable to process more than one thing at once.
>
> Another approach would be to further work with our Java guy to have
> him send and receive the messages, but we were kind of hoping to hide
> some of the complexity from that part of the system.
>
> Thank you,
> --
> David N. Welton
>
> http://www.welton.it/davidw/
>
> http://www.dedasys.com/
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140117/1f1782b9/attachment.htm>