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.

Similar Messages

How to encapsulate RMI in Http request ?

Hello,
I have an java applet that uses java RMI technology to communicate with the server. I would like to modify this architecture a little. Is it possible to wrappe RMI invocation in http web request. If yes how to do that ? Did you have samples of code ?
Thanks a lot.

RMI uses a specialised protocol which is more complex than it appears at first. It might be possible to perform RMI calls use a HTTP transport, but you would lose most of the value of using HTTP.
There are libraries which allow you to turn method calls into HTTP Web Service request, like RMI does, but no RMI is used.

RMI optimizations (stub sharing, local calls)

Hi,
Suppose I have the following scenario involving one client and one server:
1. the server exports a RMI object implementing "MyInterface" with a method "void op(MyInterface myObject)"
2. the client obtains two references to the same remote object instance, lets call them myObjectRef1 and myObjectRef2
3. the client calls the given method with one of the obtained references as a parameter, say myObjectRef1.op(myObjectRef2);
My two questions are:
In step 2: Will the RMI implementation automatically recognize that both remote reference point to the same object instance and use one shared stub? Or will there be two totally independent stubs?
In step 3: When the client invokes the method, the stub that is passed points to a RMI object that could be accessed via a local object reference on the server that is executing the method.
Theroretically either the serialized stub could be substituted by a local object reference when the method call is unmarshalled or at least upon invoking a method on the stub, the RMI system could optimize away marshalling and TCP/IP by directly calling the implementation method in the RemoteRef.invoke method. Is there some optimization like this in the Sun RMI implementation? Or is it totally unaware of such scenarios and just performs a remote call involving marshalling+TCP/IP communication?
Thanks for your replys.

In step 2: Will the RMI implementation automatically recognize that both remote reference point to the same object instance and use one shared stub? Or will there be two totally independent stubs?As a matter of fact there is a shared stub at the remote object, but by the time they're acquired by the client they will be distinct, because of serialization over distinct ObjectOutputStreams (a new one per call). But why would it matter to you either way? How could you even tell? The stubs all point to the same remote object, and the equals() methods return true.
In step 3: When the client invokes the method, the stub that is passed points to a RMI object that could be accessed via a local object reference on the server that is executing the method.If it's a stub it will always perform RMI.
Theroretically either the serialized stub could be substituted by a local object reference when the method call is unmarshalled or at least upon invoking a method on the stub, the RMI system could optimize away marshalling and TCP/IP by directly calling the implementation method in the RemoteRef.invoke method.No, it can't. That would change the pass-by-copy semantics of RMI into pass-by-value as in local method invocation. It can't do that.
Is there some optimization like this in the Sun RMI implementation?No. Nor in IBM's either.

INFORMIX and ORACLE on LINUX

Hello Stephen,
some time ago we talked about Forte for LINUX. Now I think it will need
not a long time that Forte is available on LINUX.
INFORMIX and ORACLE has officially announced that they offer their
Database on LINUX. Now it is only a question of time, that Forte
got a business-case from big Firms which want to see Forte on LINUX.
In GERMANY I know that Mercedes use LINUX for car-development and
Sixt-Budget use LINUX for their car-rental (worldwide).
I think, if Forte is availaible for LINUX than a big beng goes through
the IT-Market. Many firms just wait for a OO-orientated 4GL-Development
environment to distribute their business-processes to many little
servers which are cheap and powerfull. It is than a question of
less money to use a big machine or just 10 or 20 LINUX servers (which are
cheaper and faster).
Sorry for my enthusiasm on this mailing list, but i'am
so happy to hear from this and want's to cry it out all over the world :-)))))
Joseph Mirwald

