Increased the allowed retries to 10 from 3. This is hard-coded so it is worthwhile making it configurable.

Slightly more than 3 retries seems to be sufficient – once the connection went to 4 retries, but has been otherwise stable and accepting push notifications for 20 minutes.

The push client should include the current ice.push.heartbeat value it is using so that the server does not block for longer than the expected time.

Most probably the cause of this issue is ICE-9689.

Modified listen.icepush request to send ice.push.heartbeat parameter with the value of the current heartbeat interval.

Sending core/src/main/java/org/icepush/BlockingConnectionServer.java
Sending core/src/main/java/org/icepush/http/PushRequest.java
Sending core/src/main/java/org/icepush/http/standard/PushRequestProxy.java
Sending core/src/main/java/org/icepush/servlet/ServletPushRequest.java
Sending core/src/main/java/org/icepush/servlet/ServletPushRequestResponse.java
Transmitting file data .....
Committed revision 38795.

I added the following logic server-side:

• Get maxHeartbeatInterval and minHeartbeatInterval from the configuation
• If incoming listen.icepush request has the ice.push.heartbeat parameter assign it to clientSideHeartbeatInterval.
• If incoming listen.icepush request does not have the ice.push.heartbeat parameter assign Long.MAX_VALUE to clientSideHeartbeatInterval.
• Assign heartbeatInterval's (Slot) long value to serverSideHeartbeatInterval
• ResponseTimeoutTime is calculated as follows:

      System.currentTimeMillis() +
      Math.min(
          Math.max(
              Math.min(clientSideHeartbeatInterval, serverSideHeartbeatInterval),
              minHeartbeatInterval),
          maxHeartbeatInterval)
  

This should result in the server responding within what the timeframe the client expects within reason by keeping the server-side configured maximum and minimum in mind to avoid malicious clients.

Mircea,

We regularly see a response with the ice.push.heartbeat header trying to tell the client what the new value should be and the client not respecting this value. For instance, the server tells the client to use a heartbeat interval of 25000 while the client tells the server it expects a response within its specified heartbeat interval of 15000. This happens without a reload. After running for a certain amount of time we just see the occasional duplicate response messages.

Technique for testing bridgeit.mobi/demo/geotrack.html

Using JavaScript developer console, enter "localStorage"
Select value of bridgeit.jguid, say, acec8377-5768-48ef-af6e-2984376c23a7
Run georand acec8377-5768-48ef-af6e-2984376c23a7

where georand is:

#!/bin/zsh
curl --header "Content-Type:application/json" -d '{ "geometry" : { "type" : "Point", "coordinates" : [ '-114.$

', 1091.083740234375 ] }, "type" : "Feature", "properties" :

}' http://api.bridgeit.mobi/echo/service/echoput/geotrack-$1