Release of JVM 1.3.1_08

We need a bug fix that is slated for the 1.3.1_08 release.
How can i find out when that release is going to take place?
thanks
Alan

We need a bug fix that is slated for the 1.3.1_08
release.
How can i find out when that release is going to take
place?
Pay Sun money. Then they will do what ever you want. Other than that I haven't seen Sun ever annouce a specific date although sometimes the "chat" rooms produce comments from internal Sun people that give a rough idea.

Similar Messages

JVM dies/quits with DrWatson error

Hi,
On a busy box, where a dozen of java applications run, JVM abruptly exited several times throught the day. The machine was scanned after hours for hardware errors; memory, disk, bus adapters - everything is in proper order. DrWatson reported an application crash and made a memory dump.
My question:
How do I proceed debbuging memory dump. Has anyone had any experience ? Also, java.exe has no symbol information and there is no (as far I know ) a debugging release of JVM? So will my research of assembly code lead somewhere ? I need to know the cause of this problem.
Application Details: It's an order routing piece, which does a lot of IO & tcp/ip. It has been in production for long time-no complains. Also, the application interacts with native middle-ware product libraries through JNI ( and that product- tibco bus- is very reliable). Rebooting the server "fixed" everything. I should rather say, we have not seen the problem reoccur.
Box: Windows 2000, fully patched, 4 CPUs, 2Gb RAM, plenty of disk space. All components and software are constantly checked and monitored via snmp, and HP open-view. No errors. Server is rebooted nigtly.
JVM:
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-b24)
Java HotSpot(TM) Client VM (build 1.3.1-b24, mixed mode)
thanks,
eugene
DrWatson error, see where it says FAULT -> that's the instruction that crashed the app.
Application exception occurred:
App: (pid=3060)
When: 8/4/2004 @ 14:09:33.089
Exception number: c0000005 (access violation)
State Dump for Thread Id 0xd78
eax=448bff33 ebx=00000000 ecx=6d4b4bc2 edx=00000000 esi=e761a6c4 edi=00000020
eip=6d46643f esp=08bcfd20 ebp=08bcfd38 iopl=0 nv up ei pl zr na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00000246
function: <nosymbols>
6d466422 7705 ja JVM_FindSignal+0x1c784 (6d46ed29)
6d466424 89480c mov [eax+0xc],ecx ds:450d9e19=????????
6d466427 eb02 jmp JVM_FindSignal+0x17186 (6d46972b)
6d466429 33db xor ebx,ebx
6d46642b 85db test ebx,ebx
6d46642d 0f858c000000 jne JVM_FindSignal+0x13f1a (6d4664bf)
6d466433 8b45fc mov eax,[ebp+0xfc] ss:093e9c1e=????????
6d466436 8b4004 mov eax,[eax+0x4] ds:450d9e19=????????
6d466439 8d4808 lea ecx,[eax+0x8] ds:450d9e19=????????
6d46643c 8b4008 mov eax,[eax+0x8] ds:450d9e19=????????
FAULT ->6d46643f ff9088000000 call dword ptr [eax+0x88] ds:448bffbb=????????
6d466445 85c0 test eax,eax
6d466447 7416 jz JVM_FindSignal+0x179ba (6d469f5f)
6d466449 3b35fc0f4e6d cmp esi,[6d4e0ffc] ds:6d4e0ffc=00004000
6d46644f 7c0e jl JVM_FindSignal+0x1c9ba (6d46ef5f)
6d466451 8b0d440f4e6d mov ecx,[6d4e0f44] ds:6d4e0f44=007c75a0
6d466457 56 push esi
6d466458 8b01 mov eax,[ecx] ds:6d4b4bc2=448bff33
6d46645a ff5038 call dword ptr [eax+0x38] ds:450d9e19=????????
6d46645d eb57 jmp JVM_FindSignal+0x1c211 (6d46e7b6)
6d46645f 833d24094d6d00 cmp dword ptr [6d4d0924],0x0 ds:6d4d0924=00000000
6d466466 7442 jz JVM_FindSignal+0x1ca05 (6d46efaa)
----> Stack Back Trace <----

Hi there
Debug VM can be obtained from Sun if u have a contract with them but before raising the escalation, do try out the latest 1.3.1 VM. You are 12 versions behind. Almost 3 years worth of fixes ;)
A quick search with "JVM_FindSignal" in bug database brings up some bugs.
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5013339
Hope this helps.

JVM using abt 100% CPU. JVM thrad dump

I am having some problem in my Java Application. The idle CPU usage is always high to abt 91 % ..
My java version is
java version "1.4.2_04"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05)
Java HotSpot(TM) Client VM (build 1.4.2_04-b05, mixed mode)
Can someone help to analyze the thread dump taken from JVM.. given below...
=================================================Thread dump ===========
Full thread dump Java HotSpot(TM) Server VM (1.4.0_00-b05 mixed mode):
"ORBacus:Client:ReceiverThread" prio=5 tid=0x673c660 nid=0x5627 runnable [df1ff000..df1ffc50]
 at java.net.SocketInputStream.socketRead0(Native Method)
 at java.net.SocketInputStream.read(SocketInputStream.java:116)
 at com.ooc.OCI.IIOP.Transport_impl.receive(Transport_impl.java:210)
 at com.ooc.OB.GIOPClientWorkerThreaded.receiverRun(GIOPClientWorkerThreaded.java:492)
 at com.ooc.OB.GIOPClientWorkerThreaded$ReceiverThread.run(GIOPClientWorkerThreaded.java:112)
"ORBacus:Client:SenderThread" prio=5 tid=0x5d4ff80 nid=0x5626 waiting on monitor [e0bff000..e0bffc50]
 at java.lang.Object.wait(Native Method)
 - waiting on <e64107b0> (a com.ooc.OB.GIOPClientWorkerThreaded)
 at com.ooc.OB.GIOPClientWorkerThreaded.senderRun(GIOPClientWorkerThreaded.java:447)
 - locked <e64107b0> (a com.ooc.OB.GIOPClientWorkerThreaded)
 at com.ooc.OB.GIOPClientWorkerThreaded$SenderThread.run(GIOPClientWorkerThreaded.java:33)
"ORBacus:Client:ReceiverThread" daemon prio=5 tid=0x674f6a0 nid=0x5624 runnable [df5ff000..df5ffc50]
 at java.net.SocketInputStream.socketRead0(Native Method)
 at java.net.SocketInputStream.read(SocketInputStream.java:116)
 at com.ooc.OCI.IIOP.Transport_impl.receive(Transport_impl.java:210)
 at com.ooc.OB.GIOPClientWorkerThreaded.receiverRun(GIOPClientWorkerThreaded.java:492)
 at com.ooc.OB.GIOPClientWorkerThreaded$ReceiverThread.run(GIOPClientWorkerThreaded.java:112)
"ORBacus:Client:SenderThread" daemon prio=5 tid=0x63401d0 nid=0x5623 waiting on monitor [df2ff000..df2ffc50]
 at java.lang.Object.wait(Native Method)
 - waiting on <e6418410> (a com.ooc.OB.GIOPClientWorkerThreaded)
 at com.ooc.OB.GIOPClientWorkerThreaded.senderRun(GIOPClientWorkerThreaded.java:447)
 - locked <e6418410> (a com.ooc.OB.GIOPClientWorkerThreaded)
 at com.ooc.OB.GIOPClientWorkerThreaded$SenderThread.run(GIOPClientWorkerThreaded.java:33)
"ORBacus:Server:ReceiverThread" prio=5 tid=0x670fa28 nid=0x5621 runnable [dfdff000..dfdffc50]
 at java.net.SocketInputStream.socketRead0(Native Method)
 at java.net.SocketInputStream.read(SocketInputStream.java:116)
 at com.ooc.OCI.IIOP.Transport_impl.receive_detect(Transport_impl.java:259)
 at com.ooc.OB.GIOPServerWorkerThreaded.receiverRun(GIOPServerWorkerThreaded.java:338)
 at com.ooc.OB.GIOPServerWorkerThreaded$ReceiverThread.run(GIOPServerWorkerThreaded.java:106)
