[erlang-questions] Mixing casts and calls

[Ludovic Demblans]

To preserve the from argument you could just, in your handle_call, spawn a  
process :


     handle_call(what_version, From, State=#state{cnode=CNode}) ->
         Self = self(),
         spawn(fun() ->
                 Reply = cnode_handler:call(what_version, CNode),
                 Self ! {cnode_reply,Reply,From}
               end),
         {noreply, State}.

     handle_info({cnode_reply, Reply, From},State) ->
         gen_server:reply(From,Reply),
         {noreply,State}.


Seems it could work.



Le Fri, 17 Jan 2014 10:27:58 +0100, Daniel Abrahamsson  
<daniel.abrahamsson@REDACTED> a écrit:

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


-- 
Utilisant le logiciel de courrier révolutionnaire d'Opera :  
http://www.opera.com/mail/