dump problem
I use JDK1.2.2RC3 in Linux to run JServ. I met dump probem in the error log filr. error_log file has msg: "Full thread dump Classic VM (Linux_JDK_RC3,native threads):" "Monitor Cache Dump:" "Registered Monitor Dump:" Detail is followed. Please ask what is dump ? How can I resolve this problem ? How can I do to increase JDK's stability? Thanks. "mod_jserv.log" -- [11/01/2000 07:18:23:659] (INFO) jserv_watchdog:(16187) watchdog_cleanup() [11/01/2000 07:18:23:660] (INFO) Apache Module was cleaned-up [11/01/2000 07:18:23:663] (INFO) Wrapper: Shutting down JServ (PID=16188) (sig 15) [11/01/2000 07:18:23:663] (INFO) wrapper: Terminating JServ (PID=16188, VM PID=16199) [11/01/2000 07:18:23:663] (INFO) ajp12: sending shutdown signal [11/01/2000 07:18:34:178] (INFO) jserv_watchdog:(16502) watchdog_cleanup() [11/01/2000 07:18:34:178] (INFO) Apache Module was cleaned-up [11/01/2000 07:18:37:722] (INFO) wrapper classpath: /usr/lib/apache/ApacheJServ.jar:/home/httpd/classes/servlet-2.0.jar [11/01/2000 07:18:37:723] (INFO) wrapper: Java VM spawned (PID=16514, PPID=16503) [11/01/2000 07:18:47:729] (INFO) wrapper: watching processes (PID=16503,PPID=16502,JVM PID=16514) [11/01/2000 07:22:01:039] (INFO) jserv_watchdog:(16502) watchdog_cleanup() [11/01/2000 07:22:01:040] (INFO) Apache Module was cleaned-up [11/01/2000 07:22:01:043] (INFO) Wrapper: Shutting down JServ (PID=16503) (sig 15) [11/01/2000 07:22:01:043] (INFO) wrapper: Terminating JServ (PID=16503, VM PID=16514) [11/01/2000 07:22:01:043] (INFO) ajp12: sending shutdown signal [11/01/2000 07:22:16:713] (INFO) jserv_watchdog:(16631) watchdog_cleanup() [11/01/2000 07:22:16:714] (INFO) Apache Module was cleaned-up [11/01/2000 07:22:20:252] (INFO) wrapper classpath: /usr/lib/apache/ApacheJServ.jar:/home/httpd/classes/servlet-2.0.jar [11/01/2000 07:22:20:253] (INFO) wrapper: Java VM spawned (PID=16643, PPID=16632) [11/01/2000 07:22:30:259] (INFO) wrapper: watching processes (PID=16632,PPID=16631,JVM PID=16643) "error_log" Full thread dump Classic VM (Linux_JDK_RC3, native threads): "Thread-76" (TID:0x40e851c0, sys_thread_t:0x8272360, state:R, native ID:0x14007) prio=5 at java.net.PlainSocketImpl.socketClose(Native Method) at java.net.PlainSocketImpl.close(PlainSocketImpl.java, Compiled Code) at java.net.ServerSocket.close(ServerSocket.java, Compiled Code) at org.apache.jserv.JServ.clear(JServ.java, Compiled Code) at org.apache.jserv.JServ.terminate(JServ.java, Compiled Code) at org.apache.jserv.JServConnection.readData(JServConnection.java, Compiled Code) at org.apache.jserv.JServConnection.run(JServConnection.java, Compiled Code) at java.lang.Thread.run(Thread.java, Compiled Code) "Thread-1" (TID:0x40e7aef0, sys_thread_t:0x82d3248, state:CW, native ID:0x1406) prio=5 at java.lang.Thread.sleep(Native Method) at org.apache.jserv.JServServletManager.run(JServServletManager.java, Compiled Code) at java.lang.Thread.run(Thread.java, Compiled Code) "Thread-0" (TID:0x40e84000, sys_thread_t:0x81e6900, state:CW, native ID:0x1005) prio=1 at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java, Compiled Code) at org.apache.java.util.SimpleQueue.waitObject(SimpleQueue.java, Compiled Code) at org.apache.java.io.LogWriter$Agent.run(LogWriter.java, Compiled Code) "Finalizer" (TID:0x40e66320, sys_thread_t:0x80d07b0, state:CW, native ID:0xc04) prio=8 at java.lang.Object.wait(Native Method) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java, Compiled Code) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java, Compiled Code) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java, Compiled Code) "Reference Handler" (TID:0x40e663b0, sys_thread_t:0x80ca440, state:CW, native ID:0x803) prio=10 at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java, Compiled Code) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:114) "SIGQUIT handler" (TID:0x40e663e0, sys_thread_t:0x80cfc90, state:R, native ID:0x402) prio=5 "main" (TID:0x40e661e0, sys_thread_t:0x80531d0, state:R, native ID:0x400) prio=5 at java.net.PlainSocketImpl.socketAccept(Native Method) at java.net.PlainSocketImpl.accept(PlainSocketImpl.java, Compiled Code) at java.net.ServerSocket.implAccept(ServerSocket.java, Compiled Code) at java.net.ServerSocket.accept(ServerSocket.java, Compiled Code) at org.apache.java.net.AuthenticatedServerSocket.accept(AuthenticatedServerSock et.java, Compiled Code) at org.apache.jserv.JServ.main(JServ.java, Compiled Code) Monitor Cache Dump: java.lang.ref.Reference$Lock@40E663C0/40E9B8A8: Waiting to be notified: "Reference Handler" (0x80ca440) java.lang.ref.ReferenceQueue$Lock@40E66338/40E9BD78: Waiting to be notified: "Finalizer" (0x80d07b0) org.apache.java.util.SimpleQueue@40E7A6F0/40F28978: Waiting to be notified: "Thread-0" (0x81e6900) java.lang.Class@40E72618/40ECE498: owner "Thread-76" (0x8272360) 1 entry java.net.PlainSoc
Re: jdk1.2.2 on Slackware?
> JDK 1.2.2 requires glibc 2.1.2 which AFAIK translates to > libc 6.1.2 and _not_ libc 5. Hope this helps :-) Thanks for making it clear. Does anyone here happen to know if I can have libc5 and glibc installed on the same box? Thanks again! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Nathan's Book
FatBrain has it in stock... my copy was shipped out this morning $44 incl. shipping. -Original Message- From: Rich Ibbotson [mailto:[EMAIL PROTECTED]] Sent: Monday, January 10, 2000 2:59 PM To: [EMAIL PROTECTED] Cc: Nathan Meyers; [EMAIL PROTECTED] Subject: Re: Nathan's Book I guess they are having trouble catching up, as suggested. Borders has it listed twice: once as $39.99 (status = "Not yet published") and once as $34.99 ($15 off the cover price, ships in 24 hours). But they don't list an author on either version! The "low bidder" (vcss.com) has altered their price from $29.99 to $37.99 since this morning. Jacob Nikom wrote: > > For example, Quantum Bookstore in Cambridge cited $39.99, but called > it "preliminary" price. > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
problems with rmi (linux 1.2 client, solaris 1.3 server)
greetings,
may someone have a hint as to what my problem may be and how to fix it.
here is what is happening. i have a an rmi application with linux
client (jdk 1.2) and solaris server (jdk 1.3). the client throws an
UnmarshalException. i could not figure out why it wa happening, so i
tried the rmi example from the "professional java server programming"
which also throws the unmarshal exception. the client ran fine on the
same solaris box where the server ran, so i tried the client from
another solaris host, also running jdk 1.3 - runs fine.
are there any issues with running my configuration? the details below.
tia.
server:
bash$ uname -rs
SunOS 5.6
bash$ java -version
java version "1.3beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3beta-O)
Java(TM) HotSpot Client VM (build 1.3beta-O-release, 1.3beta-O-release,
interpreted mode)
bash$ cat ~/.java.security
grant {
permission java.io.FilePermission "/home/astromas/work/jaas/cert/-",
"read,write";
};
bash$ java -Djava.rmi.server.codebase=file:/home/astromas/work/rmi/
-Djava.security.policy=/home/astromas/.java.security
com/wrox/rmi/Reverse
Object bound
Linux client:
bash$ java -version
java version "1.2"
Classic VM (build Linux_JDK_1.2_pre-release-v2, native threads, sunwjit)
bash$ cat ~/.java.security
grant codebase "file:/home/ams/work/rmi/-" {
permission java.security.AllPermission;
};
grant {
permission java.net.SocketPermission "*:1024-65535",
"connect,resolve,accept";
};
bash$ java -Djava.security.policy=/home/ams/.java.security Client
java.rmi.UnmarshalException: error unmarshalling return; nested
exception is:
java.lang.ClassNotFoundException: com.wrox.rmi.Reverse_Stub
java.lang.ClassNotFoundException: com.wrox.rmi.Reverse_Stub
at java.io.ObjectInputStream.inputObject(Compiled Code)
at java.io.ObjectInputStream.readObject(Compiled Code)
at java.io.ObjectInputStream.readObject(Compiled Code)
at sun.rmi.registry.RegistryImpl_Stub.lookup(Compiled Code)
at java.rmi.Naming.lookup(Compiled Code)
at Client.main(Compiled Code)
bash$
solaris client:
bash$ java -version
java version "1.3beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3beta-O)
Java(TM) HotSpot Client VM (build 1.3beta-O-release, 1.3beta-O-release,
interpreted mode)
bash$ cat ~/.java.security
grant codebase "file:/home/astromas/work/rmi/-" {
permission java.security.AllPermission;
};
grant {
permission java.net.SocketPermission "*:1024-65535",
"connect,resolve";
};
bash$ java -Djava.security.policy=/home/astromas/.java.security Client
DCBAbash$
client source:
bash$ cat *.java
//Client.java
import java.rmi.*;
import com.wrox.rmi.ReverseInterface;
public class Client {
public static void main(String[] args) {
try {
if (System.getSecurityManager() == null)
System.setSecurityManager(new RMISecurityManager());
ReverseInterface ri = (ReverseInterface)
Naming.lookup("//ncnc-sun22.us.oracle.com/com.wrox.rmi.Reverse");
String r = ri.reverseString("ABCD");
System.out.print(r);
} catch (Exception e) {
e.printStackTrace();
}
}
}
//ReverseInterface.java
package com.wrox.rmi;
import java.rmi.Remote;
import java.rmi.RemoteException;
public interface ReverseInterface extends Remote {
String reverseString(String s) throws RemoteException;
}
server source:
//Reverse.java
package com.wrox.rmi;
import java.rmi.*;
import java.rmi.server.*;
public class Reverse extends UnicastRemoteObject implements
ReverseInterface {
public Reverse() throws RemoteException {
super();
}
public String reverseString(String s) throws RemoteException {
int n = s.length();
StringBuffer t = new StringBuffer(n);
for (int i = n; i > 0; i--)
t.append(s.substring(i-1, i));
return t.toString();
}
public static void main(String[] args) {
if (System.getSecurityManager() == null)
System.setSecurityManager(new RMISecurityManager());
String name = "//ncnc-sun22.us.oracle.com/com.wrox.rmi.Reverse";
try {
Reverse r = new Reverse();
Naming.rebind(name, r);
System.out.println("Object bound");
} catch (Exception e) {
e.printStackTrace();
}
}
}
//ReverseInterface.java
package com.wrox.rmi;
import java.rmi.Remote;
import java.rmi.RemoteException;
public interface ReverseInterface extends Remote {
String reverseString(String s) throws RemoteException;
}
--
Aaron Stromas| "Tick-tick-tick!!!... ja, Pantani is weg..."
Oracle Corp | BRTN commentator
+1 703.708.68.21 | L'Alpe d'Huez
1995 Tour de France
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subje
Re: problems with rmi (linux 1.2 client, solaris 1.3 server)
[EMAIL PROTECTED] wrote: > On Tue, Jan 11, 2000 at 02:00:00PM +, Aaron M. Stromas wrote: > > greetings, > > > > may someone have a hint as to what my problem may be and how to fix it. > > here is what is happening. i have a an rmi application with linux > > client (jdk 1.2) and solaris server (jdk 1.3). the client throws an > > UnmarshalException. i could not figure out why it wa happening, so i > > tried the rmi example from the "professional java server programming" > > which also throws the unmarshal exception. the client ran fine on the > > same solaris box where the server ran, so i tried the client from > > another solaris host, also running jdk 1.3 - runs fine. > > Don't the two vm's have to be the same, as the serial numbers will be > different between 1.2 and 1.3, which will cause Serialization errors? > i did not know that. is that a fact? if so, i have a serious problem :-( . >% snip > -- > John Baker, BSc CS. > Java developer and Linux lover:-) > Sms: [EMAIL PROTECTED] -- Aaron Stromas Oracle Corp. "Tick-tick-tick!!!... ja, Pantani is weg" (BRTN commentator, L'Alpe d'Huez, 1995 Tour de France) begin:vcard n:Stromas;Aaron tel;fax:+1 703-708 7923 tel;work:+1 703 708 6821 x-mozilla-html:TRUE url:http://www.oracle.com org:Oracle;Advanced Technology Solutions adr:;;196 Van Buren Street;Herndon;Virginia;22070;USA version:2.1 email;internet:[EMAIL PROTECTED] title:Senior Principal consultant x-mozilla-cpt:;7952 fn:Stromas, Aaron end:vcard
BufferedImage getSubimage call
Hi... I've implemented a 'magnifying glass' on a BufferedImage object by using the getSubimage call to get the image segment, and enlarging it and drawing it directly on top of the original segment using Graphics' drawImage method. The magnifying glass is tied to the movement of the mouse. Making hundreds of movements works fine, but everything locks up after some time. RasterFormatExceptions thrown by getSubimage are handled. No OutOfMemoryErrors are thrown, and watching the memory through Runtime's freeMemory method show tens of megs free. I'm using Blackdown jdk1.2 pre-release2, libc-2.1.1. Thanks in advance for any help. jason -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: problems with rmi (linux 1.2 client, solaris 1.3 server)
Aaron Stromas wrote: > [EMAIL PROTECTED] wrote: > > > On Tue, Jan 11, 2000 at 02:00:00PM +, Aaron M. Stromas wrote: > > > greetings, > > > > > > may someone have a hint as to what my problem may be and how to fix it. > > > here is what is happening. i have a an rmi application with linux > > > client (jdk 1.2) and solaris server (jdk 1.3). the client throws an > > > UnmarshalException. i could not figure out why it wa happening, so i > > > tried the rmi example from the "professional java server programming" > > > which also throws the unmarshal exception. the client ran fine on the > > > same solaris box where the server ran, so i tried the client from > > > another solaris host, also running jdk 1.3 - runs fine. > > > > Don't the two vm's have to be the same, as the serial numbers will be > > different between 1.2 and 1.3, which will cause Serialization errors? > > > > i did not know that. is that a fact? if so, i have a serious problem :-( that does not appear to be so, at least, not on solaris - i installed jdk1.2.1_04 and the client ran ok. > > > . >% snip > > > -- > > John Baker, BSc CS. > > Java developer and Linux lover:-) > > Sms: [EMAIL PROTECTED] > > -- > Aaron Stromas > Oracle Corp. > > "Tick-tick-tick!!!... ja, Pantani is weg" > (BRTN commentator, L'Alpe d'Huez, 1995 Tour de France) -- Aaron Stromas Oracle Corp. "Tick-tick-tick!!!... ja, Pantani is weg" (BRTN commentator, L'Alpe d'Huez, 1995 Tour de France) begin:vcard n:Stromas;Aaron tel;fax:+1 703-708 7923 tel;work:+1 703 708 6821 x-mozilla-html:TRUE url:http://www.oracle.com org:Oracle;Advanced Technology Solutions adr:;;196 Van Buren Street;Herndon;Virginia;22070;USA version:2.1 email;internet:[EMAIL PROTECTED] title:Senior Principal consultant x-mozilla-cpt:;7952 fn:Stromas, Aaron end:vcard
Re: Ziff-Davis Story: Java and Open Source
[EMAIL PROTECTED] wrote: > > Ziff-Davis' Jesse Berst has a column today pushing Open Source as Java's > most likely salvation: > > http://www.zdnet.com/anchordesk/story/story_4306.html > > A particularly memorable excerpt: > > "Sun could revive the Java dream by making it an open source product. > Unhappily, asking Sun CEO Scott McNealy to take that route is like > asking Saddam Hussein to fix Serbia. Doing the right thing just won't > occur to the man." I though Milosevic was the man charge of Republic of Yugoslavia. (!?) BTW: I seen your book in PC Bookshop, London at lunchtime -- Adios Peter - import std.Disclaimer; // More Java for your Lava, Mate. T H ER E D A R M Y! ! ! http://www.manutd.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Java 3d installation problem
Hi Jeff, Thank you very much for your answer. I followed your suggestion and it worked. The only thing I have to add was the change to the LD_LIBRARY_PATH variable, which Java (or its different packages) used to get to the shared library. Regards, Jacob Nikom Jeff Galyan wrote: > > Jacob, > > Just make a symlink to libGL.so as libMesaGL.so.3 - in Mesa3D 3.x, the > default for the build is to name the libraries libGL.so etc., for easier > swappability with "real" OpenGL implementations. Earlier versions of > Mesa3D used the name libMesaGL.so for the libGL.so library. > > The sumlink can be created in whichever directory your libGL.so lives > in. > > --Jeff > > Jacob Nikom wrote: > > > > Hi, > > > > I run RedHat 6.0, libc-2.1.1 and Blackdown jdk1.2pre-v2-debug.tar.bz2. > > I installed Java3D package from > > ftp://metalab.unc.edu/pub/linux/devel/lang/java/blackdown.org/java3d/1.1.1/i386/ > > > > Everything went smoothly, even the installation of the MesaGL library. > > I was able to run a lot of MesaGL demos. > > > > However, when I started to run Java3d examples, every example > > complained about the lack of libMesaGl.so.3 library: > > appletviewer -J-mx64m HelloUniverse.html > > java.lang.UnsatisfiedLinkError: > > /homes/nikom/Java/jdk1.2/jre/lib/i386/libJ3D.so: > > libMesaGL.so.3: cannot open shared object file: No such file or > > directory > > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > > at java.lang.ClassLoader.loadLibrary0(Compiled Code) > > at java.lang.ClassLoader.loadLibrary(Compiled Code) > > at java.lang.Runtime.loadLibrary0(Compiled Code) > > at java.lang.System.loadLibrary(Compiled Code) > > at javax.media.j3d.UniverseManager$1.run(Compiled Code) > > at java.security.AccessController.doPrivileged(Native Method) > > at javax.media.j3d.UniverseManager.(Compiled Code) > > at javax.media.j3d.VirtualUniverse$2.run(Compiled Code) > > at java.security.AccessController.doPrivileged(Native Method) > > at javax.media.j3d.VirtualUniverse.(VirtualUniverse.java:464) > > at HelloUniverse.(Compiled Code) > > at java.lang.Class.newInstance0(Native Method) > > at java.lang.Class.newInstance(Compiled Code) > > at sun.applet.AppletPanel.createApplet(Compiled Code) > > at sun.applet.AppletPanel.runLoader(Compiled Code) > > at sun.applet.AppletPanel.run(Compiled Code) > > > > However, Mesa's installation script did not create MesaGL library - it > > only > > produced libGL.so, libGLU.so, libglut.so, etc. How I can get > > libMesaGL.so > > and where I have to put it? > > > > Thank you, > > > > Jacob Nikom > > > > -- > > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > -- > Jeff Galyan > http://www.anamorphic.com > http://www.sun.com > jeffrey dot galyan at sun dot com > talisman at anamorphic dot com > Sun Certified Java(TM) Programmer > == > Linus Torvalds on Microsoft and software development: > "... if it's a hobby for me and a job for you, why are you doing such a > shoddy job of it?" > > The views expressed herein do not necessarily reflect those of my > employer. > > Sun Microsystems, Inc., has no connection to my involvement with the > Mozilla Organization. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RPM archive for new TYA1.6 available
Hi, the subject says it all, [EMAIL PROTECTED] informed me that he has packaged a TYA1.6 rpm-archive ready for download: http://www.spsselib.hiedu.cz/~ivop/ftp/tya/ Tnx to Ivo, Cheers, Albrecht -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: problems with rmi (linux 1.2 client, solaris 1.3 server)
Aaron Stromas wrote: > [EMAIL PROTECTED] wrote: > > > On Tue, Jan 11, 2000 at 02:00:00PM +, Aaron M. Stromas wrote: > > > greetings, > > > > > > may someone have a hint as to what my problem may be and how to fix it. > > > here is what is happening. i have a an rmi application with linux > > > client (jdk 1.2) and solaris server (jdk 1.3). the client throws an > > > UnmarshalException. i could not figure out why it wa happening, so i > > > tried the rmi example from the "professional java server programming" > > > which also throws the unmarshal exception. the client ran fine on the > > > same solaris box where the server ran, so i tried the client from > > > another solaris host, also running jdk 1.3 - runs fine. > > > > Don't the two vm's have to be the same, as the serial numbers will be > > different between 1.2 and 1.3, which will cause Serialization errors? > > > > i did not know that. is that a fact? if so, i have a serious problem :-( that does not appear to be so, at least, not on solaris - i installed jdk1.2.1_04 and the client ran ok. it also worked on linux when i copied the _Stub class to the client. so, why doesn't the server find the stub to return to the client? -- Aaron Stromas Oracle Corp. "Tick-tick-tick!!!... ja, Pantani is weg" (BRTN commentator, L'Alpe d'Huez, 1995 Tour de France) begin:vcard n:Stromas;Aaron tel;fax:+1 703-708 7923 tel;work:+1 703 708 6821 x-mozilla-html:TRUE url:http://www.oracle.com org:Oracle;Advanced Technology Solutions adr:;;196 Van Buren Street;Herndon;Virginia;22070;USA version:2.1 email;internet:[EMAIL PROTECTED] title:Senior Principal consultant x-mozilla-cpt:;7952 fn:Stromas, Aaron end:vcard
Re: Which Linux JVM is better?
On Mon, Jan 10, 2000 at 10:00:55AM -0500, James Caple wrote: > For what it's worth, my experience has been that the Blackdown RC3 port is > much more scaleable and stable than the Inprise Linux port. I'd place my > bets on the Blackdown port for server-side performance and scaleability. > Although somewhat slow in porting, Blackdown is doing a very thorough job. > > My comments are based on tests using green threads without a JIT, at the > moment. While I might agree with you about stability, as far as scalability goes, you need native threads to be able to being to test that. I suspect the two are relatively similar. My main plug for the Inprise port is that it has better debugging support, which is a big deal to me. --Chris PGP signature
Re: problems with rmi (linux 1.2 client, solaris 1.3 server)
On Tue, Jan 11, 2000 at 01:15:17PM -0500, Aaron Stromas wrote: > it also worked on linux when i copied the _Stub class to the client. so, > why doesn't the server find the stub to return to the client? Ah, the real meat of the question. Answer: because RMI doesn't work that way. RMI doesn't send classfiles, either for the real class or the stub. The client has to be able to find the stub in its own classpath. RMI just sends data that is used with the stub class. Nathan Meyers [EMAIL PROTECTED] > > Aaron Stromas wrote: > > > > > [EMAIL PROTECTED] wrote: > > > > > > > On Tue, Jan 11, 2000 at 02:00:00PM +, Aaron M. Stromas wrote: > > > > > greetings, > > > > > > > > > > may someone have a hint as to what my problem may be and how to fix it. > > > > > here is what is happening. i have a an rmi application with linux > > > > > client (jdk 1.2) and solaris server (jdk 1.3). the client throws an > > > > > UnmarshalException. i could not figure out why it wa happening, so i > > > > > tried the rmi example from the "professional java server programming" > > > > > which also throws the unmarshal exception. the client ran fine on the > > > > > same solaris box where the server ran, so i tried the client from > > > > > another solaris host, also running jdk 1.3 - runs fine. > > > > > > > > Don't the two vm's have to be the same, as the serial numbers will be > > > > different between 1.2 and 1.3, which will cause Serialization errors? > > > > > > > > > > i did not know that. is that a fact? if so, i have a serious problem :-( > > > > that does not appear to be so, at least, not on solaris - i installed > > jdk1.2.1_04 and the client ran ok. > > > > it also worked on linux when i copied the _Stub class to the client. so, > why doesn't the server find the stub to return to the client? > -- > Aaron Stromas > Oracle Corp. > > "Tick-tick-tick!!!... ja, Pantani is weg" > (BRTN commentator, L'Alpe d'Huez, 1995 Tour de France) > > Content-Description: Card for Aaron Stromas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: problems with rmi (linux 1.2 client, solaris 1.3 server)
I have never actually done this, by the RMIClassLoader should permit the dynamic loading of classes. Below is my summary of the description provided by Java Enterprise in a Nutshell. Cynthia Jeness - Dynamically Loaded Classes Loading classes may involve 3 different class loaders: Default ClassLoader - Classes from your CLASSPATH which do not get loaded as a result of naming look-ups. Applet ClassLoader - Loading classes over the web for applets. RMI ClassLoader - Loads from your local CLASSPATH if available; otherwise, may load from a specified URL which is identified as part of starting the process: java -Djava.rmi.server.codebase=http://pup/~cj/JavaCert/ samples.rmiRegAccount Your program must install a Security Manager which supports remote loading: System.setSecurityManager(new RMISecurityManager()); Default Java security policy does not permit this, so the following line must be added: permission java.net.SocketPermission "objhost.org", "accept,connect" where "objhost.org" is the name for your remote host. Then use the following when actually running the application: java -Djava.security.policy=rmipolicy.txt samples.rmi.AccountClient Nathan Meyers wrote: > On Tue, Jan 11, 2000 at 01:15:17PM -0500, Aaron Stromas wrote: > > it also worked on linux when i copied the _Stub class to the client. so, > > why doesn't the server find the stub to return to the client? > > Ah, the real meat of the question. Answer: because RMI doesn't work that > way. > > RMI doesn't send classfiles, either for the real class or the stub. > The client has to be able to find the stub in its own classpath. > RMI just sends data that is used with the stub class. > > Nathan Meyers > [EMAIL PROTECTED] > > > > Aaron Stromas wrote: > > > > > > > [EMAIL PROTECTED] wrote: > > > > > > > > > On Tue, Jan 11, 2000 at 02:00:00PM +, Aaron M. Stromas wrote: > > > > > > greetings, > > > > > > > > > > > > may someone have a hint as to what my problem may be and how to fix it. > > > > > > here is what is happening. i have a an rmi application with linux > > > > > > client (jdk 1.2) and solaris server (jdk 1.3). the client throws an > > > > > > UnmarshalException. i could not figure out why it wa happening, so i > > > > > > tried the rmi example from the "professional java server programming" > > > > > > which also throws the unmarshal exception. the client ran fine on the > > > > > > same solaris box where the server ran, so i tried the client from > > > > > > another solaris host, also running jdk 1.3 - runs fine. > > > > > > > > > > Don't the two vm's have to be the same, as the serial numbers will be > > > > > different between 1.2 and 1.3, which will cause Serialization errors? > > > > > > > > > > > > > i did not know that. is that a fact? if so, i have a serious problem :-( > > > > > > that does not appear to be so, at least, not on solaris - i installed > > > jdk1.2.1_04 and the client ran ok. > > > > > > > it also worked on linux when i copied the _Stub class to the client. so, > > why doesn't the server find the stub to return to the client? > > -- > > Aaron Stromas > > Oracle Corp. > > > > "Tick-tick-tick!!!... ja, Pantani is weg" > > (BRTN commentator, L'Alpe d'Huez, 1995 Tour de France) > > > > > > Content-Description: Card for Aaron Stromas > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
REMOVE
I don't know how my name got on this list bu tTAKE IT OFF!! __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Which Linux JVM is better?
I will use jdk in Linux kernel 2.2 Apache1.3.9 JSDK2.0 MySQL production environment, and I decide to use Blackdown JDK. Please ask which version of Blackdown JDK is better in stability,speed, 1.1.7vla? 1.1.7v3? 1.2.2RC2? 1.2.2RC3? JackWang >Ekkehard Kraemer wrote: >> >> Hallo Nathan, >> >> NM>Blackdown JDK. If you want to use tools that depend on the Java >> NM>Platform Debugging Architecture (like JBuilder and other IDEs), you >> NM>need the Sun/Inprise JDK. >> >> I just wanted to hint at ddd, which supports a bit of graphical debugging >> under Blackdown (without JPDA) as well. Not perfect, but it's a start. > >Ddd is an excellent interface. The main problem is that it relies on jdb >under the covers, and the JDK1.2 jdb is (last I checked) pretty flaky. >Once jdb straightens up and flies right, ddd will be in the top tier of >debugging solutions. > >Nathan > > >> >> MbG, Ekkehard >> >> -- >> To UNSUBSCRIBE, email to [EMAIL PROTECTED] >> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > >-- >To UNSUBSCRIBE, email to [EMAIL PROTECTED] >with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: problems with rmi (linux 1.2 client, solaris 1.3 server)
At 14:00 1/11/00 +, Aaron M. Stromas wrote: [...] >bash$ java -Djava.security.policy=/home/ams/.java.security Client >java.rmi.UnmarshalException: error unmarshalling return; nested >exception is: >java.lang.ClassNotFoundException: com.wrox.rmi.Reverse_Stub >java.lang.ClassNotFoundException: com.wrox.rmi.Reverse_Stub >at java.io.ObjectInputStream.inputObject(Compiled Code) >at java.io.ObjectInputStream.readObject(Compiled Code) >at java.io.ObjectInputStream.readObject(Compiled Code) >at sun.rmi.registry.RegistryImpl_Stub.lookup(Compiled Code) >at java.rmi.Naming.lookup(Compiled Code) >at Client.main(Compiled Code) RMIRegistry can't find the _Stub class. It needs three classes in order to function (interface, _Stub, _Skel). The key to interpreting this from the stack trace is to note that there are TWO exceptions nested, the outer one is the UnmarshalException, but it is wrapping a ClassNotFound exception which came accross the wire (io.ObjectInputStream.inputObject) from the RMIRegistry on a lookup call. (RegistryImpl_Stub.lookup) [EMAIL PROTECTED] apparently wrote in private email to Aaron: > Don't the two vm's have to be the same, as the serial numbers will be > different between 1.2 and 1.3, which will cause Serialization errors? there can be serialization problems, but they're primarily between 1.1 and 1.2, or classes compiled by Sun's algorythm and another (i.e. Jikes) because Sun used internal to javac constructs to generate the suuid. At 12:25 1/11/00 -0800, Nathan Meyers wrote: > RMI doesn't send classfiles, either for the real class or the stub. it can be configured to however, not only the required _Stub/_Skel gorp, but the entire dependency tree of classes. tends to make bringup times really agonizing when you try to deploy on the net though. ;) it looks like Aaron was/is on the way to doing this for the client, but I'll doubt he even took a second thought about it when starting the RMIRegisrty. (y'all have no idea how many times people have called me to complain that my code is broken and it turned out they hadn't restarted the server processes, or regenerated _Stub/_Skel(s) after changing their own code; many of them turn shades of red/purple when you deduce the problem ;) cabbey at home dot net <*> http://members.home.net/cabbey I want a binary interface to the brain! Today's opto-mechanical digital interfaces are just too slow! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: problems with rmi (linux 1.2 client, solaris 1.3 server)
If I'm not mistaken, the stubs have to be on both the server and the client side. RMI is a bit tricky that way... --Jeff Aaron Stromas wrote: > > > Aaron Stromas wrote: > > > > > [EMAIL PROTECTED] wrote: > > > > > > > On Tue, Jan 11, 2000 at 02:00:00PM +, Aaron M. Stromas wrote: > > > > > greetings, > > > > > > > > > > may someone have a hint as to what my problem may be and how to fix it. > > > > > here is what is happening. i have a an rmi application with linux > > > > > client (jdk 1.2) and solaris server (jdk 1.3). the client throws an > > > > > UnmarshalException. i could not figure out why it wa happening, so i > > > > > tried the rmi example from the "professional java server programming" > > > > > which also throws the unmarshal exception. the client ran fine on the > > > > > same solaris box where the server ran, so i tried the client from > > > > > another solaris host, also running jdk 1.3 - runs fine. > > > > > > > > Don't the two vm's have to be the same, as the serial numbers will be > > > > different between 1.2 and 1.3, which will cause Serialization errors? > > > > > > > > > > i did not know that. is that a fact? if so, i have a serious problem :-( > > > > that does not appear to be so, at least, not on solaris - i installed > > jdk1.2.1_04 and the client ran ok. > > > > it also worked on linux when i copied the _Stub class to the client. > so, why doesn't the server find the stub to return to the client? > -- > Aaron Stromas > Oracle Corp. > > "Tick-tick-tick!!!... ja, Pantani is weg" > (BRTN commentator, L'Alpe d'Huez, 1995 Tour de > France) > -- Jeff Galyan http://www.anamorphic.com http://www.sun.com jeffrey dot galyan at sun dot com talisman at anamorphic dot com Sun Certified Java(TM) Programmer == Linus Torvalds on Microsoft and software development: "... if it's a hobby for me and a job for you, why are you doing such a shoddy job of it?" The views expressed herein do not necessarily reflect those of my employer. Sun Microsystems, Inc., has no connection to my involvement with the Mozilla Organization. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: problems with rmi (linux 1.2 client, solaris 1.3 server)
Chris Abbey wrote: > > RMIRegistry can't find the _Stub class. It needs three classes in order > to function (interface, _Stub, _Skel). That isn't strictly true. If you use rmic -v1.2 all you'll get ( at least all I've gotten so far ) are _Stub's. Works fine with a 1.2 VM. By default rmic creates stubs and skeletons to be compatible with both 1.1 and 1.2. At 12:25 1/11/00 -0800, Nathan Meyers wrote: > > RMI doesn't send classfiles Well, it shouldn't, but I've seen it do so with a simple class that wasn't written properly ( woops ;). ~Rob -- wYRd.:|:[EMAIL PROTECTED]:|:.prohibitions void where offered de recta non tolerandum sunt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
