IMHO, if we can only have CGI to start with within the GSOC time frame, that would be quite an achievement. You can do the FCGI stuff after GSOC ;) That is the whole point of GSOC, make you a long time contributor :)

On the logging thing, yes it does not make sense at all to write multiple logs. So till we figure that out, may be we can go ahead without logging. Another alternative is to try and see if we can plug the log to httpd log, and let httpd manage the stuff.

Thanks,
Samisa...

Nikola Tankovć wrote:
Yes FCGI is far more better. I will first try to implement CGI as fast as possible, probably there will be time left for FCGI, but FCGI as I read is rather complicated and will take much more time. Only problem is with log files in CGI, it a little stupid to make a new file for every process, I'd say very stupid, who would make any sense in that bunch of files, so waiting for the other process to close file, will also slow down CGI impl. as well.

Supun Kamburugamuva wrote:
Hi Nikola,

Do you think that within the given time frame you can implement both CGI and FCGI? The initial idea of this project is to implement a CGI application. But it turns out that FCGI is far better than CGI in the Axis2/C scenario. So it's really great if you can implement both. But I think it is up to you to decide what is possible.

Regards,
Supun..

On Wed, May 14, 2008 at 11:35 PM, Samisa Abeysinghe <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:

    Nadir Amra wrote:

        How about starting with CGI, then extending, if deemed
        necessary, to FCGI?  I think CGI is a standard, while fast-cgi
        is not, so you will get more bang for the buck with CGI.  In
        addition, there are some implementation of CGI that does not
suffer from the performance hits that is described here.
    OK, that sounds reasonable. So lets try CGI first and then move on
    to FCGI based on the outcomes.

    Samisa...



        Nadir Amra


        "Nandika Jayawardana" <[EMAIL PROTECTED]
        <mailto:[EMAIL PROTECTED]>> wrote on 05/14/2008 12:01:27 AM:

On Tue, May 13, 2008 at 11:47 PM, Samisa Abeysinghe <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote: Nandika Jayawardana wrote: I think FastCGI is the best option since it is widely used and solves all the issues that we will get with CGI like performance. However if SCGI is a widely used protocol I am ok with it.
                    How is the adoption of SCGI and what are the
servers that support it ?. What I was thinking was to let you implement
                    it in CGI since
                    CGI part is very simple and in the process you can
                    learn the axis2
                    side of the work and then replace CGI part with
                    FastCGI.


Is it trivial, to replace CGI with FCGI? What about
                the design issues,
                leveraging FCGI features in our implementation?
Axis2 side of the code should be the same. FCGI
            implementation would
            require more effort that CGI. Anyway it was just a thought
            and I guess
            Nikola has not gone into coding yet. So its better to
            decide what
            protocol to implement take it from there.

            -- Nandika

Samisa...

Regards
                    Nandika


                    On Mon, May 12, 2008 at 9:50 PM, Nikola Tankovc'



                    <[EMAIL PROTECTED]
                    <mailto:[EMAIL PROTECTED]>> wrote:


Hy all,

                         Reading your performance article on
http://wso2.org/library/3532 (nice results by the way) I think that building an CGI exec could cause some amount of bottleneck (imagine hundreds of CGI
                        parallel processess
running and starting and stoping 10k processes in second) , I know that the CGI exec is going to be very light (just simple input parsing and output forming) , but I think we should agree with Samisa Abeysinghe when he proposed FastCGI as this method would keep Axis2/C good results as well solve concurrency problem with logging, what I would suggest is SCGI as being much lighter and easier to implement protocol similar to FastCGI. If some servers don't have (Fast/S)CGI interfaces there are small light CGI execs available to redirect input.

                         What are your opinions on this?

                        Nandika Jayawardana wrote:


Hi Nikola,

                            In implementing the axis2 CGI app, you
need to understand how axis2 server side works in the context of a web server deployment. I think going through the source code of axis2 apache module will help you understand what needs to be done. You can find the source for it at "axis2c\src\core\transport\http\server\apache2". There are a set of functions that works as the axis2's http
                            server side API. These
                            functions are defined in
