| Author |
Message |
|
| alamb |
 Posted: Wed Apr 23, 2008 1:07 pm |
 |
|
|
User
Joined: 26 Aug 2007
Posts: 55
Location: Geneva / Switzerland
|
Hello List,
Now that I have my first 3 Erlang modules (I think I may have reached
the "aha point") and looking forward to the conference in London in
June where I hope I will gain some OTP knowledge, I would like to
connect to those modules from Java.
Yes, since we live in an non perfect world, we are using Java with
Tapestry as our Web environnement (a very powerfull library, but that
is another matter).
Each user, when login in, will create a session and start working.
I am therefore writing some Java classes to call my Erlang functions.
The Java api is the one supplied with R12 version of Erlang.
Now, I imagine there are 3 possibilities:
A)
Each time I call a function, create a new OtpConnection to the Erlang
node, once done, close the connection.
B)
The first time I call a function, create a new OtpConnection to the
Erlang node, leave it open until the app is stoped. The scope of the
connection would be for the entire application deployed in a container
(e.g. Tomcat). In a situation with more than one app server (for a
cluster for example), there would be one OtpConnection per server.
C)
The first time I call a function from a session, create a new
OtpConnection. Close the connection when the user logs out or the
session times out.
Solution A is obviously the most "no side effects compatible" but
might be really slow. In addition, I need to be carefull when trying
to create two connections at the same time from two separate Java
threads... so either I create a connection per thread or I lock
(defeats the purpose of Erlang).
Solution B is maybe slightly better since I could create the
connection when starting the Java server. I still have the locking
issues, though.
Solution C seems good and scales in terms of parallelism, but it leads
to 2 questions:
1)
How many connections can I make from Java before running out of file
descriptors or whatever is needed to handle connections? In our
current business, I don't see more than 200 concurent users before
many months...
2)
If I only need to initiate function calls (e.g. the Erlang modules
don't need to call me), I don't need to create (I assume) a node for
the Java client. However, if at some point, I need to be called from
Erlang, I will need to generate a new node name (and a new OtpSelf)
for each new session. Is this correct?
Thanks for any hints...
Alex
--
Alexander Lamb
Founding Associate
RODANOTECH S |
|
|
| Back to top |
 
|
| Guest |
| Posted: Wed Apr 23, 2008 2:03 pm |
|
|
|
Guest
|
On Wed, Apr 23, 2008 at 02:59:38PM +0200, Alexander Lamb wrote:
> Hello List,
>
> Now that I have my first 3 Erlang modules (I think I may have reached
> the "aha point") and looking forward to the conference in London in
> June where I hope I will gain some OTP knowledge, I would like to
> connect to those modules from Java.
>
> Yes, since we live in an non perfect world, we are using Java with
> Tapestry as our Web environnement (a very powerfull library, but that
> is another matter).
> Each user, when login in, will create a session and start working.
>
> I am therefore writing some Java classes to call my Erlang functions.
> The Java api is the one supplied with R12 version of Erlang.
>
The Java api (Jinterface) is modelled after how Erlang itself
handles nodes and connections.
The node map is supposed to be static and rather few nodes.
There has e.g been a bug with auto generated node names
that did not allow more than some 250 external node names ever
from a node's point of view. That was a memory leak that
has been fixed, but it was no problem for many years
since the applications simply did not use many node names.
So, few nodes. They connect when started and disconnect
when they die. Nodes are long lived.
Jinterface mailboxes corresponds to Pids in Erlang.
They can be created and destroyed rather frequently
while the connection between the nodes remain.
> Now, I imagine there are 3 possibilities:
>
> A)
> Each time I call a function, create a new OtpConnection to the Erlang
> node, once done, close the connection.
>
Very expensive.
> B)
> The first time I call a function, create a new OtpConnection to the
> Erlang node, leave it open until the app is stoped. The scope of the
> connection would be for the entire application deployed in a container
> (e.g. Tomcat). In a situation with more than one app server (for a
> cluster for example), there would be one OtpConnection per server.
>
Sounds nice. Long lived nodes.
> C)
> The first time I call a function from a session, create a new
> OtpConnection. Close the connection when the user logs out or the
> session times out.
>
One OtpNode per session. You will have to auto generate the
node names as seen from Erlang. A rather unnatural mapping.
>
> Solution A is obviously the most "no side effects compatible" but
> might be really slow. In addition, I need to be carefull when trying
> to create two connections at the same time from two separate Java
> threads... so either I create a connection per thread or I lock
> (defeats the purpose of Erlang).
>
> Solution B is maybe slightly better since I could create the
> connection when starting the Java server. I still have the locking
> issues, though.
>
I do not know if Jinterface has been written with thread locking
in mind. This sounds as the most natural mapping, though;
a few static OtpNodes.
> Solution C seems good and scales in terms of parallelism, but it leads
> to 2 questions:
>
> 1)
> How many connections can I make from Java before running out of file
> descriptors or whatever is needed to handle connections? In our
> current business, I don't see more than 200 concurent users before
> many months...
>
The OS sets the limit. The Java machine may have a say too.
Each created OtpNode will use at least 1 socket
to the Erlang node, and probably 1 towards the local Epmd.
> 2)
> If I only need to initiate function calls (e.g. the Erlang modules
> don't need to call me), I don't need to create (I assume) a node for
> the Java client. However, if at some point, I need to be called from
> Erlang, I will need to generate a new node name (and a new OtpSelf)
> for each new session. Is this correct?
>
No. Erlang will only communicate with other nodes. And a node is
long lived. Even to just send a message it goes from Jinterface
Mailbox to Erlang pid and the Jinterface Mailbox exists only
in an OtpNode just as the Erlang pid exists only in an Erlang node.
> Thanks for any hints...
>
> Alex
> --
> Alexander Lamb
> Founding Associate
> RODANOTECH S |
|
|
| Back to top |
|
| alamb |
| Posted: Wed Apr 23, 2008 4:20 pm |
|
|
|
User
Joined: 26 Aug 2007
Posts: 55
Location: Geneva / Switzerland
|
Thanks for the details. I will therefore go with solution B (one
OtpConnection per app server). We don't have such trafic that we would
need more probably.
I will check the code to understand if there are threading issues. Not
really for performance issues but more to avoid collisions if two user
sessions try at the same time to send a message...
Alex
Le 23 avr. 08 |
|
|
| 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