"ORBacus:Server:SenderThread" prio=5 tid=0x6643eb0 nid=0x5620 waiting on monitor [e1d7f000..e1d7fc50]
 at java.lang.Object.wait(Native Method)
 - waiting on <ed721158> (a com.ooc.OB.GIOPServerWorkerThreaded)
 at com.ooc.OB.GIOPServerWorkerThreaded.senderRun(GIOPServerWorkerThreaded.java:286)
 - locked <ed721158> (a com.ooc.OB.GIOPServerWorkerThreaded)
 at com.ooc.OB.GIOPServerWorkerThreaded$SenderThread.run(GIOPServerWorkerThreaded.java:33)
"RMI ConnectionExpiration-[10.0.0.23:65435]" daemon prio=5 tid=0x5f112c0 nid=0x5619 waiting on monitor [e06ff000..e06ffc50]
 at java.lang.Thread.sleep(Native Method)
 at sun.rmi.transport.tcp.TCPChannel$Reaper.run(TCPChannel.java:447)
 at java.lang.Thread.run(Thread.java:536)
"Thread-5955" daemon prio=6 tid=0x5f388d8 nid=0x560d runnable [df3ff000..df3ffc50]
 at java.net.SocketInputStream.socketRead0(Native Method)
 at java.net.SocketInputStream.read(SocketInputStream.java:116)
 at java.io.BufferedInputStream.fill(BufferedInputStream.java:183)
 at java.io.BufferedInputStream.read(BufferedInputStream.java:201)
 - locked <ed700d18> (a java.io.BufferedInputStream)
 at java.io.FilterInputStream.read(FilterInputStream.java:66)
 at java.io.PushbackInputStream.read(PushbackInputStream.java:120)
 at org.apache.commons.net.io.FromNetASCIIInputStream.__read(FromNetASCIIInputStream.java:75)
 at org.apache.commons.net.io.FromNetASCIIInputStream.read(FromNetASCIIInputStream.java:170)
 at java.io.BufferedInputStream.fill(BufferedInputStream.java:183)
 at java.io.BufferedInputStream.read(BufferedInputStream.java:201)
 - locked <ed701560> (a org.apache.commons.net.telnet.TelnetInputStream)
 at org.apache.commons.net.telnet.TelnetInputStream.__read(TelnetInputStream.java:114)
 at org.apache.commons.net.telnet.TelnetInputStream.run(TelnetInputStream.java:535)
 at java.lang.Thread.run(Thread.java:536)
"Thread-5954" daemon prio=6 tid=0x367b510 nid=0x560c runnable [e187f000..e187fc50]
 at java.net.SocketInputStream.socketRead0(Native Method)
 at java.net.SocketInputStream.read(SocketInputStream.java:116)
 at java.io.BufferedInputStream.fill(BufferedInputStream.java:183)
 at java.io.BufferedInputStream.read(BufferedInputStream.java:201)
 - locked <ed701e38> (a java.io.BufferedInputStream)
 at java.io.FilterInputStream.read(FilterInputStream.java:66)
 at java.io.PushbackInputStream.read(PushbackInputStream.java:120)
 at org.apache.commons.net.io.FromNetASCIIInputStream.__read(FromNetASCIIInputStream.java:75)
 at org.apache.commons.net.io.FromNetASCIIInputStream.read(FromNetASCIIInputStream.java:170)
 at java.io.BufferedInputStream.fill(BufferedInputStream.java:183)
 at java.io.BufferedInputStream.read(BufferedInputStream.java:201)
 - locked <ed702680> (a org.apache.commons.net.telnet.TelnetInputStream)
 at org.apache.commons.net.telnet.TelnetInputStream.__read(TelnetInputStream.java:114)
 at org.apache.commons.net.telnet.TelnetInputStream.run(TelnetInputStream.java:535)
 at java.lang.Thread.run(Thread.java:536)
"Thread-5952" daemon prio=6 tid=0x633ad20 nid=0x5606 runnable [e05ff000..e05ffc50]
 at java.net.SocketInputStream.socketRead0(Native Method)
 at java.net.SocketInputStream.read(SocketInputStream.java:116)
 at java.io.BufferedInputStream.fill(BufferedInputStream.java:183)
 at java.io.BufferedInputStream.read(BufferedInputStream.java:201)
 - locked <ed703220> (a java.io.BufferedInputStream)
 at java.io.FilterInputStream.read(FilterInputStream.java:66)
 at java.io.PushbackInputStream.read(PushbackInputStream.java:120)
 at org.apache.commons.net.io.FromNetASCIIInputStream.__read(FromNetASCIIInputStream.java:75)
 at org.apache.commons.net.io.FromNetASCIIInputStream.read(FromNetASCIIInputStream.java:170)
 at java.io.BufferedInputStream.fill(BufferedInputStream.java:183)
 at java.io.BufferedInputStream.read(BufferedInputStream.java:201)
 - locked <ed703a68> (a org.apache.commons.net.telnet.TelnetInputStream)
 at org.apache.commons.net.telnet.TelnetInputStream.__read(TelnetInputStream.java:114)
 at org.apache.commons.net.telnet.TelnetInputStream.run(TelnetInputStream.java:535)
 at java.lang.Thread.run(Thread.java:536)
"ORBacus:Client:ReceiverThread" prio=5 tid=0x5b0c2c8 nid=0x5602 runnable [e267f000..e267fc50]
 at java.net.SocketInputStream.socketRead0(Native Method)
 at java.net.SocketInputStream.read(SocketInputStream.java:116)
 at com.ooc.OCI.IIOP.Transport_impl.receive(Transport_impl.java:210)
 at com.ooc.OB.GIOPClientWorkerThreaded.receiverRun(GIOPClientWorkerThreaded.java:492)
 at com.ooc.OB.GIOPClientWorkerThreaded$ReceiverThread.run(GIOPClientWorkerThreaded.java:112)
"ORBacus:Client:SenderThread" prio=5 tid=0x63ba5a8 nid=0x5601 waiting on monitor [e03ff000..e03ffc50]
 at java.lang.Object.wait(Native Method)
 - waiting on <ed703cc0> (a com.ooc.OB.GIOPClientWorkerThreaded)
 at com.ooc.OB.GIOPClientWorkerThreaded.senderRun(GIOPClientWorkerThreaded.java:447)
 - locked <ed703cc0> (a com.ooc.OB.GIOPClientWorkerThreaded)
 at com.ooc.OB.GIOPClientWorkerThreaded$SenderThread.run(GIOPClientWorkerThreaded.java:33)
"ORBacus:Server:ReceiverThread" prio=5 tid=0x5454f88 nid=0x55f3 runnable [e167f000..e167fc50]
 at java.net.SocketInputStream.socketRead0(Native Method)
 at java.net.SocketInputStream.read(SocketInputStream.java:116)
 at com.ooc.OCI.IIOP.Transport_impl.receive_detect(Transport_impl.java:259)
 at com.ooc.OB.GIOPServerWorkerThreaded.receiverRun(GIOPServerWorkerThreaded.java:338)
 at com.ooc.OB.GIOPServerWorkerThreaded$ReceiverThread.run(GIOPServerWorkerThreaded.java:106)
"ORBacus:Server:SenderThread" prio=5 tid=0xefefd0 nid=0x55f2 waiting on monitor [df6ff000..df6ffc50]
 at java.lang.Object.wait(Native Method)
 - waiting on <ed6bfd50> (a com.ooc.OB.GIOPServerWorkerThreaded)
 at com.ooc.OB.GIOPServerWorkerThreaded.senderRun(GIOPServerWorkerThreaded.java:286)
 - locked <ed6bfd50> (a com.ooc.OB.GIOPServerWorkerThreaded)
 at com.ooc.OB.GIOPServerWorkerThreaded$SenderThread.run(GIOPServerWorkerThreaded.java:33)
"ORBacus:Server:ReceiverThread" prio=5 tid=0x67ef270 nid=0x55ae runnable [e157f000..e157fc50]
 at java.net.SocketInputStream.socketRead0(Native Method)
 at java.net.SocketInputStream.read(SocketInputStream.java:116)
 at com.ooc.OCI.IIOP.Transport_impl.receive_detect(Transport_impl.java:259)
 at com.ooc.OB.GIOPServerWorkerThreaded.receiverRun(GIOPServerWorkerThreaded.java:338)
 at com.ooc.OB.GIOPServerWorkerThreaded$ReceiverThread.run(GIOPServerWorkerThreaded.java:106)
