Since the fixes to PUSH-244 and PUSH-245 I haven't been able to reproduce this anymore. However, when I was originally able to reproduce it, I didn't see the ConcurrentModificationException nor was I using logging at Level.FINE level. Therefore I'm in doubt that the fixes to PUSH-244 and PUSH-245 could have resolved this issue. But as I can't reproduce it anymore I'll mark this one as Cannot Reproduce. If Ted and/or Steve can reproduce it again we can re-open this one.
As Ted noted that he suspects a Cloud Push not having been confirmed correctly upon a subsequent listen.icepush request (either by the lack of that request or something at the server-side going awry) it could get into the case where the server decides not to schedule the ConfirmationTimeout due to the following if-statement:
long now = System.currentTimeMillis();
long timeout = status.getConnectionRecreationTimeout() * 2;
if (notifyBackURI.getTimestamp() + minCloudPushInterval <= now + timeout)
{
return startConfirmationTimeout(sequenceNumber, timeout);
}
else {
if (LOGGER.isLoggable(Level.FINE))
{
LOGGER.log(
Level.FINE,
"Timeout is within the minimum Cloud Push interval for URI '" + notifyBackURI + "'. (" +
"timestamp: '" + notifyBackURI.getTimestamp() + "', " +
"minCloudPushInterval: '" + minCloudPushInterval + "', " +
"now: '" + now + "', " +
"timeout: '" + timeout + "'" +
")");
}
}
If the NotifyBackURI instance doesn't get touched when expected it could happen that, especially with the 5 second Priority Push, the Server decides not to schedule the ConfirmationTimeout as part of its flood prevention logic.
Bug
Major
MODIFY
/icepush/trunk/icepush/core/src/main/java/org/icepush/PushID.java
Since the fixes to
PUSH-244andPUSH-245I haven't been able to reproduce this anymore. However, when I was originally able to reproduce it, I didn't see the ConcurrentModificationException nor was I using logging at Level.FINE level. Therefore I'm in doubt that the fixes toPUSH-244andPUSH-245could have resolved this issue. But as I can't reproduce it anymore I'll mark this one as Cannot Reproduce. If Ted and/or Steve can reproduce it again we can re-open this one.As Ted noted that he suspects a Cloud Push not having been confirmed correctly upon a subsequent listen.icepush request (either by the lack of that request or something at the server-side going awry) it could get into the case where the server decides not to schedule the ConfirmationTimeout due to the following if-statement:
long now = System.currentTimeMillis();
{ return startConfirmationTimeout(sequenceNumber, timeout); }long timeout = status.getConnectionRecreationTimeout() * 2;
if (notifyBackURI.getTimestamp() + minCloudPushInterval <= now + timeout)
else {
{ LOGGER.log( Level.FINE, "Timeout is within the minimum Cloud Push interval for URI '" + notifyBackURI + "'. (" + "timestamp: '" + notifyBackURI.getTimestamp() + "', " + "minCloudPushInterval: '" + minCloudPushInterval + "', " + "now: '" + now + "', " + "timeout: '" + timeout + "'" + ")"); }if (LOGGER.isLoggable(Level.FINE))
}
If the NotifyBackURI instance doesn't get touched when expected it could happen that, especially with the 5 second Priority Push, the Server decides not to schedule the ConfirmationTimeout as part of its flood prevention logic.