Date: 07/23/07

In attendance: Larry, Binod, Joel, Erik, Jan

1. Consistent hashing

The consistent hashing algorithm used by SailFin's converged
loadbalancers supports stickiness by computing a hashkey based on the
request headers of the 1st request. The computed hashkey remains
constant across subsequent requests that belong to the same
session. This hashkey is used to lookup the instance in the cluster
that is supposed to service the request. All active cluster instances
are managed in a hashmap. This hashmap changes dynamically, in
response to GMS notifications of cluster reshape events (i.e., in
response to instances leaving or joining the cluster). Every LB, which
may be a dedicated LB or an instance acting as a LB, maintains this
kind of hashmap. If the instance that is mapped to by a given hashkey
goes down, the same hashkey will be mapped to a different instance
that was selected as the failover target.

This is somewhat different from Sun's current LB approach for HTTP
requests, which uses a "proxy id" to support stickiness, but unlike
the hashkey used in consistent hashing, the "proxy id" does change
after a failover has occurred.

In either approach, the "proxy id" or hashkey, respecitvely, is
communicated to the client, and back to the LB, in the form of a
cookie or rewritten URL.

2. Versioning issues

The data model used in Ericsson's EAS product defines separate trees
for the following SIP entities: SipApplicationSession, SipSession,
SipDialog, and ServletContext. Each of these trees is keyed by a
unique key (in the case of the session related trees, the session id
is used as the key), and each SIP entity that is stored as a value in
the appropriate tree may be replicated separately.

When using in-memory replication, the above, fine-grained data model
requires that each SIP entity be supported by some kind of versioning
information (like the kind we use for HTTP sessions in GlassFish), in
order to be able to identify the most recent (and therefore most
accurate) version of a SIP entity when there are multiple versions
present on different instances.

The following issues must be considered by any approach that relies on
versioning:

2.1 Client cooperation

Any versioning approach requires cooperating clients that supply
versioning information with their requests (HTTP clients cooperate by
automatically including versioning information received in response
cookies or rewritten URLs with their requests). Even if we find that
our SIP clients do cooperate in the above sense, we must ensure that
the container will always have an opportunity to increment the version
before the response is returned to the client, so that a client will
never request a stale version of a SIP entity.

2.2 Cross-protocol updates

In a converged container, it is possible, though probably not
recommended, to traverse the session hierarchy and update session
objects belonging to a different protocol. For example, from a
ConvergedHttpSession, it is possible to navigate to the parent
SipApplicationSession and its SIP protocol session children, and
update them. However, since those SIP sessions would have been updated
from a "foreign" protocol (in this case: HTTP), it would be impossible
to communicate their incremented version information to any SIP
clients as part of the (HTTP) response.

2.3 Missing versioning info

Some of the SIP APIs, e.g.,
SipSessionsUtil.getApplicationSession(String applicationSessionId),
allow requesting a SipApplicationSession based on its id, but at the
time of their invocation, there may not be any versioning information
available.

3. Session expiration and timer activation

A SipApplicationSession may have a number of timers attached to it,
see the following javax.servlet.sip APIs:

TimerService.java:

public ServletTimer createTimer(sipAppSession, ...);

ServletTimer.java:

public SipApplicationSession getApplicationSession();

SipApplicationSession.java:

public Collection getTimers();

ServletTimer objects are associated with an application session. The
application may store data in the application session and retrieve it
later when the timer fires. The getTimers() method of the
SipApplicationSession interface returns a java.util.Collection
containing all ServletTimer objects currently scheduled and associate
with that session.

If (different versions of) the same SipApplicationSession is (are)
active at the same time, the container must ensure that only a single
set of timers fires. Session versioning alone will not address this.

EJB timers are different, because they are not attached to any session
objects. In addition, in GlassFish, EJB timers are not replicated, but
continue to be persisted to a database, even if in-memory replication
has been selected as the persistence type.

We need to check whether we can treat (SIP) ServletTimer objects as
separate from their SipApplicationSession parents as far as their
activation is concerned, and mediate their activation through GMS.