Parameter
vmcj/max_inline_sleeps

Short text
Maximum number of inline sleeps during VMC processing
When a VMC request is executed, a VM can (in rare cases) encounter asituation where it needs to wait for an external event. Examples of thisare waiting for a shared garbage collection or releasing VMs wheninternal sessions are deconstructed. Since no roll-outs are usuallypossible here, the VM is deactivated for a brief period. A drawback ofthis is that the work process in question is occupied for this period.To avoid deadlocks in extreme situations, this deactivation can belimited. There are two different situations:

• a) Deactivation during the roll-out


• b) Any other deactivations

a) The Java session is saved during the VMC roll-out using a callback tothe Java VM. In rare cases, this is not immediately possible (forexample, when a memory bottleneck causes a wait for the end of a sharedgarbage collection). Within the VMC, the VM in question is deactivatedfor a short period (known as a sleep). To prevent the roll-out frombeing delayed too often, a maximum number of delays can be defined here.Once this is reached, the VM moves to the state "PRIVATE" and processingis resumed when the next request is edited.
b) All other delays can also be limited. The request must be canceledonce this number is reached.
The parameter values must be specified using the following syntax:vmcj/max_inline_sleeps = [ROLL_OUT=<(><<)>number1> , ] [NORMAL=<(>
<<)>number2> ]
Examples
vmcj/max_inline_sleeps = NORMAL=60, ROLL_OUT=10
If the value -1 is specified, the number of delays is unlimited.

Work area
VMC

Parameter unit
Counter

Default value
NORMAL=120,ROLL_OUT=10