"ORBacus:Server:SenderThread" prio=5 tid=0x5b93508 nid=0x55ad waiting on monitor [e09ff000..e09ffc50]
 at java.lang.Object.wait(Native Method)
 - waiting on <ed6b0350> (a com.ooc.OB.GIOPServerWorkerThreaded)
 at com.ooc.OB.GIOPServerWorkerThreaded.senderRun(GIOPServerWorkerThreaded.java:286)
 - locked <ed6b0350> (a com.ooc.OB.GIOPServerWorkerThreaded)
 at com.ooc.OB.GIOPServerWorkerThreaded$SenderThread.run(GIOPServerWorkerThreaded.java:33)
"ORBacus:Client:ReceiverThread" prio=5 tid=0x5a16028 nid=0x558d runnable [dfaff000..dfaffc50]
 at java.net.SocketInputStream.socketRead0(Native Method)
 at java.net.SocketInputStream.read(SocketInputStream.java:116)
 at com.ooc.OCI.IIOP.Transport_impl.receive(Transport_impl.java:210)
 at com.ooc.OB.GIOPClientWorkerThreaded.receiverRun(GIOPClientWorkerThreaded.java:492)
 at com.ooc.OB.GIOPClientWorkerThreaded$ReceiverThread.run(GIOPClientWorkerThreaded.java:112)
"ORBacus:Client:SenderThread" prio=5 tid=0x280f9b0 nid=0x558c waiting on monitor [df8ff000..df8ffc50]
 at java.lang.Object.wait(Native Method)
 - waiting on <ed6ad270> (a com.ooc.OB.GIOPClientWorkerThreaded)
 at com.ooc.OB.GIOPClientWorkerThreaded.senderRun(GIOPClientWorkerThreaded.java:447)
 - locked <ed6ad270> (a com.ooc.OB.GIOPClientWorkerThreaded)
 at com.ooc.OB.GIOPClientWorkerThreaded$SenderThread.run(GIOPClientWorkerThreaded.java:33)
"Thread-3590" daemon prio=5 tid=0x248e790 nid=0x2ce5 runnable [e137f000..e137fc50]
 at java.net.PlainSocketImpl.socketAccept(Native Method)
 at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:343)
 - locked <ed55d900> (a java.net.PlainSocketImpl)
 at java.net.ServerSocket.implAccept(ServerSocket.java:438)
 at java.net.ServerSocket.accept(ServerSocket.java:409)
 at org.apache.log4j.net.SocketHubAppender$ServerMonitor.run(SocketHubAppender.java:336)
 at java.lang.Thread.run(Thread.java:536)
"Thread-2722" prio=5 tid=0x142fd30 nid=0x24dc waiting on monitor [e1c7f000..e1c7fc50]
 at java.lang.Object.wait(Native Method)
 - waiting on <ed517660> (a java.util.TaskQueue)
 at java.util.TimerThread.mainLoop(Timer.java:429)
 - locked <ed517660> (a java.util.TaskQueue)
 at java.util.TimerThread.run(Timer.java:382)
"Thread-2721" prio=5 tid=0x1838ae8 nid=0x24db waiting on monitor [dfbff000..dfbffc50]
 at java.lang.Object.wait(Native Method)
 - waiting on <ed5176c0> (a java.util.TaskQueue)
 at java.util.TimerThread.mainLoop(Timer.java:429)
 - locked <ed5176c0> (a java.util.TaskQueue)
 at java.util.TimerThread.run(Timer.java:382)
"Thread-1869" daemon prio=5 tid=0x11d9f88 nid=0x1971 waiting on monitor [e177f000..e177fc50]
 at java.lang.Thread.sleep(Native Method)
 at org.apache.commons.pool.impl.GenericObjectPool$Evictor.run(GenericObjectPool.java:1080)
 at java.lang.Thread.run(Thread.java:536)
"Thread-806" daemon prio=5 tid=0x756930 nid=0xb3e waiting on monitor [e02ff000..e02ffc50]
 at java.lang.Object.wait(Native Method)
 - waiting on <ebf302e0> (a java.util.TaskQueue)
 at java.util.TimerThread.mainLoop(Timer.java:429)
 - locked <ebf302e0> (a java.util.TaskQueue)
 at java.util.TimerThread.run(Timer.java:382)
"Thread-193" daemon prio=5 tid=0x6b4858 nid=0x288 waiting on monitor [e0aff000..e0affc50]
 at java.lang.Thread.sleep(Native Method)
 at org.apache.commons.pool.impl.GenericObjectPool$Evictor.run(GenericObjectPool.java:1080)
 at java.lang.Thread.run(Thread.java:536)
"Thread-189" daemon prio=5 tid=0xc36fe8 nid=0x27e waiting on monitor [e1a7f000..e1a7fc50]
 at java.lang.Thread.sleep(Native Method)
 at org.apache.commons.pool.impl.GenericObjectPool$Evictor.run(GenericObjectPool.java:1080)
 at java.lang.Thread.run(Thread.java:536)
"GC Daemon" daemon prio=2 tid=0x783d10 nid=0x60 waiting on monitor [e10ff000..e10ffc50]
 at java.lang.Object.wait(Native Method)
 - waiting on <ebe764c8> (a sun.misc.GC$LatencyLock)
 at sun.misc.GC$Daemon.run(GC.java:100)
 - locked <ebe764c8> (a sun.misc.GC$LatencyLock)
"RMI Reaper" prio=5 tid=0x339e98 nid=0x5f waiting on monitor [e0fff000..e0fffc50]
 at java.lang.Object.wait(Native Method)
 - waiting on <ebe75b40> (a java.lang.ref.ReferenceQueue$Lock)
 at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:111)
 - locked <ebe75b40> (a java.lang.ref.ReferenceQueue$Lock)
 at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:127)
 at sun.rmi.transport.ObjectTable$Reaper.run(ObjectTable.java:330)
 at java.lang.Thread.run(Thread.java:536)
"Thread-30" daemon prio=5 tid=0xcdb3f8 nid=0x5e waiting on monitor [e237f000..e237fc50]
 at java.lang.Object.wait(Native Method)
 - waiting on <ebe75de0> (a java.util.TaskQueue)
 at java.lang.Object.wait(Object.java:426)
 at java.util.TimerThread.mainLoop(Timer.java:403)
 - locked <ebe75de0> (a java.util.TaskQueue)
 at java.util.TimerThread.run(Timer.java:382)
"RMI TCP Accept-0" daemon prio=5 tid=0x88d0f8 nid=0x5d runnable [e227f000..e227fc50]
 at java.net.PlainSocketImpl.socketAccept(Native Method)
 at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:343)
 - locked <ebe75b98> (a java.net.PlainSocketImpl)
 at java.net.ServerSocket.implAccept(ServerSocket.java:438)
 at java.net.ServerSocket.accept(ServerSocket.java:409)
 at sun.rmi.transport.tcp.TCPTransport.run(TCPTransport.java:334)
 at java.lang.Thread.run(Thread.java:536)
"AllocationEventDispatcher" prio=5 tid=0xbbd388 nid=0x5c waiting on monitor [e0eff000..e0effc50]
 at java.lang.Object.wait(Native Method)
 - waiting on <ebcdd8e0> (a java.util.LinkedList)
 at java.lang.Object.wait(Object.java:426)
 at com.alopa.prov.client.EventUpdate_impl.run(EventUpdate_impl.java:61)
 - locked <ebcdd8e0> (a java.util.LinkedList)
 at java.lang.Thread.run(Thread.java:536)
"Thread-28" prio=5 tid=0x6e14c8 nid=0x58 waiting on monitor [e11ff000..e11ffc50]
 at java.lang.Object.wait(Native Method)
 - waiting on <ebcdd958> (a java.util.LinkedList)
 at java.lang.Object.wait(Object.java:426)
 at com.alopa.prov.client.AlopaProvisioningClientManager.run(AlopaProvisioningClientManager.java:114)
 - locked <ebcdd958> (a java.util.LinkedList)
 at java.lang.Thread.run(Thread.java:536)
"ProvClientRegistry-sweeper" daemon prio=5 tid=0x6fb338 nid=0x3e waiting on monitor [e197f000..e197fc50]
 at java.lang.Thread.sleep(Native Method)
 at com.alopa.prov.client.ProvisioningClientRegistry.run(ProvisioningClientRegistry.java:199)
