RMI Performance

Is there a limit on the number of simultaneous remote calls that a RMI server can handle ???

Well, here's the scenario. I'm running a RMI server on linux Red hat 9.0 with kernel 2.4.21. The client calls it's method, responding to which, the server does some processing regarding the linux kernel. The processing is nothing but just reading some values through Runtime.exec(). These raw values are converted into objects, verified, and then some values are sent to the client.
The client executes the method every 3 seconds. That's one point that may be causing problems. What do u think ? Now what goes wrong is that after a few hours the system running the RMI server hangs. That's what I wanted to know. Why does the server hang ? There no such thing in the code that might play tricks with the system. I think it's the RMI that's causing problems. And if I run the X windows server, it hangs very quickly. Please let me know what could be the possible reasons regarding RMI. I shall be thakful

Similar Messages

RMI Performance Comp. with Forte

Hi All,
I know that this topic has been discussed on the list
already, but I would like to find out whether the
current state of Sun's RMI implementation is like
I imagine it, and I want to compare with our Forte
Service objects too. Basically, these seem to be
issues that negatively affect performance,
1. A thread is created on the server per request, and
there is no way to change this easily (i.e. reuse
threads from a pool)
2. Each call opens a new socket.
In particular, does it make sense to replace RMI with
CORBA for increased performance and scalability? Can a
PC-based server handle loads of about 1000 remote
calls per second (considering the overhead imposed by
RMI/other communication methods only)? or Shall we
compare Forte against RMI.
Thankx,
Babu

