This document has not been formally reviewed for accuracy and is provided "as is" for your convenience.
Summary
Question
Typical Scenario :
Scrittura become unable to process trades and requires a restart . Prior to restart of the weblogic server, the weblogic and scrittura logs show cache full exceptions similar to below :
SCRITTURA_BVMNGLSCRP01.log:####<Apr 12, 2018 2:06:07 AM CEST> <Info> <EJB> <bvmnglscrp01> <SCRITTURA_BVMNGLSCRP01> <[ACTIVE] ExecuteThread: '93' for queue
: 'weblogic.kernel.Default (self-tuning)'> <admin> <BEA1-5BE3159DF58FFF717B9C> <> <1523491567324> <BEA-010033> <Exception from ejbLoad: weblogic.ejb20.cac
he.CacheFullException: cache size after cleaning=3000, max allowable cache size=3000, extra free space required but not obtainable = 1
Answer
There can be a number of underlying causes for the EJB cache overflow.
The first line of investigation for when this happens should perhaps be to see if any recent custom code modifications were made , as sometimes these can simply be a result of inefficient code. For example there could be a long running loop in some code which loads an EJB into a cache every time the loop executes.
If this is not the case , then it could simply be a result of gradually increasing throughput or other typical growth factors that occur during the life of a production system.
The usual procedure would be to raise a support ticket to allow the specific cause to be investigated as all systems differ. However the following information may be useful to check out before doing this :
According to this link the maximum cache size should at least be as large as the maximum number of objects that can be locked during a single transaction, times the number of threads. (Please refer Oracle doc : https://community.oracle.com/thread/760205)
It is better to test the effect of increasing the Java memory settings for the weblogic process - Xmx, -Xms . Testing with high volumes in a load test environment can help establish the optimal increase to make to these settings
We do not advise making any changes to attributes in the weblogic descriptors, such as the EJB cache size or the idle timeout , without us doing an investigation through a support ticket.