"Thread-20" prio=5 tid=0x2c7b8 nid=0x1 waiting on monitor [0..ffbfe4e0]
"GeneratorManager" prio=5 tid=0x12cb6e0 nid=0x36 waiting on monitor [e1e7f000..e1e7fc50]
 at java.lang.Thread.sleep(Native Method)
 at com.alopa.metaserv.health.generator.GeneratorManager.run(GeneratorManager.java:102)
 at java.lang.Thread.run(Thread.java:536)
"PSThread: 1" prio=5 tid=0xe2df20 nid=0x35 waiting on monitor [e1f7f000..e1f7fc50]
 at java.lang.Object.wait(Native Method)
 - waiting on <ebc9fe10> (a com.alopa.util.thread.ThreadPoolEntry)
 at java.lang.Object.wait(Object.java:426)
 at com.alopa.util.thread.ThreadPoolEntry.waitForRelease(ThreadPoolEntry.java:61)
 - locked <ebc9fe10> (a com.alopa.util.thread.ThreadPoolEntry)
 at com.alopa.util.thread.PoolThread.run(PoolThread.java:74)
"PSThread: 2" prio=5 tid=0xe2ddd8 nid=0x34 waiting on monitor [e207f000..e207fc50]
 at java.lang.Object.wait(Native Method)
 - waiting on <ebc9fdf0> (a com.alopa.util.thread.ThreadPoolEntry)
 at java.lang.Object.wait(Object.java:426)
 at com.alopa.util.thread.ThreadPoolEntry.waitForRelease(ThreadPoolEntry.java:61)
 - locked <ebc9fdf0> (a com.alopa.util.thread.ThreadPoolEntry)
 at com.alopa.util.thread.PoolThread.run(PoolThread.java:74)
"PSThread: 3" prio=5 tid=0x1696788 nid=0x33 waiting on monitor [e217f000..e217fc50]
 at java.lang.Object.wait(Native Method)
 - waiting on <ebc9fdd0> (a com.alopa.util.thread.ThreadPoolEntry)
 at java.lang.Object.wait(Object.java:426)
 at com.alopa.util.thread.ThreadPoolEntry.waitForRelease(ThreadPoolEntry.java:61)
 - locked <ebc9fdd0> (a com.alopa.util.thread.ThreadPoolEntry)
 at com.alopa.util.thread.PoolThread.run(PoolThread.java:74)
"PSThread: 4" prio=5 tid=0x1696640 nid=0x32 waiting on monitor [e2a7f000..e2a7fc50]
 at java.lang.Object.wait(Native Method)
 - waiting on <ebc9fdb0> (a com.alopa.util.thread.ThreadPoolEntry)
 at java.lang.Object.wait(Object.java:426)
 at com.alopa.util.thread.ThreadPoolEntry.waitForRelease(ThreadPoolEntry.java:61)
 - locked <ebc9fdb0> (a com.alopa.util.thread.ThreadPoolEntry)
 at com.alopa.util.thread.PoolThread.run(PoolThread.java:74)
"PSThread: 5" prio=5 tid=0x16964f8 nid=0x31 waiting on monitor [e297f000..e297fc50]
 at java.lang.Object.wait(Native Method)
 - waiting on <ebc9fd90> (a com.alopa.util.thread.ThreadPoolEntry)
 at java.lang.Object.wait(Object.java:426)
 at com.alopa.util.thread.ThreadPoolEntry.waitForRelease(ThreadPoolEntry.java:61)
 - locked <ebc9fd90> (a com.alopa.util.thread.ThreadPoolEntry)
 at com.alopa.util.thread.PoolThread.run(PoolThread.java:74)
"PSThread: 6" prio=5 tid=0x9d7038 nid=0x30 waiting on monitor [e337f000..e337fc50]
 at java.lang.Object.wait(Native Method)
 - waiting on <ebc9fd70> (a com.alopa.util.thread.ThreadPoolEntry)
 at java.lang.Object.wait(Object.java:426)
 at com.alopa.util.thread.ThreadPoolEntry.waitForRelease(ThreadPoolEntry.java:61)
 - locked <ebc9fd70> (a com.alopa.util.thread.ThreadPoolEntry)
 at com.alopa.util.thread.PoolThread.run(PoolThread.java:74)
"PSThread: 7" prio=5 tid=0x9d6ef0 nid=0x2f waiting on monitor [e327f000..e327fc50]
 at java.lang.Object.wait(Native Method)
 - waiting on <ebc9fd50> (a com.alopa.util.thread.ThreadPoolEntry)
 at java.lang.Object.wait(Object.java:426)
 at com.alopa.util.thread.ThreadPoolEntry.waitForRelease(ThreadPoolEntry.java:61)
 - locked <ebc9fd50> (a com.alopa.util.thread.ThreadPoolEntry)
 at com.alopa.util.thread.PoolThread.run(PoolThread.java:74)
"PSThread: 8" prio=5 tid=0xe2dc90 nid=0x2e waiting on monitor [e367f000..e367fc50]
 at java.lang.Object.wait(Native Method)
 - waiting on <ebc9fd30> (a com.alopa.util.thread.ThreadPoolEntry)
 at java.lang.Object.wait(Object.java:426)
 at com.alopa.util.thread.ThreadPoolEntry.waitForRelease(ThreadPoolEntry.java:61)
 - locked <ebc9fd30> (a com.alopa.util.thread.ThreadPoolEntry)
 at com.alopa.util.thread.PoolThread.run(PoolThread.java:74)
"ConnectionListener" prio=5 tid=0x1ddcc8 nid=0x2d runnable [e357f000..e357fc50]
 at java.net.PlainSocketImpl.socketAccept(Native Method)
 at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:343)
 - locked <ebc374a8> (a java.net.PlainSocketImpl)
 at java.net.ServerSocket.implAccept(ServerSocket.java:438)
 at java.net.ServerSocket.accept(ServerSocket.java:409)
 at com.alopa.util.misc.JythonServerStart.run(JythonServerStart.java:64)
 at java.lang.Thread.run(Thread.java:536)
"Thread-16" daemon prio=5 tid=0x8ab9d0 nid=0x28 waiting on monitor [e277f000..e277fc50]
 at java.lang.Object.wait(Native Method)
 - waiting on <ebc4ba50> (a java.util.TaskQueue)
 at java.util.TimerThread.mainLoop(Timer.java:429)
 - locked <ebc4ba50> (a java.util.TaskQueue)
 at java.util.TimerThread.run(Timer.java:382)
"Thread-15" daemon prio=5 tid=0x697218 nid=0x27 waiting on monitor [e287f000..e287fc50]
 at java.lang.Thread.sleep(Native Method)
 at org.apache.torque.oid.IDBroker.run(IDBroker.java:503)
 at java.lang.Thread.run(Thread.java:536)
"ORBacus:ThreadPool-0:Dispatcher-6" prio=5 tid=0x1a92e0 nid=0x23 waiting on monitor [e2b7f000..e2b7fc50]
 at java.lang.Object.wait(Native Method)
 - waiting on <ebc4bb50> (a com.ooc.OB.ThreadPool)
 at java.lang.Object.wait(Object.java:426)
 at com.ooc.OB.ThreadPool.get(ThreadPool.java:143)
 - locked <ebc4bb50> (a com.ooc.OB.ThreadPool)
 at com.ooc.OB.ThreadPool.access$0(ThreadPool.java:137)
 at com.ooc.OB.ThreadPool$Dispatcher.run(ThreadPool.java:39)
"ORBacus:ThreadPool-0:Dispatcher-5" prio=5 tid=0x1a9160 nid=0x22 waiting on monitor [e2c7f000..e2c7fc50]
 at java.lang.Object.wait(Native Method)
 - waiting on <ebc4bb50> (a com.ooc.OB.ThreadPool)
 at java.lang.Object.wait(Object.java:426)
 at com.ooc.OB.ThreadPool.get(ThreadPool.java:143)
 - locked <ebc4bb50> (a com.ooc.OB.ThreadPool)
 at com.ooc.OB.ThreadPool.access$0(ThreadPool.java:137)
 at com.ooc.OB.ThreadPool$Dispatcher.run(ThreadPool.java:39)