Okay,
A method invocation (or function call or procedure call or whatever) is
always a synchronous call. This means, you ask the service to do something
and wait for the function to complete, optionally with return values. It is
possible, that within the method, a separate thread is started, that
continues after the method is completed, but that doesn't change the
mechanism that a method invocation is a synchronous call.
In Forte, it is possible to start a method as an asynchronous call, with the
"start task" command. In that case, the caller does not wait for the method
to complete and return values are not handled. If this method invocation
happens across a network (making it a Remote Method Invocation) then a
socket will be opened when the call is made and closed immediately after. It
does solve the one-socket-per-caller problem, but not the
one-thread-per-caller problem. Also, it does remove the possibility of
receiving return values.
If you want to keep using method invocations as synchronous calls with
return values, but you also want to share resources like sockets and
threads, then you have to use TP-monitoring concepts. You must have a two
way, asynchronous call with an additional parameter. This means, the client
does a single, brief call that re-uses an existing thread and immediately
frees the socket it used. The client passes all required parameters and one
additional parameter to identify itself. In Forte, this would be a reference
to an anchored object on the client-partition. Then the client waits
(possibly blocks). The server completes the request and locates the client
that sent the request. The server invokes a method on the client, informing
that the request was handled. The server now also passes all return values.
The client exits its wait-state and continues.
In Forte (even if you use other mechanisms to hook into Forte), every call
still is a separete thread. If you wish to re-use existing threads, this
must be done using events. So, a client invokes a method asynchronously
(using "start task") and waits. The server start a new thread and posts an
event. Each existing thread is either idle in an event loop or busy handling
a previous event. The new event is added to the queue of all event loops and
the original thread is terminated (the socket was already freed). One event
loop of the thread-pool will be the first one to respond to the event, mark
this somewhere (maybe using mutex) and start handling it. All the others
will eventually respond to the event as well, but will be able to see that
the event is already being handled and ignore it.
This does introduce overhead and it makes your application more complex, but
it also prevents you running out of resources.
Now, the real issue is not the amount of calls per second, but a combination
of calls per second and seconds to complete the call. Using these two
numbers, you can calculate the amount of tasks the server has to be handling
simultaneously at any given time (average). Using the above described
technique you can handle intermittent, large loads, because if there are
more requests than available resources (threads) at any given time, the
requests will simply be put in a queue and handled later. However, if the
over-load continues for a prolonged period of time, the queue will simply
grow and grow and grow until the partition crashes and all queued items will
be lost.
Then it is time for load-balancing. You install several additional servers
and run a serverprocess on each of these machines. And you use a router that
distributes calls across the different serverprocesses. Forte has built-in
mechanisms for that, that work reasonably well. However, if the amount of
calls per second is so high, that even the short time it takes the router to
relay the request still is too long, so that the router runs out of
resources, then you have to use more complex models, for which Forte doesn't
have any ready-to-use solutions. But neither does CORBA or Java I believe.
One more thing. If you combine the above described mechanism to free sockets
as quickly as possible and use Forte loadbalancing, you might solve all your
problems. Just install 6 overloaded server processes. This results in 6
processes times 256 threads per process equals 1536 simultaneous tasks. If
each task is an asynchronous method invocation that immediately frees its
socket, then you never block you're whole server by using all sockets and
you're still able to do handle 1536 requests simultaneously.
Remember, if you have such a large load of calls per second, that all pass
through the same machine (router) then you'll run into hardware limitations
and no software solution can fix that. You have to find a mechanism to
distribute calls across different nodes without using a single router. For
example, cluster clients and have a single server node per cluster.
Pascal.
-----Original Message-----
From: Babu Raj [SMTP:ibcsmartboyyahoo.com]
Sent: Friday, March 24, 2000 3:42 PM
To: Rottier, Pascal
Cc: kamranaminyahoo.com
Subject: RE: (forte-users) RMI Performance Comp. with Forte
Hi,
I believe in CORBA, ORB maintains the same
connection ( Same Socket) for multiple calls, on the
same Servant object, unless otherwise its ONEWAY call.
But RMI uses the same strategy as Forte, I'm not sure
either on this. Thats the reason, i asked the previous
question.
Thankx,
Babu
--- "Rottier, Pascal" <Rottier.Pascalpmintl.ch>
wrote:
How are CORBA and RMI different then Forte (one
socket and one thread per
call)?
-----Original Message-----
From: Babu Raj [SMTP:ibcsmartboyyahoo.com]
Sent: Friday, March 24, 2000 3:18 PM
To: kamranaminyahoo.com
Subject: (forte-users) RMI Performance Comp. withForte
Hi All,
I know that this topic has been discussed on thelist
already, but I would like to find out whether the
current state of Sun's RMI implementation is like
I imagine it, and I want to compare with our Forte
Service objects too. Basically, these seem to be
issues that negatively affect performance,
1. A thread is created on the server per request,and
there is no way to change this easily (i.e. reuse
threads from a pool)
2. Each call opens a new socket.
In particular, does it make sense to replace RMIwith
CORBA for increased performance and scalability?Can a
PC-based server handle loads of about 1000 remote
calls per second (considering the overhead imposedby
RMI/other communication methods only)? or Shall we
compare Forte against RMI.
Thankx,
Babu
For the archives, go to:
http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. Tounsubscribe, send in a new
email the word: 'Unsubscribe' to:forte-users-requestlists.xpedior.com
For the archives, go to:
http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To
unsubscribe, send in a new
email the word: 'Unsubscribe' to:
forte-users-requestlists.xpedior.com
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: forte-users-requestlists.xpedior.com

RMI-IIOP vs WL RMI performance

Hi,
We did some performance test of WebLogic RMI and under high load (500-1000
users), it is rather slow. It is even slower with an EJB interface. If we
were to used IIOP as the underlying transport protocol, will it improve?
Would you have any other suggestions for improving performance?
Thanks
MC

Hi,
Thanks for your reply.
What I am interested in is the performance of RMI where multiple clients
e.g. JSPs, all make requests to the same object, as that is what will happen
in real life. Benchmarking with a single multi-threaded JVM client was not
recommended - but it seems that JSP may be executed on a single
multi-threaded JVM client anyway, depending on the Web Server of course.
Currently, I don't understand how the server-server benchmarking that you
proposed would work so if you could elaborate on it, that would be great.
Thanks again,
MC
"Don Ferguson" <[email protected]> wrote in message
news:[email protected]..
Yes, increasing the thread count will definately help. And note also thata
WebLogic server has different default configuration values than a WebLogic
client, so if you want to benchmark server-server performance, you reallyneed
to use a server.
mcn wrote:
Hi Andy,
Indeed, I was testing using a single multi-threaded JVM client. However,
isn't that the case if I were to use a web server and have 500-1000
JSP's
invoking methods on the same object? What is the work around?
Also, I had the executeThreadCount at the default value of 15. Willdoubling
it help?
Thanks
MC
"Andy Piper" <[email protected]> wrote in message
news:[email protected]..
"mcn" <[email protected]> writes:
We did some performance test of WebLogic RMI and under high load
(500-1000
users), it is rather slow. It is even slower with an EJB interface.
If
we
were to used IIOP as the underlying transport protocol, will it
improve?
Would you have any other suggestions for improving performance?It is likely that you have some config issue (heap size, number of
threads etc) since RMI is known to scale pretty well. Using IIOP will
not improve things. Also make sure you are not making the classic
mistake of invoking from a single multi-threaded JVM client since this
will multiplex all calls over the same connection.
andy

