Why don't use a pool or multiple processes to send_message? about apns4erl HOT 4 CLOSED

Hi @dcy. We never had the need for that, but we'll be happy to evaluate a PR with those changes if you send one our way. If you're about to implement it, I recommend you tu use @jaynel's epocxy.

from apns4erl.

It's not quite so simple as just pooling, since apns_connection is a gen_server and internally it uses a bounded queue implemented as a gen_server. There are two levels of serialization that you need to think through. Most of the work is actually formatting, with a final send on an SSL socket happening at the end of the apns_connection logic. To get any efficiency you would want to rethink that serial pipeline of events. If you took another approach, though, you would still not want multiple processes writing to the same socket directly to avoid interleaving data, unless you can ensure that atomic packets are sent completely.

from apns4erl.

SSL itself has some serialization per connection as well, so there may be no gain on sending concurrently unless you have multiple connections. I say this ambiguously because there have been large changes from 17 -> 19 and it depends on the version of erlang you are running. I would expect if you overload APNS it will just disconnect you, so spewing at it probably isn't a good thing and handling 100s of connections for errors when it isn't performing well might be a mess in the code. I would look at optimizing the formatting concurrency before tackling any sending issues. Once you have a good binary packet, sending should be relatively quick and you should probably detect and limit the pace at which you send data to the external service. Spread across machines and make each machine nice to avoid taking out your partners' services.

from apns4erl.

@jaynel I mean there are multiple processes, every process have one connection.
When apns:send_message use erlang:phash2(DeviceToken, N) to select which process to send this message.
I don't know if this way is good.

from apns4erl.