[erlang-questions] JInterface and multi-threading

[Alexander Lamb]

>>

Hello,

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,

Alex
--
Alexander Lamb
Founding Associate
RODANOTECH Sàrl

4 ch. de la Tour de Champel
1206 Geneva
Switzerland

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

http://www.rodanotech.ch