"axis2_http_transport_utils.h" header. The server modules work by extracting the http headers and content using the Web Server's API and using these
                            functions to invoke axis2.

                            So in the case of CGI, extracting http
headers is very simple since they are available as environment variables. Also the http content is available in stdin.

                            Following are the things you need to
                            figure out.

                            1. Defining the endpoint urls for axis2
services the are deployed under CGI.


{ In case of apache module, the service endpoint url for a service would be
                            http://<domain>:port/axis2/services/<service
name>. Apache module is configured such that all
                            requests that have
                            http://<domain>:port/axis2 will be
directed to mod_axis2 module. In case of CGI, I am not sure whether web servers allow such mapping. In that case one option would be to have the endpoint url something like http://<domain>:port/cgi-bin/axis2_cgi.exe/services/<service name> } 2. Solving the log file problem in case of
                            concurrent requests.

                            3. Specifing the axis2 configurations to
                            cgi executable.
                            These configurations include axis2
repository location , log file location etc. In case of Apache module,
                            these are defined in the
                            configuration file.

                            I guess, once you figure out these, you
can reuse most of the code in axis2 apache module for your
                            implementation as well.

                            Regards
                            Nandika



--------------------------------------------------------------------- To unsubscribe, e-mail:
                            [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
                            For additional commands, e-mail:
                            [EMAIL PROTECTED]
                            <mailto:[EMAIL PROTECTED]>





--------------------------------------------------------------------- To unsubscribe, e-mail:
                        [EMAIL PROTECTED]
                        <mailto:[EMAIL PROTECTED]>
                        For additional commands, e-mail:
                        [EMAIL PROTECTED]
                        <mailto:[EMAIL PROTECTED]>





------------------------------------------------------------------------
                    No virus found in this incoming message.
                    Checked by AVG. Version: 8.0.100 / Virus Database:
                    269.23.16/1430 -
Release Date: 5/13/2008 7:31 AM --
                Samisa Abeysinghe Director, Engineering; WSO2 Inc.


                http://www.wso2.com/ - "The Open Source SOA Company"


---------------------------------------------------------------------

                To unsubscribe, e-mail:
                [EMAIL PROTECTED]
                <mailto:[EMAIL PROTECTED]>
                For additional commands, e-mail:
                [EMAIL PROTECTED]
                <mailto:[EMAIL PROTECTED]>


            --             http://nandikajayawardana.blogspot.com/
            WSO2 Inc: http://www.wso2.com

---------------------------------------------------------------------
            To unsubscribe, e-mail:
            [EMAIL PROTECTED]
            <mailto:[EMAIL PROTECTED]>
            For additional commands, e-mail:
            [EMAIL PROTECTED]
            <mailto:[EMAIL PROTECTED]>


---------------------------------------------------------------------
        To unsubscribe, e-mail: [EMAIL PROTECTED]
        <mailto:[EMAIL PROTECTED]>
        For additional commands, e-mail: [EMAIL PROTECTED]
        <mailto:[EMAIL PROTECTED]>
------------------------------------------------------------------------


        No virus found in this incoming message.
        Checked by AVG. Version: 8.0.100 / Virus Database:
        269.23.16/1430 - Release Date: 5/13/2008 7:31 AM

    --     Samisa Abeysinghe Director, Engineering; WSO2 Inc.

    http://www.wso2.com/ - "The Open Source SOA Company"


---------------------------------------------------------------------
    To unsubscribe, e-mail: [EMAIL PROTECTED]
    <mailto:[EMAIL PROTECTED]>
    For additional commands, e-mail: [EMAIL PROTECTED]
    <mailto:[EMAIL PROTECTED]>




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
------------------------------------------------------------------------


No virus found in this incoming message.
Checked by AVG. Version: 8.0.100 / Virus Database: 269.23.16/1434 - Release Date: 5/15/2008 7:24 AM


--
Samisa Abeysinghe Director, Engineering; WSO2 Inc.

http://www.wso2.com/ - "The Open Source SOA Company"


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to