allow pooling of connections

[GoogleCodeExporter]

this is an enhancement request.

it would be nice if we could pool instances of PushNotificationManager...
it likely the case that sending all traffic through a single
PushNotificationManager socket would be problematic under any kind of load.

i'll be changing PushNotificationManager's constructor and extending it to
support apache commons pooling: 
http://commons.apache.org/pool/

when i get that going, i'll attach a patch/src here

thanks,

john

Original issue reported on code.google.com by jellis.r...@gmail.com on 2 Oct 2009 at 6:52

[GoogleCodeExporter]

Did you get anywhere with this?

Original comment by pat...@buckau.se on 3 Feb 2010 at 3:54

[GoogleCodeExporter]

Hi john, I was thinking of adding pooling myself until I realized that on the 
EC2 server I'm running the code on 
that once a connection has been created it takes only 1,2ms to send a 
notification, so unless you are sending 
500-1000 notifications a second there is no real need. It would be a nice 
implementation addition anyway. :)

Original comment by mfarn...@gmail.com on 26 Mar 2010 at 7:06

[GoogleCodeExporter]

i did get somewhere and it is running in production.  i'll try to get around to
attaching the patch.

the reason for the connection pooling isn't necessarily performance.  it is 
because
apple's docs specifically state that if you go connectionless, they could shut 
you
down as a DOS attack.  i'm not sure at what levels they start to become 
concerned,
but i didn't want to risk it.

Original comment by jo...@dovevalleyapps.com on 26 Mar 2010 at 1:18

[GoogleCodeExporter]

Patch would nice, and easier to commit.

Original comment by idbill.p...@gmail.com on 26 Mar 2010 at 9:35

[GoogleCodeExporter]

Original comment by idbill.p...@gmail.com on 27 Apr 2010 at 4:39

• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Solved in 2.0 (see new javapns.notification.transmission) package.

Original comment by sype...@gmail.com on 9 Sep 2011 at 7:00

• Changed state: Fixed

[GoogleCodeExporter]

I am writing an application to support notifications for 200K+ users. Where I 
need to send user specific notifications to users. So Push.alert will not help 
much. As it closes and opens connection each time. Which is not recommended by 
APNS.

Can you tell me what would be the best way to handle? Are you going to handle 
this in near future. 

Thanks in advance! 

Original comment by riz...@gmail.com on 22 Oct 2011 at 6:43

[GoogleCodeExporter]

Since this is a scenario that is likely happen for others, I have made some 
enhancements in the library.  I have added a PayloadPerDevice class which links 
a payload to a device.  You can call Push.payloads(..) with a list or an array 
of PayloadPerDevice objects.  This will allow you to push specific payloads to 
specific devices.

To try it out, you will need to get the latest build from the trunk 
(http://code.google.com/p/javapns/source/browse/trunk).

Let me know how it goes.

Original comment by sype...@gmail.com on 22 Oct 2011 at 8:15

[GoogleCodeExporter]

Thanks Sylvain! I love the work what you guys have done and planning to use it 
in my application.

Unfortunately, My application is more real time, where I need to send an alert 
immediately. Rather than waiting to having a list tokens and devices. So I 
prefer calling Push.alert(...)

I am looking for something, which will not close the connection immediately. 
rather reuse it for other alerts. Until it get closed or I am OK with 
maintaining it for for duration. I am concerned about the DOS attack.  Do you 
have any thoughts?

On an average I will using your framework to send 50K to 100K notifications in 
a day.

Keep up the good work. Thanks!

Original comment by riz...@gmail.com on 23 Oct 2011 at 4:43

[GoogleCodeExporter]

I suggest you take a look at the source code for the javapns.Push.payload(...) 
method.  It creates and opens a connection, pushes notifications and closes the 
connection.  You could do the same, except you wouldn't close the connection, 
but rather reuse it.

Original comment by sype...@gmail.com on 23 Oct 2011 at 5:34

[GoogleCodeExporter]

Hi! 
I'm working on a very similar application. It's like sms messaging so each 
payload needs to be sent immediately and connections reused. 

My idea is to implement a pool of connections and a dispatcher that decides 
(using some sort of algorithm maybe round robin) which slave has to send each 
notification.

What I don't know is how long it takes for the connection to close. I'll have 
to implement some sort of method to ask the SSLSocket if its still "logged" to 
APNS. Then I could implement a sort of monitor which checks that connections 
are up and reconnects the ones that fall.

Is my idea OK?

Original comment by gonz...@gmail.com on 26 Oct 2011 at 6:52

[GoogleCodeExporter]

It all depends on what Apple allows you to do, or what it tolerates.  I'm not 
sure that maintaining several parallel connections open with Apple servers is 
something they'll tolerate (you wouldn't want to get banned because of 
overusing their resources), but that is purely speculative.

I guess you will have to try for yourself and find out what the reliability / 
tolerance thresholds are.

Original comment by sype...@gmail.com on 26 Oct 2011 at 7:22

[GoogleCodeExporter]

Well, it seems that not much work was needed to adapt the existing 
NotificationThread and related classes to support a connection pool.  So, if 
you want to try it, you can download the latest build from SVN and run this:

  AppleNotificationServer server = new AppleNotificationServerBasicImpl(keystore, password, production);
  NotificationThreads pool = new NotificationThreads(server, 3).start();

(notice the '3' above, which is the number of threads (ie connections) to 
create in the pool)

Next, you can add a notification to the next available queue (thread) by simply 
calling:

  pool.queue(payload, token);

Since the library automatically detects and recovers from connection errors, 
your connection pool should automatically recover if Apple drops the connection.

Original comment by sype...@gmail.com on 26 Oct 2011 at 9:58

[GoogleCodeExporter]

Thanks a lot! We are IN the PROCESS TO MIGRATE TO javapns 2.0
NEXT we'll try the connection pool.
Thanks again!

Original comment by gonz...@gmail.com on 7 Nov 2011 at 6:18