cpp-netlib-devel

[cpp-netlib-devel] Python tests

[Dean M. C. B. <dmb...@fr...>]

Hi Guys,

I've only recently been able to try and test the localhost test which
uses the server. And what I found out is if you're running it in Linux
without an X server installed (or xterm), it won't work. I've tried
modifying it to use Python directly instead, but I'm not having any luck
with that.

Divye, have you tried not using xterm to spawn a new process after the
fork to run the server? Perhaps writing a bash script that gets executed
instead in execlp would be another option?

HTH

--
Dean Michael Berris
Software Engineer, Friendster, Inc.

Re: [cpp-netlib-devel] Python tests

[Divye K. <div...@gm...>]

On Thu, Aug 7, 2008 at 12:11 PM, Dean Michael C. Berris <
dmb...@fr...> wrote:

>
> Divye, have you tried not using xterm to spawn a new process after the
> fork to run the server? Perhaps writing a bash script that gets executed
> instead in execlp would be another option?
>

I've tried plenty of approaches to get this to work but this was the only
one that seemed to work.
However, I'll give it another shot and try the bash script method.

Divye


-- 
An idealist is one who, on noticing that a rose smells better than a
cabbage, concludes that it will also make better soup.
H. L. Mencken (1880 - 1956)
My official web site: http://people.iitr.ernet.in/shp/061305/
Webmaster: http://www.drkapoorsclinic.com
Blog: http://divyekapoor.blogspot.com

Re: [cpp-netlib-devel] Python tests

[Divye K. <div...@gm...>]

Hello,
   A quick workaround is to simply comment out the server_start and
server_kill tests and start the python server manually ( located at
tests/server/cgi_server.py ) before running the tests.

Divye

On Thu, Aug 7, 2008 at 3:53 PM, Divye Kapoor <div...@gm...> wrote:

>
>
> On Thu, Aug 7, 2008 at 12:11 PM, Dean Michael C. Berris <
> dmb...@fr...> wrote:
>
>>
>> Divye, have you tried not using xterm to spawn a new process after the
>> fork to run the server? Perhaps writing a bash script that gets executed
>> instead in execlp would be another option?
>>
>
> I've tried plenty of approaches to get this to work but this was the only
> one that seemed to work.
> However, I'll give it another shot and try the bash script method.
>
> Divye
>
>
> --
> An idealist is one who, on noticing that a rose smells better than a
> cabbage, concludes that it will also make better soup.
> H. L. Mencken (1880 - 1956)
> My official web site: http://people.iitr.ernet.in/shp/061305/
> Webmaster: http://www.drkapoorsclinic.com
> Blog: http://divyekapoor.blogspot.com
>



-- 
An idealist is one who, on noticing that a rose smells better than a
cabbage, concludes that it will also make better soup.
H. L. Mencken (1880 - 1956)
My official web site: http://people.iitr.ernet.in/shp/061305/
Webmaster: http://www.drkapoorsclinic.com
Blog: http://divyekapoor.blogspot.com

Re: [cpp-netlib-devel] Python tests

[Dean M. C. B. <dmb...@fr...>]

> -----Original Message-----
> From: cpp...@li... 
> [mailto:cpp...@li...] On 
> Behalf Of Divye Kapoor
> Sent: Thursday, August 07, 2008 6:23 PM
> To: C++ Networking Library Developers Mailing List
> Subject: Re: [cpp-netlib-devel] Python tests
> 
> 
> 
> On Thu, Aug 7, 2008 at 12:11 PM, Dean Michael C. Berris 
> <dmb...@fr...> wrote:
> 
> 
> 
> 	Divye, have you tried not using xterm to spawn a new 
> process after the
> 	fork to run the server? Perhaps writing a bash script 
> that gets executed
> 	instead in execlp would be another option?
> 	
> 
> 
> I've tried plenty of approaches to get this to work but this 
> was the only one that seemed to work.
> However, I'll give it another shot and try the bash script method.
> 

I'll be eagerly awaiting. :)

BTW, I've made some changes to the code in the latest version in
http_integration. For now the errors thrown by the HTTP client are
directly coming from Boost.Asio.

I'm not sure if we should be supporting a non-throwing version using
macros to differentiate, but that's for later. Now though the problem
you reported earlier (causing the HTTP client to be unusable offline)
now at least throws a boost::system::system_error exception instead of
consumes 100% CPU load.

HTH

--
Dean Michael Berris
Software Engineer, Friendster, Inc. 

