[erlang-questions] Mixing casts and calls

[Brujo Benavides @ Inaka]

Hi David,

	I’m not sure, but you might be interested in using this library on your Java node: https://github.com/inaka/jinterface_stdlib
	It provides abstract classes like OtpGenServer with which you can implement “gen_servers” in Java and then you can just use gen_server:call or gen_server:cast from your Erlang node to communicate with them.

On Jan 17, 2014, at 6:17, 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