Refactor synchronous interface #33
Conversation
bdotdub
commented
Mar 2, 2015
bdotdub
commented
| ) | ||
|
|
||
| type mockConn struct { |
There was a problem hiding this comment.
is mockConn something that users of this library would find useful when testing?
There was a problem hiding this comment.
I'd say no with the implementation as it stands – it's not a terribly generic solution. I figured since Conn is now an interface, users of the library would write their own
| conn: conn, | ||
| connm: sync.Mutex{}, | ||
| idm: sync.Mutex{}, | ||
| b: newBuffer(50), |
There was a problem hiding this comment.
¯_(ツ)_/¯ haha
Definitely should be able to specify this, but seemed "large enough" for me.
There was a problem hiding this comment.
😄
Maybe at least extract to a const?
There was a problem hiding this comment.
There is also a cleanup thread running that constantly checks the oldest notification in the ‘Sent’ queue to see if it’s older than a few seconds and if so, it is assumed to have been successfully sent and is removed from the ‘Sent’ queue. - The Problem With Apples Push Notification Service
It can take a while for the dropped connection to make its way from APNs back to your server just because of normal latency. It's possible to send over 500 notifications before a write fails because of the connection being dropped. Around 1,700 notifications writes can fail just because the pipe is full, so just retry in that case once the stream is ready for writing again. - Push Notification Throughput and Error Checking
| return s.id | ||
| } | ||
|
|
||
| func (s *session) readErrors() { |
There was a problem hiding this comment.
Some details from Apple on error checking:
https://developer.apple.com/library/ios/technotes/tn2265/_index.html#//apple_ref/doc/uid/DTS40010376-CH1-TNTAG44
If your development tool of choice supports multiple threads or interprocess communication, you could have a thread or process waiting for an error response all the time and let the main sending thread or process know when it should give up and retry.
We launch readErrors on a goroutine, but it looks like it will only read once and then end. I assume read is blocking though, but is this enough?
|
Continuing work on the develop branch. Comments here have been addressed or mentioned in #42 for later. |
| id uint32 | ||
| idm sync.Mutex | ||
|
|
||
| err SessionError |
There was a problem hiding this comment.
Is storing the last error enough?
Previously it sent all errors.