RMI performances

Hi, i should make a question, for the performaces of RMI.
I have created a software completely in Java and SQL. It's a software client-server, and it works with socket tcp (java.net). Now i'm doing the tests, but i view that a client for find the server wait 15 sec. If i want to use a "select" in mySQL (on server), i must wait too time. I thought to change my tecnology from Socket TCP to RMI, to have better performance.
But, before to do 5000 job's hours, i would like to know if RMI can resolve my problems.
Anyone knows that?
thank's and sorry for my english :-)
nickponico

generally, it wont make much difference...
im guessing that the bottleneck lies on the acessing / querying the database, in wich case changing to RMI (or CORBA or whatever) wont make any difference...
keep in mind that just changing the underlying technology wont have much effect, now that you have it working under plain socket (RMI may present some improvements, but it will be overwhelmed by huge amount of data transfered, etc)...
cheers

RMI overhead

I am having issues with RMI performance. I have a simple test set up between two machines using RMI to send and return arbitrary objects using a single method. Here is a simplified version of the code I am using.
The dispatchCommand method is invoked on the following UnicastRemoteObject class, which uses the SocketFactory classes:
public class GatewayImp extends UnicastRemoteObject
        implements GatewayHandle_Gateway {
    public GatewayImp (int port) throws Exception {
        super(sslPort,
                new CiRMIClientSocketFactory(),
                new CiRMIServerSocketFactory());
    public Object dispatchCommand(Command c) throws RemoteException {
        //Command is a POJO object
I have implementedthe createSocket methods in RMIClientSocketFactory and RMIServerSocketFactory as follows:
public class CiRMIServerSocketFactory extends java.rmi.server.RMISocketFactory
     implements Serializable {
    public ServerSocket createServerSocket(int port) throws IOException {
        return new ServerSocket(port);
and
public class CiRMIClientSocketFactory extends java.rmi.server.RMISocketFactory
        implements Serializable {
    public Socket createSocket(String host, int port) throws IOException {
        return new Socket(host, port);
}The issue is that RMI appears to perform poorly, issuing only about 5-20 method calls per second even when tested on a single machine (512MB, Linux). I also ran it through a profiler and found that RMI socket creation was using most of the CPU cycles. I have tried various techniques I have seen, such as reducing client socket creation by implementing the hashCode method on the SocketFactory but the performance is the same. Since the createSocket methods are called by the JVM, I would like to know whether there are any system configuration parameters that could be used to reduce the RMI overhead?

Thank you. I have tried this by configuring the /etc/hosts and disabling all network connections, and it has improved the performance by about 30%.
I would also like to know whether there are any sun.rmi or java.rmi parameters which are likely to lead to significant improvements in performance, or if there is somewhere I can find documentation on the subject. I have so far tried
-Djava.rmi.server.hostname=127.0.0.1
-Djava.rmi.server.disableHttp=true
-Dsun.rmi.log.debug=false
as well as programatically setting the following socket settings for the socket that is created by the socket factory:
socket.setSendBufferSize(1024*1025);
socket.setReceiveBufferSize(1024*1025);
socket.setReuseAddress(true);
socket.setTcpNoDelay(true);
which have led to a slight increase in performance.
Also, are there any test results measuring RMI calls per second available, which I could use as a benchmark?
Many thanks in advance.

Using RMI to synchronize two databases

Hello
I have studied Java for some time, but never had
the opportunity to work in a "real project", but
now I have something to do...
I have the following situation: two offices
of a company, the central one running SQL Server
database and other running Oracle, must change
information, reading data from Oracle and saving in
SQLServer and vice-versa. The programs should be
running all day, checking at specified periods of
time if there is some information to be updated
in any database.
The offices are phisically far, so it should be
used Internet to make the connection (both sites
are connected to Internet 24h).
I was wondering on using the Java RMI technology
to achieve this. I have read the official Sun
documentation about RMI and some articles, and I
found it very interesting, and pretty easy to
implement.
But I have some "real world" questions:
- Is RMI the ideal solution for this problem, or
there is some newer or more adequate one?
- At first it would be a small amount of data
to be synchronized, but if it grows a lot or
more offices are to be connected, is RMI performance
good? (is it quick?)
- About security - is RMI secure? I mean, I think
the server program should be listening a port in a
IP address open to ALL the internet... How safe is
the user authentication, or this is responsability of
the application?
- What is the relationship between RMI and proxies,
firewalls etc? Are they compatible?
- XML is something to think about using for this
application, or it have nothing to do to the job?
The initial option was using a Microsoft solution
to make this application :(, but I would be very happy
if I could use Java ;) , but I have to have the
adequate technical base to suggest it...
So, any help would be very welcome!
Luis Cabral

Here's a set of (some) answers based on my experience (which is NOT synchronizing two databases, but on synchronizing sets of files across a tree of file servers.)
Hello
1. It sounds like two databases must be cross-synchronized. You didn't say what the platforms were, but if they are mixed, then java is a positive choice.
2. Java rmi is fine for doing this kind of work. However I can't give you any performance guarantees. You probably need to get some fine requirements and write some model programs.
3. YOU are responsible for security. RMI gives you connectability; you have to develop some kind of cross-authentication procedure as part of you application.
4. To work over the internet, you will have to develop some way through firewalls.
o If the two sites use "Virtual private networks", then both the security issue and the firewall issue are mostly solved for you.
o Otherwise, and maybe even with vpn, you will have to do a little bit of work to use fixed port numbers. (The way rmi works is that there is a listener at a fixed port which will let a remote program "look up" a local object; after that, communication takes place object-object over a randomly-assigned port.) It takes about a dozen lines of code to make this work.
5. I don't think XML has anything to do with this problem. It MAY help you if you have serious data conversion issues. I hear it's a pig.
Finally, an application item that may or may not be an issue: Two databases, two platforms == possible character set conversion problems.

A right communication mechanism

Hi, all,
Here is a situation for a client/server application:
the server coded in C++;
a client is needed, but not browser since its UI is not rich enough.
I'm thinking about to have Java client distributed and launched by Java Web Start. The rest of question is the communication mechanism.
The followings are the choices I can come out:
socket - go through a firewall? need JNI on the server side?
RMI - performance? need JNI on the server side?
http protocol - need Java web server. JNI on the server side.
SOAP - Is it suitable for a non-complex application?
Any suggestions?
Thanks in advance.

The answer to your question depends on the following:
1. How complex is the C++ server's API?
2. Is the API DCOM, CORBA, what?
3. Is the server behind a firewall? Is it exclusively intranet, or should it be exposed externally?
socket - go through a firewall? need JNI on the server
side? Socket are always "fine" -- they are the foundation for most RPC protocols. But you would have to roll your own protocol, which may or may not be satisfactory depending on the complexity of your API i.e., you probably need client-side Java stubs of some sort representing the interface[s] in your server API as well as Java versions of classes used for the arguments in the API. The stubs would be responsible for marshalling calls to the server -- serializing the arguments e.g., in XML. The server, then, would need to process the socket calls typically using skeleton API classes to deserialize the args and call the existing APIs. Of course, SOAP much of this nastiness already and is also firewall friendly -- HTTP.
RMI - performance? need JNI on the server side?RMI/IIOP is fine if you don't mind CORBA and aren't concerned about firewall issues.
http protocol - need Java web server. JNI on the
server side.Unless your API is terribly simple, use SOAP if you are considering HTTP...
SOAP - Is it suitable for a non-complex application?Unless your server is and always will be internal/intranet-only, SOAP is probably the most reasonable solution.

WebLogic RMI UNIX Performance problem

Hi.
I'm experiencing problems with the performance of RMI calls from within session
beans to external RMI services. I have a system running 4 RMI services in separate
JVMs to weblogic 6.1 instance on Solaris 2.6 on SPARC boxes with 1+ Gb of RAM.
The system was developed on NT and deployed to UNIX. A typical request is serviced
in 70-90 ms on the NT development box (Desktop 512Mb RAM) but when deployed to
the UNIX box takes anywhere between 500-4000 ms. Performance metrics in the code
indicate that 'crunch' times are similar but remote RMI calls are orders of magnitude
greater.
Has anybody had similar problems? I have checked the tuning guides wrt TCP/IP
configurations but would not expect such a large difference using the default
Solaris configuration. Memory and CPU utilisation on the SPARC are low as are
I/O and other metrics available from vmstat.
Cheers
Pete

Hi.
The JVMs are running on the same machine thus should be looking in /etc/hosts
and not going via DNS.
I have read there is a performance gain by tying WL to a single CPU, any insight?
Pete
Andy Piper <[email protected]> wrote:
"Pete Harris" <[email protected]> writes:
I'm experiencing problems with the performance of RMI calls from withinsession
beans to external RMI services. I have a system running 4 RMI servicesin separate
JVMs to weblogic 6.1 instance on Solaris 2.6 on SPARC boxes with 1+Gb of RAM.
The system was developed on NT and deployed to UNIX. A typical requestis serviced
in 70-90 ms on the NT development box (Desktop 512Mb RAM) but whendeployed to
the UNIX box takes anywhere between 500-4000 ms. Performance metricsin the code
indicate that 'crunch' times are similar but remote RMI calls are ordersof magnitude
greater.
Has anybody had similar problems? I have checked the tuning guideswrt TCP/IP
configurations but would not expect such a large difference using thedefault
Solaris configuration. Memory and CPU utilisation on the SPARC arelow as are
I/O and other metrics available from vmstat.Its possible that you are getting a DNS lookup for each request or
worse a reverse lookup. You might want to try using IP addresses in
your config to see if that helps.
andy

Can i using RMI to solve performance issue

I have two database which in USA and CHINA, and a web application which located on USA, if the application connect to USA DB it is ok, i think no performance issue, but if connet to china DB, i sure that has even throgh VPN. So can i using RIM technology to solving the issue? Or using another solution. Thanks

So can i using RIM technology to solving the issue?It sounds like your problem is with Network latency.
I assume your web application connects to the database directly through JDBC and you're proposing to add a middle layer of RMI. Doing this will not reduce network latency - however if you're clever about how you serialize your resultsets, you can reduce the amount of network traffic and improve performance.
Have a look at this thread about compressing RMI data:
http://forum.java.sun.com/thread.jspa?threadID=606187&tstart=0
Note that compressing the data will add processing overhead at both ends.
Also remember to override the readObject/writeObject methods in the objects you're serializing.

RMI and SSL performance

I was wondering if there is documentation on the performance hit that I can expect when converting my RMI based app from non-SSL to SSL. I cannot find any information on this.
What have people experienced?
Thank you.

You can expect a long delay, 10-20 seconds, when you implicitly or explictly create a javax.net.ssl.SSLContext, due to seeding the initial SecureRandom(). This should only happen once: you can take it out of line of the communications by creating and initializing the SSLContext during startup; you can do this in a separate thread. You should expect new connections to be several times as slow due to the SSL handshake, and you should expect transmission times to be several times what they are now due to encryption. Finally, because of all the extra computation you should then expect your servers to be much more busy, which will increase queue lengths and therefore latencies at clients.
By 'several' I mean in the range 2 to 10, but it all depends on your hardware. You should consider using an HSM at the server.

Comparing performance of CORBA/RMI/RMI-IIOP

I would like to compare CORBA, RMI and RMI-IIOP.
Is there any s/w available, pref open source, in java to perforam benchmarking in some or all of the three.
Anything which also supports C++ would be a plus.
I know there is some data already available, but I would like to be able to perform my own tests on my platform. prob linux and linux cluster.

CORBA is supported by Windows machines (Windows XP/2000 as I know of it) and other APIs may be bought or included in some enterprise applications.
RMI and CORBA are about as fast as each other. RMI-IIOP is slower then RMI and CORBA, however, it can sometimes go a little faster depending on deployment and environment.

RMI connections performance

I am having problems looking up a RMI object. The Weblogic console reports
the following:
Wed Apr 12 23:32:11 EDT 2000:<W> <ListenThread> Connection rejected:
Login timed out after 5000 msec. The socket came from
host=10.0.3.13,port=1140,localport=7001] See property
weblogic.login.readTimeoutMillis.
Wed Apr 12 23:32:22 EDT 2000:<W> <ListenThread> Connection rejected:
Login timed out after 5000 msec. The socket came from
host=10.0.3.13,port=1141,localport=7001] See property
weblogic.login.readTimeoutMillis.
Wed Apr 12 23:32:24 EDT 2000:<W> <ListenThread> Connection rejected:
Login timed out after 5000 msec. The socket came from
host=10.0.3.13,port=1143,localport=7001] See property
weblogic.login.readTimeoutMillis.
I get about 3 time out errors and it takes almost a full minute before the
bind happens. The chunk of code that does the bind is included below:
String rmiHostAndPort = "t3://localhost:7001/foo"
System.out.println("Binding to " + rmiHostAndPort);
IFoo foo =
(IFoo) Naming.lookup(rmiHostAndPort);
System.out.println("Bound to " + rmiHostAndPort);
The time between "binding to" and "bound to" is slow. Sometimes, it does
not even return at all. This happens when the applet is restarted for some
obscure reason.
Any help would be appreciated.
Erik Currin
[email protected]

I am having problems looking up a RMI object. The Weblogic console reports
the following:
Wed Apr 12 23:32:11 EDT 2000:<W> <ListenThread> Connection rejected:
Login timed out after 5000 msec. The socket came from
host=10.0.3.13,port=1140,localport=7001] See property
weblogic.login.readTimeoutMillis.
Wed Apr 12 23:32:22 EDT 2000:<W> <ListenThread> Connection rejected:
Login timed out after 5000 msec. The socket came from
host=10.0.3.13,port=1141,localport=7001] See property
weblogic.login.readTimeoutMillis.
Wed Apr 12 23:32:24 EDT 2000:<W> <ListenThread> Connection rejected:
Login timed out after 5000 msec. The socket came from
host=10.0.3.13,port=1143,localport=7001] See property
weblogic.login.readTimeoutMillis.
I get about 3 time out errors and it takes almost a full minute before the
bind happens. The chunk of code that does the bind is included below:
String rmiHostAndPort = "t3://localhost:7001/foo"
System.out.println("Binding to " + rmiHostAndPort);
IFoo foo =
(IFoo) Naming.lookup(rmiHostAndPort);
System.out.println("Bound to " + rmiHostAndPort);
The time between "binding to" and "bound to" is slow. Sometimes, it does
not even return at all. This happens when the applet is restarted for some
obscure reason.
Any help would be appreciated.
Erik Currin
[email protected]

