Hello,
I'm been attempting to debug a Jetty Server Application in 1.4 but the process seems to be taking up too much resources including CPU time.
While using JZOSVM14(N): Version 1.2.3, I've been able to connect while eclipse Version: 2.1.3 and I been able to step through a few lines of code.
However, while creating an instance of the server class, I got until an almost endless wait state. After 10 minutes of CPU time (with very little I/O), the job had to be conceled.
The following is my current debug parameters:
HSTDBG="8000"
# Configure JVM options
# Note that Tomcat requires default ASCII file.encoding
IJO="-Xms96m -Xmx378m"
IJO="$IJO -Xdebug -Xnoagent "
IJO="$IJO -Xbootclasspath/p:$JAVA_HOME/lib/rt.jar:$JAVA_HOME/lib/tools.jar"
IJO="$IJO -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=$HSTDBG"
IJO="$IJO -Djava.compiler=NONE"
IJO="$IJO -Djzos.home=${JZOS_HOME}"
IJO="$IJO -Djetty.home=${JETTY_HOME}"
IJO="$IJO -Dfile.encoding=ISO8859-1"
IJO="$IJO -Djava.security.auth.login.config="
IJO="${IJO}${JETTY_HOME}/etc/security/FtpLogin.config"
IJO="$IJO -Dorg.apache.commons.logging.Log="
IJO="${IJO}org.apache.commons.logging.impl.SimpleLog"
export IBM_JAVA_OPTIONS="$IJO "
export JAVA_DUMP_HEAP=false
export JAVA_PROPAGATE=NO
export IBM_JAVA_ZOS_TDUMP=NO
Remote JPDA debugging in 1.4
I assume that you mean Eclipse 3.1.2?
In any case, I assume that you mean that you are able to step through lines of code, but that when you step over a line that creates a Jetty class that everything hangs up?
I'm not sure what the problem is, but you might try running with verbose:class. It could be that the initialization of the Jetty server class is causing a ton of class loads. Its not clear to me whether you have a performance problem BEFORE using JPDA or only after using JPDA. Of course, JPDA causes more overhead in the JVM, but I've used it before with Tomcat without too much problem.
In any case, I assume that you mean that you are able to step through lines of code, but that when you step over a line that creates a Jetty class that everything hangs up?
I'm not sure what the problem is, but you might try running with verbose:class. It could be that the initialization of the Jetty server class is causing a ton of class loads. Its not clear to me whether you have a performance problem BEFORE using JPDA or only after using JPDA. Of course, JPDA causes more overhead in the JVM, but I've used it before with Tomcat without too much problem.
Actually to the run this Jetty Server Application in our environment using SDK 1.4 requires a region size of 200m, though the app itself Without JPDA debugging was up and running in less than 4 seconds. However, there was a custom build application launcher which reads an XML configuration file which has the same look and feel as of tomcat. Includes, JNDI functionality. The launcher builds an updateable attribute list dynamically from any initiated server object.
We are currently, using a version of web sphere developer studio which is built around an older version of Eclipse. For compatibility issues, the following is product information displayed from version of Eclipse is:
Eclipse Platform
Version: 2.1.3
Build id: 200403101828
(c) Copyright IBM Corp. and others 2000, 2003. All rights reserved.
Visit http://www.eclipse.org/platform
Though I have doubts, there's any performance issues before using JPDA. With the debuggin option, the memory settings had to be tripled from before.
However, inspite of the debugging efforts, I believe this app has successfully trouble shooted without the debugger.
We are currently, using a version of web sphere developer studio which is built around an older version of Eclipse. For compatibility issues, the following is product information displayed from version of Eclipse is:
Eclipse Platform
Version: 2.1.3
Build id: 200403101828
(c) Copyright IBM Corp. and others 2000, 2003. All rights reserved.
Visit http://www.eclipse.org/platform
Though I have doubts, there's any performance issues before using JPDA. With the debuggin option, the memory settings had to be tripled from before.
However, inspite of the debugging efforts, I believe this app has successfully trouble shooted without the debugger.
Were you able to resolve your JDPA hanging problem by increasing the memory? (did you increase the max heap size or the region size?)
It seems a little odd that turning on JPDA required that much memory. My understanding is that JPDA slowed things down because it effectively disabled JIT, but I wouldn't expect that it would need more memory. But this could be the case; I'm lazy and generally run with REGION=0M, so I may not have noticed.
If you're still having a problem, you might have to open a PMR with IBM against the JVM. Its crippling not to be able to use JPDA when you really need it!
You might also want to try SDK5.0... its completely new JVM technology (based on "J9"), and you might find it to cooperate with JPDA a little better. We've been using it with Tomcat5.5 and it seems to work pretty well, although I haven't tried it with JPDA.
Eclipse 2.1 is really old.... however I used it extensively a couple of years ago, including remote JPDA debugging, and it seemed fine. But I only used it with zOS JDK1.3 remote JVMs, so perhaps there are issues. It -should- work against JDK1.4, but it wouldn't surprise me if there were SDK5.0 compatiblity issues.
It seems a little odd that turning on JPDA required that much memory. My understanding is that JPDA slowed things down because it effectively disabled JIT, but I wouldn't expect that it would need more memory. But this could be the case; I'm lazy and generally run with REGION=0M, so I may not have noticed.
If you're still having a problem, you might have to open a PMR with IBM against the JVM. Its crippling not to be able to use JPDA when you really need it!
You might also want to try SDK5.0... its completely new JVM technology (based on "J9"), and you might find it to cooperate with JPDA a little better. We've been using it with Tomcat5.5 and it seems to work pretty well, although I haven't tried it with JPDA.
Eclipse 2.1 is really old.... however I used it extensively a couple of years ago, including remote JPDA debugging, and it seemed fine. But I only used it with zOS JDK1.3 remote JVMs, so perhaps there are issues. It -should- work against JDK1.4, but it wouldn't surprise me if there were SDK5.0 compatiblity issues.
Hello
I've corrected my issue concerning the hanging JDPA loop by updating my debug parm as follows:
-Xdebug -Xnoagent "
-Xbootclasspath/p:$JAVA_HOME/lib/rt.jar:$JAVA_HOME/lib/tools.jar
-Xrunjdwp:transport=dt_socket,server=y,stdalloc=y,suspend=y,address=8000
Don't understand why the stdalloc parmeter made a difference, but I did.
However, concerning the memory allocations, I usually make a habit to make the region size about 100m+ of the max heap size.
Also, without the debugging, the JZOS launcher works fine. With, debuging the application still works but the following messages appears (while using -verbose):
ÝLoaded com.dovetail.jzos.TranscodingPrintStream from file:/NCSG/tmp/jzos/jzos.jar¨
ÝSignaling in VM: java/lang/UnsatisfiedLinkError, message: /java/uk07860/IBM/J1.4/bin/libjzos14.so: Could not find dll¨
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:2147)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:2006)
at java.lang.Runtime.loadLibrary0(Runtime.java:824)
at java.lang.System.loadLibrary(System.java:910)
at com.dovetail.jzos.ZUtil.<clinit>(ZUtil.java:49)
ÝLoaded java.lang.ClassLoader$4 from /java/current/J1.4/lib/core.jar¨
ÝSignaling in VM: java/lang/UnsatisfiedLinkError, message: /RESG11/lib/libjzos14.so: Could not find dll¨
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:2147)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:2025)
at java.lang.Runtime.loadLibrary0(Runtime.java:824)
at java.lang.System.loadLibrary(System.java:910)
at com.dovetail.jzos.ZUtil.<clinit>(ZUtil.java:49)
I've corrected my issue concerning the hanging JDPA loop by updating my debug parm as follows:
-Xdebug -Xnoagent "
-Xbootclasspath/p:$JAVA_HOME/lib/rt.jar:$JAVA_HOME/lib/tools.jar
-Xrunjdwp:transport=dt_socket,server=y,stdalloc=y,suspend=y,address=8000
Don't understand why the stdalloc parmeter made a difference, but I did.
However, concerning the memory allocations, I usually make a habit to make the region size about 100m+ of the max heap size.
Also, without the debugging, the JZOS launcher works fine. With, debuging the application still works but the following messages appears (while using -verbose):
ÝLoaded com.dovetail.jzos.TranscodingPrintStream from file:/NCSG/tmp/jzos/jzos.jar¨
ÝSignaling in VM: java/lang/UnsatisfiedLinkError, message: /java/uk07860/IBM/J1.4/bin/libjzos14.so: Could not find dll¨
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:2147)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:2006)
at java.lang.Runtime.loadLibrary0(Runtime.java:824)
at java.lang.System.loadLibrary(System.java:910)
at com.dovetail.jzos.ZUtil.<clinit>(ZUtil.java:49)
ÝLoaded java.lang.ClassLoader$4 from /java/current/J1.4/lib/core.jar¨
ÝSignaling in VM: java/lang/UnsatisfiedLinkError, message: /RESG11/lib/libjzos14.so: Could not find dll¨
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:2147)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:2025)
at java.lang.Runtime.loadLibrary0(Runtime.java:824)
at java.lang.System.loadLibrary(System.java:910)
at com.dovetail.jzos.ZUtil.<clinit>(ZUtil.java:49)
Its been a while, but I think that I normally used the following (under 1.3):
-Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=nnnn
I don't recall having any problems, do you have any ideas as to why your configuration requires "stdalloc=y". Curious: what information suggested that as a solution?
The UnsatisfiedLinkError messages that you see with "verbose:class"
are "normal" from the IBM JVM.... apparently it tries to load the dll from every path in the LIBPATH until it finds it somewhere.
-Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=nnnn
I don't recall having any problems, do you have any ideas as to why your configuration requires "stdalloc=y". Curious: what information suggested that as a solution?
The UnsatisfiedLinkError messages that you see with "verbose:class"
are "normal" from the IBM JVM.... apparently it tries to load the dll from every path in the LIBPATH until it finds it somewhere.