At 09:03 AM 8/22/98 +0200, Joseph Mirwald wrote:
Hello Stephen,
some time ago we talked about Forte for LINUX. Now I think it will need
not a long time that Forte is available on LINUX.Well, I suspect if you ask them, the official policy statement is: Linux is
not a supported platform at this time, and we cannot discuss unannounced
products. (or some such thing). Privately, talking to some of the Forte
people at FORUM this year, I was distinctly left with the impression that
it will be a cold day in hell before such a port is done.
INFORMIX and ORACLE has officially announced that they offer their
Database on LINUX. Now it is only a question of time, that Forte
got a business-case from big Firms which want to see Forte on LINUX.Well, I haven't talked to our Oracle sales rep, but I did go to their web
site and I couldn't find anywhere where you could download it, or much more
than a "how great it is" statement. Based upon my prior dealings with
Oracle, and some well documented cases, I would be surprised if you could
get it today - delivered and working, that is.
Informix, on the other hand, I just downloaded (not installed yet, but at
least I have in my hot little paws something that says it will be Informix
on Linux).
One of the problems that Forte faces in the marketplace is the cost of the
product. Yes, it does a lot (personally, I'm quite a fan). But, some IT
shops - especially the ones that have capable people on staff - are
beginning to look at the distributed object characteristics of Java and
asking "Why can't I do what I want with Java RMI, etc.?" When I talked to a
Forte salesman at FORUM, his only response was "Well, those really aren't
Forte customers anyway!" As Java adds things like transactional objects,
transparent database access (yup! persistent objects in a relational
database - without all the coding - and with performance too!), JavaSpaces,
Jini, etc. I think it's a "head in the sand" approach for Forte to ignore
this. To me, Java presents some very compelling features. And, according to
some friends I have inside of Sun, basically all of the brightest people in
Sun have all migrated over to doing the Java stuff, so it's only likely to
get better. People like Rick Cattel (databases) and Jim Waldo (distributed
object systems) who have been giving this stuff lots of thought for
years!! That's why it's so well thought out when you see it for the first
time.
The only glaring omission from it seems to be a generic event queue
mechanism. Fortunately, given the other stuff Java has to offer (RMI, event
classes, etc.) you can build a very good one in about a man week. In fact,
Java has one, they just didn't take a "high" enough superclass - they
limited it to AWT events. If they had made it all events, you wouldn't even
have to build that.
Now, don't get me wrong... Forte is planning to incorporate lots of really
cool Java stuff in their next release (preannounced at FORUM). But to me,
that's not the issue on a larger scale. The real issue is this: are
environments which are cheaper incorporating a lot of what Forte does - and
the answer is Yes! Incidentally, there is a version of the Java environment
being developed for Linux under the GNU license, for the express purpose of
making it open and keeping it free (and open). Someone recently told me
that it is now available, but I haven't confirmed that yet.
In GERMANY I know that Mercedes use LINUX for car-development and
Sixt-Budget use LINUX for their car-rental (worldwide).My perception is that the Europeans are more progressive and cooperative
than us in the states. Most of the really good Linux help I've gotten on
the net has been form Europe (including a wonderful sendmail
site/expert). :-)
I think, if Forte is availaible for LINUX than a big beng goes through
the IT-Market. Many firms just wait for a OO-orientated 4GL-Development
environment to distribute their business-processes to many little
servers which are cheap and powerfull. It is than a question of
less money to use a big machine or just 10 or 20 LINUX servers (which are
cheaper and faster).Well, as I was indicating above, people who are cost conscious might be
searching for lower cost alternatives to Forte itself.
Sorry for my enthusiasm on this mailing list, but i'am
so happy to hear from this and want's to cry it out all over the world:-)))))
<soapbox>
So, who says that all reactions have to be between 4 & 6 (5 being
neutral)!! Don't apologize. If you're excited - be excited! That's what
life is all about.
</soapbox>
Stephen

TIBCO , to pass variables in http request

Hi guys,
I am very new to tibco, I need to invoke a actionservlet via HTTP request, I am able to pass constant values but not the variables.
For example,
http://172.17.33.107:8988/ITProjectMonitoringTool//Login.do?xyz="6667"
The above one is working.
But if I am using the following one , I am not able to do it. It is literally printing the value ..
http://172.17.33.107:8988/ITProjectMonitoringTool//Login.do?xyz="helloVar"
where helloVar is a variable, where do i need to set this variable value. when I am trying to retrieve the "helloVar" variable value, "helloVar" is getting printed as it is.
Please help me out.
Regards,
Gautham

RMI uses a specialised protocol which is more complex than it appears at first. It might be possible to perform RMI calls use a HTTP transport, but you would lose most of the value of using HTTP.
There are libraries which allow you to turn method calls into HTTP Web Service request, like RMI does, but no RMI is used.

Forum Project: Most common misunderstandings people have

Hi all
I know this is a holiday weekend and all so there might be fewer people using the java boards. But I thought it might be fun to colaboratively put together a little list of common misconceptions that people have in the java world. I am starting this of with a common misconception about I/O
=======
Common misconception: Using a BufferedInputStream or a BufferedReader will make all reading faster
Answer: Using a buffer will only make your reads faster if you are doing inefficient reading, meaning for example that rather than load a whole file in one big chunk you are reading line by line.

tjacobs01 wrote:
1. How do you know your buffer is going to be big enough?I use the same buffer size on the client. Which is an advantage of a closed system. (Actually its a bit more complicated, the client and server exchange the maximum message size on connection and take the highest of these two values)
2. Assuming that once you've done a read, you copy the data somewhere else and effectively flush the buffer / start at 0 again, you have to do a whole bunch of extra work if the buffer is completely filled by the incoming data and there is no more waiting.I have a large buffer like 256KB or 1 MB so a message always fits into the buffer.
What I do is have the size of the message at the start and a minimum message size of 256 bytes.
So I read 256 bytes which is often all I need, but if the length is longer I read the full length. This gives me one message with no need for copying. (And I use DirectByteBuffer)
It also gives me the message in a single read.
Maybe I just don't understand your solution entirely. It goes back to question 1. That wouldn't be surprising. I make a few assumptions. :)
The other thing is that the call to available() in socket reading effectively costs you nothing - the bottleneck is the rate at which data is coming in through the socket.I find the number of calls you make also creates overhead...
BTW: My solution is for server to server communications so I can assume there is a small number (<100) of controlled connections but there is a high volume of data which requires a low latency.
The solution (with custom serialization/RMI) can perform RMI calls as low at 20 us. (on loopback) and 110 us on a LAN. And send over 100,000 message per second over a single channel.
The custom serialization support serialization to/from DirectByteBuffer.

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

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-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 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.

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

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]

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

Performance: RMI vs JavaSpaces

Similar Messages

Maybe you are looking for