Hello Glen, As you can see from this lengthy discussion you've dug up, the Channel API can be quite temperamental, mildly speaking. I'm sorry to tell you that there is really no magic bullet solution, that's just the way that Channel API is right now.
However, here are a few solutions you might find more reliable: 1. Go back to standard AJAX/JSONP communications. Reliable, but can be taxing on the server. 2. Set up a node.js external server, set up a standard websockets (there are many libraries for this, one of the most popular is http://socket.io/#how-to-use ). The downside is that you'll have to manage and provision an external server. 3. Use an external hosted web sockets service, such as Firebase https://www.firebase.com/tutorial/#gettingstarted Can get expensive quickly though, depending on your budget and use cases. 4. As you stated in your post, Channel API can get unstable if held open for long periods of time, so just force the opening of a new sockets periodically (you can do so by setting the duration_minutes argument in create_channel() function to a low number. Play around, see what works for you). Probably the best option. Here is another discussion on the topic you might find useful: https://groups.google.com/forum/#!msg/google-appengine/9wMnC7DAa80/CehgVFpFubYJ I will note that the company I work for uses all of these methods (in different apps, of course!) in production applications, and they work quite well for us. ----------------- -Vinny P Technology & Media Advisor Chicago, IL @GOV on AppDotNet: https://alpha.app.net/gov On Wednesday, March 27, 2013 6:25:27 PM UTC-5, Glen Whitaker wrote: > > We are currently facing a similar problem where the client stops receiving > messages from the server. What we have observed is the application will > perform as expected, receiving messages opening up the channel on the > initial few visits, however after a period of time the channel on the > client will not receive any more messages despite being established. > > Diagnosis has been performed on both local dev mode and production > instances and behaviour is the same, except on production it takes a longer > period of time ( approximately 1 hr ) before reaching this channel state of > not receiving on the client. The problem has been observed in both the > latest versions of Chrome and Firefox. > > Through use of lsof and netstat it was found that a large number of > sockets were being held open by the browser in a CLOSE_WAIT state, which > once the process (firefox) that was holding these sockets was closed and > released the channel started to receive again, although at a very slow rate > ( the slow rate on recovery could be caused by the current task queue > latency ). > > The problem does not exist if setting up a new channel with a new token > every time, but when refreshing (disconnect/reconnect) the channel using > the same token results in this problem where client stops receiving after a > period of time. > > Still trying to find a solution to this problem. > > On Monday, 31 December 2012 07:00:42 UTC+11, 0914...@umt.edu.pk wrote: >> >> I've recently faced the problem. I've implemented some collaborative work >> on my app. I've used the Channel API and it works really fine on localhost. >> After deploy, the "update" in the other client is never received. why? >> > -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
