The following metrics should be gathered with millisecond timestamps and browserID:

• listen connect
• listen response
• push initiated to client
• cloud push sent
• park
• unpark

The metrics logging should be clearly marked so that it can be filtered after the session for analysis.

An interesting feature would allow for the capture of these metrics in the session so that they could be displayed dynamically to the user. Since ICEpush does not normally require a session, the session capture could be optional, such as via a ThreadLocal "TraceContext" (if the TraceContext is not null, current metrics would be stored there).

An effective adaptive strategy for the reconnection timeout would be to average the recent reconnection time with the previous timeout. Any reconnect that failed to occur in double this time would cause a switchover to cloud push. This would avoid keeping a large history of timing values for each client. (Note that the reconnection timeout is maintained per client, however).

A simple implementation for the most important metric for the recent Cloud Push behaviour has been checked in.
This is accessible by enabling FINE level logging on org.icepush.servlet.ThreadBlockingAdaptingServlet.

For instance for an iPhone on a 3G connection:

Feb 29, 2012 5:45:15 PM org.icepush.servlet.ThreadBlockingAdaptingServlet service
FINE: ICEpush metric: Reconnect latency for 3gz8lpclt : 5552

The scheme for additional metric logging should be to include "ICEpush metric" in the log entry. This particular metric is calculated and uses stored data, contrary to the description above. If a particular metric is sufficiently important, it need not be implemented simply as a timestamp.

The most critical metric has been implemented and I will proceed with some analysis with different browsers and different network conditions. The other metrics may be useful, but should be considered lower priority.