"ORBacus:ThreadPool-0:Dispatcher-4" prio=5 tid=0xbe63a0 nid=0x21 waiting on monitor [e2d7f000..e2d7fc50]
 at java.lang.Object.wait(Native Method)
 - waiting on <ebc4bb50> (a com.ooc.OB.ThreadPool)
 at java.lang.Object.wait(Object.java:426)
 at com.ooc.OB.ThreadPool.get(ThreadPool.java:143)
 - locked <ebc4bb50> (a com.ooc.OB.ThreadPool)
 at com.ooc.OB.ThreadPool.access$0(ThreadPool.java:137)
 at com.ooc.OB.ThreadPool$Dispatcher.run(ThreadPool.java:39)
"ORBacus:ThreadPool-0:Dispatcher-3" prio=5 tid=0xbe6258 nid=0x20 waiting on monitor [e2e7f000..e2e7fc50]
 at java.lang.Object.wait(Native Method)
 - waiting on <ebc4bb50> (a com.ooc.OB.ThreadPool)
 at java.lang.Object.wait(Object.java:426)
 at com.ooc.OB.ThreadPool.get(ThreadPool.java:143)
 - locked <ebc4bb50> (a com.ooc.OB.ThreadPool)
 at com.ooc.OB.ThreadPool.access$0(ThreadPool.java:137)
 at com.ooc.OB.ThreadPool$Dispatcher.run(ThreadPool.java:39)
"ORBacus:ThreadPool-0:Dispatcher-2" prio=5 tid=0xce31d0 nid=0x1f waiting on monitor [e2f7f000..e2f7fc50]
 at java.lang.Object.wait(Native Method)
 - waiting on <ebc4bb50> (a com.ooc.OB.ThreadPool)
 at java.lang.Object.wait(Object.java:426)
 at com.ooc.OB.ThreadPool.get(ThreadPool.java:143)
 - locked <ebc4bb50> (a com.ooc.OB.ThreadPool)
 at com.ooc.OB.ThreadPool.access$0(ThreadPool.java:137)
 at com.ooc.OB.ThreadPool$Dispatcher.run(ThreadPool.java:39)
"ORBacus:ThreadPool-0:Dispatcher-1" prio=5 tid=0xce3088 nid=0x1e waiting on monitor [e307f000..e307fc50]
 at java.lang.Object.wait(Native Method)
 - waiting on <ebc4bb50> (a com.ooc.OB.ThreadPool)
 at java.lang.Object.wait(Object.java:426)
 at com.ooc.OB.ThreadPool.get(ThreadPool.java:143)
 - locked <ebc4bb50> (a com.ooc.OB.ThreadPool)
 at com.ooc.OB.ThreadPool.access$0(ThreadPool.java:137)
 at com.ooc.OB.ThreadPool$Dispatcher.run(ThreadPool.java:39)
"ORBacus:ThreadPool-0:Dispatcher-0" prio=5 tid=0x90e208 nid=0x1d waiting on monitor [e317f000..e317fc50]
 at java.lang.Object.wait(Native Method)
 - waiting on <ebc4bb50> (a com.ooc.OB.ThreadPool)
 at java.lang.Object.wait(Object.java:426)
 at com.ooc.OB.ThreadPool.get(ThreadPool.java:143)
 - locked <ebc4bb50> (a com.ooc.OB.ThreadPool)
 at com.ooc.OB.ThreadPool.access$0(ThreadPool.java:137)
 at com.ooc.OB.ThreadPool$Dispatcher.run(ThreadPool.java:39)
"ORBacus:Server:StarterThread" prio=5 tid=0x2e7148 nid=0x19 runnable [e347f000..e347fc50]
 at java.net.PlainSocketImpl.socketAccept(Native Method)
 at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:343)
 - locked <ebc4bda8> (a java.net.PlainSocketImpl)
 at java.net.ServerSocket.implAccept(ServerSocket.java:438)
 at java.net.ServerSocket.accept(ServerSocket.java:409)
 at com.ooc.OCI.IIOP.Acceptor_impl.accept(Acceptor_impl.java:128)
 at com.ooc.OB.GIOPServerStarterThreaded.starterRun(GIOPServerStarterThreaded.java:227)
 at com.ooc.OB.GIOPServerStarterThreaded$StarterThread.run(GIOPServerStarterThreaded.java:33)
"ORB Thread" prio=5 tid=0xb761e8 nid=0x15 waiting on monitor [e377f000..e377fc50]
 at java.lang.Object.wait(Native Method)
 - waiting on <ebc3cda0> (a java.lang.Object)
 at java.lang.Object.wait(Object.java:426)
 at com.ooc.OB.ORBControl.run(ORBControl.java:313)
 - locked <ebc3cda0> (a java.lang.Object)
 at com.ooc.OBCORBA.ORB_impl.run(ORB_impl.java:1067)
 at com.alopa.metaserv.shared.startup.CorbaOrb.run(Unknown Source)
 at java.lang.Thread.run(Thread.java:536)
"Thread-11" prio=5 tid=0xce1870 nid=0x14 waiting on monitor [e387f000..e387fc50]
 at java.lang.Object.wait(Native Method)
 - waiting on <ebc3a920> (a java.util.TaskQueue)
 at java.util.TimerThread.mainLoop(Timer.java:429)
 - locked <ebc3a920> (a java.util.TaskQueue)
 at java.util.TimerThread.run(Timer.java:382)
"FileTracker: generators.xml" prio=5 tid=0xc7ac80 nid=0x13 waiting on monitor [e397f000..e397fc50]
 at java.lang.Thread.sleep(Native Method)
 at com.alopa.metaserv.health.util.FileTracker.run(FileTracker.java:53)
"Thread-10" prio=5 tid=0xc99560 nid=0x12 waiting on monitor [e3a7f000..e3a7fc50]
 at java.lang.Object.wait(Native Method)
 - waiting on <ebc379f8> (a java.util.TaskQueue)
 at java.util.TimerThread.mainLoop(Timer.java:429)
 - locked <ebc379f8> (a java.util.TaskQueue)
 at java.util.TimerThread.run(Timer.java:382)
"Thread-9" daemon prio=5 tid=0xcddd78 nid=0x11 runnable [e3b7f000..e3b7fc50]
 at java.net.PlainDatagramSocketImpl.receive(Native Method)
 - waiting to lock <ebc34518> (a java.net.PlainDatagramSocketImpl)
 at java.net.DatagramSocket.receive(DatagramSocket.java:670)
 - locked <ed7041a0> (a java.net.DatagramPacket)
 - locked <ebc34458> (a java.net.DatagramSocket)
 at com.alopa.mgmt.core.snmp.SnmpMonitor.run(SnmpMonitor.java:81)
"Thread-8" daemon prio=5 tid=0x636ee8 nid=0x10 waiting on monitor [e3c7f000..e3c7fc50]
 at java.lang.Object.wait(Native Method)
 - waiting on <ebc32fb8> (a java.util.TaskQueue)
 at java.util.TimerThread.mainLoop(Timer.java:429)
 - locked <ebc32fb8> (a java.util.TaskQueue)
 at java.util.TimerThread.run(Timer.java:382)
"PrimaryDBConnectionPoller-1" daemon prio=5 tid=0xb75270 nid=0xf waiting on monitor [e3d7f000..e3d7fc50]
 at java.lang.Thread.sleep(Native Method)
 at com.alopa.util.dbutils.FailSafeDataSource.run(FailSafeDataSource.java:249)
 at java.lang.Thread.run(Thread.java:536)
"Thread-5" daemon prio=5 tid=0xb73c00 nid=0xe waiting on monitor [e3e7f000..e3e7fc50]
 at java.lang.Thread.sleep(Native Method)
 at com.codestudio.util.LifeGuardThread.run(LifeGuardThread.java)
 at java.lang.Thread.run(Thread.java:536)
"Thread-4" daemon prio=5 tid=0xb73ab8 nid=0xd waiting on monitor [e3f7f000..e3f7fc50]
 at java.lang.Thread.sleep(Native Method)
 at com.codestudio.util.PoolSkimmerThread.run(PoolSkimmerThread.java)
 at java.lang.Thread.run(Thread.java:536)
"Thread-1" daemon prio=5 tid=0x57f938 nid=0xb waiting on monitor [e407f000..e407fc50]
 at java.lang.Thread.sleep(Native Method)
 at org.apache.log4j.helpers.FileWatchdog.run(FileWatchdog.java:95)
