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.
