[erlang-questions] JInterface and multi-threading
Alexander Lamb
Now I have a better understanding of JInterface (from previous post
answer), I looked into the Java code.
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.
Indeed, having only one OtpConnection (which seems logical now), I
will need to do rpc calls from potentially simultanious threads.
How will this be handled? If one call is taking longer than expected,
I will block on connection.receiveRPC().
Is there a correct way to handle this problem? Do I need for example
to create a mailbox in a thread for each session in my server? This
would allow my Java sesions to run regardless of any other session
blocking on a call to the erlang server. Now, obviously, my Erlang
server might be blocked but I could create an Erlang process on the
server for each client process connecting from Java.
What is the correct way to handle those issues.
Thanks
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
Raimo Niskanen
> Hello,
>
> Now I have a better understanding of JInterface (from previous post
> answer), I looked into the Java code.
>
> 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, having only one OtpConnection (which seems logical now), I
> will need to do rpc calls from potentially simultanious threads.
> How will this be handled? If one call is taking longer than expected,
> I will block on connection.receiveRPC().
Ok. I have now started to read the Jinterface documentation for
this. It seems OtpConnection and OtpSelf are conveniance classes
for a node with only one "Erlang" process that is only one OtpMbox.
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.
>
> Is there a correct way to handle this problem? Do I need for example
> to create a mailbox in a thread for each session in my server? This
> would allow my Java sesions to run regardless of any other session
> blocking on a call to the erlang server. Now, obviously, my Erlang
> server might be blocked but I could create an Erlang process on the
> server for each client process connecting from Java.
>
> What is the correct way to handle those issues.
>
Since OtpSelf and OtpConnection only have one OtpMbox (internally),
OtpConnection.sendRPC and OtpConnection.receiveRPC will only
do one RPC call at the time, for that OtpSelf object.
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.
> Thanks
>
> 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
>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-q...@erlang.org
> http://www.erlang.org/mailman/listinfo/erlang-questions
--
/ Raimo Niskanen, Erlang/OTP, Ericsson AB
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,