Thanks. I may give that a try. That was one of the other options I thought of, but was hoping to avoid a significant re-write.
On Jul 29, 2011, at 10:44 AM, John & Kim Larson wrote: > rather than increasing worker threads, why not just spawn a new Java thread > for sending the notifications? That thread can run in the background while > you're doing EO stuff and free your app up to do the servicing of requests. > > If you go down this path, I always pass EOs to other threads as globalIDs to > prevent problems. Also, make sure you don't lock the OSC for the app during > your work or your app will hang while other threads' ECs wait to get it. If > this gets bad enough, use a separate OSC stack and dispose of it when your > done. > > John > > Sent from my iPhone > > On Jul 29, 2011, at 9:28 AM, Andrew Kinnie <[email protected]> wrote: > >> Greetings >> >> I have a deployed app which serves as a push notification server for our iOS >> app. It uses a recent ERRest (post WOWODC) to provide access to the data >> which is located on a MySQL database (using innoDB). The model has entities >> for PushApplication (the iOS app), ApplicationDevice (i.e. an iOS device >> which has our iOS app), Notification and has a lookup table for >> NotificationType (5 rows). Notification is a message, and there is a many >> to many with ApplicationDevice along with a corresponding >> device_notification table, as well as ApplicationDeviceNotificationType to >> allow particular devices to have particular types of notifications turned on >> or off. >> >> Our app in connected to by our editorial staff via a Cold Fusion app to send >> out breaking news alerts as push notifications. I then get (via a fetch) >> all the devices which have that particular notification type (basically 90% >> of our 20,000+ "installed" applicationDevices), then I pass that array into >> a method which makes the connection to Apple and iterates through the array >> sending one notification to each device in turn, then closes the connection. >> >> It takes approximately 1 minute to send an alert to all 20,000 devices. >> >> While this happens, some of these devices are getting the push from Apple >> (which is crazy fast about it), and some of them are running the app and the >> iOS app itself is querying the server for details about the notification and >> loading it in. However, if this happens while the push is still in the >> process of sending (i.e. within the 1 minute time frame), the iOS app may be >> forced to wait for the send process to finish (as many as 60 seconds >> presumably. It doesn't happen all that often, because our app doesn't buzz >> or makes a sound when it receives a notification, but it is not ideal. We >> anticipate using this same app and server for the Android version, and for >> the upcoming iPhone update, so the number of installed devices could >> increase pretty dramatically. Currently it is iPad only. >> >> So, we're trying to figure out what to do about it. Currently the app is >> deployed on a CentOS server (single core processor) which also houses the >> db, but nothing else. It has 16 GB of RAM. >> >> We were considering: >> >> 1. Trying to increase the threads the app can create, but I'm not sure that >> would fix it as much as mask it >> 2. Trying to run an additional copy of the app to send while the other one >> handles the incoming client requests, but I am not sure how to accomplish >> this other than copying the whole project, renaming it, then deploying that. >> I am also not sure this would fix anything if in fact the issue were >> locking in the database or jdbc or something of that nature. >> 3. Seeing if there was something easier, more efficient and less kludgy >> feeling than either of those. (assuming either of those would work anyway, >> we have some difficulty testing it without sending out 20,000 push >> notifications) >> >> Anyone have any insight? >> >> Andrew >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Webobjects-dev mailing list ([email protected]) >> Help/Unsubscribe/Update your Subscription: >> http://lists.apple.com/mailman/options/webobjects-dev/the_larsons%40mac.com >> >> This email sent to [email protected] _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
