Hi Igor, yes, I have rewritten the entire encoder, decoder and message classes based on the spec but there is nothing left of the old devkit. Messages, Requests and Responses just are simple classes with all the available attributes but without any procotol specific functionallity - all the complex stuff is done when encoding / decoding. This includes populating messages and/or assembling requests/responses, splitting up too huge messages, dealing with paddings etc.
Dealing with low level FCGIMessages is as easy as using FCGIRequests / FCGIResponses just with some additional code e.g. because a "GET" Request constists of a PARAMS and an empty STDIN message. I'll add an example soon. By now also different roles (Responder, Authorizer, Filter) are supported on the FCGIMessage side. Also profiling looks fine so far but I think I'm just not familar enough yet with mina to fix some concurrency problems (tested asyncweb+fastcgi against apache bench) because sometimes there is strange behaviour and exceptions thrown e.g. by IoBuffer.limit when running concurrently (e.g. ab -n 1000 -c 20). Hope someone can tell me what's going wrong later if I don't find a fix. regards Daniel On Mon, Apr 14, 2008 at 4:56 PM, Igor Clark <[EMAIL PROTECTED]> wrote: > Hi Daniel, > > This sounds great. My interest in FastCGI and Mina is to implement a sort > of application-server "layer" with which one can quickly develop very > domain-specific server components (e.g. image generator, feed aggregator, > etc) without needing to use a big fat J2EE back-end or a PHP > everything-but-the-kitchen-sink application server/scripting engine. > > I'm really interested to see more of what you've done, if that would be > possible. I took a very similar approach with a FCGICodecFactory / > RequestDecoder / ResponseEncoder pattern, and I just glued in the existing > OpenMarket Java code to return my custom FCGIRequest & FCGIResponse classes. > I found the classes to need quite a lot of reworking, particularly with > respect to things like the FCGIMessage silently modifying public members of > other classes, and haven't had time to take things further. Did you end up > rolling your own versions of these classes? > > How practical do you think it would be to implement the 'low-level' > version (using FCGIMessages) at the RequestEncoder / RequestDecoder / > CodecFactory level? > > Thanks for the response! > > Cheers, > Igor > > > On 14 Apr 2008, at 10:27, Daniel Wirtz wrote: > > Hello Igor, > > > > I didn't implement multiplexed connections directly on the FCGIRequest / > > FCGIResponse level. Found several discussions about this and none of > > them > > stated that multiplexing would be such a great deal. In fact at the > > beginning I played around with it using PHP as a backend and as far as I > > can tell even PHP has no multiplexing support at all. As a result of > > this I > > added multiple connection support to FCGIClients, so that multiple > > requests > > can be send and the responses received with a single client instance. > > > > However multiplexing is generally possible by implementing your own > > IoHandler for catching and sending FCGIMessages instead of higher level > > FCGIRequests / FCGIResponses. The encoder accepts all three types and > > the > > FCGICodecFactiry can be instanciated accordingly. I'll add a bunch of > > simple > > message factories for this (FCGIMessage.createParams(), > > FCGIMessage.createStdin(), FCGIMessage.createEndRequest() etc.) to make > > this > > even easier. > > > > Till now I created three simple examples (a FCGIClient, a FCGIServer and > > a > > basic FCGHandler) and I think that I'll add a low level one for a server > > and > > client soon. In fact you'll need low level FCGIMessages to send / > > receive > > partial requests / responses or you can even mix higher level > > FCGIRequests > > with lower level FCGIMessages if only huge responses will occur. As an > > IoHandler multiplexing could be easily established very similar to this. > > All > > you'd need to do is assembling incoming multiplexed messages and keep > > track > > of the request ids on your own. > > > > As a first impression I uploaded the current higher level examples to > > http://daniel.users.hostunity.net/asyncfcgi/. > > > > regards > > Daniel > > On Mon, Apr 14, 2008 at 10:54 AM, Igor Clark <[EMAIL PROTECTED]> > > wrote: > > > > Hi Daniel, that sounds excellent! > > > > > > I'd be really interested to see more of this - I got as far as > > > implementing the server side using the OpenMarket code as a base, but > > > started to feel I would have to do some significant reworking. Sounds > > > like > > > you've already done that and more. > > > > > > What's your take on multiplexing connections? > > > > > > Bests > > > Igor > > > > > > On 11 April 2008, at 06:11, Daniel Wirtz <[EMAIL PROTECTED]> wrote: > > > > > > I'm currently taking a deeper look into FastCGI on top of mina. I > > > built > > > > > > > the basic FCGIEncoder, FCGIDecoder and a FCGICodecFactory with > > > > performance > > > > in mind mostly using IoBuffers and stripping all the needless stuff > > > > the > > > > original 12 years old devkit contains. Connections can be used in > > > > both > > > > directions as client and/or server and there are two modes > > > > implemented: A > > > > simple responder model utilizing FCGIRequest and FCGIResponse that > > > > can be > > > > easily sent and later on received by an IoHandler bypassing all the > > > > low > > > > level stuff by pre-assembling FCGIPackets and also a low level mode > > > > to send > > > > and receive custom FCGIPackets on your own (maybe for authorizer > > > > mode, you > > > > can even mix). I'm currently working on a simple FCGIManager to > > > > easily > > > > spread requests over multiple FastCGI backends - had this working > > > > once with > > > > a good ol' threading model but then I decided to implement it > > > > completely on > > > > top of Mina with a similar overall structure like AsyncWeb. Think it > > > > would > > > > be a nice option to use PHP, Ruby etc. backends for processing > > > > arbitrary > > > > stuff (quite similar to mod_fastcgi in Apache and lighttpd). > > > > FCGIRequest request = new FCGIRequest(); > > > > request.setProperties(....); > > > > request.setStdin(...); session.write(request); -> > > > > messageReceived(...) > > > > retuns FCGIResponse containing Stdout, Stderr byte arrays + > > > > AppStatus, > > > > ProtocolStatus, RequestId etc. or alternatively a low level > > > > FCGIPacket > > > > depending on the CodecFactory setting (e.g. new > > > > FCGICodecFactory(FCGIPacket.class / FCGIResponse.class / > > > > FCGIRequest.class)). > > > > Tested it with PHP, works fine so far. > > > > Is there already a good FastCGI implementation available or is there > > > > still a need for one? > > > > > > > > > > > -- > > > Igor Clark • POKE • 10 Redchurch Street • E2 7DD • +44 (0)20 7749 5355 > > > • > > > www.pokelondon.com > > > > > > > > > > > > > > > > -- > Igor Clark • POKE • 10 Redchurch Street • E2 7DD • +44 (0)20 7749 5355 • > www.pokelondon.com > > > >
