falter
asked on
RMI question multiple servers on one host
Is it possible to run many instances of one RMI server on one host. (Of course it is)
Every server binds the same Objects to the registry with different server specific names.
And all objects are accepting input at only one server socket meaning providing a RMISocketfactory wich offers only one port for server sockets.
Will RMI handle this properly?
For clarification lets say registry is running at port 1600 and all objects are running at port 1601 (forced by RMISocketFactory directing every unspecified request port=0 do 1601)
doesn't matter to wich process they belong.
The reason for doing something like that is with many clients the server may run out of system resources /number of concurrent threads for one process, maximum amount of memory ...) and it is not a good solution to have for every server an extra host.
Every server binds the same Objects to the registry with different server specific names.
And all objects are accepting input at only one server socket meaning providing a RMISocketfactory wich offers only one port for server sockets.
Will RMI handle this properly?
For clarification lets say registry is running at port 1600 and all objects are running at port 1601 (forced by RMISocketFactory directing every unspecified request port=0 do 1601)
doesn't matter to wich process they belong.
The reason for doing something like that is with many clients the server may run out of system resources /number of concurrent threads for one process, maximum amount of memory ...) and it is not a good solution to have for every server an extra host.
ASKER
Sorry ravindra for the late reaction,
but I had some trouble to connect to EE.
May be you are right, that the described
scenario isn't possible.
But I didn't understand your UniCast MultiCast remark and the replicated RMIServer.
First I didn't want MultiCast, which means every object will get the incoming data.
Its more thinking about a dispatcher inside RMI finding the right process and object.
In the moment I'm doing something like this:
- running n RMIServer at one machine
- the server are identical
- every server creates its own registry
- every server binds at least 2 Objects to the registry
- every server gets one ServerSocket port for request to all the remote objects.
This works fine.
Now I want to reduce the number of used ports from 2*n to 2.
Ok I interpret your answer as "not possible"
Because the ServerSockets for the RMI-Calls are created by the serverprocess and not the registry I have to provide a new port number for the second server, because this is the one and only way tcp can find the right process.
Is this right?
If yes
Lets try n+1 ports
It should be possible to have a second process using the registry from server one and binding its own Objects (same as the 2 of server one) with different names to this registry.
Ok?
So I can reduce the number of needed ports to n+1 where n = number of running servers?
At the moment I need 2*n ports because every process will create a new registry.
You agree?
If not please give some explanation
and you will get the points.
(yow will get them also if you agree)
regards
jf
but I had some trouble to connect to EE.
May be you are right, that the described
scenario isn't possible.
But I didn't understand your UniCast MultiCast remark and the replicated RMIServer.
First I didn't want MultiCast, which means every object will get the incoming data.
Its more thinking about a dispatcher inside RMI finding the right process and object.
In the moment I'm doing something like this:
- running n RMIServer at one machine
- the server are identical
- every server creates its own registry
- every server binds at least 2 Objects to the registry
- every server gets one ServerSocket port for request to all the remote objects.
This works fine.
Now I want to reduce the number of used ports from 2*n to 2.
Ok I interpret your answer as "not possible"
Because the ServerSockets for the RMI-Calls are created by the serverprocess and not the registry I have to provide a new port number for the second server, because this is the one and only way tcp can find the right process.
Is this right?
If yes
Lets try n+1 ports
It should be possible to have a second process using the registry from server one and binding its own Objects (same as the 2 of server one) with different names to this registry.
Ok?
So I can reduce the number of needed ports to n+1 where n = number of running servers?
At the moment I need 2*n ports because every process will create a new registry.
You agree?
If not please give some explanation
and you will get the points.
(yow will get them also if you agree)
regards
jf
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
ravindra,
running multiple servers is necessary, because the server is reaching his memory limits on AIX, more than 300MB needed and the number of native threads is also near the limit of 512 possible ones per process.
Increasing the memory means to get a JVM for AIX 4.2 with 2GB address space.
Not yet available as I know.
But this will not solve the thread problem.
So I have to run more than one server on on a machine.
regards
jf
running multiple servers is necessary, because the server is reaching his memory limits on AIX, more than 300MB needed and the number of native threads is also near the limit of 512 possible ones per process.
Increasing the memory means to get a JVM for AIX 4.2 with 2GB address space.
Not yet available as I know.
But this will not solve the thread problem.
So I have to run more than one server on on a machine.
regards
jf
Ok.
After n+1 ports, Ur problem has solved ??
ASKER
Yes,
its better than to have 2 * n ports visible to the client.
I think to get what I want I have to write a RMI-Server only dispatching requests to a number of background servers not necessarly RMI servers.
This will reduce the number of ports seen by the client to 2.
Still an open question, what todo if the dispatcher runs out of system resources in this case threads.
If RMI reuses native threads the limit will be reached when about 500 parallel client request will come in.
its better than to have 2 * n ports visible to the client.
I think to get what I want I have to write a RMI-Server only dispatching requests to a number of background servers not necessarly RMI servers.
This will reduce the number of ports seen by the client to 2.
Still an open question, what todo if the dispatcher runs out of system resources in this case threads.
If RMI reuses native threads the limit will be reached when about 500 parallel client request will come in.
no idea
The UnicastRemoteObject class defines a non-replicated remote
object whose references are valid only while the server process is
alive. The UnicastRemoteObject class provides support for
point-to-point active object references (invocations, parameters,
and results) using TCP streams.
If java allows , replicated RMI servers,
then there should be a
MultiCastRemoteObject.
We will wait when SUN will provide this
support.
Currently Only UniCast supports is there.
It clearly tells that the RMI server is not replicated on multiple systems.
:)