Draft for 5.0
changes related to improving performance of activation
Activation patterns of our customers are changing. We see more and more concurrent activations and activations happening at the top of the hierarchies.
Many methods of the receive filter are synchronised. Synchronization forces serialization of access and becomes perofrmance bottleneck.
Activation code currently uses deep locks which means that while activation page close to the root level, majority of the site or whole site becomes locked. That is yet another performance bottleneck.
Heavy concurrent activations will exhaust http worker threads on public further lovering throughput of public instance during activation.
- Since we use JCR/XA lock for synchronizing activation, there should be no need to synchronize the methods at the filter level.
- deep lock should not be necessary. Locking parent and currently processed page should be all that is necessary for ensuring safe activation. Rest of the code need to be adapted to deal with InvalidItemState that might be caused by concurrent modifications.
- use of
mgnlSystemworkspace should be made more concurrency friendly - introduce hierarchy to prevent multiple modifications of root (and hence possibility of occurence of IISE)
- for 5.0: remove exchange from main project so it can be improved/modified/released more often