[erlang-questions] Mixing casts and calls

[James Aimonetti]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

You can call gen_server:reply/2 directly from the spawned process,
afaik. No need to send the response back to the gen_server to do the
reply.

...
spawn(fun() ->
  gen_server:reply(From, cnode_handler:call(what_version, CNode))
end),
...

On 01/21/2014 02:02 PM, Ludovic Demblans wrote:
> 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
>>> 
> 
> 


- -- 
James Aimonetti
Lead Systems Architect
"I thought I fixed that"

2600Hz | http://2600hz.com
sip:james@REDACTED
tel:415.886.7905
irc:mc_ @ freenode
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlLe738ACgkQ54NxaUq7OmCnzwD+JmvOrFAhvuMnoTOkGwEzUvOw
0WwjnwmZbCMvRCnrTN4A/1QHZC7Z+36B0qsiglOs3SKlen0QexYGk0Fyak9Ol4CX
=cYK7
-----END PGP SIGNATURE-----