-
Notifications
You must be signed in to change notification settings - Fork 1.5k
apns - handling error from previous batch #774
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
apns - handling error from previous batch #774
Conversation
when response wasn't read for previous batch (due to not enough timeout) and for current batch we read error from previous batch. As a result we can't find failed notification in current batch
removed TODO
Redth
commented
Dec 1, 2016
@denisborovnev Is this working well for you in production?
I do think we should use the existing MillisecondsToWaitBeforeDeclaredSuccess as the value. If you can update your PR I'm happy to merge this.
Thanks :)
ResponseWaitTimeout see Redth#774 (comment)
denisborovnev
commented
Dec 3, 2016
Hi @Redth !
Thanks for review!
I do think we should use the existing MillisecondsToWaitBeforeDeclaredSuccess as the value.
Is this working well for you in production?
We haven't released yet, so can't give answer right now :) But we have already tested and haven't faced problem when server stops send any notification for some period of time.
PashaPash
commented
Dec 13, 2016
Hi @Redth. We have that fix in production, working well, no issues yet. Could you please merge it?
Uh oh!
There was an error while loading. Please reload this page.
Sometimes 750ms is not enough to get response from apns when there is an error in batch
In this case all messages in batch marked as sent and connection is reused for new batches.
During sending next batch error is read, but there is no failed notification in current batch and reader does nothing
As a result notifications from this batch are not marked as sent or failed. Also next batches won't be sent because "error" connection is not closed and ApnsConnection instance continues to use it.
To fix this problem:
PS: there is already setting called MillisecondsToWaitBeforeMessageDeclaredSuccess, not sure if it might be used instead of new one ResponseWaitTimeout