Performance: RMI vs JavaSpaces

Hi, I'm new in making distributed applications using Java language.
My question is, which technology should I use: core RMI or JavaSpaces? The project, which I'm making is a simple real-time-strategy game engine. I'm looking for technology, which generate the lowest network traffic. In first phases of my project I was programming using sockets and my own protocol. But it was hard to extend the existing system. So, I've decided to use some higher-level technology like RMI or JavaSpaces (I guess, that EJB is not quite good option :).

Logical connections at the application level aren't persistant for RMI. Request/response like http. With a regular tcp socket you can push data back to a client unprompted. Useful in online games where the game state is being updated in real-time. RMI clients initiate function calls at regular intervals to get updates. Significant for minimizing network usage as there can be no fresh data to retrieve. So the more often you update the more current (real-time) you are, but the more data you push across the network.

Several JVM s with RMI?

Hi,
As you can guess, my Java program needs more and more memory as users connections grow.
We are of course trying to optimize the way its running but looks like we will anyway soon need to increase ressources of our JVM.
We first thought to increase memory heap but there is a limit, on any 32 bit system 4Go seems the theoretical maximum ram size. And we have to keep a 32 bit JVM, cant change this.
Here is our next idea: we would like to run our program on several JVMs.
Two options came then, and so here are my question: (maybe irrelevant for experts but I am a beginner regarding distributed architecture, so feel free to give me some reference to learn about it)
-First option: several 32 bit JVMs running together on one 64bits machine
Is it possible to run several 32 bit JVM (jre 1.5) on a windows (or linux) 64 bits machine? So that we could share the system (big) ram between each of them.
Is there, in this case, a limit for the memory heap per JVM?
What would be in this case the best way to communicate between jvms (I m thinking about RMI, but is it the only way to?)
-Second option: run several 32bits JVM on several 32 bits machine.
Questions are the same here:
is it possible? I guess so, and would it be worse or better from a performance/learning time point of view, compare to option 1?
Is RMI the best way here to make the several jvm communicate?
Hope this is clear, english is not my first language so feel free to ask me any precision
Thank you very much for any help or reference.
Jipe

