Details
-
Type: Bug
-
Status: Closed
-
Priority: Major
-
Resolution: Fixed
-
Affects Version/s: 2.0-Beta
-
Fix Version/s: 2.0-Beta
-
Component/s: Push Library
-
Labels:None
-
Environment:ICEpush Core, icepush-jsp-push
Description
1. Using icepush-jsp-push and icepush-jsp-cluster (my own test application) the blocking connection seems to behave oddly. A listen.icepush request is issued to the server and handled by the application. I'm not interacting with the page at all. After 50 seconds the server decides to send a <noop /> response back to the Bridge. I would expect the Bridge to re-issue a listen.icepush request upon receiving the <noop /> response. This does not seem to happen anymore.
2. Using icepush-jsp-cluster with EPS the blocking connection again seems to behave oddly. A listen.icepush request is issued and handled by the EPS. I'm not interacting with the page at all. Just before 50 seconds the Bridge issues another listen.icepush request before receiving any response to the previous one. EPS decides (using Core code) to response with an X-Connection: close to the previous listen.icepush request and handles the current listen.icepush request. After about 25 seconds the Bridge issues another listen.icepush request again before receiving any response to the previous one. EPS decides (using Core code) to response with an X-Connection: close to the previous listen.icepush request and handles the current listen.icepush request. After 12 seconds or so the blocking connection is dead.
2. Using icepush-jsp-cluster with EPS the blocking connection again seems to behave oddly. A listen.icepush request is issued and handled by the EPS. I'm not interacting with the page at all. Just before 50 seconds the Bridge issues another listen.icepush request before receiving any response to the previous one. EPS decides (using Core code) to response with an X-Connection: close to the previous listen.icepush request and handles the current listen.icepush request. After about 25 seconds the Bridge issues another listen.icepush request again before receiving any response to the previous one. EPS decides (using Core code) to response with an X-Connection: close to the previous listen.icepush request and handles the current listen.icepush request. After 12 seconds or so the blocking connection is dead.
The connection timeout detection introduced by
PUSH-82is configured to assume that the connection is in trouble when the bridge doesn't receives an answer after a period equal to 'heartbeat timeout' + 300ms. It seems that the 300ms difference is too short because even when running the test on a local machine the bridge doesn't receive and process the <noop/> response sent by the server (for each heartbeat) . As a result the timeout mechanism kicks in assuming the connection is in trouble. The connection is re-established by the timeout mechanism but the next timeout used is half the heartbeat interval, but since the <noop/> response was lost the second retry fails as well.The fix applied changes the additional timout to 5 seconds (instead of 300ms). Also modified connection timeout mechanism to use equal intervals between retries.