• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

RMI CodeBase => slowdown

 
R Bischof
Ranch Hand
Posts: 48
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
I am using JDK1.3 on W2K.
As soon as I set the codebase for RMI the connect from the client to the server slows down signifcantly. From subsecond to around 25 seconds...
I have the stubs only in the server.jar, so I need the dynamic class loading.
My codebase setting is:
-Djava.rmi.server.codebase=file://c//fbn/fbn_server.jar
BUT: this happens only when I have the network enabled. If I unplug my network everything works fine.
If I use server & client with the network enabled and afterwards disable the networking I can continue to use the still running client instance. But if I start another client I get an error indicating that my previous IP can't be reached (no route to host).
I could understand this if I used an http codebase but for file??
Any ideas?
thx
Rainer
 
Rasika Chitnis
Ranch Hand
Posts: 131
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
what do you mean "network enabled" ?? The reason for performance degradation could be because of the dynamic downloading of the stub file which involves serialization. I am using dynamic downloading also and actually re-considering copying the stub file on client and avoid dynamic download.
 
R Bischof
Ranch Hand
Posts: 48
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Rasika,
"network enabled" in this case just means: I have my network cable plugged in, so the network adapter is active. That means that my machine has an IP address provided by the DHCP host. If it is unplugged my machine has only the 127.0.0.1 loopback IP.
The main thing I just don't understand: I am using a file based codebase. nevertheles the system tries to connect to the network, I can see some activity in my network monitor.
Unfortunately serialization can't be an issue as it must be performed for every RMI call, no matter if this call goes through a real network or the "virtual" loopback adapter. Also serialization is pretty fast, somewhere in the area of a millisecond for typical objects.
I have the impression that for some reason the system tries to resolve my machine's name. But why does it do this just because of the Codebase?
Before including the codebase I had the stubs in the client JAR as well and everything worked fine without a delay. Although I tried all machine names (real name, IP, localhost).
thx
Rainer
 
R Bischof
Ranch Hand
Posts: 48
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all,
It's getting funny:
I have access to a server located in the public internet.
I just tried to run my FBN Server on that machine, using a codebase
-Djava.rmi.server.codebase=http://62.27.24.100/fbn_server.jar
The client has to connect to that machine (slow ISDN), identify that it does not have the stub classes and download the complete 25kb fbn_server.jar via HTTP to get it.
It takes only around 5 seconds to connect _and_ perform the initial search for all flights.
Funny.
I need some help. Anyone?
Thx
Rainer
 
kerry shih
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have experienced the same problem with Weblogic and their t3 protocal. It really sounds like a Windows dns timeout and the "default" ip address is used (which is why it probably still works). If you haven't tried already, use your full ip address ie (192.168.etc) or machine name in your URL, and / or try putting a static reference in your hosts file and try using that name.
Kerry
 
R Bischof
Ranch Hand
Posts: 48
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Kerry,
I tried all combinations of IP, computer name, 127.0.0.1, localhost, I hacked my HOSTS file, etc.
No difference. The only thing I found was that the delay depends on the netwrok connected:
No network: subsecond
LAN at home: 10 secs
LAN at work: 15 secs
LAN at home connected to the internet: 25-30 secs
Funny but not really satisfying...
Thx
Rainer
 
Rasika Chitnis
Ranch Hand
Posts: 131
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Rainer,
Have you tried setting hostname property in addition to codebase property when you run server ? I am not sure if it helps but you can try.
Also, does your server and client have to be in same domain for dynamic stub downloading to work ? or it does not matter ? Are you also setting codebase property on client side as well ?
When I run my client I have included following line in the policy file on client side :
permission java.io.FilePermission "d:\\scjd\\starting\\-", "read";
server is installed in "d:\scjd\starting" directory. If I omit this line I get run time error "access denied to class loader" when I run the client. I am not sure why adding this line in client policy file is necessary beacuse I set the codebase property when I run the server and I have following line in the serevr policy file :
permission java.io.FilePermission ".\\-", "read, write";
any ideas ??
Thanks
Rasika
 
R Bischof
Ranch Hand
Posts: 48
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Rasika,
I just tried the hostname property. No difference.
The domain does not matter. When working with both client and server on the same machine I use the file::// protocol for the codebase. Therefore no class definition should go over the network.
When working with my server on the internet I use the http:// protocol for the codebase. In this case the classdefinitions go over the wire.
The later is much faster...

Regarding your security issues:
The process of dynamic downloads as I understand it is as follows:
The client performs an RMI call and receives a class identifier that it does not know. It asks the RMI server for the codebase. The client uses the codebase to download the class definition. The server does _not_ stream the class to the client but only the information where to find it.
That means that the classloader of the client has to access "d:\\scjd\starting\\-" to find the stub that is missing in it's classpath. If it does not have the required permissions it throws a security exception.

That is one of the reasons why I decided to provide a completely open policy file and explain it in the decisions document. You can't ask the SUN guys to edit your policy files to match their environment (paths, hostnames, etc).
If I keep having this trouble I will do the same for the codebase issue and simply put the stub in the client jar. >:-[
Rainer
 
Rasika Chitnis
Ranch Hand
Posts: 131
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I agree with you on copying stub file on client side. I would have preferred to dynamically download the stub, because that is the way you experience the real power of RMI at run time. But I think it is lot of hassle to do right set up. There is also an issue of hard coding server code base path in the client policy file. OR grant full permision as you said.
Although I still do not understand what following line in client policy file does :
permission java.io.FilePermission "d:\\scjd\\starting\\-", "read";
In my opininon this means, client is granting a read permission to the downloaded code for d:\scjd\starting directory on client. I do not understand how this gives client the access to server's class loader ?
 
R Bischof
Ranch Hand
Posts: 48
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Rasika,
I just finalized my package yesterday evening (it's early morning here right now) as I want to upload it today. I decided to remove the dynamic class loading and granted AllPermission to both client and server. I tried for hours a lot of other things. Nothing worked. I was lucky that I used Ant and JUnit so that I did not have to make my own manual tests each time ;-)
The hassle of propertly configuring security and codebase was just too much. I rather accept one or two points reduction because of leaving these things out (I explain why in my docs so I don't expect a redutction) than getting 0 points for a non-working solution...
Reg your security issue I gues I did not explain it clear (not a native english speaker), so I try again:
* You specify a file:// codebase on the server at startup.
* The client needs to download the stubs from the server and asks the server where to find it.
* The server returns the codebase property.
* The client gets the codebase (file://d/scjd/starting)
* The client "downloads" the stubs from that path using it's own Classloader
* This "download" is not really a download: Since you specififed a file:// codebase the client has to access that file to "download" from that file.
This is IMHO the reason why the client needs access to that file. If you use an http:// based codebase you can remove this permission.
Another reason why you would want to grant AllPermission to the client as otherwise you have to ask the assessor to edit your policy file to reflect their path structure which is not allowed.

Rainer
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic