Details
-
Type: Bug
-
Status: Closed
-
Priority: Major
-
Resolution: Fixed
-
Affects Version/s: 3.3
-
Fix Version/s: EE-3.3.0.GA
-
Component/s: Push Library
-
Labels:None
-
Environment:ICEmobile, ICEpush cloud push
Description
Jun 21, 2013 10:17:52 PM com.icesoft.icepush.APNSNotificationProvider send
FINE: APNSNotificationProvider.send apns:78a89442633ebff189cee982e64a45ff138
Jun 21, 2013 10:17:53 PM com.icesoft.icepush.APNSNotificationProvider send
FINE: APNSNotificationProvider.send apns:78a89442633ebff189cee982e64a45ff138
Jun 21, 2013 10:17:54 PM com.icesoft.icepush.APNSNotificationProvider send
FINE: APNSNotificationProvider.send apns:78a89442633ebff189cee982e64a45ff138
FINE: APNSNotificationProvider.send apns:78a89442633ebff189cee982e64a45ff138
Jun 21, 2013 10:17:53 PM com.icesoft.icepush.APNSNotificationProvider send
FINE: APNSNotificationProvider.send apns:78a89442633ebff189cee982e64a45ff138
Jun 21, 2013 10:17:54 PM com.icesoft.icepush.APNSNotificationProvider send
FINE: APNSNotificationProvider.send apns:78a89442633ebff189cee982e64a45ff138
When reloading the page a new PushID is created, and the old PushID(s) are still part of the listen.icepush requests. In addition all PushIDs are still part of the same Group. Due to the lack of a BrowserID class representation at the server side at the moment, a ConfirmationTimeout TimerTask was being scheduled for every PushID in the Group, regardless of if multiple PushIDs belong to the same BrowserID. There can be up to a single NotifyBackURI per BrowserID. Each PushID can have up to a single associated NotifyBackURI. When iterating over the PushIDs of a Group it will keep track of if a particular NotifyBackURI already has its ConfirmationTimeout TimerTask scheduled. If not, schedule it, otherwise skip it. Marking this one as FIXED.