[erlang-questions] JInterface and multi-threading

Alexander Lamb <>
Mon Apr 28 10:11:12 CEST 2008



Thanks a lot for the answer (sorry to be late, I was without connexion  
for 3 day...)

>> It it is not clear to me if rpc from Jinterface is thread safe. Or,  
>> in
>> other words, will this be a bottleneck for an application in an app
>> server with many concurent users.
> It seems the code is written to be thread safe. It synchronizes
> on the socket writes and reads. The socket to the other (Erlang)
> node will always be a bottleneck (absolutely not necessarily the  
> smallest).

Indeed, the read and write process should really be fast enough in our  
situation. I am not trying to optimize as if I were Google, I just  
want to avoid one function call to block others for example because of  
an exception. So it is more a question of reliability and scalability  
than a question of speed.
> The more Erlanghish way is to create an OtpNode and in that
> create many OtpMbox:es. Each OtpMbox could be used in a dedicated
> Java thread and call servers, e.g the rpc server 'rex' or
> one of your own.
> A few conveniance function in OtpConnection, that is
> sendRPC and receiveRPC can be used as a template for
> doing RPC calls from an OtpMbox.
> sendRPC sends:
> {self(), {call, Mod, Fun, ArgList, user}}
> to {rex,OtherNode}
> receiveRPC receives:
> {rex,Result} and returns Result.
> This is a sneak way to call the RPC server. If you do it from
> Erlang rpc:call uses gen_server calls, but that should also
> be possible to do from Jinterface.

Ok, what this means is that my Java code which created a JInterface  
mbox will wait on mbox.receive()

Normally, If I am in a servlet session, I will not block my other  
sessions while waiting for the reply, since each servlet session is in  
a thread.
> If you create one OtpNode per app server, and one OtpMbox
> per user session, the sending of RPC calls from several
> OtpMbox:es will compete for the connection between the
> Java node (OtpNode) and the Erlang node, but the RPC
> server in Erlang will spawn a new process for each
> new RPC call, so one RPC call in progress will not
> block other RPC calls. That is, while receiving one
> RPC reply in one OtpMbox, other OtpMbox:es can
> do RPC sends and receives.
Now this touches on the Erlang server part.

For the time being (writing my first real Erlang app), I wrote  
something which will block on each call (I guess) because I wrote  
simple functions in a module which call a single process spawned at  
the initialisation of the module (as the examples given by Amstrong in  
his book).

A better way of doing this would be to spawn a process just for the  
handling of the call and returning immediately.

 From what I read in your reply, either "rex" or OTP do this for you  
"out of the box". Now, I didn't want to dive into OTP before my class  
in London in June, but it looks like OTP could solve the bottleneck  
problem on the Erlang server side.

Thanks again,

Alexander Lamb
Founding Associate

4 ch. de la Tour de Champel
1206 Geneva

Tel:  022 347 77 37
Fax: 022 347 77 38


More information about the erlang-questions mailing list