As Tom can attest to by now, this is something of an iceberg with big sharp edges below the surface.

The Java heap is fixed at 256MB on CCX. The Java heap is used by Tomcat as execution memory. In addition to this, applications, scripts, and other repository data is loaded into the heap at runtime. Depending on your environment, you may be approaching the limits of the heap, which cannot be changed. If the heap size is reached, it will be dumped and impact calls.

What have you been doing as of late on your CCX server? How many applications and scripts do you have? Are any of these using XML files extensively?

Note there is also a possible bug where the MIVR engine does not properly release all objects loaded into the heap at the end of a script execution leading to a memory leak of sorts. The discussion [debate] over this behavior is continuing. As of this week, it may be represented under CSCte49231. If it is, this may qualify as the most poorly described defect ever.

We went live on the system (testing was pretty extensive) on Friday, 2/19. The contact  center is about 35 queues/skills, about 60 agents logged in a given time. I do have an xml "read" at the beginning of the scripts to receiving about 4 variables (i.e. forced open/closed, voicemail on/off, etc.).

The big difference with these scripts compared with many I have done in the past is that all their DNISs point to a single script. This script does a database dip into an Oracle database with the dnis and the DB returns to me what "call center" to send the call (via subflows). I am concern with the number of subflows since I typically dont do subflow mostly because it is difficult to debug.

Interesting note, I received this message on Friday night (they received 1000 calls on Friday). On Monday (they received 2,200 calls), the message was gone.

TAC stated that they have filed this under a new bug, but I don't know if the ID has been released yet.

So it is not cosmetic? It is something I need to be concern with? Should I reboot the server?

The interesting thing is that I got the message on Friday but yesterday I refreshed the applicationa and I didn't get the message.

setup a perfmon counter and add the following counters. Java Process>Private Bytes and Java Process>Heap Bytes. If your Private Bytes exceed 153 (60%), you will receive this warning. It will go away once the memory is cleared, that is why you only see it during certain times.

The main thing to look for is auto-generated .hprof files in the MIVR log directory. This would indicate an issue.

new defect ID is CSCtf13713

I know this is 2 years old, but I am guessing that you might not have closed all the DB connections properly. I had a customer get this every day during peak volume. I went through the scripts and properly closed all the DB Get and DB Write steps. The occurance went way down. They also have just a lot of scripts.

Also, too many big XML files and too many scripts do this would be bad for heap.