"Signal Dispatcher" daemon prio=10 tid=0x10ef20 nid=0x7 waiting on monitor [0..0]
"Finalizer" daemon prio=8 tid=0xf1608 nid=0x4 waiting on monitor [e637f000..e637fc50]
 at java.lang.Object.wait(Native Method)
 - waiting on <ebb8c840> (a java.lang.ref.ReferenceQueue$Lock)
 at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:111)
 - locked <ebb8c840> (a java.lang.ref.ReferenceQueue$Lock)
 at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:127)
 at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)
"Reference Handler" daemon prio=10 tid=0xf0530 nid=0x3 waiting on monitor [fa4ff000..fa4ffc50]
 at java.lang.Object.wait(Native Method)
 - waiting on <ebb8c8a8> (a java.lang.ref.Reference$Lock)
 at java.lang.Object.wait(Object.java:426)
 at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:113)
 - locked <ebb8c8a8> (a java.lang.ref.Reference$Lock)
"VM Thread" prio=5 tid=0xef9b0 nid=0x2 runnable
"VM Periodic Task Thread" prio=10 tid=0x10dc60 nid=0x5 waiting on monitor
"Suspend Checker Thread" prio=10 tid=0x10e5c0 nid=0x6 runnable

Hi,
- What does the mystifying jlaunch.exe do besides executing java.exe ?
This is so that the startupframework can connect more easily and take control of the JVM in some situations
- Why is the Java virtual machine launched by a custom executable like jlaunch (What is it that cannot be program med in Java) ?
I assume when SAP release their JVM (in the next major release), that will be called directly.
- If the problem is not caused by jlaunch.exe, then it must be caused by the JVM. What activity, invisible in thread dumps, is performed by the JVM that can cause the high CPU load ?
Loads of thing, but there should be clues in the thread dumps. (the reason why your code is not in those thread dumps is that your code is only active during the processing of a particular request, unless you have a service, afterwards there are no trace of it as the thread which does the processing goes back to sleep)
I've experienced a similar situation with a an 6.40 portal, and it was then caused by the following:
1. User A comes logs in and sees that some cache timeout has occured , therefore it issues a SQL query which does a full table scan on a table of approx. 1 GB (on of the UME tables)
2. User B comes in just afterwards and also sees that the cache timeout has occured, and issues the same SQL query as User A
3. User C .... and so on untill the query from User A eventually finishes
So
1. Check database. Any big queries running ?
2. Check file activity, are there a lot of writing ?
3. Check network activity, especially to the state controller which is the weakest link
4. What about portal logs ? Any activity during the hang ?
Also, please provide one of the thread dumps for further analysis..
cheers
Dagfinn

JVM for the ARM Core

Can any body tell me about the JVM which supports the ARM core .
How do i get that ?
Is it free or i have to purchase license ? Please help me on this is it very urgent..

Jumping on the JVM bandwagon, I've posted a couple notes to the JES upgrade/install forum, but this is valid here..
Scenario #1
Installed Solaris 9 12/03 and JES Release 1
JVM version reports as 1.4.1_06
Scenario #1a
When i install Webserver 6.1 SP1, (after verifying that SUN supports this with JES) the JVM drops down Post SP1 application to JVM 1.4.1_03
Scenario #2
When I install Solaris 9 04/04 and JES Release 1
JVM version reports as 1.4.2_04-b05
Now Webserver 6.1 SP2 is out.. (notice the install docs say to install via JES not via SP2 installer.. but how do you do this??? I can't find further documentation, and the JES installer either uninstalls or installs the product that's part of JES??))
Anyhow, so.. It appears that the JVM is at the mercy of the Solaris version you install... What IS the optimum JES Release 1 JVM that I should be running..? Who's in command here, JES or Solaris..
For JES, I'm using portal, SRA, and ID svr, and Dir svr etc...
Things that make you go.. "Hmmmm"
Dave

JFrame and Memory Leak

Hello
In my java application i am opening a Frame to display HTML data from database but after many times i have a problem with the memory.
at each time i close the frame with dispose() but it seems that the memory does not released from JVM.
if i add the line System.gc() then seems the problem solved.
Is it correct because i have read that must avoid of calling the Garbage collector programatically?

To get better help sooner, post a [_SSCCE_|http://mindprod.com/jgloss/sscce.html] that clearly demonstrates your problem.
db

JNI and Out of Memory errors

Hi,
At my job, we seem to have a memory leak related to JNI. We know we
have a memory leak because we keep getting Out of Memory errors even
after increasing the maximum heap size to more than 256 megs. And we
know that this is the application that is eating up all the system
memory.
We are running under Windows 2000, with both JDK 1.3.0 and JDK 1.4.1.
We tried looking at the problem under JProbe, but it shows a stable
Java heap (no problems, except that the Windows task manager shows it
growing and growing...)
I tried a strip down version, where I set the max heap size to 1 Meg,
and print out the total memory, memory used, and maximum memory used at
a 5 sec interval.
Memory used = Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory().
Well, I let that strip down version running for about a day. The
maximum memory used has stabilized to about 1.1 Meg, and has not
increased. The current memory used increases until it gets to some
threshold, then it decreases again. However, the Windows task manager
shows the memory increasing -- and currently it is at 245 Megs!
In the lab, the behavior we see with the Windows task manager is as
follows:
1. Total memory used in the system increases until some threshold.
2. Then it goes back down by about 100 Megs.
3. This cycle continues, but at each cycle the memory goes back down
less and less, until the app crashes.
Now, our theory is that JNI is consuming all this memory (maybe we are
using JNI wrong). That's the only explanation we can come up with to
explain what we have seen (Java showing an OK heap, but the task
manager showing it growing, until crashing).
Does that make sense? Can the new operator throw an Out of Memory
error if the system does not have enough memory to give it, even if
there is still free heap space as far as the Runtime object is
concerned? Does the Runtime object figures objects allocated through
JNI methods into the heap used space?
Note that I know the task manager is not a reliable indicator.
However, I don't think a Java app is supposed to runaway with system
memory -- the problem is not simply that the Java app is consuming too
much memory, but that it seems to always want more memory. Besides, we
do get the Out of Memory error.
Thanks for your help,
Nicolas Rivera

Hi,
there are two sources of memory leakage in JNI:
- regular leaks in c/c++ code;
- not released local/global references of java objects in JNI.
I think that the first issue in not a problem for you. The second is more complex. In your JNI code you should check
- how many local references alive you keep in your code as their number is restricted (about 16 and can be enlarged). The good style is not to store local references but keep only global.
- any local reference accepted from java call in JNI are released by JVM. You should release local references you created in JNI and also global references.
- do not use a large number of java object references. Each new reference gets new memory in JVM. Try to reuse refences.
I guess that is your problem.
Vitally

100% CPU load but no clue in thread dump, EP. Win a bottle of champagne...

Hi,
We are suddenly facing 100% CPU load in our EP cluster (5 x 8-way Xeon multiprocessor machines). We have a serious performance problem that is burning a lot of our time and causes a lot of stress for over 3 weeks now.
We have taken tens of thread dumps from Application Nodes.
- In none of the thread dumps we see the Finalizer thread
running.
- From the garbage collector log we see that full garbage
collection runs occur very rarily (once an hour).
- We use the compacting garbage collector.
- In a lot of thread dumps we do not even see our own portal code in the stack traces of the threads!
- In Windows Task Manager we see the jlaunch.exe processes
consume all available CPU time.
- Portal users see a blank portal page when the CPU load hits 100%. When the load goes down again, things return to normal.
- There are no errors logged in any of the log files of the portal. We checked all of them. We expected a log full of errors somewhere but nothing even remotely interesting was found. Windows Event Viewer shows nothing either.
- The amount of sockets in CLOSE_WAIT status is < 10 on every machine in the cluster.
This forces me to conclude that something in the jlaunch.exe executable consumes the CPU time. This raises the following 3 questions:
- What does the mystifying jlaunch.exe do besides executing java.exe ?
- Why is the Java virtual machine launched by a custom executable like jlaunch (What is it that cannot be program med in Java) ? Can it be GZip compression ?
- If the problem is not caused by jlaunch.exe, then it must be caused by the JVM. What activity, invisible in thread dumps, is performed by the JVM that can cause the high CPU load ?
Our development- and support teams are desperate. All suggestions are welcome. The person that comes up with
the solution to our problem gets a nice bottle of champagne.
Regards,
Chris Twigt

Hi,
- What does the mystifying jlaunch.exe do besides executing java.exe ?
This is so that the startupframework can connect more easily and take control of the JVM in some situations
- Why is the Java virtual machine launched by a custom executable like jlaunch (What is it that cannot be program med in Java) ?
I assume when SAP release their JVM (in the next major release), that will be called directly.
- If the problem is not caused by jlaunch.exe, then it must be caused by the JVM. What activity, invisible in thread dumps, is performed by the JVM that can cause the high CPU load ?
Loads of thing, but there should be clues in the thread dumps. (the reason why your code is not in those thread dumps is that your code is only active during the processing of a particular request, unless you have a service, afterwards there are no trace of it as the thread which does the processing goes back to sleep)
I've experienced a similar situation with a an 6.40 portal, and it was then caused by the following:
1. User A comes logs in and sees that some cache timeout has occured , therefore it issues a SQL query which does a full table scan on a table of approx. 1 GB (on of the UME tables)
2. User B comes in just afterwards and also sees that the cache timeout has occured, and issues the same SQL query as User A
3. User C .... and so on untill the query from User A eventually finishes
So
1. Check database. Any big queries running ?
2. Check file activity, are there a lot of writing ?
3. Check network activity, especially to the state controller which is the weakest link
4. What about portal logs ? Any activity during the hang ?
Also, please provide one of the thread dumps for further analysis..
cheers
Dagfinn

IE Pluggin question ... problem or not?

In my employment we utilize a pre-packaged product that we can and sometimes do customize to our needs, as well as add additions to. This package is available in both traditional client/server and thin-client (web-browser) server form. At this time, we use the traditional C/S product, but will be going to the web based version in the future of necessity. The Traditional C/S is modeled around Oracle forms. The web-based product somehow turns these forms into Java Applets (I don't know the mechanics).
Other institutions who also utilize this same product, and who are using the web-based version are saying that the Sun IE plugin is not compatible with the web-based product, and have using IE in 'Native mode' (MS JVM).
Ok, snore ... sorry for all that, but anyway, here's the question ...
I perceive that this will be a BIG problem:
1. Now, for any other web-based apps requiring the Sun JVM plugin,
2. Later, in case the MS JVM is either:
a) Not upgraded
b) Discontinued entirely.
Thus far my web experiences is in PL/SQL packages for dynamic web pages and Java Applets only.
So I would appreciate the opinions of those of you more experienced in this technology if you'd care to offer it. Thanks,
~Bill

