You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
def connectionLost(self, reason):
# TODO notify handlers
# FIXME fix this shutdown
if self.peer is not None:
self.peer.transport.loseConnection()
self.peer = None
This shutdown used to be rare but it is occurring more often now where the iPhone sporadically loses its connection to the proxy server. It seems to happen most during periods of high traffic of APSNotifications. I have been able to find no meaningful info from debugging, and updating biplist (1.0.1), Twisted (15.5) and pyOpenSSL (0.15.1) to latest version had no effect. The 'reason' parameter under connectionLost also reveals no useful info:
Peer connection lost ([Failure instance: Traceback (failure with no frames): <class 'twisted.internet.error.ConnectionDone'>: Connection was closed cleanly. ])
Is it possible to perform more debugging or logging and determine what is triggering the connection closure? Trying to reconnect if you catch it in the InterceptClient factory is not helpful either, it simply starts an endless loop of errors.
One thing to note is that this seems to occur after the server sends a series of APSNotifications to the client, as such:
From https://github.com/meeee/pushproxy/blob/master/src/icl0ud/push/intercept.py#L47
This shutdown used to be rare but it is occurring more often now where the iPhone sporadically loses its connection to the proxy server. It seems to happen most during periods of high traffic of APSNotifications. I have been able to find no meaningful info from debugging, and updating biplist (1.0.1), Twisted (15.5) and pyOpenSSL (0.15.1) to latest version had no effect. The 'reason' parameter under connectionLost also reveals no useful info:
Peer connection lost ([Failure instance: Traceback (failure with no frames): <class 'twisted.internet.error.ConnectionDone'>: Connection was closed cleanly. ])
Is it possible to perform more debugging or logging and determine what is triggering the connection closure? Trying to reconnect if you catch it in the InterceptClient factory is not helpful either, it simply starts an endless loop of errors.
One thing to note is that this seems to occur after the server sends a series of APSNotifications to the client, as such:
2016-01-27 15:04:37-0500 [#3] -> APSNotificationResponse message: 00000001 status: 00
2016-01-27 15:04:37-0500 [#3] -> APSNotificationResponse message: 00000001 status: 00
2016-01-27 15:04:37-0500 [#3] -> APSNotificationResponse message: 00000001 status: 00
2016-01-27 15:04:37-0500 [#3] -> APSNotificationResponse message: 00000001 status: 00
2016-01-27 15:04:37-0500 [#3] -> APSNotificationResponse message: 00000001 status: 00
2016-01-27 15:04:37-0500 [#3] -> APSNotificationResponse message: 00000001 status: 00
2016-01-27 15:04:37-0500 [#3] -> APSNotificationResponse message: 00000001 status: 00
2016-01-27 15:04:37-0500 [#3] -> APSNotificationResponse message: 00000001 status: 00
2016-01-27 15:04:37-0500 [#3] -> APSNotificationResponse message: 00000001 status: 00
2016-01-27 15:04:37-0500 [#3] -> APSNotificationResponse message: 00000001 status: 00
2016-01-27 15:04:37-0500 [#3] -> APSNotificationResponse message: 00000001 status: 00
2016-01-27 15:04:37-0500 [#3] -> APSNotificationResponse message: 00000001 status: 00
2016-01-27 15:04:37-0500 [#3] -> APSNotificationResponse message: 00000001 status: 00
2016-01-27 15:04:37-0500 [#3] -> APSNotificationResponse message: 00000001 status: 00
2016-01-27 15:04:37-0500 [#3] -> APSNotificationResponse message: 00000001 status: 00
2016-01-27 15:04:37-0500 [#3] -> APSNotificationResponse message: 00000001 status: 00
The text was updated successfully, but these errors were encountered: