Upscale

Larry has done some changes in SR and now it is possible to upscale a cluster.
What is left is to check that CLB handles upscale.
AP Joel: check that CLB handles upscale.

Expat

Larry and Jan has more or less completed the implementation of Expat-list handling.
In order for it to handle the case that CLB does not remap synchronously a 30 s delay is introduced before building the Expat list after a cluster reshape.

Last Access Time

We had a discussion about the implementation and finally all agreed on that the current solution is OK.

Foreground Lock

Handling of aquiring/releasing foreground lock is postponed to the FCS release, i.e, it is not part of the Beta.
The reason is that Peter, Joel and Robert had some discussions about the workings of session invalidation which ended up in that invalidation of sessions could leverage on the same principles that would apply for foreground locking. Rather than trying to push this into the Beta we will take a larger grip and implement a solution that handles all aspects: dialog set life time, session invalidation, foreground locking and unit of work and ensure that they work in harmony.

The invalidation problem is something that we have omitted and is primarily caused by the introduction of the SipSessionmanager and DialogFragmentManager. The problem is that when a session is invalidated it is removed from the manager and after that the container cannot retrieve the SS, DF and possible the SAS any more. A typical case where this would occur (and we already have a issue reported on that) is when the application sends a BYE and the invalidates the session in the next line. Later when the 200 response arrives a null pointer exception is thrown dua to that the session can not be found in the manager. We have other scenarios where this occur as well.

The solution is the same as for foreground lock: wait with removal from manager until the last transacion in which the dialog is part of, finishes. (Our solution for foreground lock is taht the lock on the dialog structure is released at that point).

Since the current purpose of foreground locking is only to minimize the risk of failures in ongoing transactions when the CLB remaps after recovery of a node (which is a relatively slim window), we think this can safely be excluded from the Beta.

AP testers: exclude any test case that would test that an ongoing transaction on a backup node (i.e, the node that handles traffic for a failed node) is not disrupted when the failed node recovers.

Repair-under-load

Repair-under-load is always active in Glassfish.
Larrys sends out information on how to disable this.

Misc

Erik has found some flaws that seems to make the replcation framework to do unnecessary replications. Erik sends diffs to Larry.

There are problems when trying to deploy 100+ apps in the cluster. But is this really a requirement? Larry escalates the matter to Binod.

Rolling upgrade: While we investigates the MMAS requierements Larry continues with our proposed implementation (but is prepared to change the implementation when the requirements has been defined).