Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 2.0-Alpha3
-
Fix Version/s: 2.0-Alpha3
-
Component/s: Samples
-
Labels:None
-
Environment:ICEpush svn trunk - Tomcat 6
Description
From the original email...
I have completed my initial implementation of the <icep:push> tag, but have run up against an oddity that I need you to look at.
I have checked everything in, so you should be able to build it. Need to build the following in order:
core
integration/common/notify
integration/jsp/core
integration/jsp/samples/push
URL is http://localhost:8080/icepush-jsp-push
The application works as follows:
1) You identify yourself with a nickname and enter the system at in.jsp
2) You are initially IN, but have a button to get you OUT, which navigates you to out.jsp
3) From out.jsp you have the option to get back in, navigating back to in.jsp.
4) The IN and OUT lists are rendered in <icep:region> tags, and an <icep:push> tag on each page causes a push with each page navigation.
This mostly works except I noticed an issue when you have multiple windows in the same session. If you toggle in/out from the window that is not maintaining the blocking connection, everything works fine. But if you submit from the window that is maintaining the blocking connection, the page load cause control to switch to the other window, but the notification associated with the page load never occurs. You can now toggle back and forth without issue in the non-controlling window, but the one notification has gone missing.
I have completed my initial implementation of the <icep:push> tag, but have run up against an oddity that I need you to look at.
I have checked everything in, so you should be able to build it. Need to build the following in order:
core
integration/common/notify
integration/jsp/core
integration/jsp/samples/push
URL is http://localhost:8080/icepush-jsp-push
The application works as follows:
1) You identify yourself with a nickname and enter the system at in.jsp
2) You are initially IN, but have a button to get you OUT, which navigates you to out.jsp
3) From out.jsp you have the option to get back in, navigating back to in.jsp.
4) The IN and OUT lists are rendered in <icep:region> tags, and an <icep:push> tag on each page causes a push with each page navigation.
This mostly works except I noticed an issue when you have multiple windows in the same session. If you toggle in/out from the window that is not maintaining the blocking connection, everything works fine. But if you submit from the window that is maintaining the blocking connection, the page load cause control to switch to the other window, but the notification associated with the page load never occurs. You can now toggle back and forth without issue in the non-controlling window, but the one notification has gone missing.
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
Make sure that the sent pushIDs are saved each time a new blocking connection is created. The last sent pushIds are continuously compared with the list of currently registered pushIds. When the lists differ the blocking connection is recreated so that the correct list of active pushIds is sent to the server.
Show
Mircea Toma
added a comment - Make sure that the sent pushIDs are saved each time a new blocking connection is created. The last sent pushIds are continuously compared with the list of currently registered pushIds. When the lists differ the blocking connection is recreated so that the correct list of active pushIds is sent to the server.
The solution chosen was to detect when the blocking connection switches between windows and resent the last notifications again (assuming that they were lost during the switch).
Show
Mircea Toma
added a comment - The solution chosen was to detect when the blocking connection switches between windows and resent the last notifications again (assuming that they were lost during the switch).
Global list of notified pushid is regularly purged of unused/discarded pushIds. Without this the callbacks corresponding to the unused pushIds were called repeatedly.