In server mode script doesn't detect when it loses a connection due to timeout from APNS
GoogleCodeExporter opened this issue · comments
What steps will reproduce the problem?
1. Run in Push Server mode
2. Leave running overnight or for several hours
3. APNS will either timeout or disconnect and ApnsPHP doesn't detect it thereby
hanging the connection open.
Once the connection has been severed and ApnsPHP finds that fwrite returns 0
bytes written it only creates a warning and does not close the socket and
reconnect. Other times when fwrite actually does return bytes written but the
actual socket is hung or timed out ApnsPHP doesn't have a way to detect it and
the push is never received by the phone.
What version of the product are you using? On what operating system?
Ubuntu Linux running php 5.3.2
This is consistent and reproducible.
Original issue reported on code.google.com by omnidy...@gmail.com on 2 Dec 2010 at 4:01
Issue 10 has been merged into this issue.
Original comment by aldo.arm...@gmail.com on 25 Dec 2010 at 3:59
hmm... i don't think that's a connection problem (and you've already merged
it), because it happens everytime on certain tokens or devices or so, but maybe
you are true. Are you goning to fix the issue with reconnecting due to lost
connection? If yes, when ? :) and one more thing, as i said, it works as
expected when i do ->send() after every message, but it lasts really a LOT. and
it doesn't send the same message as if i run ->send() only once. so i don't
think it's as you told. The only difference is, that when i ->send() it after
each message, it DOES reconnect on fail, and if i don't, it doesn't. why ?
Original comment by kuk...@gmail.com on 25 Dec 2010 at 4:09
I think Apple is closing connection if it discover something wrong in the
message.
I can't reproduce the problem: please try the attached push.php.
In this version, when a connection problems is detected (0 bytes written) we
disconnect and reconnect to Apple push gateway (the message is not removed from
queue so it will resent on the next run).
Original comment by aldo.arm...@gmail.com on 25 Dec 2010 at 4:19
Attachments:
Thank you, i will try this one then. Will you make this one also available in
the next revision, or it's just a solution for me ? because i really want to
stay up2date, and want to update apns-php when you release an update ;) and one
more thing, will the message be in the error array then ? cause im checking for
those, and if some token has problem like this for more than 3 times, i remove
it from my database. thank you
Original comment by kuk...@gmail.com on 25 Dec 2010 at 4:33
At the moment this is only a temporary solution: I need to reproduce this issue
and then investigate on them.
The message will be in the message array if and only if on the next send there
is an error response from Apple (e.g. Invalid token).
Original comment by aldo.arm...@gmail.com on 25 Dec 2010 at 5:06
- Changed state: Accepted
Original comment by aldo.arm...@gmail.com on 25 Dec 2010 at 5:07
- Added labels: Priority-High
- Removed labels: Priority-Medium
in my opinion, it would be okay to check for the apns connection in order to
send each message, and if it is not available, just reconnect ... or not ? if
you want to, you can send me an example, and i can try it. In my opinion, that
will work, and it's not a bad solution.
Original comment by kuk...@gmail.com on 25 Dec 2010 at 5:26
Fixed at revision 85.
Please, feel free to reopen this issue if this problem persist. Thanks!
Original comment by aldo.arm...@gmail.com on 25 Dec 2010 at 8:03
- Changed state: Fixed
Please, check out revision 88.
In this revision the error message will anyway always be read from the main
stream. The latest successful message sent is the lowest between this error
message and the message that was read from the main stream.
Original comment by aldo.arm...@gmail.com on 25 Dec 2010 at 9:31
Hmm i don't know if it's my fault, but just don't understand what you wanted to
say in the last comment. But problably it's my mistake. can you specify what
changed? thanks
Original comment by kuk...@gmail.com on 25 Dec 2010 at 9:46
In revision 85 when 0 bytes are written to server I assumed that the latest
message was bad.
With revision 88 I always read the error message from the apple server.
If there is an Apple error message and the message id is lower that the message
id that produced a 0 bytes the library suppose that this is the latest
successful message sent.
Otherwise (no message from apple server) the latest message succesful sent was
supposed to be the message before the 0 bytes error message.
It's simple to look code diff between rev85 and rev88 :-)
Original comment by aldo.arm...@gmail.com on 25 Dec 2010 at 10:45
Thank you a lot! Tomorrow i'll know if it's okay, so if it won't i'll write
you. But I looked at the new code, and I think it should work that way. And on
more 'feature' tip. Turning the logging on and off. cause when it'll be all
fine, i dont want to receive emails from my cron jobs if everything is okay..
maybe you can make something like $logType with some constants like LOG_ALL,
LOG_ERRORS, LOG_NO. cause it's useful to receive errors on the mail from a cron
job.
Original comment by kuk...@gmail.com on 26 Dec 2010 at 1:11
Hello aldo,
It works pretty good now, it's fast, and it reconnects, but i think sometimes
it reconnects when it doesn't have to :) i'll send you all the log, just look,
it looks like it's reconnecting periodically after certain number of sent
messages. And one more thing. i don't think that when you do ->send() and have
an empty queue, it should throw an exception... It will be better to not do
anything... so i would just replace the exception with a return; or so, because
then it crashes all the script, and that's not needed. It just doesn't have
anything to send, and now i have to do:
if(count($push->getQueue(false)) > 0) $push->send();
and that's not nice... an if you sometimes change the parameter for the
function getQueue if will be bad :)
I know i can modify it myself, but i want to use your script, and want to
update in the future.
Hope you have some time to release the next revision, heh ;)
Original comment by kuk...@gmail.com on 26 Dec 2010 at 12:23
forgotten to attach the file:
Original comment by kuk...@gmail.com on 26 Dec 2010 at 12:23
Attachments:
one more thing i realized is, that the first 'wrong' device with 0 bytes
written is not the 75th everytime ... sometimes it's the 69th and so ... but
the gaps between them are pretty similar.
Original comment by kuk...@gmail.com on 26 Dec 2010 at 8:03
[deleted comment]
Hi,
I don't know why Apple disconnects the client.
In my test I can send about 800-1600-2100-1700 push notification without been
disconnected, see the attached log.txt
---
When you use the library APIs you should wrap it in a try/catch pattern because
I can throw an exception. So, for example:
........................
try {
$push->send();
} catch (ApnsPHP_Push_Exception $e) {
printf("Oops, an exception thrown: %s\n", $e->getMessage());
}
........................
Original comment by aldo.arm...@gmail.com on 26 Dec 2010 at 11:07
Attachments:
thank you very much :) i'll try this... don't you know why this could happen? i
don't see any reason why apple should disconnect me randomly :( im just sending
the same payloads to multiple devices... i don't think that's wrong somehow ...
I'll probably write to apple after the holidays and ask them what's wrong
because now, i don't know if the message is sent 2 times to those devices
(probably not). and also im reconnecting to apns pretty often and lot of times
when i have to send 4000 notifications ... i reconnect 50 times when sending
4000 notifications. and it lasts only a minute to send them all, so it's 50
times a minute... and i think that this is pretty often and they have a reason
to ban me from sending push now probably... thank you aldo really A LOT. i love
your work. it's really useful.
Original comment by kuk...@gmail.com on 26 Dec 2010 at 11:18