-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I found a bug in my lighty implementation, and I don't want to pollute this list with more versions of the patch, so just uncomment "out->is_closed = 1;" in mod_proxy_backend_tora.c line 560 after applying the patch and recompile.
Nicolas, what about the tora server patch I've provided earlier ? will you apply it to CVS or do you think about a better solution ? For the lighttpd patch, It might be better to distribute it in an advanced topic page on the haxe website for the moment ? thanks kaalh KaalH! a écrit : > I've made some cleaning & fixes, updated patches attached. > > kaalh > > KaalH! a écrit : >> Nicolas Cannasse a écrit : >>>>> I'm not sure I'm following your here. >>>>> >>>>> Why exactly mod_tora for lighty or nginx cannot connect directly to >>>>> the tora host and use the protocol as mod_tora for Apache is doing ? >>>>> >>>> I maybe have a wrong vision of tora. >>>> >>>> You may have think mod_tora "only" as a http server plugin to solve >>>> some memory comsumption issues. >>>> >>>> But for me, programmer and sysadmin (can't choose only one, both are >>>> madly enjoying ), tora must be a scalable way to deploy neko >>>> application in web farms, so the lighttpd/nginx/... implementation >>>> should be able to connect to several tora instances, load balance and >>>> failover between them, like it's done with fastcgi on lighttpd and nginx. >>> I can understand that, but IMHO that's just a matter of configuration. >>> Once the tora server is selected (depending on balancing and failover), >>> you should be able to use tora protocol. >>> Or am I missing something else ? >> I don't think so :) > >>>> The proxy paradigm make difficult to implement the tora multipart >>>> content scheme, be able to pass raw data to tora without have to wait >>>> for the CGetMultipart code would be a lot easier to implement in >>>> lighttpd, and seems to be required for nginx ( >>>> http://marc.info/?l=nginx&m=121425082522327&w=2 ) >>> Yes, this is similar to what mod_tora is doing, for similar reasons I >>> guess, which are the necessity to stream multipart/POST data only when >>> requested to do so. >>> I'm not sure however what exactly a nginx/lighty "proxy" (between?) is >>> doing here so you might have to explain it to me first :) >> - lighttpd core read the incoming data to a buffers chain (chunkqueue). >> - this "in" chunkqueue is converted by the tora proxy backend to another >> chunkqueue. >> - data is sent from this chunkqueue to the tora server. >> - lighttpd read the response from tora and pass it to the tora backend >> thru another chunckqueue. >> - the backend convert the data from tora to http to another chunkqueue >> - the lighttpd core send the response to the client > >> I haven't played yet with nignx, but It seems to be the same, except >> that nginx does not wait for any state completion, chains of small >> buffers are piped along handler/filters/upstream(aka proxy) modules, so >> you could start to send the response to the client while still reading >> incoming data, looks amazing. > >>> It might be possible to modify the tora protocol to let the server parse >>> and send the multipart data without waiting for the CGetMultipart : this >>> should not actually interfere with the client since it's not expecting >>> anything else from the server. >> Thanks, I was on the wrong way :) > >> My lighttpd implementation is now a lot more efficient as it do no >> longer need to do tricky things in the proxy layer, I'm still in >> testing, I plan to use it in production environment in approx one month. >> The only missing feature is data flush, but I don't know yet if it's >> possible with lighttpd. > >> You need to path the tora server with the attached "tora.diff". >> With CBoundary/CMultipartData/CMultipartDone, multipart data is saved by >> tora in a temporary directory ( TMPDIR environment variable, default set >> to "/tmp" ), and only decoded while calling parse_multipart_data. > >> lighttpd patching instructions are the same as previous, updated patch >> attached. > >> kaalh > >>> Nicolas > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJAG2kWRw620CDc80RAqM5AJ9Q3OAkdT6yJbv9hBlrOhOfzT6mRACfanSu GhPfhVTY40GLbB6XiPaezIc= =RLp/ -----END PGP SIGNATURE----- -- Neko : One VM to run them all (http://nekovm.org)
