MMAPI in JVM

Dear All,
I wrote a small midp application that plays a media file. I run my application in my IPAQ that runs esmertec JVM and I noticed that the MMAPI of the JVM cannot play any video file(no video supported by mmapi).
I downloaded the IBM websphere everyplace JVM(evaluation version) and it does not also play .mpg video.
Is there a JVM for pocket pc with full mmapi installed?
or how can I add video playback function on the mmapi of the esmertec jvm?
Thank you very much in advance.

i have found an article on that in nokia-forums try this keyword in Google
the first link will lead you to destination "creating 3gp player in J2me"

Similar Messages

Oop.. What JVM on PDA can run MMAPI?

Hi. I'm a developer on iPAQ. I want to capture audio from microphone and I know MMAPI can do it. Now i'm using J9VM but when i doesn't work (-_-). when i tried this code
Player p = Manager.createPlayer("capture://audio");
it told me "scheme not found: capture".
What should i do?

ahem does the jvk support mmapi?
most jvms for pdas do not

Jvm startup fails with error when using large -Xmx value

I'm running JDK 1.6.0_02-b05 on RHEL5 server. I'm getting error when starting the JVM with large -Xmx value. The host has ample memory to succeed yet it fails. I see this error when I'm starting tomcat with a bunch of options but found that it can be easily reproduced by starting the JVM with -Xmx2048M and -version. So it's this boiled down test case that I've been examining more closely.
host% free -mt
total used free shared buffers cached
Mem: 6084 3084 3000 0 184 1531
-/+ buffers/cache: 1368 4716
Swap: 6143 0 6143
Total: 12228 3084 9144
Free reveals the host has 6 GB of RAM, approximately half is available. Swap is totally free meaning I should have access to about 9 GB of memory at this point.
host% java -version
java version "1.6.0_02"
Java(TM) SE Runtime Environment (build 1.6.0_02-b05)
Java HotSpot(TM) Server VM (build 1.6.0_02-b05, mixed mode)
java -version succeeds
host% java -Xmx2048M -version
Error occurred during initialization of VM
Could not reserve enough space for object heap
Could not create the Java virtual machine.
java -Xmx2048M -version fails. Trace of this reveals mmap call fails.
mmap2(NULL, 2214592512, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = -1 ENOMEM (Cannot allocate memory)
Any ideas?

These are the relevant java options we are using:
-server -XX:-OmitStackTraceInFastThrow -XX:+PrintClassHistogram -XX:+UseLargePages -Xms6g -Xmx6g -XX:NewSize=256m -XX:MaxNewSize=256m -XX:PermSize=128m -XX:MaxPermSize=192m -XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled -XX:+ExplicitGCInvokesConcurrent -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.awt.headless=true
This is a web application that is very dynamic and uses lots of database calls to build pages. We use a large clustered cache to reduce trips to the database. So being able to acces lots of memory is important to our application.
I'll explain some of the more uncommon options:
We use the Concurrent Garbage collector to reduce stop the world GC's. Here are the CMS options:
-XX:+UseConcMarkSweepGC
-XX:+CMSClassUnloadingEnabled
-XX:+CMSPermGenSweepingEnabled An explicit coded GC invokes the Concurrent GC instead of the stop the world GC.
-XX:+ExplicitGCInvokesConcurrentThe default PermSizes where not large enough for our application. So we increased them.
-XX:PermSize=128m
-XX:MaxPermSize=192mWe had some exceptions that were omitting their stack traces. This options fixes that problem:
-XX:-OmitStackTraceInFastThrowWe approximate between 10% to 20% performance improvement with Large Page support. This is an advance feature.
-XX:+UseLargePagesUseLargePages requires OS level configuration as well. In SUSE10 we configured the OS's hugepages by executing
echo "vm.nr_hugepages = 3172" >> /etc/sysctl.confand then rebooting. kernel.shmmax may also need to be modified. If you use Large Page be sure to google for complete instructions.
When we transitioned to 64bit we transitioned from much slower systems having 4GB of ram to much faster machines with 8GB of ram, so I can't answer the question of degraded performance, however with our application, the bigger our cache the better our performance, so if 64bit is slower we more than make up for it being able to access more memory. I bet the performance difference depends on the applications. You should do your own profiling.
You can run both the 32bit version and the 64bit version on most 64bit OSes. So if there is a significant difference run the version you need for the application. For example if you need the memory use the 64bit version if you don't then use the 32bit version.

What would make a JVM memory size 1.9GB ?

This is on Solaris 2.6, JDK 1.2.2_05a, JDK1.2.2_07, possibly JDK 1.3 (it crashed).
WLS 5.1, SP8. With inline_instrs_jit=0.
This is the [heap] segment shown by /usr/proc/bin/pmap. This is native heap, it is
NOT the Java Heap.
I know it could be the Type 2 db drivers - but I doubt it.
With JDK1.3 we set -XX:MaxPermSize=128m - it crashes after an hour.
One part of the application creates its own threads for some parallel processing.
Is this a known
problem with the JVMs?
Any help is much appreciated.
Mike Reiche

What is the 'Break difference' that the debug JVM shows? Is that the Java Heap? Or
is memory in the C Heap that is wasted by fragmentation?
============== C Heap Report ========================
mmap space 300515328
Committed space 95690752
Allocated space 34049316
Break difference 66060288
Breakdown by type:
ClassSpace 15252128
JITCompiledStackMaps 5277188
StackMap 1892672
Dependency 1856760
utf8_space 1854838
untagged 1783520
basicBlocksState 1664992
utf8_table 1055903
Class 811520
JITPrestub 610480
NearClass 531360
CardObjectTable 386048
JavaStack 257024
CheckingDone 200367
SummaryCardTable 193024
name_loader_cache_entry 65976
ScratchRecord 65548
basic_block_t 50896
IntfMethodTable 48960
stringTableOverflowRecord 46480
BitVectorElem 32768
ObjectMap 30724
ClassName 28407
Clinit 18752
Table_mem 18628
LoaderConstraintsTableEntry 11668
JITInlineByteCode 1928
LoaderConstraintsTableLoaderEntry 520
stateVecBuf 237
=====================================================
Total GC time: 2987981 ms
- Mike
"[email protected]" Mike wrote:
>
>
Aslo - GC[1] are taking way long (Debug JVM) - I'm used to seeing them taking
500
ms with the regular JVM. With -ms32m -m256m - I wanted GC[1] to run often
because
that has helped with other memory problems in the past - it doesn't work
so hot here.
GC[1] in 5514 ms: (38Mb, 0% free) -> (38Mb, 69% free)
GC[1] in 6300 ms: (38Mb, 0% free) -> (38Mb, 65% free)
GC[1] in 7130 ms: (38Mb, 0% free) -> (38Mb, 64% free)
GC[1] in 6158 ms: (38Mb, 2% free) -> (38Mb, 62% free)
GC[1] in 6171 ms: (38Mb, 0% free) -> (38Mb, 65% free)
GC[1] in 6885 ms: (38Mb, 0% free) -> (38Mb, 64% free)
GC[1] in 7403 ms: (38Mb, 0% free) -> (38Mb, 61% free)
GC[1] in 689101:25:49 PM PST {218} - Evaluation is: true
GC[1] in 6545 ms: (38Mb, 1% free) -> (38Mb, 61% free)
GC[1] in 7459 ms: (38Mb, 0% free) -> (38Mb, 62% free)
GC[1] in 6861 ms: (38Mb, 2% free) -> (38Mb, 58% free)
GC[1] in 6090 ms: (38Mb, 0% free) -> (38Mb, 56% free)
GC[1] in 6413 ms: (38Mb, 0% free) -> (38Mb, 60% free)
GC[1] in 8230 ms: (38Mb, 1% free) -> (38Mb, 58% free)
GC[1] in 7649 ms: (38Mb, 0% free) -> (38Mb, 54% free)
GC[1] in 7912 ms: (38Mb, 0% free) -> (38Mb, 55% free)
GC[1] in 7696 ms: (38Mb, 1% free) -> (38Mb, 57% free)
GC[1] in 6543 ms: (38Mb, 1% free) -> (38Mb, 60% free)
GC[1] in 7036 ms: (38Mb, 1% free) -> (38Mb, 59% free)
GC[1] in 7483 ms: (38Mb, 0% free) -> (38Mb, 56% free)
GC[1] in 5132 ms: (38Mb, 1% free) -> (38Mb, 59% free)
GC[1] in 8186 ms: (38Mb, 0% free) -> (38Mb, 53% free)
GC[1] in 5691 ms: (38Mb, 0% free) -> (38Mb, 58% free)
GC[1]01:35:49 PM PST {575} - Evaluation is: true
GC[1] in 8176 ms: (38Mb, 0% free) -> (38Mb, 46% free)
GC[1] in 8463 ms: (38Mb, 0% free) -> (38Mb, 47% free)
GC[1] in 7342 ms: (38Mb, 0% free) -> (42Mb, 41% free)
GC[1] in 6920 ms: (42Mb, 0% free) -> (49Mb, 41% free)
GC[1] in 8610 ms: (49Mb, 1% free) -> (60Mb, 40% free)
GC[1] in 9581 ms: (60Mb, 1% free) -> (60Mb, 50% free)
GC[1] in 10514 ms: (60Mb, 0% free) -> (60Mb, 59% free)
GC[1] in 9865 ms: (60Mb, 0% free) -> (60Mb, 60% free)
GC[1] in 11323 ms: (60Mb, 0% free) -> (60Mb, 57% free)
GC[1] in 18768 ms: (60Mb, 0% free) -> (60Mb, 60% free)
GC[1] in 11147 ms: (60Mb, 0% free) -> (60Mb, 55% free)
GC[1] in 7293 ms: (60Mb, 0% free) -> (60Mb, 42% free)
GC[1] in 9372 ms: (60Mb, 0% free) -> (60Mb, 53% free)
GC[1] in 8814 ms: (60Mb, 0% free) -> (60Mb, 55% free)
GC[1] in 9695 ms: (60Mb, 1% free) -> (60Mb, 54% free)
GC[1] in 7309 ms: (60Mb, 0% free) -> (60Mb, 53% free)
GC[1] in 8713 ms: (60Mb, 0% free) -> (60Mb, 54% free)
GC[1] in 11955 ms: (60Mb, 0% free) -> (60Mb, 55% free)
GC[1] in 12685 ms: (60Mb, 1% free) -> (60Mb, 55% free)
GC[1] in 18906 ms: (60Mb, 0% free) -> (60Mb, 58% free)
GC[1] in 13333 ms: (60Mb, 0% free) -> (60Mb, 51% free)
"[email protected]" <[email protected]> wrote:
Rob -
Thanks for your attention -
We create lots of threads - up to five threads for each DB hit (i didn't
design it).
The multi-threading will be disabled/removed and tested later on today.
Both 'top'
and pstack show around 85 threads.
I've read articles on the bea newsgroups about WL hanging on to threadreferences
so that the threads could not be GC'ed, but it sounded more like a customer's
impression
of what might be going on than something from BEA engineering.
Right now we are running with the 1.2.2_05a 'Debug' JVM with -verbose:gc
-verbose:gc
-verbose:gc
JVMARGS=verbose_c_heap,inline_instrs_jit=0
Unfortunately, some of the code being tested is now broken and not being
excercised
today. I will keep you posted.
- Mike
Rob Woollen <[email protected]> wrote:
How many threads are you creating?
Each thread uses some memory (stack etc.), but 1.9GB would be a lot of
thread creation.
-- Rob
Mike Reiche wrote:
This is on Solaris 2.6, JDK 1.2.2_05a, JDK1.2.2_07, possibly JDK 1.3
(it
crashed).
WLS 5.1, SP8. With inline_instrs_jit=0.
This is the [heap] segment shown by /usr/proc/bin/pmap. This is nativeheap, it is
NOT the Java Heap.
I know it could be the Type 2 db drivers - but I doubt it.
With JDK1.3 we set -XX:MaxPermSize=128m - it crashes after an hour.
One part of the application creates its own threads for some parallelprocessing.
Is this a known
problem with the JVMs?
Any help is much appreciated.
Mike Reiche--
Coming Soon: Building J2EE Applications & BEA WebLogic Server
by Michael Girdley, Rob Woollen, and Sandra Emerson
http://learnweblogic.com

The impact of java.ext.dirs and XMX settings to a JVM

Hello,
I've been using a XMX setting of 3800M for a particular JVM running a particular task.
However, if I pass the -Djava.ext.dirs option, and point it to some directories, the JVM fails for the same task I've been running in my first run.
truss output appears to show the failure occurring during mmap() resulting in ENOMEM.
The question is, under what condition would java.ext.dirs change the behavior of my XMX setting? If it take it out, it runs fine.
Java version: 1.4.1, SunOS Sparc

This sounds like a problem I had a while ago that stumped me for several days.
If your class with the "main" method is loaded from the extensions directory (java.ext.dirs), it appears that a special classloader is used to do that, not the standard classloader that looks in the classpath. This special classloader appears to ignore the classpath and look only in the extensions directory. Also, the JVM appears to try this classloader before the standard classloader.
Now, when one class wants to load another class, it always uses the classloader that loaded it to load that other class (unless you specifically write your program to use some other classloader). So what is happening to you is this: The "extensions classloader" loads your class with the "main" method, because it can. Then your "main" method tries to load another class, but it uses the "extensions classloader" to do that. And the "extensions classloader" doesn't look in the classpath, and what you saw is what you got.
At least the answer to your problem is clear: Don't do that.

IMSL C library causes JVM crash through JNI in GC with JDK 1.6

Hi Java friends,
We use the IMSL C library (made by Visual Numerics) via JNI which picks up a C++ so on Linux. Under JDK 1.5 it works fine. Under 1.6 it crashes in the GC. I put together a very simple testcase that just calls the IMSL error options function (which sets up the library) and it causes the JVM to crash somewhere in the GC. The reason I know it's in the GC is that the crash is not immediate, it's only when the GC is active, so we wrote some test code to push the GC like this:
log("Looping");
long block = 10000000;
int numBlocks = 10;
long loops = block * numBlocks;
for (long i = 0; i < loops; i++) {
// Create some objects that need disposal
String.valueOf(i);
if (i % block == 0) {
log("Reached " + i);
System.gc();
Anyone got any idea why? Crash dump follows.
Many thanks,
David.
# An unexpected error has been detected by Java Runtime Environment:
# SIGSEGV (0xb) at pc=0x00000000, pid=23854, tid=4143893424
# Java VM: Java HotSpot(TM) Server VM (1.6.0_03-b05 mixed mode)
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
--------------- T H R E A D ---------------
Current thread (0x08058c00): JavaThread "main" [_thread_in_Java, id=23855]
siginfo:
[error occurred during error reporting, step 90, id 0xb]
Stack: [0xf6f9c000,0xf6fed000), sp=0xf6feb55c, free space=317k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0x53b9a7]
V [libjvm.so+0x53c5b4]
C [libpthread.so.0+0xb890]
V [libjvm.so+0x53b3f5]
V [libjvm.so+0x53b9a7]
V [libjvm.so+0x4541d0]
V [libjvm.so+0x451a68]
--------------- P R O C E S S ---------------
Java Threads: ( => current thread )
0x08157c00 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=23866]
0x08155c00 JavaThread "CompilerThread1" daemon [_thread_blocked, id=23865]
0x08154800 JavaThread "CompilerThread0" daemon [_thread_blocked, id=23864]
0x08153400 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=23863]
0x08140400 JavaThread "Finalizer" daemon [_thread_blocked, id=23862]
0x0813f800 JavaThread "Reference Handler" daemon [_thread_blocked, id=23861]
=>0x08058c00 JavaThread "main" [_thread_in_Java, id=23855]
Other Threads:
0x0813d000 VMThread [id=23860]
0x08159400 WatcherThread [id=23867]
VM state:synchronizing (normal execution)
VM Mutex/Monitor currently owned by a thread: ([mutex/lock_event])
[0x08056d60/0x08056d88] Safepoint_lock - owner thread: 0x0813d000
[0x08056de0/0x08056e08] Threads_lock - owner thread: 0x0813d000
Heap
PSYoungGen total 87040K, used 8962K [0xecca0000, 0xf21e0000, 0xf3e60000)
eden space 86784K, 10% used [0xecca0000,0xed528b98,0xf2160000)
from space 256K, 87% used [0xf21a0000,0xf21d8040,0xf21e0000)
to space 256K, 0% used [0xf2160000,0xf2160000,0xf21a0000)
PSOldGen total 230976K, used 0K [0xb3e60000, 0xc1ff0000, 0xecca0000)
object space 230976K, 0% used [0xb3e60000,0xb3e60000,0xc1ff0000)
PSPermGen total 16384K, used 2540K [0xafe60000, 0xb0e60000, 0xb3e60000)
object space 16384K, 15% used [0xafe60000,0xb00db1d8,0xb0e60000)
Dynamic libraries:
0085a000-0086f000 r-xp 00000000 68:06 213117 /lib/ld-2.3.4.so
0086f000-00870000 r-xp 00015000 68:06 213117 /lib/ld-2.3.4.so
00870000-00871000 rwxp 00016000 68:06 213117 /lib/ld-2.3.4.so
00873000-00875000 r-xp 00000000 68:06 213179 /lib/libdl-2.3.4.so
00875000-00877000 rwxp 00001000 68:06 213179 /lib/libdl-2.3.4.so
0089b000-009c0000 r-xp 00000000 68:06 213118 /lib/tls/libc-2.3.4.so
009c0000-009c1000 r-xp 00124000 68:06 213118 /lib/tls/libc-2.3.4.so
009c1000-009c4000 rwxp 00125000 68:06 213118 /lib/tls/libc-2.3.4.so
009c4000-009c6000 rwxp 009c4000 00:00 0
009c8000-009e9000 r-xp 00000000 68:06 213200 /lib/tls/libm-2.3.4.so
009e9000-009eb000 rwxp 00020000 68:06 213200 /lib/tls/libm-2.3.4.so
009ed000-009fb000 r-xp 00000000 68:06 213087 /lib/tls/libpthread-2.3.4.so
009fb000-009fd000 rwxp 0000d000 68:06 213087 /lib/tls/libpthread-2.3.4.so
009fd000-009ff000 rwxp 009fd000 00:00 0
00a01000-00a09000 r-xp 00000000 68:06 213205 /lib/tls/librt-2.3.4.so
00a09000-00a0b000 rwxp 00007000 68:06 213205 /lib/tls/librt-2.3.4.so
00a0b000-00a15000 rwxp 00a0b000 00:00 0
00a31000-00a43000 r-xp 00000000 68:06 213202 /lib/libnsl-2.3.4.so
00a43000-00a45000 rwxp 00011000 68:06 213202 /lib/libnsl-2.3.4.so
00a45000-00a47000 rwxp 00a45000 00:00 0
06000000-065a0000 r-xp 00000000 00:1c 172281 /home/gdadev/tools/i686/rhel4.0/jdk1.6.0_03/jre/lib/i386/server/libjvm.so
065a0000-065db000 rwxp 005a0000 00:1c 172281 /home/gdadev/tools/i686/rhel4.0/jdk1.6.0_03/jre/lib/i386/server/libjvm.so
065db000-069fc000 rwxp 065db000 00:00 0
08048000-08052000 r-xp 00000000 00:1c 287782 /home/gdadev/tools/i686/rhel4.0/jdk1.6.0_03/bin/java
08052000-08053000 rwxp 00009000 00:1c 287782 /home/gdadev/tools/i686/rhel4.0/jdk1.6.0_03/bin/java
08053000-08545000 rwxp 08053000 00:00 0
a7210000-a7211000 ---p a7210000 00:00 0
a7211000-a7c11000 rwxp a7211000 00:00 0
a7c11000-a7cd7000 r-xp 00000000 00:1c 498129 /home/gdadev/tools/i686/rhel4.0/gcc-3.4.6/lib/libstdc++.so.6.0.3
a7cd7000-a7cdc000 rwxp 000c6000 00:1c 498129 /home/gdadev/tools/i686/rhel4.0/gcc-3.4.6/lib/libstdc++.so.6.0.3
a7cdc000-a7ce1000 rwxp a7cdc000 00:00 0
a7ce1000-a7dc6000 r-xp 00000000 00:1f 2900632 /home/cartedav/workspaces/dev/vendor/i686-rhel4.0-gcc3.4/lib/libstlport-mcg-5.1.so
a7dc6000-a7de2000 rwxp 000e4000 00:1f 2900632 /home/cartedav/workspaces/dev/vendor/i686-rhel4.0-gcc3.4/lib/libstlport-mcg-5.1.so
a7de2000-a7de6000 rwxp a7de2000 00:00 0
a7de6000-a7f5c000 r-xp 00000000 00:1f 2900652 /home/cartedav/workspaces/dev/vendor/i686-rhel4.0-gcc3.4/lib/libmkl_vml_def.so
a7f5c000-a7f6b000 rwxp 00175000 00:1f 2900652 /home/cartedav/workspaces/dev/vendor/i686-rhel4.0-gcc3.4/lib/libmkl_vml_def.so
a7f6b000-a8434000 r-xp 00000000 00:1f 2900523 /home/cartedav/workspaces/dev/vendor/i686-rhel4.0-gcc3.4/lib/libmkl_lapack.so
a8434000-a8436000 rwxp 004c9000 00:1f 2900523 /home/cartedav/workspaces/dev/vendor/i686-rhel4.0-gcc3.4/lib/libmkl_lapack.so
a8436000-a8492000 r-xp 00000000 00:1f 2900484 /home/cartedav/workspaces/dev/vendor/i686-rhel4.0-gcc3.4/lib/libmkl_core.so
a8492000-a8496000 rwxp 0005b000 00:1f 2900484 /home/cartedav/workspaces/dev/vendor/i686-rhel4.0-gcc3.4/lib/libmkl_core.so
a8496000-a84a4000 rwxp a8496000 00:00 0
a84a4000-a8652000 r-xp 00000000 00:1f 2900521 /home/cartedav/workspaces/dev/vendor/i686-rhel4.0-gcc3.4/lib/libmkl_intel_thread.so
a8652000-a869f000 rwxp 001ae000 00:1f 2900521 /home/cartedav/workspaces/dev/vendor/i686-rhel4.0-gcc3.4/lib/libmkl_intel_thread.so
a869f000-a86a0000 rwxp a869f000 00:00 0
a86a0000-a87d9000 r-xp 00000000 00:1f 2900517 /home/cartedav/workspaces/dev/vendor/i686-rhel4.0-gcc3.4/lib/libmkl_intel.so
a87d9000-a87dc000 rwxp 00139000 00:1f 2900517 /home/cartedav/workspaces/dev/vendor/i686-rhel4.0-gcc3.4/lib/libmkl_intel.so
a87dc000-a87e2000 rwxp a87dc000 00:00 0
a87e2000-a87e9000 r-xp 00000000 00:1f 570263 /home/cartedav/workspaces/dev/mlclib/vendors-gda2/i686-rhel4.0-gcc3.4/lib/libimslcstat_iblas.so
a87e9000-a87ea000 rwxp 00006000 00:1f 570263 /home/cartedav/workspaces/dev/mlclib/vendors-gda2/i686-rhel4.0-gcc3.4/lib/libimslcstat_iblas.so
a87ea000-a8b08000 r-xp 00000000 00:1f 570239 /home/cartedav/workspaces/dev/mlclib/vendors-gda2/i686-rhel4.0-gcc3.4/lib/libimslcstat.so
a8b08000-a8b45000 rwxp 0031d000 00:1f 570239 /home/cartedav/workspaces/dev/mlclib/vendors-gda2/i686-rhel4.0-gcc3.4/lib/libimslcstat.so
a8b45000-a8b5e000 r-xp 00000000 00:1f 570822 /home/cartedav/workspaces/dev/mlclib/vendors-gda2/i686-rhel4.0-gcc3.4/lib/libimslcmath_iblas.so
a8b5e000-a8b5f000 rwxp 00019000 00:1f 570822 /home/cartedav/workspaces/dev/mlclib/vendors-gda2/i686-rhel4.0-gcc3.4/lib/libimslcmath_iblas.so
a8b5f000-a8c18000 r-xp 00000000 00:1f 570832 /home/cartedav/workspaces/dev/mlclib/vendors-gda2/i686-rhel4.0-gcc3.4/lib/libimslcmath_scalar.so
a8c18000-a8c19000 rwxp 000b8000 00:1f 570832 /home/cartedav/workspaces/dev/mlclib/vendors-gda2/i686-rhel4.0-gcc3.4/lib/libimslcmath_scalar.so
a8c19000-a8ee7000 r-xp 00000000 00:1f 570819 /home/cartedav/workspaces/dev/mlclib/vendors-gda2/i686-rhel4.0-gcc3.4/lib/libimslcmath.so
a8ee7000-a8ef6000 rwxp 002ce000 00:1f 570819 /home/cartedav/workspaces/dev/mlclib/vendors-gda2/i686-rhel4.0-gcc3.4/lib/libimslcmath.so
a8ef6000-a8ef7000 rwxp a8ef6000 00:00 0
a8ef7000-a8f19000 r-xp 00000000 00:1f 2900421 /home/cartedav/workspaces/dev/vendor/i686-rhel4.0-gcc3.4/lib/libboost_thread-mcg-1.34-stlport-5.1.so
a8f19000-a8f1d000 rwxp 00022000 00:1f 2900421 /home/cartedav/workspaces/dev/vendor/i686-rhel4.0-gcc3.4/lib/libboost_thread-mcg-1.34-stlport-5.1.so
a8f1d000-aa180000 r-xp 00000000 00:1f 761178 /home/cartedav/workspaces/dev/mlclib/build/i686-rhel4.0-gcc3.4/checked-stlport-fine-full-multi-dynamic/libgda2mlclib.so
aa180000-aa430000 rwxp 01263000 00:1f 761178 /home/cartedav/workspaces/dev/mlclib/build/i686-rhel4.0-gcc3.4/checked-stlport-fine-full-multi-dynamic/libgda2mlclib.so
aa430000-aa53a000 rwxp aa430000 00:00 0
aa53a000-ad779000 r-xp 00000000 00:1f 699688 /home/cartedav/workspaces/dev/mlclib/build/i686-rhel4.0-gcc3.4/checked-stlport-fine-full-multi-dynamic/libgda2ocean.so
ad779000-ae56b000 rwxp 0323f000 00:1f 699688 /home/cartedav/workspaces/dev/mlclib/build/i686-rhel4.0-gcc3.4/checked-stlport-fine-full-multi-dynamic/libgda2ocean.so
ae56b000-ae7a8000 rwxp ae56b000 00:00 0
ae7a8000-ae886000 r-xp 00000000 00:1f 699721 /home/cartedav/workspaces/dev/mlclib/build/i686-rhel4.0-gcc3.4/checked-stlport-fine-full-multi-dynamic/libgda2generic.so
ae886000-ae8a6000 rwxp 000de000 00:1f 699721 /home/cartedav/workspaces/dev/mlclib/build/i686-rhel4.0-gcc3.4/checked-stlport-fine-full-multi-dynamic/libgda2generic.so
ae8a6000-ae8ac000 rwxp ae8a6000 00:00 0
ae8ac000-ae904000 r-xp 00000000 00:1c 206109 /home/gdadev/builds/nightly/i686-rhel4.0-gcc3.4/libguide.so
ae904000-ae909000 rwxp 00058000 00:1c 206109 /home/gdadev/builds/nightly/i686-rhel4.0-gcc3.4/libguide.so
ae909000-ae90e000 rwxp ae909000 00:00 0
ae90e000-aef20000 r-xp 00000000 00:1c 52046 /home/gdadev/builds/nightly/i686-rhel4.0-gcc3.4/libgda2rt.so
aef20000-af01d000 rwxp 00612000 00:1c 52046 /home/gdadev/builds/nightly/i686-rhel4.0-gcc3.4/libgda2rt.so
af01d000-af028000 rwxp af01d000 00:00 0
af028000-af030000 r-xp 00000000 00:1c 497827 /home/gdadev/tools/i686/rhel4.0/gcc-3.4.6/lib/libgcc_s.so.1
af030000-af031000 rwxp 00007000 00:1c 497827 /home/gdadev/tools/i686/rhel4.0/gcc-3.4.6/lib/libgcc_s.so.1
af031000-af136000 r-xp 00000000 00:1c 205704 /home/gdadev/builds/nightly/i686-rhel4.0-gcc3.4/libgda2jni.so
af136000-af158000 rwxp 00105000 00:1c 205704 /home/gdadev/builds/nightly/i686-rhel4.0-gcc3.4/libgda2jni.so
af158000-af15d000 rwxp af158000 00:00 0
af15d000-af15f000 r-xs 00009000 00:1c 205693 /home/gdadev/builds/nightly/i686-rhel4.0-gcc3.4/gda2.jar
af15f000-af160000 ---p af15f000 00:00 0
af160000-af1e0000 rwxp af160000 00:00 0
af1e0000-af1e3000 ---p af1e0000 00:00 0
af1e3000-af231000 rwxp af1e3000 00:00 0
af231000-af234000 ---p af231000 00:00 0
af234000-af2b2000 rwxp af234000 00:00 0
af2b2000-af2b5000 ---p af2b2000 00:00 0
af2b5000-af333000 rwxp af2b5000 00:00 0
af333000-af336000 ---p af333000 00:00 0
af336000-af384000 rwxp af336000 00:00 0
af384000-af584000 r-xp 00000000 68:06 101636 /usr/lib/locale/locale-archive
af584000-af587000 ---p af584000 00:00 0
af587000-af5d5000 rwxp af587000 00:00 0
af5d5000-af5d8000 ---p af5d5000 00:00 0
af5d8000-af626000 rwxp af5d8000 00:00 0
af626000-af627000 ---p af626000 00:00 0
af627000-af6d7000 rwxp af627000 00:00 0
af6d7000-af853000 r-xs 02c8f000 00:1c 925583 /home/gdadev/tools/i686/rhel4.0/jdk1.6.0_03/jre/lib/rt.jar
af853000-af854000 ---p af853000 00:00 0
af854000-af8d4000 rwxp af854000 00:00 0
af8d4000-af8d5000 ---p af8d4000 00:00 0
af8d5000-af955000 rwxp af8d5000 00:00 0
af955000-af956000 ---p af955000 00:00 0
af956000-af9d6000 rwxp af956000 00:00 0
af9d6000-af9d7000 ---p af9d6000 00:00 0
af9d7000-afa5f000 rwxp af9d7000 00:00 0
afa5f000-afa77000 rwxp afa5f000 00:00 0
afa77000-afae8000 rwxp afa77000 00:00 0
afae8000-afc3f000 rwxp afae8000 00:00 0
afc3f000-afc47000 rwxp afc3f000 00:00 0
afc47000-afc5f000 rwxp afc47000 00:00 0
afc5f000-afcd0000 rwxp afc5f000 00:00 0
afcd0000-afe26000 rwxp afcd0000 00:00 0
afe26000-afe51000 rwxp afe26000 00:00 0
afe51000-afe5f000 rwxp afe51000 00:00 0
afe5f000-b0e60000 rwxp afe5f000 00:00 0
b0e60000-b3e60000 rwxp b0e60000 00:00 0
b3e60000-c1ff0000 rwxp b3e60000 00:00 0
c1ff0000-ecca0000 rwxp c1ff0000 00:00 0
ecca0000-f21e0000 rwxp ecca0000 00:00 0
f21e0000-f3e60000 rwxp f21e0000 00:00 0
f3e6d000-f3e76000 rwxp f3e6d000 00:00 0
f3e76000-f3f2d000 rwxp f3e76000 00:00 0
f3f2d000-f416d000 rwxp f3f2d000 00:00 0
f416d000-f6f2d000 rwxp f416d000 00:00 0
f6f2d000-f6f3c000 r-xp 00000000 00:1c 172554 /home/gdadev/tools/i686/rhel4.0/jdk1.6.0_03/jre/lib/i386/libzip.so
f6f3c000-f6f3e000 rwxp 0000e000 00:1c 172554 /home/gdadev/tools/i686/rhel4.0/jdk1.6.0_03/jre/lib/i386/libzip.so
f6f3e000-f6f61000 r-xp 00000000 00:1c 172497 /home/gdadev/tools/i686/rhel4.0/jdk1.6.0_03/jre/lib/i386/libjava.so
f6f61000-f6f63000 rwxp 00023000 00:1c 172497 /home/gdadev/tools/i686/rhel4.0/jdk1.6.0_03/jre/lib/i386/libjava.so
f6f63000-f6f6e000 r-xp 00000000 00:1c 172493 /home/gdadev/tools/i686/rhel4.0/jdk1.6.0_03/jre/lib/i386/libverify.so
f6f6e000-f6f6f000 rwxp 0000b000 00:1c 172493 /home/gdadev/tools/i686/rhel4.0/jdk1.6.0_03/jre/lib/i386/libverify.so
f6f6f000-f6f77000 rwxs 00000000 68:06 247809 /tmp/hsperfdata_cartedav/23854
f6f77000-f6f7f000 r-xp 00000000 68:06 213047 /lib/libnss_nis-2.3.4.so
f6f7f000-f6f81000 rwxp 00007000 68:06 213047 /lib/libnss_nis-2.3.4.so
f6f81000-f6f8a000 r-xp 00000000 68:06 213042 /lib/libnss_files-2.3.4.so
f6f8a000-f6f8c000 rwxp 00008000 68:06 213042 /lib/libnss_files-2.3.4.so
f6f93000-f6f99000 r-xp 00000000 00:1c 172254 /home/gdadev/tools/i686/rhel4.0/jdk1.6.0_03/jre/lib/i386/native_threads/libhpi.so
f6f99000-f6f9a000 rwxp 00006000 00:1c 172254 /home/gdadev/tools/i686/rhel4.0/jdk1.6.0_03/jre/lib/i386/native_threads/libhpi.so
f6f9a000-f6f9b000 rwxp f6f9a000 00:00 0
f6f9b000-f6f9c000 ---p f6f9b000 00:00 0
f6f9c000-f6f9f000 ---p f6f9c000 00:00 0
f6f9f000-f6fef000 rwxp f6f9f000 00:00 0
f6fef000-f6ff6000 r-xp 00000000 00:1c 172514 /home/gdadev/tools/i686/rhel4.0/jdk1.6.0_03/jre/lib/i386/jli/libjli.so
f6ff6000-f6ff8000 rwxp 00006000 00:1c 172514 /home/gdadev/tools/i686/rhel4.0/jdk1.6.0_03/jre/lib/i386/jli/libjli.so
f6fff000-f7000000 rwxp f6fff000 00:00 0
feff9000-ff000000 rwxp feff9000 00:00 0
ffffe000-fffff000 ---p 00000000 00:00 0
VM Arguments:
java_command: TestCrash AGRCRV.ODR.CC.xdr
Launcher Type: SUN_STANDARD
Environment Variables:
JAVA_HOME=/home/gdadev/tools/i686/rhel4.0/jdk1.6.0_03
PATH=/home/gdadev/tools/i686/rhel4.0/jdk1.6.0_03/bin:/home/cartedav/bin:/home/gdadev/tools/i686/rhel4.0/j2sdk/bin:/home/gdadev/tools/i686/rhel4.0/gcc-3.4.6/bin:/home/gdadev/tools/i686/rhel4.0/bin:/home/cartedav/workspaces/dev/images/i686-rhel4.0-gcc3.4/bin:/home/gdadev/tools/i686/rhel4.0/j2sdk/bin:/home/cartedav/workspaces/dev/vendor/i686-rhel4.0-gcc3.4/bin:/home/gdadev/tools/i686/rhel4.0/j2sdk/bin:/apps/linuxdev/bin:/usr/kerberos/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/quest/bin:/usr/X11R6/bin:
LD_LIBRARY_PATH=/home/gdadev/tools/i686/rhel4.0/jdk1.6.0_03/jre/lib/i386/server:/home/gdadev/tools/i686/rhel4.0/jdk1.6.0_03/jre/lib/i386:/home/gdadev/tools/i686/rhel4.0/jdk1.6.0_03/jre/../lib/i386:/home/cartedav/workspaces/dev/vendor/i686-rhel4.0-gcc3.4/lib:/home/gdadev/builds/nightly/i686-rhel4.0-gcc3.4/:/home/cartedav/workspaces/dev/mlclib/vendors-gda2/i686-rhel4.0-gcc3.4/lib:/home/gdadev/tools/i686/rhel4.0/j2sdk/lib:/home/gdadev/tools/i686/rhel4.0/gcc-3.4.6/lib:/home/gdadev/tools/i686/rhel4.0/lib:/home/cartedav/workspaces/dev/images/i686-rhel4.0-gcc3.4/lib:/home/cartedav/workspaces/dev/vendor/i686-rhel4.0-gcc3.4/lib:/home/gdadev/tools/i686/rhel4.0/j2sdk/lib:/apps/linuxdev/lib::
SHELL=/bin/csh
DISPLAY=169.243.119.66:0.0
HOSTTYPE=i386-linux
OSTYPE=linux
MACHTYPE=i386
Signal Handlers:
SIGSEGV: [libjvm.so+0x53c560], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGBUS: [libjvm.so+0x53c560], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGFPE: [libjvm.so+0x451a50], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGPIPE: [libjvm.so+0x451a50], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGILL: [libjvm.so+0x451a50], sa_mask[0]=0x00000000, sa_flags=0xe0000000, flags was changed from 0x10000004, consider using jsig library
SIGUSR1: SIG_DFL, sa_mask[0]=0x00000000, sa_flags=0x00000000
SIGUSR2: [libjvm.so+0x453a80], sa_mask[0]=0x00000000, sa_flags=0x10000004
SIGHUP: [libjvm.so+0x4534a0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGINT: [libjvm.so+0x4534a0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGQUIT: [libjvm.so+0x4534a0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGTERM: [libjvm.so+0x4534a0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGUSR2: [libjvm.so+0x453a80], sa_mask[0]=0x00000000, sa_flags=0x10000004
--------------- S Y S T E M ---------------
OS:Red Hat Enterprise Linux AS release 4 (Nahant Update 4)
uname:Linux 2.6.9-42.0.2.ELhugemem #1 SMP Thu Aug 17 18:22:52 EDT 2006 i686
libc:glibc 2.3.4 NPTL 2.3.4
rlimit: STACK 10240k, CORE 0k, NPROC 274431, NOFILE 1024, AS infinity
load average:0.28 0.17 0.16
CPU:total 4 (2 cores per cpu, 1 threads per core) family 15 model 65 stepping 2, cmov, cx8, fxsr, mmx, sse, sse2, sse3, mmxext, 3dnow, 3dnowext
Memory: 4k page, physical 16629672k(722080k free), swap 16779884k(16779740k free)
vm_info: Java HotSpot(TM) Server VM (1.6.0_03-b05) for linux-x86, built on Sep 24 2007 22:32:39 by "java_re" with gcc 3.2.1-7a (J2SE release)

Thanks very much for your advice. Unfortunately, stepping through the code doesn't help at all. The error occurs much later after the C code has been executed, whilst running the java code (which is just creating string objects to invoke the GC). The C code that we are executing is extremely simple - it consists of Sun's JNI example coupled with a sinlge call to the IMSL error options function:
JNIEXPORT jbyteArray JNICALL Java_ReadFile_loadFile
(JNIEnv * env, jobject jobj, jstring name) {
printf("%s", "Setting imsl_error_options()...\n");
imsl_error_options( IMSL_SET_SIGNAL_TRAPPING, 0, // Disable IMSL signal trapping - necessary for MT code.
IMSL_SET_STOP, IMSL_FATAL, 0, // Disable stopping on FATAL errors
IMSL_SET_STOP, IMSL_FATAL_IMMEDIATE, 0, // Disable stopping on FATAL_IMMEDIATE errors
IMSL_SET_STOP, IMSL_TERMINAL, 0, // Disable stopping on TERMINAL errors
IMSL_SET_PRINT, IMSL_FATAL, 1, // Enable printing on FATAL errors
IMSL_SET_PRINT, IMSL_FATAL_IMMEDIATE, 1, // Enable printing on FATAL_IMMEDIATE errors
IMSL_SET_PRINT, IMSL_TERMINAL, 1, // Enable printing on TERMINAL errors
IMSL_SET_PRINT, IMSL_WARNING, 1, // Enable printing on WARNING errors
IMSL_SET_PRINT, IMSL_WARNING_IMMEDIATE, 1, // Enable printing on WARNING_IMMEDIATE errors
IMSL_SET_PRINT, IMSL_ALERT, 1, // Enable printing on TERMINAL errors
IMSL_SET_PRINT, IMSL_NOTE, 1, // Enable printing on TERMINAL errors
0 );
caddr_t m;
jbyteArray jb;
jboolean iscopy;
struct stat finfo;
const char mfile = (env)->GetStringUTFChars(
env, name, &iscopy);
int fd = open(mfile, O_RDONLY);
if (fd == -1) {
printf("Could not open %s\n", mfile);
lstat(mfile, &finfo);
m = mmap((caddr_t) 0, finfo.st_size,
PROT_READ, MAP_PRIVATE, fd, 0);
if (m == (caddr_t)-1) {
printf("Could not mmap %s\n", mfile);
return(0);
jb=(*env)->NewByteArray(env, finfo.st_size);
(*env)->SetByteArrayRegion(env, jb, 0,
finfo.st_size, (jbyte *)m);
close(fd);
(*env)->ReleaseStringUTFChars(env, name, mfile);
return (jb);
If I remove the call to imsl_error_options then there is no adverse behaviour - the Java loop completes ok (creating 1 trillion strings in the process) and the manual call the GC works fine. With the call to imsl, the execution gets to the string creation loop (in Java, after the C has been executed) and then it dies pretty quickly (presumably after the GC kicks in to clean up some of the strings).
Here is the java code:
import java.util.*;
class ReadFile {
//Native method declaration
native byte[] loadFile(String name);
//Load the library
static {
System.loadLibrary("nativelib");
public static void main(String args[]) {
byte buf[];
//Create class instance
ReadFile mappedFile=new ReadFile();
//Call native method to load ReadFile.java
buf=mappedFile.loadFile("ReadFile.java");
//Print contents of ReadFile.java
for(int i=0;i<buf.length;i++) {
System.out.print((char)buf);
System.out.print("Now running the string creation loop...\n");
long block = 100000000;
int numBlocks = 10;
long loops = block * numBlocks;
for (long i = 0; i < loops; i++) {
// Create some objects that need disposal
String.valueOf(i);
if (i % block == 0) {
System.out.print("Reached " + i + "\n");
System.out.print("Now running the GC...\n");
System.gc();

Which JVM for PDA?

I have to develop an application that runs on a Dell Axim X51 with Intel XScale PXA270 processor and Windows Mobile 5.0 OS.
I am new to J2ME and I'm not sure if there is already a JVM installed.
(I don't have the PDA yet)
What JVM can I use? Can I just install the SUN CDLC Reference Implementation and everything is fine or do I have to install some other JVM like IBM J9?
(Or have I mixed up something and the CLDC Reference Implementation is no JVM?)
Can somebody help me, please?

Hi,
I downloaded and installed on my HP iPAQ hx2790 JVM
from IBM - J9.
The file is:
ibm-weme-wm50-arm-ppro11_6.1.1.20061110-161633.exe
This JVM works on my HP iPAQ hx2790 (Windows Mobile
5.0 OS).
At least it was possible to run first example.
By the way - my device HP iPAQ hx2790 is not in the
list of target devices for J9, but in practice J9
works on this device.
Is J9 good or not - I don't know yet. Never did god
tests yet.
Go to IBM and try to use J9.
http://www.RoboHobby.com - Java brain for small J2ME
robot with camera.
.J9 is OK for most PDA devices. A big problem with J9 is that it does not support Video or any other Optional API that are supported by most smartphones (i.e. Bluetooth, Location, MMAPI).
I still cant believe that in order to play a small video file I need to write JNI crossplatform code.
Has anyone tried to play a video file with J9.
Mike Greece...

MMAPI compatibility Cell Phones

We are in the designing stages for a program to capture aduio from cellphones and store it. We are planning to use MMAPI in order to acheive this.
The following are the doubts I have..
1. Can the program work across all cellphones implementing MMAPI or will it have to be modified in some way for each phone?
2. If the program is built using MMAPI will PocketPC and Windows Mobile phones support it?
3. Is there any other way to effectively capture audio from phones not implementing MMAPI?

I have devceloped MMAPI apps on several handsets..
What you should be doing at this stage is to complete spreadsheet called MMAPI compatibility matrix..
You will going throuhg the datasheets per hdnset serie4s and vendor to determine what compatibilityproblems exits..
Than when you have the full number of hadnsets that you can deploy to without problems you will thna have clearer pciture of to use MMAPi or not..
For most updated handsets yes you can use MMAPI..
on WIndowsMobile and other oSes as long as the J2ME jVm supports mampi you are golden..for the most part most J2ME JVms on wondowsMobile and pocketpc do support MMAPI..
If you or your company needs help tha they can py for you can reach me at [email protected]

How do I run multiple java apps in one JVM to reduce memory use?

Hi all,
I saw an article either on the web or in a magazine not too long ago about how to "detect" if the app is already running, and if so, it hands off the new instance to the already running JVM, which then creates a thread to run the Java app in. As it turns out, my app will be used in an ASP environment, through Citrix. We may have as many as 50 to 100 users running the same app, each with their own unique user ID, but all using the same one server to run it on. Each instance eats up 25MB of memory right now. So the question is if anybody knows of a URL or an app like this that can handle the process of running the same (or even different Java) apps in one JVM as separate threads, instead of requring several instances of the JVM to run? I know this article presented a fully working example, and I believe I know enough to do it but I wanted ot use the article as a reference to make sure it is done right. I know that each app basically would use the same one "launcher" program that would on first launch "listen" to a port, as well as send a message through the port to see if an existing launcher was running. If it does, it hands off the Java app to be run to the existing luancher application and shuts down the 2nd launching app. By using this method, the JVM eats up its normal memory, but each Java app only consumes its necessary memory as well and doesn't use up more JVM instance memory.
Thanks.

<pre>
import java.util.Properties;
import java.io.FileInputStream;
import java.io.IOException;
import java.lang.reflect.Method;
import java.lang.reflect.InvocationTargetException;
import java.util.Enumeration;
import java.util.NoSuchElementException;
public class RunProg implements Runnable, Cloneable
private String iProg;
private String iArgs[];
public static void main(String args[])
new RunProg().main();
// first step is to start main program itself
private void main()
Properties properties = System.getProperties();
try
properties.load(new FileInputStream("RunProg.properties"));
catch(IOException e)
System.setProperties(properties);
int i = 0;
System.out.println("enter main, activeCount=" + Thread.activeCount());
while(true)
String program = properties.getProperty("Prog" + i);
if(program == null)
break;
StringTokenizer st = new StringTokenizer(program);
String[] args = new String[st.countTokens() - 1];
try
RunProg rp = (RunProg)this.clone();
rp.iProg = st.nextToken();
for(int j = 0; st.hasMoreTokens(); j++)
     args[j] = st.nextToken();
rp.iArgs = args;
Thread th = new Thread(rp);
th.setName("prog" + i + "=" + program);
th.start();
System.out.println("prog" + i + "=" + program + ", started");
catch(CloneNotSupportedException e)
System.out.println("prog" + i + "=" + program + ", can't start");
i++;
     System.out.println("end of main, activeCount=" + Thread.activeCount());
// next step is to start all others one by one
public void run()
try
Class c = Class.forName(iProg);
Class p[] = new Class[1];
p[0] = String[].class;
Method m = c.getMethod("main", p);
Object o[] = new Object[1];
o[0] = iArgs;
m.invoke(null, o);
catch(ClassNotFoundException e)
System.out.println(iProg + "ClassNotFoundException");
catch(NoSuchMethodException e)
System.out.println(iProg + "NoSuchMethodException");
catch(InvocationTargetException e)
System.out.println(iProg + "NoSuchMethodException");
catch(IllegalAccessException e)
System.out.println(iProg + "NoSuchMethodException");
System.out.println(Thread.currentThread().getName() + ", ended");
System.out.println("exit run, activeCount=" + Thread.activeCount());
// setup SecurityManager to disable method System.exit()
public RunProg()
     SecurityManager sm = new mySecurityManager();
     System.setSecurityManager(sm);
// inner-class to disable method System.exit()
protected class mySecurityManager extends SecurityManager
     public void checkExit(int status)
          super.checkExit(status);
          Thread.currentThread().stop();
          throw new SecurityException();
* inner-class to analyze StringTokenizer. This class is enhanced to check double Quotation marks
protected class StringTokenizer implements Enumeration
private int currentPosition;
private int maxPosition;
private String str;
private String delimiters;
private boolean retTokens;
* Constructs a string tokenizer for the specified string. All
* characters in the <code>delim</code> argument are the delimiters
* for separating tokens.
* <p>
* If the <code>returnTokens</code> flag is <code>true</code>, then
* the delimiter characters are also returned as tokens. Each
* delimiter is returned as a string of length one. If the flag is
* <code>false</code>, the delimiter characters are skipped and only
* serve as separators between tokens.
* @param str a string to be parsed.
* @param delim the delimiters.
* @param returnTokens flag indicating whether to return the delimiters
* as tokens.
public StringTokenizer(String str, String delim, boolean returnTokens)
currentPosition = 0;
this.str = str;
maxPosition = str.length();
delimiters = delim;
retTokens = returnTokens;
* Constructs a string tokenizer for the specified string. The
* characters in the <code>delim</code> argument are the delimiters
* for separating tokens. Delimiter characters themselves will not
* be treated as tokens.
* @param str a string to be parsed.
* @param delim the delimiters.
public StringTokenizer(String str, String delim)
this(str, delim, false);
* Constructs a string tokenizer for the specified string. The
* tokenizer uses the default delimiter set, which is
* <code>"\t\n\r\f"</code>: the space character, the tab
* character, the newline character, the carriage-return character,
* and the form-feed character. Delimiter characters themselves will
* not be treated as tokens.
* @param str a string to be parsed.
public StringTokenizer(String str)
this(str, " \t\n\r\f", false);
* Skips delimiters.
protected void skipDelimiters()
while(!retTokens &&
(currentPosition < maxPosition) &&
(delimiters.indexOf(str.charAt(currentPosition)) >= 0))
currentPosition++;
* Tests if there are more tokens available from this tokenizer's string.
* If this method returns <tt>true</tt>, then a subsequent call to
* <tt>nextToken</tt> with no argument will successfully return a token.
* @return <code>true</code> if and only if there is at least one token
* in the string after the current position; <code>false</code>
* otherwise.
public boolean hasMoreTokens()
skipDelimiters();
return(currentPosition < maxPosition);
* Returns the next token from this string tokenizer.
* @return the next token from this string tokenizer.
* @exception NoSuchElementException if there are no more tokens in this
* tokenizer's string.
public String nextToken()
skipDelimiters();
if(currentPosition >= maxPosition)
throw new NoSuchElementException();
int start = currentPosition;
boolean inQuotation = false;
while((currentPosition < maxPosition) &&
(delimiters.indexOf(str.charAt(currentPosition)) < 0 || inQuotation))
if(str.charAt(currentPosition) == '"')
inQuotation = !inQuotation;
currentPosition++;
if(retTokens && (start == currentPosition) &&
(delimiters.indexOf(str.charAt(currentPosition)) >= 0))
currentPosition++;
String s = str.substring(start, currentPosition);
if(s.charAt(0) == '"')
s = s.substring(1);
if(s.charAt(s.length() - 1) == '"')
s = s.substring(0, s.length() - 1);
return s;
* Returns the next token in this string tokenizer's string. First,
* the set of characters considered to be delimiters by this
* <tt>StringTokenizer</tt> object is changed to be the characters in
* the string <tt>delim</tt>. Then the next token in the string
* after the current position is returned. The current position is
* advanced beyond the recognized token. The new delimiter set
* remains the default after this call.
* @param delim the new delimiters.
* @return the next token, after switching to the new delimiter set.
* @exception NoSuchElementException if there are no more tokens in this
* tokenizer's string.
public String nextToken(String delim)
delimiters = delim;
return nextToken();
* Returns the same value as the <code>hasMoreTokens</code>
* method. It exists so that this class can implement the
* <code>Enumeration</code> interface.
* @return <code>true</code> if there are more tokens;
* <code>false</code> otherwise.
* @see java.util.Enumeration
* @see java.util.StringTokenizer#hasMoreTokens()
public boolean hasMoreElements()
return hasMoreTokens();
* Returns the same value as the <code>nextToken</code> method,
* except that its declared return value is <code>Object</code> rather than
* <code>String</code>. It exists so that this class can implement the
* <code>Enumeration</code> interface.
* @return the next token in the string.
* @exception NoSuchElementException if there are no more tokens in this
* tokenizer's string.
* @see java.util.Enumeration
* @see java.util.StringTokenizer#nextToken()
public Object nextElement()
return nextToken();
* Calculates the number of times that this tokenizer's
* <code>nextToken</code> method can be called before it generates an
* exception. The current position is not advanced.
* @return the number of tokens remaining in the string using the current
* delimiter set.
* @see java.util.StringTokenizer#nextToken()
public int countTokens()
int count = 0;
int currpos = currentPosition;
while(currpos < maxPosition)
* This is just skipDelimiters(); but it does not affect
* currentPosition.
while(!retTokens &&
(currpos < maxPosition) &&
(delimiters.indexOf(str.charAt(currpos)) >= 0))
currpos++;
if(currpos >= maxPosition)
break;
int start = currpos;
boolean inQuotation = false;
while((currpos < maxPosition) &&
(delimiters.indexOf(str.charAt(currpos)) < 0 || inQuotation))
if(str.charAt(currpos) == '"')
inQuotation = !inQuotation;
currpos++;
if(retTokens && (start == currpos) &&
(delimiters.indexOf(str.charAt(currpos)) >= 0))
currpos++;
count++;
return count;
</pre>
RunProg.properties like this:
Prog1=GetEnv 47838 837489 892374 839274
Prog0=GetEnv "djkfds dfkljsd" dsklfj

Communication between multiple JVMs

We have a Java toolkit that is shipped as a JAR file. The toolkit is ported from a C++ DLL running on Windows. Therefore, in both instances (Java and C++), we can't control who loads us or when.
I need to communicate between different JVMs running on the same machine. The communication is very simple: "Is this user logged on in your JVM?" I send a string to the other JVM and I get back a boolean. I don't need to worry about crossing machine boundaries. Also, I'm not expecting to have a huge number of JVMs running. Maybe 3 or 4 could be likely. However, the solution does need to scale in case there are more than that. I'm not setting a limit on the number of JVMs either.
The C++ code handled this situation very easily and elegantly. It created a named system semaphore (mutex) whenever a user logged on. The name of the mutex was the username. So, if there were multiple instances of the DLL running in separate processes (EXEs), we could easily tell if this user was logged on in another instance. We'd try to create the system semaphore - it would fail saying the name already exists. Therefore, we'd know the user was already logged on. The named system semaphore provided the means for a machine-global list - which is exactly what we wanted. It also had this extra benefit: if the process terminates normally or abnormally, the system semaphore is removed from memory. This means: the application is terminated, the user is no longer logged on, and we can relog this user on.
Therefore, I have 2 requirements:
1) A machine-global list where we can place a string. Keep in mind, it doesn't absolutely have to be a machine-global list. A suitable means to talk to other JVMs is acceptable too.
2) If the process exits normally or abnormally, the string(s) get removed (for this JVM) from the list. Abnormal termination is the more important one to focus on because lots of people of varying skill levels use our toolkit. Abnormal terminations can be common.
The first thought is to store these in a file. That solves #1, but not #2. I've seen the JIPC package. However, I'm not too crazy about requiring 3rd party developers to start up another program (JIPC) before they start up their application. As I said, we're just a toolkit so we can't control when or who loads us. It's not totally out of the question, but I'd prefer something else.
I have a fairly involved solution that involves sockets. The first JVM creates a ServerSocket on a specific port and becomes the server. Subsequent JVMs also try to create the ServerSocket on the same port. They get a BindException because the ServerSocket already exists, so they know they're clients. Then, they create a client socket and talk to the server that way. This gets a little hairy when the server goes away. The clients will scramble to become the server and then all the other clients need to reconnect to the new server.
This proposed solution sounds like it will address both requirements. However, I'm looking for something simpler. I'm asking this forum for help in case there's an easier way to do this. I don't have the breadth of experience with Java yet to know if there's a simpler way to fix this. If I have to go with the socket solution, I will. I just didn't want to overlook something simple that is already built into Java.
Thanks for any tips or suggestions

Thanks for the response.
FileLock. We still have to target JDK 1.3 so we can't use FileLocks (at this point)
JNI: That's an interesting idea. I suspect many people are using our software on Windows. Therefore, we could probably fix it in Windows the same as in the C++ code. If they're not on Windows, we could use the Sockets approach.
I also had another idea: how about hashing the username string into some integer (or long) value. Then use the hashed value to lock some other resource: like the port number passed to ServerSocket. I know ServerSocket only accepts 0 - 0xFFFF so this obviously won't work. But is there some other system-wide thing we could lock given an integral value?

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.

Hotspot core dumping during JVM garbage collection ?

We have an application which calls a 3rd party supplied server API which has recently been upgraded to use Java 1.5
We are getting the following error reported by our client application. The application is also now running Java 1.5 but references many classes in jar files which would have quite old code in.
The supplier of the API has stated that the problem requires us to recompile all our jar files using v 1.5 ( including things like jconnect and jms ?!?!? ). This sounds like a bit of a cop-out to me, not to mention being impossible since we don't have the source for things like jconnect.
I suspect that there is a garbage collection problem at the bottom of all this, but I'm not sure how I can "prove" this, nor do I currently have any real clue as to how to fix any GC problem that may exist.
The application is supposed to wait for a message on a MQSeries queue and then transforms it via Xalan XSLT and sends it to a Server application. I've tried playing around with heap sizes etc but that just seems to make it worse. If I leave it at the settings that the previous version used then the client at least manages to process a couple of messages before core dumping. There doesn't seem to be a consistent trigger event to cause the core dump ( it's not a message arriving on a queue for example ) but it does seem to be fairly consistent timewise, i.e. after
Any ideas gratefully accepted.
Here's a logfile excerpt from my applications showing the Hotspot error message :
=====================================================================================
08-Jul-2008 10:01:05 Waiting for messages from COLT.BBFS
08-Jul-2008 10:02:05 Waiting for messages from COLT.BBFS
08-Jul-2008 10:03:05 Waiting for messages from COLT.BBFS
405.815: [GC [PSYoungGen: 17331K->9244K(37632K)] 111702K->103615K(192128K), 0.1615910 secs]
405.977: [Full GC#
# An unexpected error has been detected by HotSpot Virtual Machine:
# SIGBUS (0xa) at pc=0xfe141348, pid=2600, tid=8
# Java VM: Java HotSpot(TM) Server VM (1.5.0_03-b07 mixed mode)
# Problematic frame:
# V [libjvm.so+0x141348]
# An error report file with more information is saved as hs_err_pid2600.log
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
=====================================================================================
The logfile referred to in the error message contains the following.
=====================================================================================
# An unexpected error has been detected by HotSpot Virtual Machine:
# SIGBUS (0xa) at pc=0xfe141348, pid=2600, tid=8
# Java VM: Java HotSpot(TM) Server VM (1.5.0_03-b07 mixed mode)
# Problematic frame:
# V [libjvm.so+0x141348]
--------------- T H R E A D ---------------
Current thread (0x001484d8): VMThread [id=8]
siginfo:si_signo=10, si_errno=0, si_code=1, si_addr=0x0000080f
Registers:
O0=0x00487588 O1=0xfe7d6454 O2=0x000079b0 O3=0x00007800
O4=0x00008868 O5=0x00147d48 O6=0xf8781460 O7=0xfe0f7938
G1=0xe52aaae8 G2=0x00000003 G3=0x00000003 G4=0x001484d8
G5=0xf8781d98 G6=0x00000002 G7=0xf8781d98 Y=0x805683e2
PC=0xfe141348 nPC=0xfe14134c
Top of Stack: (sp=0xf8781460)
0xf8781460: fe786000 00c6ba20 fe10013c e54bab68
0xf8781470: 0000080f e54bab6c 0000080f 00000004
0xf8781480: 00487588 00000134 e54bab6c 00000004
0xf8781490: 00000001 00000000 f87814c0 fe17aef4
0xf87814a0: fe6485b4 fe7d899c 001484d8 0011da40
0xf87814b0: 00148988 00148c10 00148d7c f8781880
0xf87814c0: 007c3389 007c3c0e 00000f87 00008868
0xf87814d0: 00008800 00487588 fe141310 fe7d6454
Instructions: (pc=0xfe141348)
0xfe141338: ec 06 c0 1a 80 a5 a0 00 22 40 00 0a ba 07 60 01
0xfe141348: f2 05 a0 00 ae 0e 60 03 80 a5 e0 03 22 40 00 05
Stack: [0xf8702000,0xf8781d98), sp=0xf8781460, free space=509k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0x141348]
V [libjvm.so+0x17aefc]
V [libjvm.so+0x2d557c]
V [libjvm.so+0x300ef8]
V [libjvm.so+0x301e84]
V [libjvm.so+0x2ff950]
V [libjvm.so+0x29df30]
V [libjvm.so+0x362b44]
V [libjvm.so+0x6436f0]
VM_Operation (0xe03012b0): parallel gc system gc, mode: safepoint, requested by thread 0x0031bca0
--------------- P R O C E S S ---------------
Java Threads: ( => current thread )
0x00b2c028 JavaThread "Thread-4" [_thread_in_native, id=85]
0x007f5048 JavaThread "Thread-0" [_thread_blocked, id=84]
0x00c27cf0 JavaThread "Notification Delivery" [_thread_blocked, id=81]
0x0026fa08 JavaThread "RMI LeaseChecker" daemon [_thread_blocked, id=73]
0x00821048 JavaThread "RMI RenewClean-[162.11.2.32:44425]" daemon [_thread_blocked, id=70]
0x0031bca0 JavaThread "GC Daemon" daemon [_thread_blocked, id=67]
0x00cd5d28 JavaThread "RMI Reaper" [_thread_blocked, id=66]
0x003c9300 JavaThread "Timer-0" daemon [_thread_blocked, id=65]
0x00929fe0 JavaThread "RMI TCP Accept-0" daemon [_thread_in_native, id=64]
0x0089bf18 JavaThread "SeedGenerator Thread" daemon [_thread_blocked, id=42]
0x00c47248 JavaThread "Pool thread #7" daemon [_thread_blocked, id=38]
0x00c466a0 JavaThread "Pool thread #6" daemon [_thread_blocked, id=37]
0x00311850 JavaThread "Pool thread #5" daemon [_thread_blocked, id=36]
0x00287a40 JavaThread "Pool thread #4" daemon [_thread_blocked, id=35]
0x00286e98 JavaThread "Pool thread #3" daemon [_thread_blocked, id=34]
0x00c134b0 JavaThread "Pool thread #2" daemon [_thread_blocked, id=33]
0x00ad09e0 JavaThread "Pool thread #1" daemon [_thread_blocked, id=32]
0x00286cd8 JavaThread "PoolThreadManager" daemon [_thread_blocked, id=31]
0x00c129e0 JavaThread "Channel Reaper" daemon [_thread_blocked, id=30]
0x00c669e8 JavaThread "ORB Daemon Thread" daemon [_thread_blocked, id=29]
0x00b10170 JavaThread "Worker for ServerProtocol: (iiop) /0.0.0.0:20168" daemon [_thread_blocked, id=22]
0x008a17e0 JavaThread "Syn~ Client" daemon [_thread_blocked, id=21]
0x003dc378 JavaThread "PoolScavenger0" daemon [_thread_blocked, id=20]
0x0015a928 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=15]
0x00159880 JavaThread "CompilerThread1" daemon [_thread_blocked, id=14]
0x00158a18 JavaThread "CompilerThread0" daemon [_thread_blocked, id=13]
0x00157b98 JavaThread "AdapterThread" daemon [_thread_blocked, id=12]
0x00156dc8 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=11]
0x0014ccd8 JavaThread "Finalizer" daemon [_thread_blocked, id=10]
0x0014ad90 JavaThread "Reference Handler" daemon [_thread_blocked, id=9]
0x00038238 JavaThread "main" [_thread_in_native, id=1]
Other Threads:
=>0x001484d8 VMThread [id=8]
0x0015c3b0 WatcherThread [id=16]
VM state:at safepoint (normal execution)
VM Mutex/Monitor currently owned by a thread: ([mutex/lock_event])
[0x00037728/0x00037758] Threads_lock - owner thread: 0x001484d8
[0x00033650/0x00037ba8] Heap_lock - owner thread: 0x0031bca0
Heap
PSYoungGen total 37632K, used 9244K [0xf2eb0000, 0xf7ba0000, 0xf8400000)
eden space 28352K, 0% used [0xf2eb0000,0xf2eb0000,0xf4a60000)
from space 9280K, 99% used [0xf4a60000,0xf5367080,0xf5370000)
to space 25216K, 0% used [0xf6300000,0xf6300000,0xf7ba0000)
PSOldGen total 154496K, used 94371K [0xe8400000, 0xf1ae0000, 0xf2eb0000)
object space 154496K, 61% used [0xe8400000,0xee028e78,0xf1ae0000)
PSPermGen total 35584K, used 18260K [0xe4400000, 0xe66c0000, 0xe8400000)
object space 35584K, 51% used [0xe4400000,0xe55d5158,0xe66c0000)
Dynamic libraries:
0x00010000      /dsdvlp/java/jvm/jdk1.5.0_03/bin/java
0xff350000      /usr/lib/libthread.so.1
0xff340000      /usr/lib/libdl.so.1
0xff200000      /usr/lib/libc.so.1
0xff390000      /usr/platform/SUNW,Sun-Fire-880/lib/libc_psr.so.1
0xfe000000      /dsdvlp/java/jvm/jdk1.5.0_03/jre/lib/sparc/server/libjvm.so
0xff1e0000      /usr/lib/libsocket.so.1
0xff2d0000      /usr/lib/libsched.so.1
0xff1b0000      /usr/lib/libCrun.so.1
0xff160000      /usr/lib/libm.so.1
0xff080000      /usr/lib/libnsl.so.1
0xff060000      /usr/lib/libmp.so.2
0xff030000      /dsdvlp/java/jvm/jdk1.5.0_03/jre/lib/sparc/native_threads/libhpi.so
0xfdfc0000      /dsdvlp/java/jvm/jdk1.5.0_03/jre/lib/sparc/libverify.so
0xfdf80000      /dsdvlp/java/jvm/jdk1.5.0_03/jre/lib/sparc/libjava.so
0xfdf50000      /dsdvlp/java/jvm/jdk1.5.0_03/jre/lib/sparc/libzip.so
0xfb7e0000      /usr/lib/locale/en_GB.ISO8859-1/en_GB.ISO8859-1.so.2
0xe4190000      /dsdvlp/java/jvm/jdk1.5.0_03/jre/lib/sparc/libnet.so
0xe3bd0000      /dsdvlp/lib/5/libSolarisNatives.so
0xe3e90000      /dsdvlp/java/jvm/jdk1.5.0_03/jre/lib/sparc/librmi.so
VM Arguments:
jvm_args: -Djava.ext.dirs=/dsdvlp/java/tmijar/firs7/lib/cli:/dsdvlp/java/tmijar/firs7/lib/cli/ext:/dsdvlp/java/tmijar/firs7/lib/cmn/OpenORB:/dsdvlp/java/tmijar/firs7/lib/cmn/OpenORB/ext:/dsdvlp/java/tmijar/firs7/lib/cmn:/dsdvlp/java/tmijar/firs7/lib/cmn/ext:/dsdvlp/java/tmijar/firs7/daemonlib -Duser.dir=/dsdvlp/java/tmijar/firs7 -Dopenorb.config=file:/dsdvlp/java/tmijar/firs7/configs/OpenORB/config/SynOpenORB.xml -Dopenorb.home=file:/dsdvlp/java/tmijar/firs7/configs/OpenORB -Dcom.coexis.syn.general.orbbinding=com.coexis.syn.general.orbbinding.openorb.OpenORBBinding_1_4 -Dsun.rmi.dgc.client.gcInterval=360000 -Dsun.rmi.dgc.server.gcInterval=360000000 -Xms32m -Xmx256m -Dcom.coexis.syn.clientcommandsconfiglocation=file://localhost//dsdvlp/java/tmijar/firs7/configs/clientcommands.xml -Dcom.coexis.syn.clientconfiglocation=file://localhost//dsdvlp/java/tmijar/firs7/configs/fsbbtd_client.xml -XX:+PrintGCTimeStamps -XX:+PrintGCDetails
java_command: com.coexis.syn.mqmessaging.daemon.RunDaemon -p /dsdvlp/bin/5/lndsfsd_fsbbtd.properties start
Environment Variables:
JAVA_HOME=/dsdvlp/java/jvm/jdk150
CLASSPATH=.:/dsdvlp/java/jar/jconnect520.jar:/dsdvlp/java/jar/vbjapp340.jar:/dsdvlp/java/jar/vbjorb340.jar:/dsdvlp/java/jar/javax_jndi120.jar
PATH=/usr/local/etc:/usr/lang:/usr/openwin/bin:/usr/ucb:/bin:/usr/etc:/usr/local/5/bin:/dsdvlp/bin/5:/dsdvlp/bin/4:/home/app/sybase/5/bin:/home/app/sybase/5/localscripts:/home/app/sybase/5/sqr:/home/app/lang:/home/app/lang/SC2.0.1:/usr/ccs/bin:/usr/local/opt/Acrobat3/bin:/dsdvlp/bin:.
LD_LIBRARY_PATH=/dsdvlp/java/jvm/jdk1.5.0_03/jre/lib/sparc/server:/dsdvlp/java/jvm/jdk1.5.0_03/jre/lib/sparc:/dsdvlp/java/jvm/jdk1.5.0_03/jre/../lib/sparc:/usr/lib:/usr/openwin/lib:/usr/local/5/lib:/dsdvlp/lib/5:/dstest/lib/5:/home/app/sybase/5/lib:/dstest/cats/sun4/lib:/tmitest/Opus/opus/lib
SHELL=/bin/csh
DISPLAY=CLI00184.mfil.local:1.0
OS=5
--------------- S Y S T E M ---------------
OS: Solaris 8 2/02 s28s_u7wos_08a SPARC
Copyright 2002 Sun Microsystems, Inc. All Rights Reserved.
Assembled 18 December 2001
uname:SunOS 5.8 Generic_117350-20 sun4u (T1 libthread)
rlimit: STACK 8192k, CORE 9216k, NOFILE 4096, AS infinity
load average:2.24 2.67 2.68
CPU:total 4 has_v8, has_v9, has_vis1, has_vis2, is_ultra3
Memory: 8k page, physical 8388608k(166384k free)
vm_info: Java HotSpot(TM) Server VM (1.5.0_03-b07) for solaris-sparc, built on Apr 13 2005 03:31:26 by unknown with unknown Workshop:0x550

The very first suggestion I have is to move your VM to a more recent update of 1.5.0.
It looks like you are crashing with 5.0u3, and I'm pretty sure 5.0u16 is available. You
don't want to waste your time chasing a bug that's already been fixed.

LDAP or JNDI Synchronization Across JVMs?

I need to perform an atomic operation (get & set) in
LDAP that is synchronized between multiple
applications (i.e. across JVMs).
Is that possible using iDS 4.x or 5.x?
Does iDS implementation of JNDI/LDAP API provide a
global lock mechanism (I know that this feature is not
supported in the API)?
Here is my actual problem. I need to generate a unique
id of type "long". This id should be unique across
several Java applications. I would like to store this
id in LDAP.
Any help is appreciated.
Thanks, Shahriar

There is no such locking mechanism. Is there a reason the unique id has to be type long? If not, then how about using a UUID? If it needs to be long, perhaps apportioning the number space between applications would work for you.

Printing report that has a parameter with multiple values crashes jvm

I am using BOE XI 4.0 as an unmanaged RAS.
I am able to preview a report that has a string discrete parameter that can have multiple values. If I give it a single value. It previews fine. If I give it an empty string it prints all values which is fine. If I give it two discrete values, it displays just those two.
However, if I try printing the report to a printer:
1 parameter value - prints fine.
2 parameter values - crashes jvm
empty string parameter value - crashes jvm
I would appreciate some direction on how to do this. It works in crystal reports for eclipse.
The test jsp I am using is based off of the samples. The print test jsp is the same as the preview test with the exception of the following code differences.:
preview report.jsp code
// Create a Viewer object
CrystalReportViewer viewer = new CrystalReportViewer();
// Set the report source for the viewer to the ReportClientDocument's report source
viewer.setReportSource(clientDoc.getReportSource());
// Process the http request to view the report
viewer.processHttpRequest(request, response, getServletConfig().getServletContext(), out);
// Dispose of the viewer object
viewer.dispose();
print report jsp code
PrintReportOptions printOptions = new PrintReportOptions();
printOptions.setPrinterName("DELL");
try {
      clientDoc.getPrintOutputController().printReport(printOptions);
} catch (ReportSDKException ex1) {
      System.out.println("Message - " + ex1.getLocalizedMessage());
} catch (Exception ex2) {
      System.out.println("Message - " + ex2.getLocalizedMessage());
clientDoc.close();

I am using BOE XI 4.0 as an unmanaged RAS.
I am able to preview a report that has a string discrete parameter that can have multiple values. If I give it a single value. It previews fine. If I give it an empty string it prints all values which is fine. If I give it two discrete values, it displays just those two.
However, if I try printing the report to a printer:
1 parameter value - prints fine.
2 parameter values - crashes jvm
empty string parameter value - crashes jvm
I would appreciate some direction on how to do this. It works in crystal reports for eclipse.
The test jsp I am using is based off of the samples. The print test jsp is the same as the preview test with the exception of the following code differences.:
preview report.jsp code
// Create a Viewer object
CrystalReportViewer viewer = new CrystalReportViewer();
// Set the report source for the viewer to the ReportClientDocument's report source
viewer.setReportSource(clientDoc.getReportSource());
// Process the http request to view the report
viewer.processHttpRequest(request, response, getServletConfig().getServletContext(), out);
// Dispose of the viewer object
viewer.dispose();
print report jsp code
PrintReportOptions printOptions = new PrintReportOptions();
printOptions.setPrinterName("DELL");
try {
      clientDoc.getPrintOutputController().printReport(printOptions);
} catch (ReportSDKException ex1) {
      System.out.println("Message - " + ex1.getLocalizedMessage());
} catch (Exception ex2) {
      System.out.println("Message - " + ex2.getLocalizedMessage());
clientDoc.close();

What is the diffrence between java run time env and JVM ?

I wrote an applet on computer that installed run time env J2SE 1.4 that is running ok.
when i try to run the applet on diffrent mechine that has earlier version my applet didn't run ok.
Isn't enught just to install JVM ?

The target mechine requirements should be more then
only JVM installed ?
do I have to ask for updated Run Time Env installed
also ?Yes, you have to. If your program has been developed taking advantage of a certain version of the JRE, then all people using your program must have at least that version of the JRE.

MMAPI in JVM

Similar Messages

Maybe you are looking for