pyapns icon indicating copy to clipboard operation
pyapns copied to clipboard

Multiple notifications while disconnected

Open ggarber opened this issue 12 years ago • 5 comments

When APNS connection is not established you defer sending the notification with this line:

d.addCallback(lambda p: p.sendMessage(notifications))

When sending multiple notifications those callbacks are chained and second one fails because first one doesn't return p. I think it should be:

def connected(protocol): protocol.sendMessage(notifications) return protocol

d.addCallback(connected)

ggarber avatar Apr 10 '12 12:04 ggarber

Hey I just fixed this in a branch I will push soon. :)

samuraisam avatar Jan 25 '13 23:01 samuraisam

I'm running into a similar issue. I did verify that the #28 fix is in the v50 branch I'm working with. In the case I'm hitting it, our server is in very rapid succession we are calling pypans twice. Once with a token that will be rejected on production and once with a token it will like. These calls are separate and not part of a notify call with multiple items. My thought had been that perhaps we would use the batch later, but for now we would be safer and just call for each token and treat the feedback and disconnect as almost the same thing. In any case, here's the resulting log:

2013-03-07 15:28:41+0000 [HTTPChannel,89,xx.xxx.xxx.xx] APNSProtocol sendMessage msg=0100000001513a02fd0020ea23d7fd8fc4436fbf90333195863691d76a25dd387d7606c80775b77064955100557b22617073223a7b226261646765223a312c22616c657274223a2250726f64756374696f6e507573682c207465737420726570617273652e227d2c22656370223a7b2263616d706169676e223a2254657374227d7d
2013-03-07 15:28:41+0000 [HTTPChannel,89,xx.xxx.xxx.xx] xx.xxx.xxx.xx - - [07/Mar/2013:15:28:40 +0000] "POST /apps/PSF/production/notifications HTTP/1.1" 201 29 "-" "AppEngine-Google; (+xxx)"
2013-03-07 15:28:41+0000 [HTTPChannel,90,xx.xxx.xxx.xx] APNSProtocol sendMessage msg=0100000003513a02fd0020db8c1baed0abd795f8fa7dab4d95ad35e511550944319450a5a02c6069f4572400557b22617073223a7b226261646765223a312c22616c657274223a2250726f64756374696f6e507573682c207465737420726570617273652e227d2c22656370223a7b2263616d706169676e223a2254657374227d7d
2013-03-07 15:28:41+0000 [HTTPChannel,90,xx.xxx.xxx.xx] xx.xxx.xxx.xx - - [07/Mar/2013:15:28:40 +0000] "POST /apps/PSF/production/notifications HTTP/1.1" 201 29 "-" "AppEngine-Google; (+xxx)"
2013-03-07 15:28:41+0000 [APNSProtocol (TLSMemoryBIOProtocol),client] data received after sendMessage data=
2013-03-07 15:28:41+0000 [APNSProtocol (TLSMemoryBIOProtocol),client] APNSProtocol connectionLost
2013-03-07 15:28:41+0000 [APNSProtocol (TLSMemoryBIOProtocol),client] APNSClientFactory clientConnectionLost reason=[Failure instance: Traceback (failure with no frames): <class 'twisted.internet.error.ConnectionLost'>: Connection to the other side was lost in a non-clean fashion.
    ]
2013-03-07 15:28:41+0000 [APNSProtocol (TLSMemoryBIOProtocol),client] <twisted.internet.tcp.Connector instance at 0x3324f38> will retry in 2 seconds
2013-03-07 15:28:41+0000 [APNSProtocol (TLSMemoryBIOProtocol),client] Stopping factory <pyapns.server.APNSClientFactory instance at 0x3324dd0>
2013-03-07 15:28:43+0000 [-] Starting factory <pyapns.server.APNSClientFactory instance at 0x3324dd0>
2013-03-07 15:28:43+0000 [-] APNSClientFactory startedConnecting
2013-03-07 15:28:43+0000 [Uninitialized] APNSProtocol connectionMade

I was expecting that notifications sent as separate requests would not be affected by a prior disconnect, but only none of the notifies make it out. In any case, I'll be spending some time looking into this today. I could very easily be mistaken about what the expected behavior is. It would also be helpful to get a little doc up that explains the expected use of the disconnects log (in v50).

troppoli avatar Mar 07 '13 17:03 troppoli

I don't have much familiarity with twisted and hence the guts of transport or any of it, but seems like there is a window of opportunity where close calls like this will end up being lost when the connection is closed down with an invalid token.

It's also unclear to me when I read the apple docs if it is expected behavior to drop all of the received data (send no notifications) when closing the connection due to an invalid token. Do you have any insight?

troppoli avatar Mar 07 '13 21:03 troppoli

I did find a reply in the dev forums to the final question, they accept all items before to the bad item.

troppoli avatar Mar 07 '13 22:03 troppoli

I'm running into this same issue. I think the situation is this: if pyapns sends two messages to Apple's servers in one connection, and the first of the two is "bad" and will be rejected by Apple, then the second one fails to send and we get the connection dropped, with a message indicating that "data received after sendMessage data=xxxx". Is there a solution to this issue?

eswenson1 avatar Mar 18 '15 22:03 eswenson1