Multiple JVMs dont have any inherent special behavior on the same maching. However, you must consider the shared resources of that machine such as ports and files that may be contended for.
The only advantage of multiple JVMs of single JVMs is an OS one. The JVMs are separate processes and as such if one crashes it will not bring the other down.
If you want to transfer user sessions from one JVM to another, no matter if on the same computer or not, you will need an architecture to support this. That is where application servers come in. Some of them will allow you to do this. So if you design your product to run in an application server, you have a lot of room to expand. That is really the benefit of designing for an application server.
The details of a shared session are likely very complicated. You will have to ask the application server folks about that. Maybe go over to the JBoss forums.

RMI : error on JRE 1.6 but not on JRE 1.5 ???

Hello,
I've got a problem with my application since i use JRE 1.6
My application run perfectly with JRE 1.5 !!!
My code is first :
LocateRegistry.createRegistry(port);
NamingManager.setInitialContextFactoryBuilder(new InitialServerContextFactory());
NamingManager.getInitialContext(environment);(with environment is an hastable containing HOST et PORT)
An next, i have a Java Class witch impl�ments Context :
public class InitialServerContext implements Context
    public void bind(String name, Object obj) throws NamingException
          getRMIContext().bind("rmi://" + mServer + ':' + mPort + '/' + name, obj);
    static Context getRMIContext() throws NamingException
          return NamingManager.getURLContext("rmi", null);
