Browse thread
CamlGI question
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | Michael Alexander Hamburg <hamburg@f...> |
| Subject: | Re: [Caml-list] CamlGI question |
On Tue, 19 Apr 2005, Christophe TROESTLER wrote: > On Mon, 18 Apr 2005, Mike Hamburg <hamburg@fas.harvard.edu> wrote: > > > > http://capricorn.dnsalias.org/mike/index/ > > I downloaded your files. For a start, all the modules are -pack'ed > into camlGI.cm[x]a, so you only need to link with that file. Also, > the interface of the library is in camlGI.mli with complete > documentation. In particular, you should not use hidden submodules: > e.g. in "path.ml", say [open CamlGI] and then [Cgi.HttpError] instead > of [Cgi_types.HttpError]. Same in "index.ml": you should say [open > CamlGI.Cgi], not [open Cgi]. > > [Request.metavar rq.rq "SERVER_NAME"] can simply be replaced with > [Request.server_name rq.rq] > > [cgi#header_was_emitted ()]: such method does not exist in the public > interface. It doesn't exist at all. I added it because I was getting mysterious type errors from OCaml when trying to compile directly. It was on my "things to clean up" list. > I do not see why you set [rq=request] as the request can be gotten > from the cgi object [cgi#request]. You're right, I missed that. > > When used as a FastCGI, the indexing script hangs, [...] It is quite > > clear that the script has finished by the time the hang occurs > > Do the examples provided with the lib work as they should? I'll check that too (I'm not at home right now). > Are you sure your [main] function actually terminates? Indeed, the > output is buffered (at least by CamlGI) and may not be fully outputted > until the script finishes. Also, if you wish to launch a new > process/thread per request, be sure to use the [fork] optional > parameter to [handle_requests ?fork f conn] -- otherwise [f] will > return immediately and the output "channel" will be closed early. My main function does actually terminate. I put a logging message at the end of the function. And it's not just buffering output, as killing the CGI script with signal 9 causes no truncation. I'll set it to create a new thread to handle the request, although that doesn't particularly matter (the threading is necessary to keep the thumbnail cache running, not for load issues). > CamlGI follows closely the spec -- even the multiplexing part which is > not implemented by many. > > > The plain CGI version works just fine > > CGI output is not buffered. > > > the features of the script only work in the FastCGI version, such as > > thumbnailing. > > Why is that? Do you need persistence for that? I can do it without persistence, but synchronization is much more difficult in that case, eg, preventing to processes from trying to thumbnail the same files at the asme time. > Hope it helps. If it does not, send me an example (if possible > minimal but definitely self-contained) that exhibits the undesired > behavior and I'll have a look. I'll work on it soon and figure out whether this helps or not. Hopefully it will. > ChriS > Thanks a lot for your help, Mike