So they can't use the Java plugin, and they require the MS JVM? I'm not sure I've seen an applet that wouldn't work in the plugin if it works in the MS JVM, but maybe.
But IE6 is the only current browser version with a built-in JVM, that I'm aware of. Not counting the few people that might still use Netscape 4.x. And it is my understanding that as of the next IE release, that JVM will go away. It's just as well, as the last Netscape and IE JVMs only are equivalent with Java 1.1.4, and both have some bugs which will never be fixed anyway. So I would say it's high time to make things work for the Java plugin or drop applets altogether.

Portable(java.lang.IllegalStateException): SafeNamedCache was exexplicitly

Hi All,
I have seen similar post in this forum, but this error looks bit different than the old post.
This is the log on the TCP Node.
INFO | jvm 1 | 2011/11/17 20:30:05 | 2011-11-17 20:30:05.758/92113.566 Oracle Coherence GE 3.6.1.5 <D5> (thread=Proxy:pof-remote-proxy-service:TcpAcceptorWorker:6, memb
er=78): An exception occurred while processing a GetAllRequest for Service=Proxy:pof-remote-proxy-service:TcpAcceptor: java.lang.IllegalStateException: SafeNamedCache was ex
plicitly released
INFO | jvm 1 | 2011/11/17 20:30:05 | at com.tangosol.coherence.component.util.SafeNamedCache.ensureRunningNamedCache(SafeNamedCache.CDB:23)
INFO | jvm 1 | 2011/11/17 20:30:05 | at com.tangosol.coherence.component.util.SafeNamedCache.getRunningNamedCache(SafeNamedCache.CDB:1)
INFO | jvm 1 | 2011/11/17 20:30:05 | at com.tangosol.coherence.component.util.SafeNamedCache.getAll(SafeNamedCache.CDB:1)
INFO | jvm 1 | 2011/11/17 20:30:05 | at com.tangosol.coherence.component.net.extend.proxy.NamedCacheProxy.getAll(NamedCacheProxy.CDB:1)
INFO | jvm 1 | 2011/11/17 20:30:05 | at com.tangosol.coherence.component.net.extend.messageFactory.NamedCacheFactory$GetAllRequest.onRun(NamedCacheFactory.CDB:6)
INFO | jvm 1 | 2011/11/17 20:30:05 | at com.tangosol.coherence.component.net.extend.message.Request.run(Request.CDB:4)
INFO | jvm 1 | 2011/11/17 20:30:05 | at com.tangosol.coherence.component.net.extend.proxy.NamedCacheProxy.onMessage(NamedCacheProxy.CDB:11)
INFO | jvm 1 | 2011/11/17 20:30:05 | at com.tangosol.coherence.component.net.extend.Channel.execute(Channel.CDB:39)
INFO | jvm 1 | 2011/11/17 20:30:05 | at com.tangosol.coherence.component.net.extend.Channel.receive(Channel.CDB:26)
INFO | jvm 1 | 2011/11/17 20:30:05 | at com.tangosol.coherence.component.util.daemon.queueProcessor.service.Peer$DaemonPool$WrapperTask.run(Peer.CDB:9)
INFO | jvm 1 | 2011/11/17 20:30:05 | at com.tangosol.coherence.component.util.DaemonPool$WrapperTask.run(DaemonPool.CDB:32)
INFO | jvm 1 | 2011/11/17 20:30:05 | at com.tangosol.coherence.component.util.DaemonPool$Daemon.onNotify(DaemonPool.CDB:63)
INFO | jvm 1 | 2011/11/17 20:30:05 | at com.tangosol.coherence.component.util.Daemon.run(Daemon.CDB:42)
INFO | jvm 1 | 2011/11/17 20:30:05 | at java.lang.Thread.run(Thread.java:619)
This is the log on the client ( which is a compute grid)
Caused by: Portable(java.lang.IllegalStateException): SafeNamedCache was explicitly released
 at com.tangosol.io.pof.ThrowablePofSerializer.deserialize(ThrowablePofSerializer.java:57)
 at com.tangosol.io.pof.PofBufferReader.readAsObject(PofBufferReader.java:3306)
 at com.tangosol.io.pof.PofBufferReader.readObject(PofBufferReader.java:2603)
 at com.tangosol.coherence.component.net.extend.message.Response.readExternal(Response.CDB:20)
 at com.tangosol.coherence.component.net.extend.Codec.decode(Codec.CDB:29)
 at com.tangosol.coherence.component.util.daemon.queueProcessor.service.Peer.decodeMessage(Peer.CDB:25)
 at com.tangosol.coherence.component.util.daemon.queueProcessor.service.Peer.onNotify(Peer.CDB:54)
 at com.tangosol.coherence.component.util.Daemon.run(Daemon.CDB:42)
 at java.lang.Thread.run(Thread.java:619)
what Causes this Exception ? Why would the SafeNamedCache be released on the TCP-Proxy Node ?
what could be the reason for TCP-Proxy node releasing the SafeNamedCahce - I checked the status of the underlyig cache service and it is running fine.
Any pointers/help is highly appreciated.
Regards
S

Hi S
Someone have made a call to NamedCache.release(). Have a look at your code to ensure that there is no calls to this method.
Thanks
/Charlie

JUGIM on JXTA

I'm a developer from JUGIM project (http://jugim.dev.java.net). We lack the expertise in our JXTA-based project and thought that we could find some people here.
JUGIM is a peer-to-peer, decentralised Instant Messenger (IM), having the ability to share files, held meeeting (video conferencing), exchange information & services, as well as simple text chat. Its' mission was to serve all JUGs and Virtual JUGs to collaborate and communicating better.
Please write to us if you are interested at [email protected] We welcome any form of feedback, suggestions and comments.
By Avatar Ng
(JUGIM: from the user; for the user)
blog: http://avatar21.superihost.com/

Message was edited by:
ngavarta


