| Author |
Message |
|
| alamb |
 Posted: Wed Apr 23, 2008 4:53 pm |
 |
|
|
User
Joined: 26 Aug 2007
Posts: 55
Location: Geneva / Switzerland
|
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.
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
http://www.rodanotech.ch
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist |
|
|
| Back to top |
 
|
| Guest |
| Posted: Thu Apr 24, 2008 12:04 pm |
|
|
|
Guest
|
On Wed, Apr 23, 2008 at 06:49:26PM +0200, Alexander Lamb wrote:
> 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 |
|
|
| Back to top |
|
| alamb |
| Posted: Mon Apr 28, 2008 8:13 am |
|
|
|
User
Joined: 26 Aug 2007
Posts: 55
Location: Geneva / Switzerland
|
>>
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 |
|
|
| Back to top |
|
| adamprisa |
| Posted: Mon Feb 02, 2009 1:35 pm |
|
|
|
Joined: 21 Nov 2008
Posts: 7
|
|
| Back to top |
|
| wuji |
| Posted: Tue Aug 14, 2012 7:30 am |
|
|
|
User
Joined: 10 Aug 2012
Posts: 654
|
for information leading to the capture of Miguel Angel and and cheap polo ralph lauren and Omar.The brothers, whose numeric aliases refer to their alleged
within the Zetas at the time of the cartel's creation creation [h4]jordan 6[/h4] creation several years ago, are now allegedly top leaders of
organization that controls drug trafficking in the east and south south [h4]cheap jordans[/h4] south of Mexico. Miguel, or "40," allegedly runs the Zetas
with "3," Heriberto Lazcano.The Zetas began in 1999 when former former jordan 6 former members of the Mexican military signed on to work
security for the Gulf drug cartel. The Zetas went into into knockoff designer *beep* into business for themselves and are now at war with |
|
|
| Back to top |
|
|
|
All times are GMT
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum
|
|
|
Digg It
Del.icio.us
Reddit
Facebook
Stumble Upon
Technorati
