+1 for starting with CGI. Regards Nandika
On Thu, May 15, 2008 at 10:53 PM, Samisa Abeysinghe <[EMAIL PROTECTED]> wrote: > 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] > > -- http://nandikajayawardana.blogspot.com/ WSO2 Inc: http://www.wso2.com
