Hi Daniel, it sounds brilliant. I look forward to seeing your examples.
FYI I had similar problems with ab when testing against my FCGI
version + nginx; with a concurrency level of (IIRC) 24 it worked
perfectly, but when I raised it to 25, I started getting lots of
failed requests. I didn't get any further investigating it.
Cheers,
Igor
On 14 Apr 2008, at 21:11, Daniel Wirtz wrote:
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
--
Igor Clark • POKE • 10 Redchurch Street • E2 7DD • +44 (0)20 7749 5355
• www.pokelondon.com
