You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@axis.apache.org by Nikola Tankovć <ni...@gmail.com> on 2008/05/12 18:20:24 UTC
Re: GSOC: Axis2/C CGI
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: axis-c-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
RE: Multi threading in Axis2/C
Posted by Bill Mitchell <bm...@austin.rr.com>.
Hello Rinil,
I see two aspects to the multi-threading question, whether Axis2C runs in a
multi-threaded environment, and whether Axis2C itself takes advantage of a
multi-threading. My experience has been on the client side; it seems your
question may be on the server side, with which I am much less familiar.
What I can tell you is that Axis2C can be used successfully in a
multithreaded client. The key is that the processing is done in the context
of an axutil environment structure. What I found is that I can share one
axis configuration across multiple threads by creating multiple environments
that share the same allocator and logger while each use their own axutil
error handler. The separate error handler is needed so that each thread
sees only its own errors, not errors that appear in another thread. Sharing
the allocator allows the configuration to be processed only once for the
client app, instead of being processed as each thread is initialized. So,
in this case, Axis2C client is running in a multithreaded environment,
without taking any particular advantage of multithreading itself.
Perhaps someone else can shed some light your question about the message
receiver.
Enjoy,
Bill
-----Original Message-----
From: Baxi, Rinilkumar (TCS) [mailto:rinilkumar.baxi@hp.com]
Sent: Friday, May 16, 2008 6:19 AM
To: Apache AXIS C Developers List
Subject: Multi threading in Axis2/C
Hello,
I have been looking at the Axis2/C code. Axis configuration files indicate
that Axis supports multi threading. It appears at first glance that it is
the HTTP listener (in transport phase) which provides multi threading
support. And the rest of Axis(Axis engine, message receiver) is single
threaded. Kindly let me know whether my understanding is correct.
Also I'd like to know if its feasible to introduce multi threading in the
message receiver.
Thanks and Regards,
Rinil
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
Re: Multi threading in Axis2/C
Posted by Manjula Peiris <ma...@wso2.com>.
On Fri, 2008-05-16 at 11:19 +0000, Baxi, Rinilkumar (TCS) wrote:
> Hello,
>
> I have been looking at the Axis2/C code. Axis configuration files indicate that Axis supports multi threading. It appears at first glance that it is the HTTP listener (in transport phase) which provides multi threading support. And the rest of Axis(Axis engine, message receiver) is single threaded. Kindly let me know whether my understanding is correct.
>
> Also I'd like to know if its feasible to introduce multi threading in the message receiver.
You may need to write your own message_receiver in the case. [1] is an
example of a custom message receiver.
Thanks,
-Manjula.
[1]https://wso2.org/repos/wso2/trunk/wsf/php/src/wsf_xml_msg_recv.c
>
> Thanks and Regards,
> Rinil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
Re: Multi threading in Axis2/C
Posted by Dinesh Premalal <xy...@gmail.com>.
"Baxi, Rinilkumar (TCS)" <ri...@hp.com> writes:
> Hello,
>
> I have been looking at the Axis2/C code. Axis configuration files
> indicate that Axis supports multi threading. It appears at first
> glance that it is the HTTP listener (in transport phase) which
> provides multi threading support. And the rest of Axis(Axis engine,
> message receiver) is single threaded. Kindly let me know whether my
> understanding is correct.
AFAIK, your understanding is correct. Axis2/C engine is designed to be
operated single threaded in multi threading environment, that is why
we could see using mutexes in op_ctx and conf_ctx.
thanks,
Dinesh
--
http://nethu.org
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
Multi threading in Axis2/C
Posted by "Baxi, Rinilkumar (TCS)" <ri...@hp.com>.
Hello,
I have been looking at the Axis2/C code. Axis configuration files indicate that Axis supports multi threading. It appears at first glance that it is the HTTP listener (in transport phase) which provides multi threading support. And the rest of Axis(Axis engine, message receiver) is single threaded. Kindly let me know whether my understanding is correct.
Also I'd like to know if its feasible to introduce multi threading in the message receiver.
Thanks and Regards,
Rinil
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
Re: GSOC: Axis2/C CGI
Posted by Nikola Tankovć <ni...@gmail.com>.
OK +1 from me too, later after GSOC we can go to FCGI.
Nandika Jayawardana wrote:
> +1 for starting with CGI.
>
> Regards
> Nandika
>
> On Thu, May 15, 2008 at 10:53 PM, Samisa Abeysinghe <sa...@wso2.com> 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 <samisa@wso2.com
>>>> <ma...@wso2.com>> 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" <jayawark@gmail.com
>>>> <ma...@gmail.com>> wrote on 05/14/2008 12:01:27 AM:
>>>>
>>>> On Tue, May 13, 2008 at 11:47 PM, Samisa Abeysinghe
>>>> <samisa@wso2.com <ma...@wso2.com>> 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'
>>>>
>>>>
>>>>
>>>> <nikola.tankovic@gmail.com
>>>> <ma...@gmail.com>> 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:
>>>> axis-c-dev-unsubscribe@ws.apache.org
>>>> <ma...@ws.apache.org>
>>>> For additional commands, e-mail:
>>>> axis-c-dev-help@ws.apache.org
>>>> <ma...@ws.apache.org>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail:
>>>> axis-c-dev-unsubscribe@ws.apache.org
>>>> <ma...@ws.apache.org>
>>>> For additional commands, e-mail:
>>>> axis-c-dev-help@ws.apache.org
>>>> <ma...@ws.apache.org>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>> 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:
>>>> axis-c-dev-unsubscribe@ws.apache.org
>>>> <ma...@ws.apache.org>
>>>> For additional commands, e-mail:
>>>> axis-c-dev-help@ws.apache.org
>>>> <ma...@ws.apache.org>
>>>>
>>>>
>>>>
>>>> -- http://nandikajayawardana.blogspot.com/
>>>> WSO2 Inc: http://www.wso2.com
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail:
>>>> axis-c-dev-unsubscribe@ws.apache.org
>>>> <ma...@ws.apache.org>
>>>> For additional commands, e-mail:
>>>> axis-c-dev-help@ws.apache.org
>>>> <ma...@ws.apache.org>
>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
>>>> <ma...@ws.apache.org>
>>>> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>>>> <ma...@ws.apache.org>
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>>
>>>> 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: axis-c-dev-unsubscribe@ws.apache.org
>>>> <ma...@ws.apache.org>
>>>> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>>>> <ma...@ws.apache.org>
>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>>> ------------------------------------------------------------------------
>>>
>>>
>>> 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: axis-c-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>>
>>
>>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
Re: GSOC: Axis2/C CGI
Posted by Nandika Jayawardana <ja...@gmail.com>.
+1 for starting with CGI.
Regards
Nandika
On Thu, May 15, 2008 at 10:53 PM, Samisa Abeysinghe <sa...@wso2.com> 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 <samisa@wso2.com
>>> <ma...@wso2.com>> 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" <jayawark@gmail.com
>>> <ma...@gmail.com>> wrote on 05/14/2008 12:01:27 AM:
>>>
>>> On Tue, May 13, 2008 at 11:47 PM, Samisa Abeysinghe
>>> <samisa@wso2.com <ma...@wso2.com>> 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'
>>>
>>>
>>>
>>> <nikola.tankovic@gmail.com
>>> <ma...@gmail.com>> 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:
>>> axis-c-dev-unsubscribe@ws.apache.org
>>> <ma...@ws.apache.org>
>>> For additional commands, e-mail:
>>> axis-c-dev-help@ws.apache.org
>>> <ma...@ws.apache.org>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> axis-c-dev-unsubscribe@ws.apache.org
>>> <ma...@ws.apache.org>
>>> For additional commands, e-mail:
>>> axis-c-dev-help@ws.apache.org
>>> <ma...@ws.apache.org>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> 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:
>>> axis-c-dev-unsubscribe@ws.apache.org
>>> <ma...@ws.apache.org>
>>> For additional commands, e-mail:
>>> axis-c-dev-help@ws.apache.org
>>> <ma...@ws.apache.org>
>>>
>>>
>>>
>>> -- http://nandikajayawardana.blogspot.com/
>>> WSO2 Inc: http://www.wso2.com
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> axis-c-dev-unsubscribe@ws.apache.org
>>> <ma...@ws.apache.org>
>>> For additional commands, e-mail:
>>> axis-c-dev-help@ws.apache.org
>>> <ma...@ws.apache.org>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
>>> <ma...@ws.apache.org>
>>> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>>> <ma...@ws.apache.org>
>>>
>>> ------------------------------------------------------------------------
>>>
>>>
>>> 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: axis-c-dev-unsubscribe@ws.apache.org
>>> <ma...@ws.apache.org>
>>> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>>> <ma...@ws.apache.org>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>> ------------------------------------------------------------------------
>>
>>
>> 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: axis-c-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>
>
--
http://nandikajayawardana.blogspot.com/
WSO2 Inc: http://www.wso2.com
Re: GSOC: Axis2/C CGI
Posted by Samisa Abeysinghe <sa...@wso2.com>.
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 <samisa@wso2.com
>> <ma...@wso2.com>> 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" <jayawark@gmail.com
>> <ma...@gmail.com>> wrote on 05/14/2008 12:01:27 AM:
>>
>>
>> On Tue, May 13, 2008 at 11:47 PM, Samisa Abeysinghe
>> <samisa@wso2.com <ma...@wso2.com>>
>> 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'
>>
>>
>>
>> <nikola.tankovic@gmail.com
>> <ma...@gmail.com>> 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:
>> axis-c-dev-unsubscribe@ws.apache.org
>>
>> <ma...@ws.apache.org>
>> For additional commands, e-mail:
>> axis-c-dev-help@ws.apache.org
>> <ma...@ws.apache.org>
>>
>>
>>
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>>
>> To unsubscribe, e-mail:
>> axis-c-dev-unsubscribe@ws.apache.org
>> <ma...@ws.apache.org>
>> For additional commands, e-mail:
>> axis-c-dev-help@ws.apache.org
>> <ma...@ws.apache.org>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>> 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:
>> axis-c-dev-unsubscribe@ws.apache.org
>> <ma...@ws.apache.org>
>> For additional commands, e-mail:
>> axis-c-dev-help@ws.apache.org
>> <ma...@ws.apache.org>
>>
>>
>>
>>
>> -- http://nandikajayawardana.blogspot.com/
>> WSO2 Inc: http://www.wso2.com
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> axis-c-dev-unsubscribe@ws.apache.org
>> <ma...@ws.apache.org>
>> For additional commands, e-mail:
>> axis-c-dev-help@ws.apache.org
>> <ma...@ws.apache.org>
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
>> <ma...@ws.apache.org>
>> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>> <ma...@ws.apache.org>
>>
>> ------------------------------------------------------------------------
>>
>>
>> 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: axis-c-dev-unsubscribe@ws.apache.org
>> <ma...@ws.apache.org>
>> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>> <ma...@ws.apache.org>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
> ------------------------------------------------------------------------
>
>
> 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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
Re: GSOC: Axis2/C CGI
Posted by Nikola Tankovć <ni...@gmail.com>.
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 <samisa@wso2.com
> <ma...@wso2.com>> 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" <jayawark@gmail.com
> <ma...@gmail.com>> wrote on 05/14/2008 12:01:27 AM:
>
>
>
> On Tue, May 13, 2008 at 11:47 PM, Samisa Abeysinghe
> <samisa@wso2.com <ma...@wso2.com>>
>
> 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'
>
>
>
> <nikola.tankovic@gmail.com
> <ma...@gmail.com>> 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:
> axis-c-dev-unsubscribe@ws.apache.org
> <ma...@ws.apache.org>
> For additional commands, e-mail:
> axis-c-dev-help@ws.apache.org
> <ma...@ws.apache.org>
>
>
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
>
>
> To unsubscribe, e-mail:
> axis-c-dev-unsubscribe@ws.apache.org
> <ma...@ws.apache.org>
> For additional commands, e-mail:
> axis-c-dev-help@ws.apache.org
> <ma...@ws.apache.org>
>
>
>
>
>
>
>
>
>
>
> ------------------------------------------------------------------------
>
>
>
> 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:
> axis-c-dev-unsubscribe@ws.apache.org
> <ma...@ws.apache.org>
> For additional commands, e-mail:
> axis-c-dev-help@ws.apache.org
> <ma...@ws.apache.org>
>
>
>
>
>
> --
> http://nandikajayawardana.blogspot.com/
> WSO2 Inc: http://www.wso2.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> axis-c-dev-unsubscribe@ws.apache.org
> <ma...@ws.apache.org>
> For additional commands, e-mail:
> axis-c-dev-help@ws.apache.org
> <ma...@ws.apache.org>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> <ma...@ws.apache.org>
> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
> <ma...@ws.apache.org>
> ------------------------------------------------------------------------
>
>
> 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: axis-c-dev-unsubscribe@ws.apache.org
> <ma...@ws.apache.org>
> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
> <ma...@ws.apache.org>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
Re: GSOC: Axis2/C CGI
Posted by Supun Kamburugamuva <su...@gmail.com>.
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 <sa...@wso2.com> 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" <ja...@gmail.com> wrote on 05/14/2008 12:01:27
>> AM:
>>
>>
>>
>>> On Tue, May 13, 2008 at 11:47 PM, Samisa Abeysinghe <sa...@wso2.com>
>>>
>>>
>> 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'
>>>>>
>>>>>
>>>>>
>>>>> <ni...@gmail.com> 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: axis-c-dev-unsubscribe@ws.apache.org
>>>>>>> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>> ---------------------------------------------------------------------
>>
>>
>>> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
>>>>>> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> ------------------------------------------------------------------------
>>
>>
>>>
>>>>> 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: axis-c-dev-unsubscribe@ws.apache.org
>>>> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>>>>
>>>>
>>>>
>>>>
>>>
>>> --
>>> http://nandikajayawardana.blogspot.com/
>>> WSO2 Inc: http://www.wso2.com
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>> ------------------------------------------------------------------------
>>
>>
>> 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: axis-c-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>
>
Re: GSOC: Axis2/C CGI
Posted by Samisa Abeysinghe <sa...@wso2.com>.
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" <ja...@gmail.com> wrote on 05/14/2008 12:01:27
> AM:
>
>
>> On Tue, May 13, 2008 at 11:47 PM, Samisa Abeysinghe <sa...@wso2.com>
>>
> 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'
>>>>
>>>>
>>>>
>>>> <ni...@gmail.com> 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: axis-c-dev-unsubscribe@ws.apache.org
>>>>>> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
> ---------------------------------------------------------------------
>
>>>>> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
>>>>> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
> ------------------------------------------------------------------------
>
>>>>
>>>> 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: axis-c-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>>>
>>>
>>>
>>
>> --
>> http://nandikajayawardana.blogspot.com/
>> WSO2 Inc: http://www.wso2.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>
> ------------------------------------------------------------------------
>
>
> 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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
Re: GSOC: Axis2/C CGI
Posted by Nadir Amra <am...@us.ibm.com>.
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.
Nadir Amra
"Nandika Jayawardana" <ja...@gmail.com> wrote on 05/14/2008 12:01:27
AM:
> On Tue, May 13, 2008 at 11:47 PM, Samisa Abeysinghe <sa...@wso2.com>
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'
> > >
> > >
> > >
> > > <ni...@gmail.com> 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: axis-c-dev-unsubscribe@ws.apache.org
> > > > > For additional commands, e-mail: axis-c-dev-help@ws.apache.org
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: axis-c-dev-help@ws.apache.org
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
------------------------------------------------------------------------
> > >
> > >
> > >
> > > 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: axis-c-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-c-dev-help@ws.apache.org
> >
> >
>
>
>
> --
> http://nandikajayawardana.blogspot.com/
> WSO2 Inc: http://www.wso2.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
Re: GSOC: Axis2/C CGI
Posted by Nandika Jayawardana <ja...@gmail.com>.
On Tue, May 13, 2008 at 11:47 PM, Samisa Abeysinghe <sa...@wso2.com> 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'
> >
> >
> >
> > <ni...@gmail.com> 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: axis-c-dev-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: axis-c-dev-help@ws.apache.org
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: axis-c-dev-help@ws.apache.org
> > >
> > >
> > >
> > >
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> >
> >
> > 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: axis-c-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>
>
--
http://nandikajayawardana.blogspot.com/
WSO2 Inc: http://www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
Re: GSOC: Axis2/C CGI
Posted by Samisa Abeysinghe <sa...@wso2.com>.
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?
Samisa...
> Regards
> Nandika
>
>
> On Mon, May 12, 2008 at 9:50 PM, Nikola Tankovc'
> <ni...@gmail.com> 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: axis-c-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>>>
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>>
>>
>>
>
>
>
>
> ------------------------------------------------------------------------
>
>
> 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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
Re: GSOC: Axis2/C CGI
Posted by Nandika Jayawardana <ja...@gmail.com>.
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.
Regards
Nandika
On Mon, May 12, 2008 at 9:50 PM, Nikola Tankovć
<ni...@gmail.com> 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: axis-c-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-c-dev-help@ws.apache.org
> >
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>
>
--
http://nandikajayawardana.blogspot.com/
WSO2 Inc: http://www.wso2.com