You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@mina.apache.org by Igor Clark <ig...@pokelondon.com> on 2008/04/14 10:54:39 UTC
Re: FastCGI on Mina
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 <da...@virtunity.com> 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
Re: FastCGI on Mina
Posted by Igor Clark <ig...@pokelondon.com>.
Thanks Mathieu.
On 14 Apr 2008, at 16:42, Mathieu Lecarme wrote:
> Igor Clark a écrit :
>> Hiya, thanks for replying. I'm not really sure what you mean
>> though! By AJP13 do you mean http://tomcat.apache.org/connectors-doc-archive/jk2/common/AJPv13.html?
> AJP13 means Apache Java Protocol 1.3, or something near.
>> I don't want to use servlets or the servlet SDK, and I don't want
>> to pass filesystem references to big files back to the webserver. I
>> want to write simple, task-specific mainly POJO java applications
>> which carry out one job upstream of the front-end webserver, and
>> can speak FastCGI protocol to that webserver, without having to use
>> a J2EE/JSDK layer.
> X-Sendfile, in your example, can be used if you cache generated image.
>> How does the X-Sendfile relate to this? Perhaps I'm missing
>> something important, please let me know!
> You're missing nothing. FastCGI is a must have for Mina, and X-
> Sendfile is the bonus gift for light application server.
>
> M.
Re: FastCGI on Mina
Posted by Mathieu Lecarme <ma...@garambrogne.net>.
Igor Clark a écrit :
> Hiya, thanks for replying. I'm not really sure what you mean though!
> By AJP13 do you mean
> http://tomcat.apache.org/connectors-doc-archive/jk2/common/AJPv13.html?
AJP13 means Apache Java Protocol 1.3, or something near.
> I don't want to use servlets or the servlet SDK, and I don't want to
> pass filesystem references to big files back to the webserver. I want
> to write simple, task-specific mainly POJO java applications which
> carry out one job upstream of the front-end webserver, and can speak
> FastCGI protocol to that webserver, without having to use a J2EE/JSDK
> layer.
X-Sendfile, in your example, can be used if you cache generated image.
> How does the X-Sendfile relate to this? Perhaps I'm missing something
> important, please let me know!
You're missing nothing. FastCGI is a must have for Mina, and X-Sendfile
is the bonus gift for light application server.
M.
Re: FastCGI on Mina
Posted by Igor Clark <ig...@pokelondon.com>.
Hiya, thanks for replying. I'm not really sure what you mean though!
By AJP13 do you mean http://tomcat.apache.org/connectors-doc-archive/jk2/common/AJPv13.html?
I don't want to use servlets or the servlet SDK, and I don't want to
pass filesystem references to big files back to the webserver. I want
to write simple, task-specific mainly POJO java applications which
carry out one job upstream of the front-end webserver, and can speak
FastCGI protocol to that webserver, without having to use a J2EE/JSDK
layer. How does the X-Sendfile relate to this? Perhaps I'm missing
something important, please let me know!
Thanks,
Igor
On 14 Apr 2008, at 16:11, Mathieu Lecarme wrote:
> Igor Clark a écrit :
>> 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.
> Don't forget the lighty's X-Sendfile. With this header, mina can do
> something like ACL, logging, cache check, and give the hand back to
> httpd to serve some files.
> FastCGI is just a standard ajp13.
>
> M.
Re: FastCGI on Mina
Posted by Mathieu Lecarme <ma...@garambrogne.net>.
Igor Clark a écrit :
> 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.
Don't forget the lighty's X-Sendfile. With this header, mina can do
something like ACL, logging, cache check, and give the hand back to
httpd to serve some files.
FastCGI is just a standard ajp13.
M.
Re: FastCGI on Mina
Posted by Igor Clark <ig...@pokelondon.com>.
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 <ig...@pokelondon.com>
> 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 <ig...@pokelondon.com>
>>> 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 <da...@virtunity.com>
>>>> 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
Re: FastCGI on Mina
Posted by 이희승 (Trustin Lee) <t...@gmail.com>.
Daniel Wirtz wrote:
> 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.
Sure. Please feel free to file a JIRA issue.
Regards,
--
Trustin Lee - Principal Software Engineer, JBoss, Red Hat
--
what we call human nature is actually human habit
--
http://gleamynode.net/
Re: FastCGI on Mina
Posted by Daniel Wirtz <da...@virtunity.com>.
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 <ig...@pokelondon.com> 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 <ig...@pokelondon.com>
> > 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 <da...@virtunity.com> 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
>
>
>
>
Re: FastCGI on Mina
Posted by Igor Clark <ig...@pokelondon.com>.
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 <ig...@pokelondon.com>
> 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 <da...@virtunity.com>
>> 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
Re: FastCGI on Mina
Posted by Daniel Wirtz <da...@virtunity.com>.
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 <ig...@pokelondon.com> 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 <da...@virtunity.com> 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
>
>
>
>