should we do a apnsClient.connect and disconnect for every notification

169 views
Skip to first unread message

Shreerang Pande

unread,
Apr 7, 2017, 9:45:36 AM4/7/17
to pushy
There was no concept of explicitly establishing a connection in HTTP/1. or HTTP/1.1. Every-time we made a new get/post request, a new connection used to be made. In the pushy-apns client, I saw that we explicitly need to make a connection with apns server before we can send a notification. In such a case, should we make a new connection for every notification request or should we make the connection once and destroy it only on server shutdown?

Jon Chambers

unread,
Apr 7, 2017, 10:30:36 AM4/7/17
to Shreerang Pande, pushy
To quote the documentation (http://relayrides.github.io/pushy/apidocs/0.9/com/relayrides/pushy/apns/ApnsClient.html):

> APNs clients are intended to be long-lived, persistent resources. Callers should shut them down when they are no longer needed (i.e. when shutting down the entire application).

So, yes. You should only disconnect your client when your server is shutting down.

-Jon

On Fri, Apr 7, 2017 at 9:45 AM, Shreerang Pande <shreera...@gmail.com> wrote:
There was no concept of explicitly establishing a connection in HTTP/1. or HTTP/1.1. Every-time we made a new get/post request, a new connection used to be made. In the pushy-apns client, I saw that we explicitly need to make a connection with apns server before we can send a notification. In such a case, should we make a new connection for every notification request or should we make the connection once and destroy it only on server shutdown?

--
Pushy is an open-source Java library for sending APNs (iOS and OS X) push notifications. Pushy is brought to you by the engineers at RelayRides.
---
You received this message because you are subscribed to the Google Groups "pushy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pushy-apns+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Shreerang Pande

unread,
Apr 7, 2017, 10:33:17 AM4/7/17
to pushy, shreera...@gmail.com
Thanks Jon for the clarification.
To unsubscribe from this group and stop receiving emails from it, send an email to pushy-apns+...@googlegroups.com.

Matthias Wessendorf

unread,
Apr 7, 2017, 10:34:04 AM4/7/17
to Jon Chambers, Shreerang Pande, pushy
Also, from APNs:

"
APNs treats rapid connection and disconnection as a denial-of-service attack. You should leave a connection open unless you know it will be idle for an extended period of time—for example, if you only send notifications to your users once a day, it is acceptable practice to use a new connection each day.
"

Shreerang Pande

unread,
Apr 7, 2017, 10:43:44 AM4/7/17
to pushy, j...@turo.com, shreera...@gmail.com, mat...@apache.org
@Matthias, got it. thanks for the info. 


On Friday, April 7, 2017 at 8:04:04 PM UTC+5:30, Matthias Wessendorf wrote:
Also, from APNs:

"
APNs treats rapid connection and disconnection as a denial-of-service attack. You should leave a connection open unless you know it will be idle for an extended period of time—for example, if you only send notifications to your users once a day, it is acceptable practice to use a new connection each day.
"
On Fri, Apr 7, 2017 at 4:30 PM, Jon Chambers <j...@turo.com> wrote:
To quote the documentation (http://relayrides.github.io/pushy/apidocs/0.9/com/relayrides/pushy/apns/ApnsClient.html):

> APNs clients are intended to be long-lived, persistent resources. Callers should shut them down when they are no longer needed (i.e. when shutting down the entire application).

So, yes. You should only disconnect your client when your server is shutting down.

-Jon
On Fri, Apr 7, 2017 at 9:45 AM, Shreerang Pande <shreera...@gmail.com> wrote:
There was no concept of explicitly establishing a connection in HTTP/1. or HTTP/1.1. Every-time we made a new get/post request, a new connection used to be made. In the pushy-apns client, I saw that we explicitly need to make a connection with apns server before we can send a notification. In such a case, should we make a new connection for every notification request or should we make the connection once and destroy it only on server shutdown?

--
Pushy is an open-source Java library for sending APNs (iOS and OS X) push notifications. Pushy is brought to you by the engineers at RelayRides.
---
You received this message because you are subscribed to the Google Groups "pushy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pushy-apns+...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
Pushy is an open-source Java library for sending APNs (iOS and OS X) push notifications. Pushy is brought to you by the engineers at RelayRides.
---
You received this message because you are subscribed to the Google Groups "pushy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pushy-apns+...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Shreerang Pande

unread,
Apr 7, 2017, 10:49:46 AM4/7/17
to pushy, shreera...@gmail.com
@Jon, I had one more doubt. How should we handle race conditions. Say if one thread is handling connecting to APNS and other is handling the actual sending of notifications. Should the 2nd thread wait for the first thread. If yes, how is it possible, 2nd thread would not have the connectFuture. Can we use the getReconnectionFuture() to get the connect future in this case. I am explicitly asking because the documentation says this method should be used after we get a ClientNotConnectedException.


On Friday, April 7, 2017 at 8:00:36 PM UTC+5:30, Jon Chambers wrote:
To unsubscribe from this group and stop receiving emails from it, send an email to pushy-apns+...@googlegroups.com.

Jon Chambers

unread,
Apr 8, 2017, 11:38:29 AM4/8/17
to Shreerang Pande, pushy
This sounds like a general multi-threaded programming question more than a Pushy-specific question, to be honest. Some suggestions:

1. You could wait until your connection future has completed before starting your second thread.
2. You could have your second thread `wait` on a shared object, then `notify` that object when the connection future completes.
3. Calling `connect()` again on an ApnsClient will return the initial connection future; it will still be marked as "succeeded" if the client is already connected.

Hope that helps!

-Jon

To unsubscribe from this group and stop receiving emails from it, send an email to pushy-apns+unsubscribe@googlegroups.com.

Shreerang Pande

unread,
Apr 9, 2017, 3:17:30 AM4/9/17
to pushy, shreera...@gmail.com
Thanks Jon for the suggestions.
Reply all
Reply to author
Forward
0 new messages