Re: [Webware-discuss] AjaxSuggest example busy-waits
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 --- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/webware-discuss
Re: [Webware-discuss] AjaxSuggest example busy-waits
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. --- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/webware-discuss
Re: [Webware-discuss] AjaxSuggest example busy-waits
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 --- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/webware-discuss
Re: [Webware-discuss] AjaxSuggest example busy-waits
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 --- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/webware-discuss
Re: [Webware-discuss] AjaxSuggest example busy-waits
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 --- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/webware-discuss
Re: [Webware-discuss] AjaxSuggest example busy-waits
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 --- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/webware-discuss
Re: [Webware-discuss] AjaxSuggest example busy-waits
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 --- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/webware-discuss
Re: [Webware-discuss] AjaxSuggest example busy-waits
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 --- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/webware-discuss
Re: [Webware-discuss] AjaxSuggest example busy-waits
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. --- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/webware-discuss
Re: [Webware-discuss] AjaxSuggest example busy-waits
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 --- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/webware-discuss
Re: [Webware-discuss] AjaxSuggest example busy-waits
I stand corrected. [EMAIL PROTECTED] - You are in a maze of twisty integration histories, all alike. --- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/webware-discuss
RE: [Webware-discuss] AjaxSuggest example busy-waits
sophana wrote: > Jeff With The Big Yellow Suit wrote: > >>> If someone could explain, I would be grateful... >> >> If I'm interpreting your questions and statements correctly >> then you seem to have two misunderstandings. One is about >> how HTTP requests work, and the other is about the costs >> of threading. Please forgive me if I've gotten either of these >> interpretations wrong. >> >> To correct the first misconception, here's an outline of how an HTTP >> request works. >> >> 1) Client opens a TCP connection to server. >> 2) Client sends HTTP request to server over TCP connection. 3) >> Server performs request 4) Server returns the results over _the >> same_ TCP connection. 5) TCP connection is terminated > > I know that already. > I simply didn't understand why the server was polling anything in the > first email of this thread. It is a very specific application for very > long responses (more than 5 minutes) That's not the only application; it would also be useful if the client wants *instant* notification when something has happened on the server, rather than waiting several seconds for the next polling interval. > >> >> To correct the second misconception, threads are *not* >> zero cost. They're cheap in comparison to forking, but they're >> nowhere near free. That's why non-threaded networking >> frameworks such as twisted exist. By avoiding the costs of >> threading they can achieve much higher throughputs. >> > Sorry, I will repeat myself: We are not talking about the same > threads. Python threads have NOTHING in common with the threads you > are talking about. Not true -- Python really does use actual, honest-to-goodness operating system threads. - 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/webware-discuss
Re: [Webware-discuss] AjaxSuggest example busy-waits
Jeff With The Big Yellow Suit wrote: > If someone could explain, I would be grateful... If I'm interpreting your questions and statements correctly then you seem to have two misunderstandings. One is about how HTTP requests work, and the other is about the costs of threading. Please forgive me if I've gotten either of these interpretations wrong. To correct the first misconception, here's an outline of how an HTTP request works. 1) Client opens a TCP connection to server. 2) Client sends HTTP request to server over TCP connection. 3) Server performs request 4) Server returns the results over _the same_ TCP connection. 5) TCP connection is terminated I know that already. I simply didn't understand why the server was polling anything in the first email of this thread. It is a very specific application for very long responses (more than 5 minutes) To correct the second misconception, threads are *not* zero cost. They're cheap in comparison to forking, but they're nowhere near free. That's why non-threaded networking frameworks such as twisted exist. By avoiding the costs of threading they can achieve much higher throughputs. Sorry, I will repeat myself: We are not talking about the same threads. Python threads have NOTHING in common with the threads you are talking about. --- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/webware-discuss
Re: [Webware-discuss] AjaxSuggest example busy-waits
John Dickinson wrote: I think I understand now. The client is polling the server for new data that could come up because of external events. If I understand correctly, this kind of application is useful for a certain class of websites like chat, real time data updating (like stock quotes), etc.. In majority of ajax applications, such polling might be useless isn't it? Not quite useless. The reason I originally wrote AjaxPage was for a system that can have long-running requests to the server (generating reports). In that case, I was fighting against browser/server timeouts. On our installation of Apache, the client/server connection would be broken after 5 minutes. OK!!! This is a VERY specific application. I thought the ajax page was a base class for any ajax application but it is absolutely not... Believe me that a vast majority of http or ajax request is responded immediately, and such mechanism is simply not needed. Sorry for having bothered you. --- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/webware-discuss
Re: [Webware-discuss] AjaxSuggest example busy-waits
I think I understand now. The client is polling the server for new data that could come up because of external events. If I understand correctly, this kind of application is useful for a certain class of websites like chat, real time data updating (like stock quotes), etc.. In majority of ajax applications, such polling might be useless isn't it? Not quite useless. The reason I originally wrote AjaxPage was for a system that can have long-running requests to the server (generating reports). In that case, I was fighting against browser/server timeouts. On our installation of Apache, the client/server connection would be broken after 5 minutes. I needed a way to get around this. For a long running request, AjaxPage works as follows: 1) Client requests a big report. This request is sent to ajax_request(). 2) ajax_request() calls the appropriate functions on the server. 2a) Once the server-side function has returned, the results are sent back down the pipe to the client... 2b) ...unless it took longer that TIMEOUT seconds to complete (the timeout is defaulted to 100). Since, in our example, the request _did_ take a while to finish, ajax_request() puts the results into the results bucket that ajax_response() is polling. 3) ajax_response(), which is being polled every few seconds by the client, sees that there is something for the client in the results bucket, grans it, and sends it to the cient. The results sent to the client can be anything, really, but, in my implementation, the results are eval'd on the client side as javascript. For a particular application, one may not ever need this functionality. Since the amount of time the client waits between polls of the sever is set on the server, you could just set that value to a really big number, essentially stopping the polling (see ajax_response). --John --- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/webware-discuss
Re: [Webware-discuss] AjaxSuggest example busy-waits
> If someone could explain, I would be grateful... If I'm interpreting your questions and statements correctly then you seem to have two misunderstandings. One is about how HTTP requests work, and the other is about the costs of threading. Please forgive me if I've gotten either of these interpretations wrong. To correct the first misconception, here's an outline of how an HTTP request works. 1) Client opens a TCP connection to server. 2) Client sends HTTP request to server over TCP connection. 3) Server performs request 4) Server returns the results over _the same_ TCP connection. 5) TCP connection is terminated To correct the second misconception, threads are *not* zero cost. They're cheap in comparison to forking, but they're nowhere near free. That's why non-threaded networking frameworks such as twisted exist. By avoiding the costs of threading they can achieve much higher throughputs. [EMAIL PROTECTED] - You are in a maze of twisty integration histories, all alike. --- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/webware-discuss
Re: [Webware-discuss] AjaxSuggest example busy-waits
John Dickinson wrote: In answer to your first set of questions, ajax_response() waited to see if anything would show up in the response bucket that needed to be sent to the client. Once something showed up, it was send down the pipe to the client, and the connection was closed. What kind of thing shows up? I don't see the application... The client would then reopen the connection the ajax_response to see if anything else was on the server that needed to be processed on the client side. But, that was an inefficient implementation. I would suggest that the newer implementation I posted this morning be used instead. I'm sure that it can still be improved upon, but it is better (for webware's threads) than the older implementation used in the AjaxSuggest example page. In your previous mail, you explain that the client wait for some amount of time. Wait for what? In the newer implementation, the client waits so as not to hammer the server with requests as fast as possible. If that were allowed, it would amount to the site developer willingly subjecting themselves to a DDOS. The client timeout allows the servers some time between requests. Essentially, the client wakes up every few seconds and asks the server if any new data is available. The server then responds immediately. If there was something to give to the client, then that is sent back. If there is nothing to give back to the client, nothing is send back besides the number of seconds for the client to wait until it asks the server for results again. Check out the code: wiki.w4py.org/ajax_in_webware.html. I think I understand now. The client is polling the server for new data that could come up because of external events. If I understand correctly, this kind of application is useful for a certain class of websites like chat, real time data updating (like stock quotes), etc.. In majority of ajax applications, such polling might be useless isn't it? --- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/webware-discuss
Re: [Webware-discuss] AjaxSuggest example busy-waits
But there is thread switching going on all the time. The more threads, the more switching overhead. I don't think we talk about the same threads. python is an interpreted language. There is absolutely no overhead in switching a python context. Nothing similar with a regular os thread switch. python generators iteration are an example of python contexts use at no cost. well, in my understanding the proposal was to mix the conventional threaded execution of 'regular' requests (which allows you to run each request straight through, without async-specific contortions) with async handling of ajax requests. One thread cannot at the same time run a single request straight through and at the same time hop around between additional async'ed ones. So, you would have to dedicate one or more threads exclusively to the async'ed handling of ajax requests. I'm really sorry bothering you with so many questions. I thought that the 'Async' word in AJAX, was the about the way the request is made at the client side. If I understand correctly, async means that the script does not block when waiting for the server response. At the server side, I see no difference how this request is handled, compared to any http request. In simple ajax examples on the web, the script calls a really simple php script like any other, except that it responds javascript instead of html... If someone could explain, I would be grateful... Thanks --- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/webware-discuss
Re: [Webware-discuss] AjaxSuggest example busy-waits
In answer to your first set of questions, ajax_response() waited to see if anything would show up in the response bucket that needed to be sent to the client. Once something showed up, it was send down the pipe to the client, and the connection was closed. The client would then reopen the connection the ajax_response to see if anything else was on the server that needed to be processed on the client side. But, that was an inefficient implementation. I would suggest that the newer implementation I posted this morning be used instead. I'm sure that it can still be improved upon, but it is better (for webware's threads) than the older implementation used in the AjaxSuggest example page. In your previous mail, you explain that the client wait for some amount of time. Wait for what? In the newer implementation, the client waits so as not to hammer the server with requests as fast as possible. If that were allowed, it would amount to the site developer willingly subjecting themselves to a DDOS. The client timeout allows the servers some time between requests. Essentially, the client wakes up every few seconds and asks the server if any new data is available. The server then responds immediately. If there was something to give to the client, then that is sent back. If there is nothing to give back to the client, nothing is send back besides the number of seconds for the client to wait until it asks the server for results again. Check out the code: wiki.w4py.org/ajax_in_webware.html. --John --- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/webware-discuss
Re: [Webware-discuss] AjaxSuggest example busy-waits
sophana wrote: Michael Palmer wrote: Geoffrey Talvola wrote: John Dickinson wrote: Not only that, it consumes a webware thread that could be used for other requests. Yes, this won't scale too well if you have large numbers of concurrent users. You could probably handle hundreds of users with a large thread pool though. According to some measurements I made, a pool with more than 10-20 threads will seriously affect overall performance. Are you sure of that? A python thread has nothing in common to standard threads (pthread or even light weight threads) It will use some memory, but no performance pelnalty at all. But there is thread switching going on all the time. The more threads, the more switching overhead. I haven't understood why ajax requests require a busy thread to be handled. Is it because the tcp connection is not closed between the requests? Why ajax requests are not handled like standard http requests, using a session Id to maintain the per client state (with a new tcp connection per request)? Nevow/Twisted solves this problem by using async event-driven methods instead of threads. I think Twisted's architecture is a better fit for this type of application than Webware's thread pool. I wonder if there is some way to combine the two -- use standard Webware threads for "normal" short-lived requests but have some way to handle the ajax_response-type requests without tying up threads. It would probably require reworking the ThreadedAppServer architecture significantly. Should work in principle. One problem is the lack of thread priorities in Python. If you dedicate one thread to the asynchronous requests, that thread will compete for CPU time against all others in the pool and may be quite slow. It might be necessary to use several threads to get more overall CPU time for the async requests. Why dedicating one thread only? Why aren't the event handled by the same pool of thread concurrently? well, in my understanding the proposal was to mix the conventional threaded execution of 'regular' requests (which allows you to run each request straight through, without async-specific contortions) with async handling of ajax requests. One thread cannot at the same time run a single request straight through and at the same time hop around between additional async'ed ones. So, you would have to dedicate one or more threads exclusively to the async'ed handling of ajax requests. --- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/webware-discuss -- Michael --- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/webware-discuss
Re: [Webware-discuss] AjaxSuggest example busy-waits
They are handled like standard requests. The issue is that (in my older implementation) the request would be made to the server, and the server would sit around with that request for TIMEOUT seconds. That is my question: Why waiting? Why not immediately close the connection and the thread like any http request? Is it because the javascript client does maintain the tcp connection? The problem is when you have multiple users connecting (or even several ajax-enable pages viewed in rapid succession), many of the threads from webware's thread pool are used for up to TIMEOUT seconds. Once the threads are all busy, the next user trying to connect must wait until a busy thread finishes its current task before that user's request is served. With the changes I posted to the wiki this morning, the ajax_response requests are not held up on the server side, so the limit of concurrent users goes up (a lot). The problem is not really solved, per se, but it's impact is weakened. In your previous mail, you explain that the client wait for some amount of time. Wait for what? Sorry if my questions look silly, I don't understand everything in this ajax mechanism. --- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/webware-discuss
Re: [Webware-discuss] AjaxSuggest example busy-waits
I haven't understood why ajax requests require a busy thread to be handled. Is it because the tcp connection is not closed between the requests? Why ajax requests are not handled like standard http requests, using a session Id to maintain the per client state (with a new tcp connection per request)? They are handled like standard requests. The issue is that (in my older implementation) the request would be made to the server, and the server would sit around with that request for TIMEOUT seconds. The problem is when you have multiple users connecting (or even several ajax-enable pages viewed in rapid succession), many of the threads from webware's thread pool are used for up to TIMEOUT seconds. Once the threads are all busy, the next user trying to connect must wait until a busy thread finishes its current task before that user's request is served. With the changes I posted to the wiki this morning, the ajax_response requests are not held up on the server side, so the limit of concurrent users goes up (a lot). The problem is not really solved, per se, but it's impact is weakened. --John --- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/webware-discuss
Re: [Webware-discuss] AjaxSuggest example busy-waits
Michael Palmer wrote: Geoffrey Talvola wrote: John Dickinson wrote: Not only that, it consumes a webware thread that could be used for other requests. Yes, this won't scale too well if you have large numbers of concurrent users. You could probably handle hundreds of users with a large thread pool though. According to some measurements I made, a pool with more than 10-20 threads will seriously affect overall performance. Are you sure of that? A python thread has nothing in common to standard threads (pthread or even light weight threads) It will use some memory, but no performance pelnalty at all. I haven't understood why ajax requests require a busy thread to be handled. Is it because the tcp connection is not closed between the requests? Why ajax requests are not handled like standard http requests, using a session Id to maintain the per client state (with a new tcp connection per request)? Nevow/Twisted solves this problem by using async event-driven methods instead of threads. I think Twisted's architecture is a better fit for this type of application than Webware's thread pool. I wonder if there is some way to combine the two -- use standard Webware threads for "normal" short-lived requests but have some way to handle the ajax_response-type requests without tying up threads. It would probably require reworking the ThreadedAppServer architecture significantly. Should work in principle. One problem is the lack of thread priorities in Python. If you dedicate one thread to the asynchronous requests, that thread will compete for CPU time against all others in the pool and may be quite slow. It might be necessary to use several threads to get more overall CPU time for the async requests. Why dedicating one thread only? Why aren't the event handled by the same pool of thread concurrently? --- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/webware-discuss
Re: [Webware-discuss] AjaxSuggest example busy-waits
Geoffrey Talvola wrote: John Dickinson wrote: Not only that, it consumes a webware thread that could be used for other requests. Yes, this won't scale too well if you have large numbers of concurrent users. You could probably handle hundreds of users with a large thread pool though. According to some measurements I made, a pool with more than 10-20 threads will seriously affect overall performance. Nevow/Twisted solves this problem by using async event-driven methods instead of threads. I think Twisted's architecture is a better fit for this type of application than Webware's thread pool. I wonder if there is some way to combine the two -- use standard Webware threads for "normal" short-lived requests but have some way to handle the ajax_response-type requests without tying up threads. It would probably require reworking the ThreadedAppServer architecture significantly. Should work in principle. One problem is the lack of thread priorities in Python. If you dedicate one thread to the asynchronous requests, that thread will compete for CPU time against all others in the pool and may be quite slow. It might be necessary to use several threads to get more overall CPU time for the async requests. Michael --- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/webware-discuss
RE: [Webware-discuss] AjaxSuggest example busy-waits
John Dickinson wrote: > Not only that, it consumes a webware thread that could be used for > other requests. Yes, this won't scale too well if you have large numbers of concurrent users. You could probably handle hundreds of users with a large thread pool though. Nevow/Twisted solves this problem by using async event-driven methods instead of threads. I think Twisted's architecture is a better fit for this type of application than Webware's thread pool. I wonder if there is some way to combine the two -- use standard Webware threads for "normal" short-lived requests but have some way to handle the ajax_response-type requests without tying up threads. It would probably require reworking the ThreadedAppServer architecture significantly. > > 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. I can see 2 gotchas with this method though. First, you introduce several seconds of latency between the time the server wants to send information to the client and the time the client receives the information; that may be unacceptable depending on the application. Second, this actually increases the amount of traffic between client and server because of the polling every few seconds. - 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/webware-discuss
Re: [Webware-discuss] AjaxSuggest example busy-waits
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@lists.sourceforge.net 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@lists.sourceforge.net 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. __ --- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/webware-discuss
Re: [Webware-discuss] AjaxSuggest example busy-waits
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@lists.sourceforge.net 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/webware-discuss
