ACTION_MB_JUST_CHECK / 1

used to trigger checks - shall be always ON

ACTION_REJECT_APPLICATION / 2
when on, no new applications will be created. Application is required for BEx We
b Session, Broadcasting, Xcelsius, Web Application Designer call...
ACTION_REJECT_WEB_SESSION / 3
when on, new web sessions (BEx Web) will not be accepted. All other use cases ar
e still working.
ACTION_REJECT_WEB_REQUEST / 4
when on, every web request can be potentially terminated - existing sessions wil
l be terminated with "NotEnoughMemoryException"
ACTION_REJECT_EXPORT / 5
when on, export will show an error that not enough memory is available. The chec
k is done every 500 rows exported.
ACTION_REJECT_RESULT_SET_REQUEST / 6
check before result set is requested - session will be terminated
ACTION_REJECT_RESULT_SET_CREATION / 7
after result set is provided from ABAP side, Java needs to create corresponding
objects (rows, cells...). Every 500 rows the check wil be executed and can poten
tially terminate the request.
ACTION_REJECT_TEMPLATE_DEPLOYMENT / 8
no new templates can be opened as the deployment step is required for processing
. The deployment step is temporary consuming memory - therefore the check before
.
ACTION_REJECT_TRUE_TYPE_FONT / 9
the font instantiation is required for BI PDF export, it is consuming temporary
memory
(not in use) ACTION_REJECT_BUFFER_APPEND / 10
prototype, not in use
ACTION_REJECT_DOM_PARSER_BEFORE / 11
loading query views requires the dom parser - temporary memory use - check befor
e processing
ACTION_REJECT_DOM_PARSER_AFTER / 12
loading query views requires the dom parser - temporary memory use - check after
processing
ACTION_REJECT_RFC_FUNCTION_CALL_BEFORE / 13
execution of RFC calls via JCo is temporary using memory for the network traffic
- check before
ACTION_REJECT_RFC_FUNCTION_CALL_AFTER / 14
execution of RFC calls via JCo is temporary using memory for the network traffic
- check after
ACTION_REJECT_RFC_FUNCTION_APPEND_ROW / 15
reading result set from JCo is a place which consumes memory as well. Every 500
rows the memory check will be done.
ACTION_RUN_GC_EXPLICIT / 16
this setting is triggering explicit GC run - shall not be used in standard. It i
s introduced to avoid dead-lock situations in Alert Level 3 (memory could be rel
eased, but there are no requests which can trigger the JRE to run GC)
The explicit GC run is expensive - if you want to trigger it, consider also the
setting "RSWR_JAVA_MEMORY_CHECK_POINTS, point 7".
IMPORTANT: there is also a recommendation to switch off explicit GCs on JRE leve
l for the J2EE. In case you follow the recommendations, you have to increase the
alert level to assure the server will start blocking sessions first in the high
er heap useage (abouve 75%) after J2EE GCs triggers are already executed.