Webware for Python

Not only that, it consumes a webware thread that could be used for other 
requests.

All in all, that implementation was flawed.

I've got a new implementation that solves both of these problems, but I 
can't seen to get in to the wiki to post it. The basic idea, though, is 
to move the work from the server to the client. The client, running the 
javascript, will wait for some amount of time and then call 
ajax_response() on the server. The server will see if anything is 
available for that client. If not, ajax_response() can return 
immediately and wait for the next connection from a client. To avoid any 
synchronization of client connections to the server, the wait period on 
the client side is not constant (random between 3 and 8 seconds). Also, 
the server can send back what the timeout should be until the next 
connection. This will allow the server control how often the client 
connects (maybe depending on the page the user is looking at).

In the short term, by adding a time.sleep(2) to the current 
implementation of ajax_response(), you can avoid all CPU cycles being 
consumed.

--John

Geoffrey Talvola wrote:
> I just tried out the AjaxSuggest example servlet that was added to
> Subversion last month.  It works, but unfortunately it seems to gobble up
> 100% of the CPU.
>
> It looks to me like the problem is in the ajax_response method of AjaxPage.
> It uses an inefficient polling loop; instead, it needs to use a
> threading.Event or Queue or something along those lines that it can
> efficiently wait on.
>
> - Geoff
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Webware-discuss mailing list
> Webware-discuss@...
> https://lists.sourceforge.net/lists/listinfo/webware-discuss
>
> ______________________________________________________________________
> This e-mail has been scanned by MCI Managed Email Content Service, using Skeptic(tm) technology powered by MessageLabs. For more information on MCI's Managed Email Content Service, visit http://www.mci.com.
> ______________________________________________________________________
>
>
>

and, of course, as soon as I sent my message, I could get in to the wiki 
and update it.

wiki.w4py.org/ajax_in_webware.html
wiki.w4py.org/ajaxpage.html
wiki.w4py.org/ajaxjavascript.html

--John

John Dickinson wrote:
> Not only that, it consumes a webware thread that could be used for 
> other requests.
>
> All in all, that implementation was flawed.
>
> I've got a new implementation that solves both of these problems, but 
> I can't seen to get in to the wiki to post it. The basic idea, though, 
> is to move the work from the server to the client. The client, running 
> the javascript, will wait for some amount of time and then call 
> ajax_response() on the server. The server will see if anything is 
> available for that client. If not, ajax_response() can return 
> immediately and wait for the next connection from a client. To avoid 
> any synchronization of client connections to the server, the wait 
> period on the client side is not constant (random between 3 and 8 
> seconds). Also, the server can send back what the timeout should be 
> until the next connection. This will allow the server control how 
> often the client connects (maybe depending on the page the user is 
> looking at).
>
> In the short term, by adding a time.sleep(2) to the current 
> implementation of ajax_response(), you can avoid all CPU cycles being 
> consumed.
>
> --John
>
> Geoffrey Talvola wrote:
>> I just tried out the AjaxSuggest example servlet that was added to
>> Subversion last month.  It works, but unfortunately it seems to 
>> gobble up
>> 100% of the CPU.
>>
>> It looks to me like the problem is in the ajax_response method of 
>> AjaxPage.
>> It uses an inefficient polling loop; instead, it needs to use a
>> threading.Event or Queue or something along those lines that it can
>> efficiently wait on.
>>
>> - Geoff
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by xPML, a groundbreaking scripting 
>> language
>> that extends applications into web and mobile media. Attend the live 
>> webcast
>> and join the prime developer group breaking into this new coding 
>> territory!
>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
>> _______________________________________________
>> Webware-discuss mailing list
>> Webware-discuss@...
>> https://lists.sourceforge.net/lists/listinfo/webware-discuss
>>
>> ______________________________________________________________________
>> This e-mail has been scanned by MCI Managed Email Content Service, 
>> using Skeptic(tm) technology powered by MessageLabs. For more 
>> information on MCI's Managed Email Content Service, visit 
>> http://www.mci.com.
>> ______________________________________________________________________
>>
>>
>>   
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting 
> language
> that extends applications into web and mobile media. Attend the live 
> webcast
> and join the prime developer group breaking into this new coding 
> territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Webware-discuss mailing list
> Webware-discuss@...
> https://lists.sourceforge.net/lists/listinfo/webware-discuss
>
> ______________________________________________________________________
> This e-mail has been scanned by MCI Managed Email Content Service, 
> using Skeptic(tm) technology powered by MessageLabs. For more 
> information on MCI's Managed Email  Content Service, visit 
> http://www.mci.com.
> ______________________________________________________________________
>
> ______________________________________________________________________
> This e-mail has been scanned by MCI Managed Email Content Service, 
> using Skeptic(tm) technology powered by MessageLabs. For more 
> information on MCI's Managed Email Content Service, visit 
> http://www.mci.com.
> ______________________________________________________________________
>
>

John Dickinson wrote:
> I've got a new implementation that solves both of these problems, but I 
> can't seen to get in to the wiki to post it.

Thanks a lot. I have already checked it in to the SVN repository.

BTW, I have restarted the Wiki and let it use the current Webware 0.9. 
Should be better now.

Your new implementation of ajax_response() looks good to me.

However, I'm actually wondering whether you really always need to run 
this background polling. If requests are always answered within the 
timeout interval (which is set to 100 seconds), that mechanism should be 
never needed. For instance, in the "AjaxSuggest" example, it will be 
surely not needed. You will only need it if you have long-running 
queries or computations where getting the result is crucial. So I was 
wondering whether AjaxPage should provide a parameter that allows 
disabling and enabling the polling mechanism. In the AjaxSuggest 
example, I would like to disable it from the beginning.

-- Christoph

> However, I'm actually wondering whether you really always need to run 
> this background polling. If requests are always answered within the 
> timeout interval (which is set to 100 seconds), that mechanism should 
> be never needed. For instance, in the "AjaxSuggest" example, it will 
> be surely not needed. You will only need it if you have long-running 
> queries or computations where getting the result is crucial. So I was 
> wondering whether AjaxPage should provide a parameter that allows 
> disabling and enabling the polling mechanism. In the AjaxSuggest 
> example, I would like to disable it from the beginning.

I agree with you that webware is not designed for doing this kind of stuff.
If you want to do long running queries, I suggest that you bypass apache 
and webware, and implement a separate dedicated (python) server that 
supports these very long running queries, without the timeout problem, 
without polling.

> However, I'm actually wondering whether you really always need to run 
> this background polling. If requests are always answered within the 
> timeout interval (which is set to 100 seconds), that mechanism should 
> be never needed. For instance, in the "AjaxSuggest" example, it will 
> be surely not needed. You will only need it if you have long-running 
> queries or computations where getting the result is crucial. So I was 
> wondering whether AjaxPage should provide a parameter that allows 
> disabling and enabling the polling mechanism. In the AjaxSuggest 
> example, I would like to disable it from the beginning.

Instead of turning the polling off, would setting the client polling 
interval to some big number be good enough? I added an 
ajax_clientPollingInterval to AjaxPage so that a child page can easily 
set the polling interval (long if it doesn't need it, short if it does).

Also I added an auto_connect flag to the javascript that will prevent 
the client from connecting to ajax_response on the server at all. It 
could be set to false for a site that would never need the ajax_response 
mechanism.

There are two uses I can see for ajax_response. One is for long running 
requests (in my case, generating reports). The other is sending 
javascript commands to the client without the client first triggering an 
event (perhaps a chat application). The servlet can use ajax_cmdToClient 
for this second use.

--John

sophana wrote:
> I agree with you that webware is not designed for doing this kind of stuff.
> If you want to do long running queries, I suggest that you bypass apache 
> and webware, and implement a separate dedicated (python) server that 
> supports these very long running queries, without the timeout problem, 
> without polling.

Anyway, you need to somehow inform the client that your result is ready. 
For VERY long running queries, you can expect the client to look at a 
certain result page. But John's solution is nice in that it informs the 
client automatically when the server is ready, even if it takes longer 
than the usual timeout of 90 seconds.

However, this is really not the normal use case, therefore I have made 
the polling part now optional. The timeout for long-running queries is 
now an attribute of the AjaxPage class that can be overridden by servlet 
instances. If it is set to 0, not polling takes place. I have also split 
up the Javascript file in two parts, separating the functions used for 
polling. If timeout is set to 0, the second part is not loaded. The 
AjaxSuggest example works now with a timeout of 0, i.e. without any 
polling. It is already checked in to the SVN repository.

-- Christoph

John Dickinson wrote:
> Instead of turning the polling off, would setting the client polling 
> interval to some big number be good enough? I added an 
> ajax_clientPollingInterval to AjaxPage so that a child page can easily 
> set the polling interval (long if it doesn't need it, short if it does).

Sorry, I should have waited for your response before doing it on my own. 
That looks good. However, I really would like to be able to switch off 
the polling completely. This spares loading and running the Javascript 
for the polling mechanism, and the shutdown, with all possible 
Javascript errors.

> Also I added an auto_connect flag to the javascript that will prevent 
> the client from connecting to ajax_response on the server at all. It 
> could be set to false for a site that would never need the ajax_response 
> mechanism.

But it is not so easy to set it to false from the Webware servlet (you 
have to make two versions of the Javascript file).

> There are two uses I can see for ajax_response. One is for long running 
> requests (in my case, generating reports). The other is sending 
> javascript commands to the client without the client first triggering an 
> event (perhaps a chat application). The servlet can use ajax_cmdToClient 
> for this second use.

Ok, I see. In the latter case, I would probably want to set the 
ajax_clientPollingInterval lower than in the former case, and make it 
less random. So I will implement the ajax_clientPollingInterval in a 
similar way. I will also add more comments and docstrings to the 
AjaxPage class in the Example context.

By the way, I just saw the ajax_cmdToClient() method still uses the 
remote address instead of the session identifier.

-- Christoph

> Sorry, I should have waited for your response before doing it on my 
> own. That looks good. However, I really would like to be able to 
> switch off the polling completely. This spares loading and running the 
> Javascript for the polling mechanism, and the shutdown, with all 
> possible Javascript errors.
I like the idea of splitting the javascript up rather than a global flag.
>> There are two uses I can see for ajax_response. One is for long 
>> running requests (in my case, generating reports). The other is 
>> sending javascript commands to the client without the client first 
>> triggering an event (perhaps a chat application). The servlet can use 
>> ajax_cmdToClient for this second use.
>
> Ok, I see. In the latter case, I would probably want to set the 
> ajax_clientPollingInterval lower than in the former case, and make it 
> less random. So I will implement the ajax_clientPollingInterval in a 
> similar way. I will also add more comments and docstrings to the 
> AjaxPage class in the Example context.
Right. It still needs a little randomness, though. You don't want to get 
in a situation where somehow the clients become synchronized and make 
all of their polling requests at the same time. A little randomness will 
avoid that.
>
> By the way, I just saw the ajax_cmdToClient() method still uses the 
> remote address instead of the session identifier.
oops. fixed in the wiki.

--John

I have now incorporated your ajax_clientPollingInterval() to AjaxPage as 
well and separated the responseTimeout parameter from the clientPolling 
flag. Adding some more docstrings and splitting the Javascript in two 
parts now makes the whole thing much better understandable.

-- Christoph

I have also updated the wiki with similar changes (splitting the 
javascript, allowing polling to be disabled and stopped once it is 
going). It's probably slightly different than your changes in svn, so we 
should probably figure out which is better suited to the necessary tasks 
and go with that one.

--John

I am still not convinced that polling is a good solution for long queries.
One good reason for this is that you can't implement real time 
application anymore: a chat board, real time stock quotes, etc...

Isn't it better to store the tcp socket file handles left open in a 
connection pool?
As soon as a new event is to be sent, the tcp connection is retrieved 
from the pool, then simply written.
If apache limit connection time, isn't it simpler to use another port 
and let the javascript contact directly the webware application server 
bypassing apache?
I don't know how many tcp connections can a single linux server can 
handle, probably tens of thousand?
Maybe a persistant connection handler could be implemented in webware?

> Anyway, you need to somehow inform the client that your result is 
> ready. For VERY long running queries, you can expect the client to 
> look at a certain result page. But John's solution is nice in that it 
> informs the client automatically when the server is ready, even if it 
> takes longer than the usual timeout of 90 seconds.

John Dickinson wrote:
> I have also updated the wiki with similar changes (splitting the 
> javascript, allowing polling to be disabled and stopped once it is 
> going). It's probably slightly different than your changes in svn, so we 
> should probably figure out which is better suited to the necessary tasks 
> and go with that one.

I have added your code for telling the client to stop polling once it is 
going and they are essentially the same now. If you think anything else 
should be changed in the SVN version, let me know.

-- Christoph