« Return to Thread: implementing long poll in grails
Re: implementing long poll in grails
by Robert Fischer
::
Rate this Message:
Have you done any kind of proof-of-concept on this? I'm pretty sure this is premature optimization
at its worst, and this kind of approach will kill your web server. They're really, *really* not
designed for that kind of usage. Cluttering the server with requests is much more what they're used
to, and can actually fairly efficient given HTTP 1.1 caching[1] and connection optimizations[2].
Some of those connection optimizations actually take care of common performance concerns—for
instance, it's unlikely a user will be re-opening new TCP/IP connections for each request.
You probably want to look into different ways of doing this, Jabber/XMPP being the most popular (and
there's both a Jabber and XMPP plugin in Grails). Doing long polling via PeriodicUpdater (either
the built-in Prototype version or my jQuery version[3]) is also a good way to go. It's got built in
decay for users who don't see changes often.
Don't fight HTTP's nature: work with it. If you really don't want to, create a Java or Flash rich
client that can form a persistence connection back to some other port over raw TCP/IP.
[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html
[2] http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html
[3] http://enfranchisedmind.com/blog/posts/jquery-periodicalupdater-ajax-polling/
~~ Robert.
redheat wrote:
> Yes, Robert, exactly.
>
> My understanding of what Dave posted is that he is also trying to achieve
> that, see for example the part localPoll: while (counter < 10){
> if (changed){
> //render a response to say something has changed
> break localPoll
> }else{
> Thread.currentThread.sleep(5000)
> counter+=1
> }
>
> I'm doing similar things but with plain while and return, not
> localPoll:while and break.
>
> The idea is not to have the client ask for news all the time, cluttering the
> server with requests. Instead, the client opens an Ajax request, lets it sit
> there waiting, and the server loops checking for new database items and
> re-renders the list view to the response if new items are found in my case.
> The client side Javascript, after receiving the response, updates the DOM
> element with the list and re-issues the request for updates.
> This kind of approach is referred to often as Ajax long polling, or reverse
> Ajax, a variant of Comet style Ajax.
>
> I used a controller and not a service for that because, with services you
> would first need to expose them somehow and you have all sorts of
> limitations if you want to access scopes like session from a service which I
> couldn't solve.
>
>
> Robert Fischer wrote:
>> Why is your controller in a loop? Are you trying for some kind of
>> server-push implementation?
>>
>> ~~ Robert.
>>
>>
>>
>
--
~~ Robert Fischer, Smokejumper IT Consulting.
Enfranchised Mind Blog http://EnfranchisedMind.com/blog
Check out my book, "Grails Persistence with GORM and GSQL"!
http://www.smokejumperit.com/redirect.html
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
at its worst, and this kind of approach will kill your web server. They're really, *really* not
designed for that kind of usage. Cluttering the server with requests is much more what they're used
to, and can actually fairly efficient given HTTP 1.1 caching[1] and connection optimizations[2].
Some of those connection optimizations actually take care of common performance concerns—for
instance, it's unlikely a user will be re-opening new TCP/IP connections for each request.
You probably want to look into different ways of doing this, Jabber/XMPP being the most popular (and
there's both a Jabber and XMPP plugin in Grails). Doing long polling via PeriodicUpdater (either
the built-in Prototype version or my jQuery version[3]) is also a good way to go. It's got built in
decay for users who don't see changes often.
Don't fight HTTP's nature: work with it. If you really don't want to, create a Java or Flash rich
client that can form a persistence connection back to some other port over raw TCP/IP.
[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html
[2] http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html
[3] http://enfranchisedmind.com/blog/posts/jquery-periodicalupdater-ajax-polling/
~~ Robert.
redheat wrote:
> Yes, Robert, exactly.
>
> My understanding of what Dave posted is that he is also trying to achieve
> that, see for example the part localPoll: while (counter < 10){
> if (changed){
> //render a response to say something has changed
> break localPoll
> }else{
> Thread.currentThread.sleep(5000)
> counter+=1
> }
>
> I'm doing similar things but with plain while and return, not
> localPoll:while and break.
>
> The idea is not to have the client ask for news all the time, cluttering the
> server with requests. Instead, the client opens an Ajax request, lets it sit
> there waiting, and the server loops checking for new database items and
> re-renders the list view to the response if new items are found in my case.
> The client side Javascript, after receiving the response, updates the DOM
> element with the list and re-issues the request for updates.
> This kind of approach is referred to often as Ajax long polling, or reverse
> Ajax, a variant of Comet style Ajax.
>
> I used a controller and not a service for that because, with services you
> would first need to expose them somehow and you have all sorts of
> limitations if you want to access scopes like session from a service which I
> couldn't solve.
>
>
> Robert Fischer wrote:
>> Why is your controller in a loop? Are you trying for some kind of
>> server-push implementation?
>>
>> ~~ Robert.
>>
>>
>>
>
--
~~ Robert Fischer, Smokejumper IT Consulting.
Enfranchised Mind Blog http://EnfranchisedMind.com/blog
Check out my book, "Grails Persistence with GORM and GSQL"!
http://www.smokejumperit.com/redirect.html
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
« Return to Thread: implementing long poll in grails
| Free embeddable forum powered by Nabble | Forum Help |