The error on JRE 1.6 is on the line :
getRMIContext().bind("rmi://" + mServer + ':' + mPort + '/' + name, obj);
_Exception is
:_java.lang.NullPointerException
at com.sun.jndi.rmi.registry.RegistryContext.<init>(Unknown Source)
at com.sun.jndi.url.rmi.rmiURLContext.getRootURLContext(Unknown Source)
at com.sun.jndi.toolkit.url.GenericURLContext.bind(Unknown Source)
at com.xxx.aes.naming.InitialServerContext.bind(InitialServerContext.java:231)
at com.xxx.aes.naming.InitialServerContextFactory.getInitialContext(InitialServerContextFactory.java:104)
at javax.naming.spi.NamingManager.getInitialContext(Unknown Source)
at com.xxx.aes.server.NamingServer.start(NamingServer.java:65)
What is the difference between JRE 1.5 and 1.6 ?
Why my application in 1.6 is not correct ?
If necessary, i can give you my Java Class InitialServerContextFactory.java
Thanks a lot for your responses.

Hello,
I tired this approach you mentioned, and interestingly if i just make ejb calls without any event handling, meaning if i call them separately they all just work fine and i see the results coming back from server. But when i relate them to any click events the whole IE freezes.
One more thing i noted is that, seems like the way JRE 1.6 render my applet is somewhat different than JRE 1.5.* familiy,because initially when my aplet is loaded, i see everything which should be displayed from the first screen, but any further operations i cannot perform, even opening a file chooser from tool bar. I admit my applet is real heavy and it contains a lot of data in it on the first screen, may be its the heap size causing the problem in 1.6 but fine with jre 1.5.
Day by day am coming to conlusion that jre 1.6 is my concern now ..:(
Thanks,

RMI Performance

Similar Messages

Maybe you are looking for