Re: [cpp-netlib-devel] Python tests

[Divye K. <div...@gm...>]

Hi Dean,

On Thu, Aug 7, 2008 at 4:00 PM, Dean Michael C. Berris <
dmb...@fr...> wrote:

> <snip>

Now though the problem
> you reported earlier (causing the HTTP client to be unusable offline)
> now at least throws a boost::system::system_error exception instead of
> consumes 100% CPU load.
>

I've found another case where the http::client is causing resource leaks and
mammoth CPU loads. It occurs when you try to access a CGI script that has
failed to execute.

A way to reproduce this is to simply use the version of requestinfo.py
before revision 77 (use revision 65) and perform a default POST request on
it. The cgi script fails with an error but the http::client fails to respond
and eats up system resources (seen on Vista/MSVC8).

I think its a sign of a larger problem with the way we are using getline
calls in http::client. But I'm not sure. Can anyone shed some light on this?

Divye


-- 
An idealist is one who, on noticing that a rose smells better than a
cabbage, concludes that it will also make better soup.
H. L. Mencken (1880 - 1956)
My official web site: http://people.iitr.ernet.in/shp/061305/
Webmaster: http://www.drkapoorsclinic.com
Blog: http://divyekapoor.blogspot.com

Re: [cpp-netlib-devel] Python tests

[Dean M. B. <mik...@gm...>]

Hi Diyve,

On Sun, Sep 7, 2008 at 2:47 AM, Divye Kapoor <div...@gm...> wrote:
> Hi Dean,
>
> On Thu, Aug 7, 2008 at 4:00 PM, Dean Michael C. Berris
> <dmb...@fr...> wrote:
>>
>> <snip>
>>
>> Now though the problem
>> you reported earlier (causing the HTTP client to be unusable offline)
>> now at least throws a boost::system::system_error exception instead of
>> consumes 100% CPU load.
>
> I've found another case where the http::client is causing resource leaks and
> mammoth CPU loads. It occurs when you try to access a CGI script that has
> failed to execute.
>
> A way to reproduce this is to simply use the version of requestinfo.py
> before revision 77 (use revision 65) and perform a default POST request on
> it. The cgi script fails with an error but the http::client fails to respond
> and eats up system resources (seen on Vista/MSVC8).
>
> I think its a sign of a larger problem with the way we are using getline
> calls in http::client. But I'm not sure. Can anyone shed some light on this?
>

Hmmm... I don't do getline() anymore, except from getting the headers,
which should throw if the server has already closed the connection
(connection reset).

Can you write something that will induce this behavior without having
to revert the version of requestinfo.py?

Thanks for reporting this. Looking forward to the test. ;-)

-- 
Dean Michael C. Berris
Software Engineer, Friendster, Inc.

Re: [cpp-netlib-devel] Python tests

[Divye K. <div...@gm...>]

Hi Dean,

On Mon, Sep 8, 2008 at 10:58 AM, Dean Michael Berris <mik...@gm...
> wrote:

> Hi Diyve,
>
>
> Hmmm... I don't do getline() anymore, except from getting the headers,
> which should throw if the server has already closed the connection
> (connection reset).
>
> Can you write something that will induce this behavior without having
> to revert the version of requestinfo.py?
>

I investigated the issue and it was because I was using an older version of
http::client. The issue seems resolved in the newer versions of
http::client. I guess I reverted one file too many. Sorry for the trouble.

Divye

-- 
An idealist is one who, on noticing that a rose smells better than a
cabbage, concludes that it will also make better soup.
H. L. Mencken (1880 - 1956)
My official web site: http://people.iitr.ernet.in/shp/061305/
Webmaster: http://www.drkapoorsclinic.com
Blog: http://divyekapoor.blogspot.com

Re: [cpp-netlib-devel] Python tests

[Dean M. B. <mik...@gm...>]

On Mon, Sep 8, 2008 at 9:39 PM, Divye Kapoor <div...@gm...> wrote:
> Hi Dean,
>
> On Mon, Sep 8, 2008 at 10:58 AM, Dean Michael Berris
>>
>> Can you write something that will induce this behavior without having
>> to revert the version of requestinfo.py?
>
> I investigated the issue and it was because I was using an older version of
> http::client. The issue seems resolved in the newer versions of
> http::client. I guess I reverted one file too many. Sorry for the trouble.
>

Whew! That scared me just a little. ;-)

Thanks for looking into it! :-)

-- 
Dean Michael C. Berris
Software Engineer, Friendster, Inc.