|
Graham Dumpleton
grahamd at dscpl.com.au
Fri Oct 6 19:18:13 EDT 2006
On 07/10/2006, at 2:46 AM, Andreas Klauer wrote: > On Fri, Oct 06, 2006 at 12:14:43PM -0400, Jorey Bump wrote: >> I think the problem is outside of apache/mod_python. Similar work has >> been done to develop IMAP proxies to reduce load caused by webmail >> opening a new connection to the IMAP server for every click. You >> might >> want to start there for examples. > > That's just it. There would be no need for an additional daemon, if I > could just select the correct thread. A mod_python script by itself > holds up a telnet connection just fine. No additional work would be > required in my situation if it were not for threads (or lack of thread > control for that matter). > > Instead of opening a telnet connection in a mod_python script > directly, > I now have to use an independent daemon, with additional > connections to > every mod_python thread, and I also have to encapsulate each query > into > a separate protocol. If that does not add unnecessary load, I don't > know what does. > > But I guess for that I'd have to talk to the Apache folks wether it is > not possible to give modules (and therefore users) more control over > what is done in which threads. Personally I think you are possibly working under some misconceptions about how Apache/mod_python works. You keep mentioning 'threads' as a problem, but frankly I cannot see how that is really relevant at all. Before I try and address that I would ask why you are trying to perhaps reinvent the wheel as others have already solved this problem. In the webmin interface for remotely managing systems, there is a standard SSH/Telnet Login module that uses a Java applet. There are also other third party implementations as well. Some sites to start tracking this stuff down are: http://www.webmin.com/ustandard.html http://webadminmodules.sourceforge.net/?page=Others Back to your threads. The problem with using Apache/mod_python when you want to preserve some state between requests is not threads but processes. This is because when using prefork or worker Apache MPMs on UNIX systems, subsequent requests can be directed to different Apache child processes. As a result, if one child process had initiated a telnet connection, when a subsequent request arrives and it ends up being processed by a different child process, it will not have access to the open connection. On Win32 boxes this isn't a problem, as there is only one Apache process and all requests are handled by it. For further information, see: http://www.dscpl.com.au/wiki/ModPython/Articles/ TheProcessInterpreterModel As far as threads go, on Win32, and when worker MPM is used on UNIX, when subsequent requests arrive, they may indeed be handled by different threads within that process, but that shouldn't matter, unless you have made the mistake of storing state information as thread local data within that thread such that only that thread can access it. If the data is stored globally, is thread protected and keyed by some user session credentials then it shouldn't be an issue as it wouldn't matter which actual thread handled a request, as all could still access it. If you do this correctly, then it would be possible to do what you want on a Win32 system, as the same Apache process is always used. On prefork and even worker MPMs on UNIX though you can't, as you can't ensure the same process always gets the requests. Also, even if there were some way, Apache is allowed to shutdown specific child processes at any time, so you would loose any open connection anyway. If you want to pursue this direction of implementing it yourself, you have no choice but to stick the bits which create the telnet connection in a separate long running daemon process. Communication between the Apache child processes and the separate daemon could use XML-RPC albeit perhaps inefficiently, a persistently connected messaging system, or a custom protocol over a socket connection. Writing that daemon isn't necessarily going to be straight forward, as making it secure may be an issue, plus you need to track user sessions, possibly implement inactivity timers to cleanup sessions if not used etc etc. Thus, overall, I would really suggest you pursue some of the Java applet solutions that exist instead that people have already written. Graham
|