Closed
Bug 1207743
Opened 10 years ago
Closed 9 years ago
ack's not tracked on reconnect
Categories
(Core :: DOM: Push Subscriptions, defect, P3)
Core
DOM: Push Subscriptions
Tracking
()
RESOLVED
FIXED
mozilla50
| Tracking | Status | |
|---|---|---|
| firefox50 | --- | fixed |
People
(Reporter: benbangert, Assigned: lina)
Details
(Whiteboard: btpp-active)
Attachments
(1 file, 1 obsolete file)
|
12.76 KB,
patch
|
dragana
:
review+
|
Details | Diff | Splinter Review |
If the connection drops and ack's are in the _queue, they will not be retired, nor will knowledge of them be present. This means on reconnect, the notifications will come down, and processed again.
Sending the ack's on reconnect doesn't really help, since the notifications will be sent immediately by the server anwyays.
A more ideal solution might be having the client track the last N ack's, and if it sees a notification that it has already ack'd, then it drops it and sends another ack.
Comment 1•10 years ago
|
||
This is for WebSocket and only for data delivery with WebSocket? The notification when data is turned of have a version number, but semantics needs to be change for that one
http://mxr.mozilla.org/mozilla-central/source/dom/push/PushServiceWebSocket.jsm#1055
| Reporter | ||
Comment 2•10 years ago
|
||
:kit did you want to follow up on this?
Flags: needinfo?(kcambridge)
| Assignee | ||
Comment 3•10 years ago
|
||
I somehow missed this one. Sorry about that! We'll triage this tomorrow, but it sounds reasonable, especially if we're going to defer acks until we've finished processing the message (bug 1246341).
Flags: needinfo?(kcambridge)
Updated•10 years ago
|
Priority: -- → P3
| Assignee | ||
Updated•9 years ago
|
Assignee: nobody → kcambridge
Status: NEW → ASSIGNED
Whiteboard: btpp-active
| Assignee | ||
Comment 4•9 years ago
|
||
I think this should do it. This patch stores the 10 most recent message IDs for a subscription, and drops any dupes.
There's still the case where the user could close the browser after we store the message ID, but before we deliver the message to the service worker or ack it. ISTM that's OK, because the user could still close the browser after we ack the message, but before the worker could finish processing.
Attachment #8760013 -
Flags: review?(dd.mozilla)
Attachment #8760013 -
Flags: feedback?(bbangert)
| Assignee | ||
Comment 5•9 years ago
|
||
Attachment #8760013 -
Attachment is obsolete: true
Attachment #8760013 -
Flags: review?(dd.mozilla)
Attachment #8760013 -
Flags: feedback?(bbangert)
Attachment #8760024 -
Flags: review?(dd.mozilla)
Attachment #8760024 -
Flags: feedback?(bbangert)
| Reporter | ||
Comment 6•9 years ago
|
||
Looks fine to me.
Updated•9 years ago
|
Attachment #8760024 -
Flags: review?(dd.mozilla) → review+
Pushed by kcambridge@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/3943ac2a0fd1
Track recent push messages to avoid duplicate notifications on reconnect. r=dragana
| Assignee | ||
Updated•9 years ago
|
Attachment #8760024 -
Flags: feedback?(bbangert)
Comment 8•9 years ago
|
||
| bugherder | ||
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
status-firefox50:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla50
You need to log in
before you can comment on or make changes to this bug.
Description
•