Hi everyone,
I would like to discribe my situation before asking
my questions:
Currently i am busy with my Thesis concerning the P2P
filesharing for mobile devices (PDA). To enable the
P2P communication, I used the JXTA technology.
However, I don't use the JXME because i want to
implement pure P2P instead of hybrid P2P.There are two implementations of JXTA for Java ME:
the Proxy and proxyless implementation. You
should use the proxyless implementation at
jxme.jxta.org (check the proxyless CVS directory).
>
Moreover, at this moment, the program runs well in
desktop (where I test it) but I tried to implement it
on the PDA (QTek 9090), it runs but stuck on the JXTA
auto-configurator and after 1 hour or so, it
complains about the stackoverflow error.This is likely a configuration problem that has nothing
to do with the VM.
Hth,
B.
>
To run this, I used Mysaifu 0.1.7 (the new version is
0.3.2 but it doesn't work in the new version).
Here comes my questions:
1. Does anybody know a better JVM (probably it would
be J9)
2. Does anybody have this kind of story or
experience.
3. Does Sun actually release the JVM (CVM) that can
be run on the real devices.
I would really appreciate for your responses and your
help.
Thank you.

How to release the prompt and how to stop JVM afterwords

There are 2 related questions here:
(1st) I have a Java class that I'd like to start and release the command prompt. In Linux, I usually start it this way:
> java MyClass &
But in Windows I can't do that, it always holds the command prompt open. If I try this way:
> javaw MyClass
it works, but if I call it from inside a batch file, it opens a command prompt (then I can close the command prompt and it remains in memory). But I'd like it not to open any command prompt. Does anyone know a way?
(2nd) I'd like to start the class above like we do for some services... I thought of doing somethind like this:
> java MyClass -start
This, after solving the (1st) question, looks easy. The problem is: how to implement this class in order to be able to call
> java MyClass -stop
to stop it, finishing its JVM? How will this class be able to detect an instance of itself in memory and stop it??? Is there something simpler than using sockets for that purpose?
Thanks for your help, friends!

Well, the first is easy - instead of starting with java.exe, use javaw.exe. No more icky command prompt. ;-)
The second one is trickier. If you really want to go that route, I'd suggest looking at the Tomcat bootstrap code - it listens on a specific port for program handling commands.

Jvm unnamed windows events handle leak 1.3.1_08-b03 - 1.4.2-b28

Hello,
I have an server application that leaks windows unnamed event handles on small loads. (200 network connections) I've used the process explorer from www.sysinternals.com to find the type of handles that where leaking. I've run my application through jprobe several times and i'm not leaking any java objects. it doesn't happen on every run. It can run about 5 to 10 times with no leak but as i continue running a request that has 200 network connnections it will leak one handle. Over time they add up memory increases and eventually we get a out of memory error and the server has to be restarted
My application uses the following
java version "1.3.1_08"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_08-b03)
Java HotSpot(TM) Client VM (build 1.3.1_08-b03, mixed mode)
windows server 2000 service pack 3 (I've tried sp1 and sp2 same issue)
starting and stopping threads
inet jdbc driver una2000
zlib compression libraries
encryption DES
sockets
no jni code
My network code uses input.available() and Socket.setSoTimeout() I don't think the setSoTimeOut time is timing anything out on these small runs.
I've also have run it with
java version "1.4.2"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28)
Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode)
I've tried not stopping any threads from my thread pool and it made no change. It still leaks! :-(
Does anyone know what creates the unamed event handles? Are they created by synchronization? Since my applications uses so many different api's it's like looking for a needle in a hay stack.
p.s. I've been working on this problem on and off for about 1 month. I've search the java forums and google.
Thanks
Alexander Anguiano

My message has been here for a while and is off the first page. :-( Oh, well. I thought I would update this just incase anyone was following it. (can I award my self those duke dollars?)
I think i've found the problem of why we are leaking handles. In the first 10 minutes it leaked 3 handles.(they may not have leaked but are resource that our application needed because of all the lazy initialization that we do) I've been runing a 200 task request every 5 minutes for the last 6 hours and have not leak any handles. The problem appears to be with calls to socket.setSoTimeout. I set it to 0. This effectively tells the socket to never time out. This is not an acceptable solution to the problem. I will be working on that next.
Has any one had problems with the socket.setSoTimeout?
If not then it may have to do with our simulated select. We have one thread that handles connection. Once the connection is established it's put on a list that get's polled [input.available()] that is handled by thread 2 if there is data then it gets handled by a worker thread [thread n-12]. Once the worker thread has read up to 4K of data it is put back on thread 2. I'm thinking that it has to do with so many thread doing a little work on it.

What needs to be released to avoid memory leaks in the jvm?

I've got a C application server that makes Java calls to process requests.
Eventually, the JVM runs out of memory, I assume because my C code is leaking references.
My question is... what references should I be freeing? I am freeing local/global object references, but it still leaks memory.
Should I also be freeing classIds? Method ids? Is DeleteLocalRef() the way to do that?
Thanks,
Jeff

The simple answer is that you are responsible for deallocating every single reference (basically anything that isn't either a fieldID or a methodID) that is returned from a JNI call. The return value from each JNI call is a newly allocated local reference that you must delete with a call to DeleteLocalRef. For example, you must delete the jclass returned by FindClass() or the jthrowable returned by ExceptionOccurred(). In addition to that, you must also ensure that you delete any global references that you explicitly allocate yourself.
Notice that the rules change, when you are executing from within the context of a native method invoked from the JVM. In that case, the JVM will automatically clean up any local references that are left over once the native method returns. Even then, though, it's smart to be careful with local references, because you can easily exceed the maximum number of local refs, or hold on to excessive amounts of objects, or hold onto objects for excessive amounts of time, because none of the local refs are deallocated by the VM until the native method actually returns.
Local reference management is a real pain in the butt in JNI. For example, it took me quite some time to get it right in Jace.
God bless,
-Toby Reyelts
Check out the free, open-source, JNI toolkit, Jace - http://jace.reyelts.com/jace

Java JVM 8: Using incremental CMS is deprecated and will likely be removed in a future release

Hello,
We (my company) have been using YoungGC=Parallel; Old=CMS/Incremental since Java 1.5 for a Java caching application running in a 64 GB heap (yes, even in HotSpot 1.5).
At various times, we have tested the G1 collector. The performance for our caching application has not met expectations with G1GC. Always looking for ways to improve the system, we are certainly open to new technologies. However, the loss of the CMS collector will mean our application won’t be able to adopt newer versions of Java.
Basic JVM options for GC:
-XX:+UnlockExperimentalVMOptions
-XX:+UseParNewGC
-XX:+UseConcMarkSweepGC
-XX:+CMSIncrementalMode
-XX:-CMSIncrementalPacing
-XX:CMSIncrementalDutyCycleMin=100
-XX:CMSIncrementalDutyCycleMin=95
-XX:+ExplicitGCInvokesConcurrent
-XX:ConcGCThreads=6
With these options, on servers with 64GB heap used at 60% and thousands of QPS, we see Young GC pauses in the range of 50-100 ms every roughly 10 seconds (for .5-1% of the time) and about the same for the short GC pauses of the background CMS. We NEVER see a long CMS pause and the servers run for months at a time, being taken down pretty much only to patch the OS. With a new generation of the hardware, improved software and taking advantage of the ConcGCThreads option, we are just beginning a series of tests to determine how high we can crank-up the memory to reduce the farm size.This project is expected to go OpenSource later this year. Without the CMS collector, very large heaps will become very difficult (or impossible) to manage.
Before removing the CMS collector, and I understand it is causing grief to still have it in the Java code base, please ensure there is an adequate replacement (G1 is currently not it).
Thank you for your attention,
Pierre

I recomend you probe and test the MetaSpace GC policy in 1.8
Probably you improve the application in 30% of performance terms.

JVM Versions - Release Dates

Hi,
This is not entirely on topic, but its about the most appropriate forum I could find!
I am looking for information on the exact release dates (to the day) for previous versions of Java, up to and including 1.5.0_u14. Can anyone point me to an authorative (preferable a Sun official page) source of this information? I have tried searching the Sun site but can't find this information.
Regards,
Adrian

Google - wow what a great tool - thanks for the tip.
I am looking for dates for releases including minor versions, up to 1.5.0_u14 as I said in my post. I have searched of the Sun site using both the internal Sun search tool and also Google, but can't find readily this info. Hence my post to the forum.
If anyone has any idea where I might find this information, that would be great.
Edited by: AdrianFitz on Nov 27, 2007 1:24 AM

Release of JVM 1.3.1_08

Similar Messages

Maybe you are looking for