GC Overhead Limit Exceeded & Test mode issue?

rbross

Hello,

URGENT!!!
Does anyone know what causes this error?
I am trying to merge changes from one BSV into another. I add the new attributes to the BSV and when I try to save it I get this error.
When AwareIM first open I can get the BSV into test mode but once any type of change is mode it will no longer go into test mode!
Then AwareIM will no longer close by itself and has to be stopped by the Task Manager.
I tried importing a backup BSV over it but still, have the same issue.

rbross

This is the actual error we are getting.

I tried creating a new version but still, have the same issue.

customaware

This might be totally unrelated but just a thought.....

Have you deleted everything in the Context Histories?

rbross

No, I don't have direct access to the DB. I will have to ask Callum to let me open MSSQL to view that table. Maybe that is the issue? Thanks...

tford

The table Mark referred to is: execution_contexts

customaware

Correct Tom.

My bad. Thanx for correcting

rbross

Turns out it was a permissions issue on the server with the username I was logging in as. Once I used the Admin username and pw I was able to merge changes to the master BSV and enter test mode without any issues.
That was a strange one...

customaware

Glad you resolved it Roger.

aware_support

It's a memory problem - you need to increase memory for the component where this happens. The fact that it worked when you logged in differently doesn't mean that the problem was resolved.

rbross

We did increase the memory for the configurator to 1024mb so maybe that's what resolved it?
Tomcat and AwareIM are both set to 1024mb as well.

joben

We experienced this issue when trying to set a Business Space in Editing Mode.
The CPU usage for the java process skyrocketed and eventually it crashed. It made all business spaces inaccessible for a while for the end users.
We first thought it was a hard drive space issue so we freed up some space.
We then decided to double the vCPU cores and RAM even if we didn't believe in it. It did nothing.

The cause turned out to be a process that ended up in the execution_contexts table way too many times. We must have caused a loop at some point. At first we did not find this table. It resided inside the schema called basdbtest. We just ran a query to display all records and it was 3000+ rows of the same process name.

Thanks tford for mentioning the table name.

We are running MySQL and this is the command that resolved the issue for us:

SET SQL_SAFE_UPDATES = 0;
DELETE FROM execution_contexts WHERE PROCNAME='name_of_your_process';

We also restarted the server for good measure.
Have a nice weekend!