Details
-
Type:
New Feature
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 2.0-Alpha2
-
Fix Version/s: 2.0-Alpha3
-
Component/s: Push Library
-
Labels:None
-
Environment:browser
Description
In the open-source version of ICEpush, only a single, active push application is supported. If there are multiple-push apps running on the same server, only one application can successfully use push. We need to ensure that in this scenario that we gracefully degrade the applications that don't get push access. We should also consider logging information that describes that the degradation has occurred and why. We can also consider providing something on the client side that indicates what is happening. This could present an opportunity to point out that moving to the enterprise version of ICEpush would solve the problem.
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
Each bridge instance (within a window) is now configured with the context path it was loaded from. Also a cookie was introduced to hold the context path of the bridge instance that owns the blocking connection. This way when a page is loaded from a different context the loading bridge can detect that the context path does not match and force the re-creation of the blocking connection to the new context. A INFO message is logged describing the reason why the connection was recreated.
Show
Mircea Toma
added a comment - Each bridge instance (within a window) is now configured with the context path it was loaded from. Also a cookie was introduced to hold the context path of the bridge instance that owns the blocking connection. This way when a page is loaded from a different context the loading bridge can detect that the context path does not match and force the re-creation of the blocking connection to the new context. A INFO message is logged describing the reason why the connection was recreated.
The algorithm should assign the connection to the most recent one as determined by some metric.