smaldini/grailsTodos

Gateway Time-out

deerow opened this issue · 5 comments

Stephane,
This is a very cool app. I need this type of functionality in my Grails app and I am planing to use this app as a model for my implementation.

However, while studying this app, I opened up two browsers ( ie9 and chrome19) to test/demo. I left these open while I researched the parts of the app. After some time I returned to the browsers and they did not update when changes were made. I looked at the javascript console in chrome and it has several errors of:

Failed to load resource: the server responded with a status of 504 (Gateway Time-out)

followed by :

Failed to load resource: the server responded with a status of 403 (Forbidden)

Is there a configuration option that will keep the browser connection alive?

Thanks,
Mark
p.s. Is there another site for general discussions about these features?

hey Mark,

thank you for your kind message :) For ie9/chrome19, I advise you to change this line https://github.com/smaldini/grailsTodos/blob/master/grails-app/views/todos/index.gsp#L13 to

window.grailsEvents = new grails.Events('${createLink(uri: '')}');

it will automatically use websocket if available (grails 2.0.4 uses tomcat 7.0.27 which is websocket compliant) and failbacks to forever connection akka streaming mode if doesn't work.

Currently this sample is deployed to cloudfoundry which doesn't support both of the mentioned protocols, thus I used long-polling. Apparently Cloudfoundry forces a timeout through the front nginx hence why you receive a 504 time out. I normally try to intercept that to relaunch the connection but it seems you get a 403 (can you provide the headers params for this failed request, using webdeveloper for instance?).

You can discuss the features on grails mailing list :)

Best regards.

Stephane,
I haven't been able to reproduce the 403 error to get you the header params. However, the app eventually stops broadcasting changes to the todo list if the browsers are allowed to sit for a while (not sure exactly how long "a while" is). It seems that "poll" is not showing as activity and the session is expiring.

I am currently using cloudfoundry for my demo site, so getting this to work there will be good for me, too.

Mark

Stephane,
ie9 and FireFox both remain responsive (they both receive broadcasts, even those sent from chrome19). Chrome19 doesn't get the broadcasts after a while and even after sending changes.

Mark

Stephane,
Sorry about the multiple comments of incomplete information.

It appears that on Chrome19, it doesn't get broadcasts even thou it continues to poll every 30 sec. When I check off a ToDo, an event is sent, but the polling stops! Below is the are the headers of the event sent by checking off a ToDo:

Request URL:http://grailstodos.cloudfoundry.com/todos/415
Request Method:PUT
Status Code:200 OK
Request Headersview source
Accept:application/json, text/javascript, /; q=0.01
Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-US,en;q=0.8
Connection:keep-alive
Content-Length:87
Content-Type:application/json
Cookie:__qca=P0-882575462-1315360795160; s_nr=1337120471144; __utma=207604417.1006737476.1329839006.1337120464.1337365644.7; __utmz=207604417.1334339438.2.2.utmcsr=google|utmccn=(organic)|utmcmd=organic|utmctr=cloud%20foundry%20pricing
Host:grailstodos.cloudfoundry.com
Origin:http://grailstodos.cloudfoundry.com
Referer:http://grailstodos.cloudfoundry.com/todos
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.52 Safari/536.5
X-Requested-With:XMLHttpRequest
Request Payload
{"content":"wait for timeout","done":true,"class":"todosample.Todo","id":415,"order":1}
Response Headersview source
Connection:keep-alive
Content-Type:application/json;charset=UTF-8
Date:Wed, 06 Jun 2012 04:15:37 GMT
Keep-Alive:timeout=20
Server:nginx
Transfer-Encoding:chunked

Fixed