An example of all that John said is available there thanks to Kieran : https://github.com/projectwonder/wonder/tree/master/Examples/Misc/BackgroundTasks
Alex Le 29 juil. 2011 à 16:52, Andrew Kinnie a écrit : > 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/alexis.tual%40gmail.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]
