The BlockingConnectionServer now has a private respondIfBackOffRequested() method which is invoked upon backOff(...) method invocation and whenever an incoming listen.icepush request comes in. Upon backOff(...) invocation it stores the requested delay and tries to send a respond, which if successful removes the requested delay and if unsuccessful leaves the requested delay as is. Upon an incoming listen.icepush it will always invoke the respondIfBackOffRequested() method and if there's a pending requested delay, it tries to send a respond.

Marking this one as FIXED.

<back-off/> is not being sent under all expected conditions: it seems that if the client was recently notified, there is no <back-off/> response sent even though PushContext.backOff() is invoked.

A PushBackOffPhaseListener has been added to ICEmobile which delays ICEpush listen for 300ms after each JSF render. Initial testing shows responsive page updates in mediacast.

Modified BlockingConnectionServer to send 'back-off' XML message instead of X-Connection-Backoff header since this is a command in itself not data sent along with every response, also the client side implementation is much clearer and simpler. Implemented back-off functionality in bridge which pauses and then resumes connection after the specified delay.

Upon invoking the PushContext.backOff(String browserID, long delay) method a <noop /> response is send to the JavaScript bridge containing a new X-Connection-Backoff HTTP extension header containing the delay in milliseconds. The JavaScript bridge should use this value to wait for the specified milliseconds before sending the following listen.icepush request.

Sending icepush-ee/core/src/main/java/org/icepush/BlockingConnectionServer.java
Sending icepush-ee/core/src/main/java/org/icepush/LocalPushGroupManager.java
Sending icepush-ee/core/src/main/java/org/icepush/NoopPushGroupManager.java
Sending icepush-ee/core/src/main/java/org/icepush/PushContext.java
Sending icepush-ee/core/src/main/java/org/icepush/PushGroupManager.java
Transmitting file data .....
Committed revision 33000.

Sending icepush-ee/eps/src/main/java/com/icesoft/push/DynamicPushGroupManager.java
Sending icepush-ee/eps/src/main/java/com/icesoft/push/RemotePushGroupManager.java
Sending icepush-ee/eps/src/main/java/com/icesoft/push/messaging/MessagePayload.java
Sending icepush-ee/eps/src/main/java/com/icesoft/push/messaging/PushMessageService.java
Transmitting file data ....
Committed revision 33254.

Note that this appears to be a specific problem for iOS, android does not appear to be affected.

The attached wireshark capture illustrates the problem:

24 - 27 seconds image is uploaded and response is received (port 55905)
40 seconds noop response received for listen.icepush (port 55898)
40 seconds GET for new image on listen.icepush socket (port 55898)

Ideally, the browser would have used port 55905 for fetching the image, but since it did not, a substantial delay was introduced.

Testing with Safari mobile vs Safari desktop definitely shows fewer connections being used by the mobile browser (typically 2 vs 6). However, this is not strict, as during the initial page load, several connections are used by Safari mobile. Perhaps the mobile browser takes the strategy of using several connections to load the page and then backs off to fewer connections. Safari desktop has no such back-off strategy.