Status Update
Comments
ge...@gmail.com <ge...@gmail.com> #2
var ws = new WebSocket("ws://
Possibilities are endless for instant communication, social games, real-time
monitoring, etc.
we...@google.com <we...@google.com>
se...@gmail.com <se...@gmail.com> #5
we...@google.com <we...@google.com> #6
a useful feature. If you cannot wait, here is one alternative:
python/browse_thread/thread/a12350c582d32ea4
to...@gmail.com <to...@gmail.com> #7
se...@gmail.com <se...@gmail.com> #8
any demo in java?
wo...@gmail.com <wo...@gmail.com> #9
According to
Web Sockets are only implemented in Chrome dev channel (4.0.238.0 or later), although
there are efforts to implement it in Firefox and Safari/WebKit.
an...@gmail.com <an...@gmail.com> #10
GAE funciona sobre jetty, y este ya tiene una implementación de un servlet para
websockets, entiendo entonces que si Google apuesta por el html5 también apuesta por
websockets, por lo que esto es algo que debería implementar en GAE.
pe...@gmail.com <pe...@gmail.com> #11
Chrome.
This would be wonderful to have.
pk...@gmail.com <pk...@gmail.com> #12
instead of using thrid-party hosts.
an...@gmail.com <an...@gmail.com> #13
with constant pull requests
ro...@gmail.com <ro...@gmail.com> #14
I'm so excited to see it implemented into GAE! For me, it's a true web's revolution.
RL, France.
to...@gmail.com <to...@gmail.com> #15
Looking forward to the new Chanel API using Web Sockets.
w....@gmail.com <w....@gmail.com> #16
je...@gmail.com <je...@gmail.com> #17
cf...@gmail.com <cf...@gmail.com> #18
ho...@gmail.com <ho...@gmail.com> #19
na...@gmail.com <na...@gmail.com> #20
ka...@gmail.com <ka...@gmail.com> #21
co...@gmail.com <co...@gmail.com> #23
to...@gmail.com <to...@gmail.com> #24
I wonder if I should port the Channel API to use Web Sockets...
ol...@hppc.co.uk <ol...@hppc.co.uk> #25
ik...@google.com <ik...@google.com> #26
bu...@gmail.com <bu...@gmail.com> #27
fv...@gmail.com <fv...@gmail.com> #28
to...@deck.cc <to...@deck.cc> #30
co...@gmail.com <co...@gmail.com> #31
ph...@gmail.com <ph...@gmail.com> #32
communicate currently, I would not say that this is fixed. We asked for a
WebSocket API. Once the Channel API uses WebSocket, you can close this issue
as fixed, but until then - there is no WebSocket API in Google App Engine.
☆*PhistucK*
da...@gmail.com <da...@gmail.com> #33
So its not even a WebSocket-like feature either.
bt...@brandonthomson.com <bt...@brandonthomson.com> #34
bt...@brandonthomson.com <bt...@brandonthomson.com> #35
Anyway, WebSocket is a very specific W3C standard, and held-open http requests (aka Comet) is not WebSocket.
mc...@gmail.com <mc...@gmail.com> #36
This issue is "fixed" if the intention was to provide some sort of real-time client notifications from App Engine. It is NOT if you are looking for a true WebSockets compatability.
ha...@gmail.com <ha...@gmail.com> #37
This issue, however, is very clear, including a link to the specification page for Web Sockets. Channel API is cool, but it doesn't deliver Web Sockets. The most obvious tests:
1. Is client code portable to other server implementations of the Web Socket specification?
2. Can I leverage the feature directly through a native browser API (no js include)?
ar...@gmail.com <ar...@gmail.com> #38
Fact: Channel API != WebSockets.
ik...@google.com <ik...@google.com> #39
I will advise that this is not currently on our roadmap, so please don't let this block you.
la...@gmail.com <la...@gmail.com> #40
Indeed they are. Thanks for reopening. Too bad not anytime soon it looks like.
ge...@gmail.com <ge...@gmail.com> #41
var ws = new WebSocket("ws://
At least Channel API is a great addition to GAE.
ha...@gmail.com <ha...@gmail.com> #42
di...@gmail.com <di...@gmail.com> #43
as...@gmail.com <as...@gmail.com> #44
I would put my efforts behind this, since it doesn't have gapping security flaws and better browser support. (According to
gr...@gmail.com <gr...@gmail.com> #45
su...@gmail.com <su...@gmail.com> #46
sh...@gmail.com <sh...@gmail.com> #47
jo...@gmail.com <jo...@gmail.com> #48
th...@gmail.com <th...@gmail.com> #49
Seem like it have limit so we cannot open long polling for every connection like I want to
jo...@gmail.com <jo...@gmail.com> #50
Instead of establishing a socket in a common way, you create a socket like the Channel API, so you pass a token (maybe even an IP or URL to the server you're going to connect) and that server handles all the connection details with the client. The GAE instance sends commands through a synchronized API and the server has a read buffer where every byte that it receives gets written, so our instances can do a query (say a socks.has_bytes() function) and then subsequently read the data from the buffer.
All this should work on an unmetered, throttled way (say, no data amount limit, but a very low maximum throughtput limit around 1-2 kb/s) because websockets aren't for data transmission but instead for control messages. Also you could have a maximum number of concurrent users quota, so the servers handling sockets don't get bogged down because of free quotas.
This feature is definitively a must for real-time games to become a consolidated reality with GAE.
fr...@gmail.com <fr...@gmail.com> #51
th...@gmail.com <th...@gmail.com> #52
se...@ginx.com.br <se...@ginx.com.br> #53
da...@gmail.com <da...@gmail.com> #54
ph...@gmail.com <ph...@gmail.com> #55
The state of the world today consists of about three to five different implementations, that support various versions/editions/drafts of the protocol, not at all inter-operable.
Probably not before Internet Explorer 10 is shipped (when will that be? if it is correlated with Windows 8, then somewhen in 2012, if I am not mistaking).
ab...@gmail.com <ab...@gmail.com> #56
[Deleted User] <[Deleted User]> #57
na...@gmail.com <na...@gmail.com> #58
[Deleted User] <[Deleted User]> #59
na...@gmail.com <na...@gmail.com> #60
yo...@gmail.com <yo...@gmail.com> #61
pe...@gmail.com <pe...@gmail.com> #62
fe...@gmail.com <fe...@gmail.com> #63
jo...@gmail.com <jo...@gmail.com> #64
li...@gmail.com <li...@gmail.com> #65
co...@gmail.com <co...@gmail.com> #66
Javascript (node.js + aws or heroku) looking like a pretty good alternative at this point...
(as much as I love GWT)
Ja...@wetheinter.net <Ja...@wetheinter.net> #67
What about enabling web sockets for backends, where the new ThreadManager code already allows long running daemons? Who cares how high the latency is on a backend that's always on?
Web sockets would be a huge win.
st...@gmail.com <st...@gmail.com> #68
Puff, puff, give.
jo...@gmail.com <jo...@gmail.com> #69
Ja...@wetheinter.net <Ja...@wetheinter.net> #70
The secret to unlocking super fast requests is to use asynchronous-everything. The ApiProxy async services all fire up piles of threads, which you don't pay for as instance hours {you pay as api calls}. If you can fire off at 3-5 async requests per browser request, appengine will keep 4-6 instances warm, with full threadpools, all waiting to service your requests... And if those 4-6 instance can service all requests ~150ms, you will only get charged for 1~2 instances. This is because you are charged based on whether the dispatcher has to block or not. It has to keep instances up to service api calls, but one or two instances actually service requests.
pa...@gmail.com <pa...@gmail.com> #71
jo...@gmail.com <jo...@gmail.com> #72
gi...@gmail.com <gi...@gmail.com> #73
jo...@gmail.com <jo...@gmail.com> #75
da...@daave.com <da...@daave.com> #76
jo...@gmail.com <jo...@gmail.com> #77
[Deleted User] <[Deleted User]> #78
gi...@gmail.com <gi...@gmail.com> #79
ro...@gmail.com <ro...@gmail.com> #80
Can't find issue about that...
jo...@gmail.com <jo...@gmail.com> #81
ro...@gmail.com <ro...@gmail.com> #82
I wish I knew the guy who can answer this question in Google.
dr...@gmail.com <dr...@gmail.com> #83
wo...@gmail.com <wo...@gmail.com> #84
wo...@gmail.com <wo...@gmail.com> #85
fr...@gmail.com <fr...@gmail.com> #86
bo...@cbn-it.ro <bo...@cbn-it.ro> #87
bo...@cbn-it.ro <bo...@cbn-it.ro> #88
They've used it in this year at Google IO to make a P.V.P. Game:
In the Trusted Tester Features i can see that you can enroll to test: Outbound sockets support:
vv...@gmail.com <vv...@gmail.com> #89
lu...@gmail.com <lu...@gmail.com> #90
hu...@gmail.com <hu...@gmail.com> #91
I can swallow 'No' for an answer much easier than dangling from a line for another year or two.
do...@gmail.com <do...@gmail.com> #92
fa...@gmail.com <fa...@gmail.com> #93
[Deleted User] <[Deleted User]> #94
See roadmap for socket:
ks...@gmail.com <ks...@gmail.com> #95
br...@gmail.com <br...@gmail.com> #96
vi...@umich.edu <vi...@umich.edu> #97
a....@gmail.com <a....@gmail.com> #98
go...@gmail.com <go...@gmail.com> #99
java.net.SocketException: Permission denied: Not allowed to issue a socket connect: permission denied.
at com.google.appengine.api.socket.SocketApiHelper.translateError(SocketApiHelper.java:94)
at com.google.appengine.api.socket.SocketApiHelper.translateError(SocketApiHelper.java:105)
at com.google.appengine.api.socket.SocketApiHelper.makeSyncCall(SocketApiHelper.java:71)
at com.google.appengine.api.socket.AppEngineSocketImpl.createSocket(AppEngineSocketImpl.java:498)
at com.google.appengine.api.socket.AppEngineSocketImpl.connectToAddress(AppEngineSocketImpl.java:343)
at com.google.appengine.api.socket.AppEngineSocketImpl.connect(AppEngineSocketImpl.java:335)
at java.net.Socket.connect(Socket.java:529)
at java.net.Socket.connect(Socket.java:478)
at java.net.Socket.<init>(Socket.java:375)
at java.net.Socket.<init>(Socket.java:189)
at com.arpit.WebSocketClient.connect(WebSocketClient.java:41)
at com.arpit.WebSocketClient.mainprogram(WebSocketClient.java:98)
at com.arpit.ReadSocketPort.DOMparser(ReadSocketPort.java:53)
at com.arpit.URLconnectionServlet.doGet(URLconnectionServlet.java:15)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1166)
at com.google.appengine.api.socket.dev.DevSocketFilter.doFilter(DevSocketFilter.java:74)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
at com.google.appengine.tools.development.ResponseRewriterFilter.doFilter(ResponseRewriterFilter.java:123)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
at com.google.appengine.tools.development.HeaderVerificationFilter.doFilter(HeaderVerificationFilter.java:34)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
at com.google.appengine.api.blobstore.dev.ServeBlobFilter.doFilter(ServeBlobFilter.java:61)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
at com.google.apphosting.utils.servlet.TransactionCleanupFilter.doFilter(TransactionCleanupFilter.java:43)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
at com.google.appengine.tools.development.StaticFileFilter.doFilter(StaticFileFilter.java:125)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
at com.google.appengine.tools.development.BackendServersFilter.doFilter(BackendServersFilter.java:97)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:388)
at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:418)
at com.google.appengine.tools.development.DevAppEngineWebAppContext.handle(DevAppEngineWebAppContext.java:94)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at com.google.appengine.tools.development.JettyContainerService$ApiProxyHandler.handle(JettyContainerService.java:383)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:326)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:923)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:547)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409)
at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
in...@gmail.com <in...@gmail.com> #100
Is progress on this evenly difficult for all supported languages? Or could it be released earlier for some? E.g. could be released earlier for Python or Go than for Java or PHP?
Thanks,
Ingo
[Deleted User] <[Deleted User]> #101
ge...@duzy.info <ge...@duzy.info> #102
cu...@gmail.com <cu...@gmail.com> #103
are there new news?
na...@gmail.com <na...@gmail.com> #104
mr...@gmail.com <mr...@gmail.com> #105
mv...@gmail.com <mv...@gmail.com> #106
sh...@fullsalon.me <sh...@fullsalon.me> #107
ch...@gmail.com <ch...@gmail.com> #108
be...@lucidtechnics.com <be...@lucidtechnics.com> #109
ka...@gmail.com <ka...@gmail.com> #110
Is there going to be a cake cutting ceremony?
[Deleted User] <[Deleted User]> #111
rm...@gmail.com <rm...@gmail.com> #112
cr...@gmail.com <cr...@gmail.com> #113
(
Google should really consider embracing this open standard in GAE to remain a good hosting option.
al...@gmail.com <al...@gmail.com> #114
an...@gmail.com <an...@gmail.com> #115
cramsdale@google.com
Access to native resources (such as a network stack) is now available via Managed VMs.
There is also a sample project on GitHub that walks folks through how to do this.
qg...@gmail.com <qg...@gmail.com> #116
Developing ManagedVM's apps is still complicated for now, since ManagedVM is beta
go...@gmail.com <go...@gmail.com> #117
jo...@gmail.com <jo...@gmail.com> #118
al...@gmail.com <al...@gmail.com> #119
sh...@gmail.com <sh...@gmail.com> #120
ar...@highest-peak.net <ar...@highest-peak.net> #121
oy...@gmail.com <oy...@gmail.com> #122
ar...@gmail.com <ar...@gmail.com> #123
ja...@gmail.com <ja...@gmail.com> #124
ng...@google.com <ng...@google.com> #126
Further updates will be posted here.
[1]:
[2]:
ni...@gmail.com <ni...@gmail.com> #127
BOW NOW BEFORE THEM
ni...@gmail.com <ni...@gmail.com> #128
[Deleted User] <[Deleted User]> #129
ar...@gmail.com <ar...@gmail.com> #130
pe...@gmail.com <pe...@gmail.com> #131
ma...@bkper.com <ma...@bkper.com> #132
an...@gmail.com <an...@gmail.com> #133
ra...@gmail.com <ra...@gmail.com> #135
All I get is:
Failed to load resource: ___ the server responded with a status of 400 (Bad Request)
zz...@verus.io <zz...@verus.io> #136
st...@gmail.com <st...@gmail.com> #137
It has been used by many of us as "workaround" to missing websocket support.
Google PLS update us about some ETA for "standard" WebSockets support.
vi...@gmail.com <vi...@gmail.com> #138
im...@gmail.com <im...@gmail.com> #139
ta...@google.com <ta...@google.com>
ni...@gmail.com <ni...@gmail.com> #140
sh...@fullsalon.me <sh...@fullsalon.me> #141
ja...@gmail.com <ja...@gmail.com> #142
fr...@kurpiel.eng.br <fr...@kurpiel.eng.br> #143
mr...@gmail.com <mr...@gmail.com> #144
bo...@shulha.pp.ua <bo...@shulha.pp.ua> #145
al...@gmail.com <al...@gmail.com> #146
actually i tried a lot of alternative scenario till this added feature, but at the end the websocket is the best solution for a lot of business problem.
Still waiting websockets API in Google App Engine, hope so (:
[Deleted User] <[Deleted User]> #147
mm...@lex.vin <mm...@lex.vin> #148
bt...@gmail.com <bt...@gmail.com> #149
ka...@gmail.com <ka...@gmail.com> #150
lk...@google.com <lk...@google.com> #151
lk...@google.com <lk...@google.com> #152
Please head over to this form when you have a chance, we really appreciate it!
ti...@gmail.com <ti...@gmail.com> #153
bl...@gmail.com <bl...@gmail.com> #154
Still, I'm really impressed by Google. First time I see an 8 years old issue, you guys should really celebrate when this is done. Seriously, you made my day :))
[Deleted User] <[Deleted User]> #155
bl...@gmail.com <bl...@gmail.com> #156
ro...@arcus-solutions.nl <ro...@arcus-solutions.nl> #157
8 years !?! Come on .... With Microservices it's easy to move between several solutions, so Google has to compete on functionality and price.
br...@gmail.com <br...@gmail.com> #158
ni...@gmail.com <ni...@gmail.com> #159
whenever possible. Is that not the case?
On Wed, Mar 15, 2017 at 5:07 AM, <buganizer-system@google.com> wrote:
ro...@arcus-solutions.nl <ro...@arcus-solutions.nl> #160
With these;
Etc.
And the proposed Google 'solution';
"You can use the Firebase Realtime Database to achieve superior realtime functionality in your application"
Yes indeed, just change your database (no problem?)
sl...@gmail.com <sl...@gmail.com> #161
do...@gmail.com <do...@gmail.com> #162
flex is a pain for existing applications...
Websocket is a must-have for any PWA, even on HTTP 2.0...
Find a way to have it persistent, even if you limit the payload (forcing
subsequent fetches to get all information).
On Wed, Mar 15, 2017 at 6:50 AM, <buganizer-system@google.com> wrote:
ph...@gmail.com <ph...@gmail.com> #163
#161 - please, do not deter the issue into a channel API deprecation outcry... This issue is about web socket support.
ob...@gmail.com <ob...@gmail.com> #164
ko...@gmail.com <ko...@gmail.com> #165
Could someone help out?
Tried out the sockets documented here:
NOTHING WORKS.
Google help a sister out.
mi...@hashtagfoundation.org <mi...@hashtagfoundation.org> #166
I need web socket support.
ro...@arcus-solutions.nl <ro...@arcus-solutions.nl> #167
Our investors are getting nervous and we already ported parts of our software to docker containers with Google Container Engine on their behalf.
Will Google Container Engine replace GAE in the near future?
Some insight on this subject would be really helpful at this moment.
lk...@google.com <lk...@google.com> #168
ni...@gmail.com <ni...@gmail.com> #169
[Deleted User] <[Deleted User]> #170
ma...@bkper.com <ma...@bkper.com> #171
du...@gmail.com <du...@gmail.com> #172
al...@gmail.com <al...@gmail.com> #173
sh...@fullsalon.me <sh...@fullsalon.me> #174
[Deleted User] <[Deleted User]> #175
Still no port forwarding, still no websockets #sad.
[Deleted User] <[Deleted User]> #176
We need a fast answer from Google about this issue !
#unacceptable
ta...@google.com <ta...@google.com> #177
Thanks for your patience. I'm a manager for the engineering team delivering WebSockets for App Engine.
I can't give specific dates, but know that we're working hard to support WebSockets. Our first goal is to launch an early access preview (EAP) with a few high need and early adopter customers (read: willing to put up with breakage and incompatible changes). Supporting it involves changing some long baked assumptions around instance lifecycles, request flows, and runtime behaviors, so there have been some big hurdles to overcome. We've solutions for the implications and are implementing now.
-Tad
sh...@fullsalon.me <sh...@fullsalon.me> #178
[Deleted User] <[Deleted User]> #179
I'm in... breakage and incompatible changes are allways better than an useless work while trying to implement outdated Google's code samples
i.e : -
/!\ WARNING -> Don't even read it, merly unusable broken pieces in a jigsaw where most of the parts are leaking.
#cheers - just don't forget to purge these out of your GitHub's reference.
pa...@gmail.com <pa...@gmail.com> #180
mi...@kristovar.com <mi...@kristovar.com> #181
i understand all the baked in assumptions about the request flows, to the point where i figured it wouldn't be possible to integrate with existing GAE networks... will the whitelisted projects move to a different network that might suffer in other ways while the websockets feature is worked out, or will they remain in place?
lk...@google.com <lk...@google.com> #182
lk...@google.com <lk...@google.com> #183
sh...@fullsalon.me <sh...@fullsalon.me> #184
ro...@arcus-solutions.nl <ro...@arcus-solutions.nl> #185
st...@google.com <st...@google.com> #186
We expect to send the first invites within a week. Note that this depends on what criteria (runtime / env) you filled in the form.
[Deleted User] <[Deleted User]> #187
ro...@arcus-solutions.nl <ro...@arcus-solutions.nl> #188
And we're waiting for a long long long... time...
Op za 7 okt. 2017 18:29 schreef <buganizer-system@google.com>:
st...@google.com <st...@google.com> #189
Websockets are not yet ready for all languages and environments. As I mentioned, we use the information you provided in the form to send invitations.
If you received an invitation, you should have been added to the alpha tester Google group. Please prefer sending feedback in the Google group rather than on this bug.
[Deleted User] <[Deleted User]> #190
ca...@emerald.li <ca...@emerald.li> #191
I'm looking over to migrate my app from Heroku to your platform but I cannot do that unless you have websocket support. I am simply not able to or willing to refactor, so the platform must have the support for web sockets.
I spend $1000 a month on Heroku, that's about $12,000 a year that will be spent on your platform, please please please implement this and get it finished as soon as possible, I am thinking of going over to Amazon but I am holding off because I don't want to do that believe me!
I signed up for the test also, please please get this done soon it really is important to many devs, many of which I am sure didn't even find this. I had to scour the web to find it after all.
ni...@gmail.com <ni...@gmail.com> #192
through a compute engine VM. For us we're using vert.x + sockJS.
On Mon, Nov 6, 2017 at 7:40 AM, <buganizer-system@google.com> wrote:
st...@google.com <st...@google.com> #193
Depending on your language and environment, you might receive an invitation.
ca...@emerald.li <ca...@emerald.li> #194
is there an ETA on this yet?
I signed the form but received nothing, I am guessing no access for Ruby developers yet?
ca...@emerald.li <ca...@emerald.li> #195
dv...@gmail.com <dv...@gmail.com> #196
I just saw an announcement of Java 7 appEngine being replaced by Java 8 appEngine. Advantages listed for Java 8 included: "availability of all public JDK APIs, and ability to use java.io.File, threads, and any Java libraries."
Does that mean that appEngine on Java 8 can use Web Sockets API without the beta?
ro...@arcus-solutions.nl <ro...@arcus-solutions.nl> #198
Poloniex uses a push API over WebSockets using the WAMP protocol
Is the brand new GAE web-socket API we're all anxiously waiting for supporting the WAMP protocol?
[Deleted User] <[Deleted User]> #199
an...@gmail.com <an...@gmail.com> #200
fr...@gmail.com <fr...@gmail.com> #201
fr...@gmail.com <fr...@gmail.com> #202
tu...@gmail.com <tu...@gmail.com> #203
ni...@gmail.com <ni...@gmail.com> #204
engine to host the websocket connection. This is what we have done.
On Mar 12, 2018 5:10 PM, <buganizer-system@google.com> wrote:
ro...@arcus-solutions.nl <ro...@arcus-solutions.nl> #205
mk...@gmail.com <mk...@gmail.com> #206
in...@gmail.com <in...@gmail.com> #207
[Deleted User] <[Deleted User]> #208
[Deleted User] <[Deleted User]> #209
do...@autofleet.io <do...@autofleet.io> #210
kn...@google.com <kn...@google.com> #212
an...@gmail.com <an...@gmail.com> #213
ph...@gmail.com <ph...@gmail.com> #214
kn...@google.com <kn...@google.com> #215
ro...@arcus-solutions.nl <ro...@arcus-solutions.nl> #216
jo...@gmail.com <jo...@gmail.com> #217
kn...@google.com <kn...@google.com> #218
jo...@gmail.com <jo...@gmail.com> #219
kn...@google.com <kn...@google.com> #220
ra...@shine.fr <ra...@shine.fr> #221
fe...@gmail.com <fe...@gmail.com> #222
ke...@gmail.com <ke...@gmail.com> #223
ka...@group.riehle.org <ka...@group.riehle.org> #224
Having websockets on GAE standard for node.js would be perfect. but even on flexible would be a step up from managing our own VMs.
de...@gmail.com <de...@gmail.com> #225
yes, we would all love to have this feature and they work on it
google may want to push Firebase and the engineers cannot help management policy
or they just need to wait for (or implement) an infrastructure change first
we will eventually get websockets but you should try something else for the next year or two I guess
thanks
an...@gmail.com <an...@gmail.com> #226
And also can you provide a more specific timeline for enabling it in the Standard Environment? When you say "it will likely not land this year", does that mean next year? Or more like three to five years?
wa...@gmail.com <wa...@gmail.com> #227
ro...@arcus-solutions.nl <ro...@arcus-solutions.nl> #228
For a company relying on Google App Engine we really need to know the path to the future.
What is Google doing on/with Google App Engine (standard)?
Should we completely move to Kubernetes/Container Engine (is that the intention)?
ma...@dfrag.tv <ma...@dfrag.tv> #229
be...@gmail.com <be...@gmail.com> #230
kn...@google.com <kn...@google.com> #231
Websockets for Standard are at least a year away. I'll continue to update here as we get more clarity on the timeline.
da...@gmail.com <da...@gmail.com> #232
While "at least a year away" does not sound too good, it is at least good to know that Google is still working on this feature.
It would have been great to have something available *before* shutting down the Channel API as this caused a lot of pain. We have migrated to Pusher and it would be great if websockets on Google Cloud would provide a similar feature set and not just the networking capabilities to implement something like Pusher on top of App Engine ourselves.
al...@gmail.com <al...@gmail.com> #233
How is it possible that in 2018 something as basic as a websocket server is just not supported? A little heads up in the Getting Started documentation would've been nice. I have to go back to Heroku now. I don't wanna go back to Heroku.
Also...guys, this issue's been open for almost 10 years. Google has figured out how to offer sophisticated processors designed to accelerate the training of AI models as a service. But websockets? Nah...that kind of technology is "at least a year away".
This needs to be a meme.
am...@gmail.com <am...@gmail.com> #234
am...@gmail.com <am...@gmail.com> #235
Le jeu. 2 août 2018 à 22:06, Amirouche Boubekki <
amirouche.boubekki@gmail.com> a écrit :
fa...@gmail.com <fa...@gmail.com> #236
am...@gmail.com <am...@gmail.com> #237
as blob of json so that in the end it loads very fast, but has the current
state of the interaction with the user. Depending on your requirements,
persistence might short span of life or long like always. The more
durability you ask for the more cost it incures. Now, they are optimization
that plays with whatever limit (or minimal life span) before the unit of
work is killed and re-scheduled. In serverless the lifetam is around a 1
minute.
Le jeu. 2 août 2018 à 22:28, <buganizer-system@google.com> a écrit :
am...@gmail.com <am...@gmail.com> #238
pattern, there might be no subscribers.
Le jeu. 2 août 2018 à 22:36, Amirouche Boubekki <
amirouche.boubekki@gmail.com> a écrit :
sp...@gmail.com <sp...@gmail.com> #239
You can see that services like Firestore (beta) only support up to 100,000 simultaneous connections -
The same is true for the Firebase Real Time Database -
Are there any current websocket implementation out there in production than can handle 10+ million simultaneous connections?
I would imagine that this would require some special pricing and accounting as well.
For now, you can simply create a GCE or GKE instance that handles your websocket traffic.
am...@gmail.com <am...@gmail.com> #240
connectivity one way or another in other it has error handling code. Some
how like cat, it can make the user have patience without leaving him with
nothing, like in browser editor that backups to leveldb. A retry loop will
queue tasks to retry later. It may be transparent to the user.
From the backend perspective opening up a websocket say 1 minute of
connectivity every 1s is good enough to synchronize a wysiwyg editor state.
Le jeu. 2 août 2018 à 23:07, <buganizer-system@google.com> a écrit :
de...@gmail.com <de...@gmail.com> #241
As topic related, until websockets are available (and we really should accept that there are tecnological and businness considerations, google is not a charity employing infinite number of gods after all...) I would be interested why xhr long polling is no alternative for you guys waiting.
ca...@unityworks.se <ca...@unityworks.se> #242
bo...@cbn-it.ro <bo...@cbn-it.ro> #243
I am using firebase realtime database for sending messages to my webUI. I write the info to certain paths in firebase and from webUI i listen for them. I know its not bi-directional, but for sending messages to server i use HTTP requests and for Server to Client messages i use firebase.
de...@gmail.com <de...@gmail.com> #244
I have not tested it yet but I am pretty sure it is going to work. I could also send another post request every minute I guess if needed and I would lose a round trip time + (re)identification time of client at most (from the real time effect). I must add although I have some technical background I do not consider myself an expert in this field... So I am always happy to listen to more experienced developers. I would appreciate what you guys think are the caveats/limitations/experiences with long polling and other websocket alternatives you tried or planning to try. As soon as I have practical experiences I will be happy to share if you are interested. (business... yes, I can spell it correctly! :)
an...@gmail.com <an...@gmail.com> #245
ro...@arcus-solutions.nl <ro...@arcus-solutions.nl> #246
Engine use-cases (possibilities) but Google could easily implement (or even
buy) a solution like Pusher and add it to App Engine... I think most users
will be satisfied with a solution like this ... "something is better than
nothing ..."
2018-08-03 18:44 GMT+02:00 <buganizer-system@google.com>:
se...@brevetti.ai <se...@brevetti.ai> #247
Thank you very much for dedicating resources to building this feature. I am developing an
Do you have any idea of when this will be available? Later this month? Next month? End of Q3? Q4?
se...@brevetti.ai <se...@brevetti.ai> #248
[Deleted User] <[Deleted User]> #249
lo...@gmail.com <lo...@gmail.com> #250
Websockets are definitely a requirement for our project. Lack of support will drive us away from Google Cloud i am afraid.
al...@gmail.com <al...@gmail.com> #251
ro...@arcus-solutions.nl <ro...@arcus-solutions.nl> #252
Therefore Firebase is no option in its current form (in our opinion).
As a 'quick' shift we're using Pusher for web socket use-cases.
Meanwhile we're migrating all our projects to Kubernetes to escape situation like this issue in the future.
[Deleted User] <[Deleted User]> #253
do...@gmail.com <do...@gmail.com> #254
ro...@arcus-solutions.nl <ro...@arcus-solutions.nl> #255
420 days, 14 hours, 7 minutes and 10 seconds to go
eb...@gmail.com <eb...@gmail.com> #256
me...@gmail.com <me...@gmail.com> #257
Well, i cant pay 1000-5000$ for testing my project. But who cares? 10 years and doingnothing. Is this realy Google?
an...@gmail.com <an...@gmail.com> #258
rh...@gmail.com <rh...@gmail.com> #259
ma...@gmail.com <ma...@gmail.com> #260
Neither 1st and 2nd generation.
Sure ... I've tested ;-)
Le jeu. 15 nov. 2018 à 01:42, <buganizer-system@google.com> a écrit :
ro...@arcus-solutions.nl <ro...@arcus-solutions.nl> #261
de...@gmail.com <de...@gmail.com> #262
this means ETA: from 2019-08-01 to 2020-08-01... bitte schön
they do seem to work actively on it, please read former @google tweets before posting your usual frustrated hate postings
I guess you got what you wanted as kids crying loud or you just do not seem to be growing up ;)
pa...@gmail.com <pa...@gmail.com> #263
az...@gmail.com <az...@gmail.com> #264
[Deleted User] <[Deleted User]> #265
Twas the night before Christmas, when all thro' the house
Not a dev was stirring, nor even their spouse;
The sockets were promised, “soon they’ll be here!”
In hopes that St. Google would deliver them there;
The devs were nestled all snug in beds,
While visions of websockets danced in their heads
al...@gmail.com <al...@gmail.com> #266
ro...@arcus-solutions.nl <ro...@arcus-solutions.nl> #268
ti...@gmail.com <ti...@gmail.com> #269
kn...@google.com <kn...@google.com> #270
I'm really happy to let you all know that WebSockets support for App Engine Flex is now in Beta!
Here's the documentation:
Python:
Java:
Nodejs:
It will work for other languages as well, we just don't have samples and dedicated docs pages yet.
P.S. Thank you Justin in #265 for the brilliant poem :)
jd...@slb.com <jd...@slb.com> #271
[Deleted User] <[Deleted User]> #272
jo...@gmail.com <jo...@gmail.com> #273
ev...@gmail.com <ev...@gmail.com> #274
kn...@google.com <kn...@google.com> #275
We will be adding docs for Go, likely before we "graduate" the feature out of Beta.
uk...@gmail.com <uk...@gmail.com> #276
en...@gmail.com <en...@gmail.com> #277
kn...@google.com <kn...@google.com> #278
ro...@undeadindustries.com <ro...@undeadindustries.com> #279
kn...@google.com <kn...@google.com> #280
We're working on adding the documentation for those languages.
On Fri, Apr 26, 2019 at 1:06 PM <buganizer-system@google.com> wrote:
[Deleted User] <[Deleted User]> #281
ya...@google.com <ya...@google.com> #282
th...@gmail.com <th...@gmail.com> #283
kn...@google.com <kn...@google.com> #284
Cloud Run. I can tell though you that it's not something that's coming in
the next few quarters; if you need to use Websockets right now, I'd
recommend App Engine Flex or GKE.
On Wed, Jun 5, 2019 at 3:37 PM <buganizer-system@google.com> wrote:
kn...@google.com <kn...@google.com> #285
We've also published documentation for this feature for all App Engine Flex languages.
[Deleted User] <[Deleted User]> #286
ha...@gmail.com <ha...@gmail.com> #287
java.util.concurrent.ExecutionException: org.eclipse.jetty.websocket.api.UpgradeException: Failed to upgrade to websocket: Unexpected HTTP Response Status Code: 400 Bad Request at java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:357) at java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1895) at interContILP.SendServlet.sendMessageOverWebSocket(SendServlet.java:150) at interContILP.SendServlet.doPost(SendServlet.java:90) at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:848) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1772) at com.google.apphosting.utils.servlet.JdbcMySqlConnectionCleanupFilter.doFilter(JdbcMySqlConnectionCleanupFilter.java:60) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1759) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:524) at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134) at com.google.apphosting.runtime.jetty9.ParseBlobUploadHandler.handle(ParseBlobUploadHandler.java:119) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1182) at com.google.apphosting.runtime.jetty9.AppEngineWebAppContext.doHandle(AppEngineWebAppContext.java:187) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) at com.google.apphosting.runtime.jetty9.AppVersionHandlerMap.handle(AppVersionHandlerMap.java:293) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134) at org.eclipse.jetty.server.Server.handle(Server.java:539) at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:333) at com.google.apphosting.runtime.jetty9.RpcConnection.handle(RpcConnection.java:213) at com.google.apphosting.runtime.jetty9.RpcConnector.serviceRequest(RpcConnector.java:81) at com.google.apphosting.runtime.jetty9.JettyServletEngineAdapter.serviceRequest(JettyServletEngineAdapter.java:134) at com.google.apphosting.runtime.JavaRuntime$RequestRunnable.dispatchServletRequest(JavaRuntime.java:722) at com.google.apphosting.runtime.JavaRuntime$RequestRunnable.dispatchRequest(JavaRuntime.java:685) at com.google.apphosting.runtime.JavaRuntime$RequestRunnable.run(JavaRuntime.java:655) at com.google.apphosting.runtime.JavaRuntime$NullSandboxRequestRunnable.run(JavaRuntime.java:847) at com.google.apphosting.runtime.ThreadGroupPool$PoolEntry.run(ThreadGroupPool.java:270) at java.lang.Thread.run(Thread.java:748) Caused by: org.eclipse.jetty.websocket.api.UpgradeException: Failed to upgrade to websocket: Unexpected HTTP Response Status Code: 400 Bad Request at org.eclipse.jetty.websocket.client.WebSocketUpgradeRequest.onComplete(WebSocketUpgradeRequest.java:527) at org.eclipse.jetty.client.ResponseNotifier.notifyComplete(ResponseNotifier.java:196) at org.eclipse.jetty.client.ResponseNotifier.notifyComplete(ResponseNotifier.java:188) at org.eclipse.jetty.client.HttpReceiver.terminateResponse(HttpReceiver.java:441) at org.eclipse.jetty.client.HttpReceiver.responseSuccess(HttpReceiver.java:387) at org.eclipse.jetty.client.http.HttpReceiverOverHTTP.messageComplete(HttpReceiverOverHTTP.java:316) at org.eclipse.jetty.http.HttpParser.handleContentMessage(HttpParser.java:599) at org.eclipse.jetty.http.HttpParser.parseContent(HttpParser.java:1669) at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:1517) at org.eclipse.jetty.client.http.HttpReceiverOverHTTP.parse(HttpReceiverOverHTTP.java:172) at org.eclipse.jetty.client.http.HttpReceiverOverHTTP.process(HttpReceiverOverHTTP.java:135) at org.eclipse.jetty.client.http.HttpReceiverOverHTTP.receive(HttpReceiverOverHTTP.java:73) at org.eclipse.jetty.client.http.HttpChannelOverHTTP.receive(HttpChannelOverHTTP.java:133) at org.eclipse.jetty.client.http.HttpConnectionOverHTTP.onFillable(HttpConnectionOverHTTP.java:155) at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:305) at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103) at org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.onFillable(SslConnection.java:427) at org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:321) at org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.java:159) at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103) at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117) at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333) at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310) at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168) at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126) at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:698) at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:804) ... 1 more
I am wondering what "Websockets traffic is now subject to our SLA." --- Any suggestions would be appreciated.
ya...@google.com <ya...@google.com> #288
to...@gmail.com <to...@gmail.com> #289
ya...@google.com <ya...@google.com> #290
an...@gmail.com <an...@gmail.com> #291
an...@hawkfish.us <an...@hawkfish.us> #292
an...@gmail.com <an...@gmail.com> #293
br...@gmail.com <br...@gmail.com> #294
an answer about it any time soon. (Understandably)
Il giorno dom 29 mar 2020 alle 21:08 <buganizer-system@google.com> ha
scritto:
we...@google.com <we...@google.com>
kn...@google.com <kn...@google.com>
mu...@gmail.com <mu...@gmail.com> #296
an...@googlemail.com <an...@googlemail.com> #297
In the Doc there is only a solution for Flask as far as I can tell. Thanks!
an...@gmail.com <an...@gmail.com> #298
st...@google.com <st...@google.com> #299
While this Feature Request is about App Engine standard environment, we wanted to let you know that Cloud Run, another of our serverless compute products, now supportd WebSockets:
an...@gmail.com <an...@gmail.com> #300
kn...@google.com <kn...@google.com> #301
Engine Standard. If you need websockets support for your application, I
recommend using Cloud Run or App Engine Flex.
On Thu, Jan 21, 2021 at 9:18 AM <buganizer-system@google.com> wrote:
ep...@gmail.com <ep...@gmail.com> #302
I am glad to hear that GCP has been supporting WebSockets on App Engine Flex. However, support for WebSockets on App Engine Standard is highly needed.
WebSockets are a very simple tool for developers, but requiring that they be deployed on App Engine Flex is rather frustrating. WebSockets are a very "standard" tool, and should not be withheld from App Engine Standard. App Engine Flex does not support scaling to 0, has a higher instance startup time, and features a longer deployment.
I would love to know when support for WebSockets will be available for App Engine Standard, especially considering this issue was first opened almost 12 years ago, and we haven't had an update in almost 9 months.
Thank you.
ga...@latinamericaforless.com <ga...@latinamericaforless.com> #303
ro...@gmail.com <ro...@gmail.com> #304
an...@nodata.ltd <an...@nodata.ltd> #305
I chose app engine because I didn't want to worry about the ins and outs of the environment, but I find myself battling with GCP and GAE daily now.
bu...@gmail.com <bu...@gmail.com> #306
ka...@gmail.com <ka...@gmail.com> #307
On Wed, Aug 24, 2022, 1:55 PM <buganizer-system@google.com> wrote:
la...@gmail.com <la...@gmail.com> #308
I have had multiple apps deployed on GAE with websockets.
They do work, there's also some special features for it listed in the documentation, and it is great.
As for the mentioned ws vs wss, GAE is a containerized type solution, which means your encryption should live outside of it.
Please google the documentation and read it instead of googling a 13 years old issue.
jt...@linux-consulting.us <jt...@linux-consulting.us> #309
Your reference to documentation is for GAE Flex, not GAE Standard... The comments above mostly ask for its support in Standard; they don't want Flex.
But I agree that we should move on! There are so many other solutions. Years ago in my GAE Standard apps, I replaced my WebSocket needs with Firebase. Works very well!
The BIG Question:
Why are we using GAE anymore?
Cloud Run is replacing it and is much better! It isn't quite a lift-and-shift if you want to leverage all the new features, but it is worth it! You should NOT be building anything new on GAE!
GAE isn't even promoted as a product on cloud.google.com anymore (it's there but hard to find). Cloud Run is the future for this kind of stuff. I expect a long tail for GAE support, but it is long-in-the-tooth.
ma...@gmail.com <ma...@gmail.com> #310
Google still taking our money and claiming they are working on something
that is impossible to achieve.
On Sat, Sep 3, 2022, 10:35 AM <buganizer-system@google.com> wrote:
va...@google.com <va...@google.com>
su...@google.com <su...@google.com> #312
Hello,
Thank you for your continued patience and understanding regarding this feature request.
We'd like to share again that this functionality has been added to the
However, we understand that for many users the request is for the App Engine standard environment. While this feature hasn't been implemented there yet, we are evaluating the best way to make it available. We can't offer a timeline at this point, but please know that your feedback is important to us. It helps us prioritize enhancements that matter most to our users.
Description