Cherokee and its mysterious connection dropping

Hi,


In the past I found many strange issues using Cherokee for
Cisco 
telephone provisioning. Basically all request arrived
broken. Currently 
I have a similar problem with a Java program.

http://xen.bot.nu
/josm-request.pcap


It is 100% clear that a program like wget works. But as you
can see in 
the last packet in pcap, the XML file isn't transfered
fully. I saw this 
behavior on a big website too, packets that are reset or
have a 
non-normal scenario seems to be ignored/dropped.

Could anyone take a peek at the file and advise what to do?




Stefan
_______________________________________________
Cherokee mailing list
Cherokeecherokee-project.com
http://cherokee-project.com/cgi-bin/mailman/listinf
o/cherokee

On 28 May 2008, at 18:59, Stefan de Konink wrote:

> In the past I found many strange issues using Cherokee
for Cisco
> telephone provisioning. Basically all request arrived
broken.  
> Currently
> I have a similar problem with a Java program.
>
> http://xen.bot.nu
/josm-request.pcap
>
>
> It is 100% clear that a program like wget works. But as
you can see in
> the last packet in pcap, the XML file isn't transfered
fully. I saw  
> this
> behavior on a big website too, packets that are reset
or have a
> non-normal scenario seems to be ignored/dropped.
>
> Could anyone take a peek at the file and advise what to
do?

I'm going to check it out; although I don't think I will be
able to do  
much if I cannot reproduce the problem locally.  Have you
found a way  
to make it fail?

--
Greetings, alo.

_______________________________________________
Cherokee mailing list
Cherokeecherokee-project.com
http://cherokee-project.com/cgi-bin/mailman/listinf
o/cherokee

On 28 May 2008, at 18:59, Stefan de Konink wrote:

> In the past I found many strange issues using Cherokee
for Cisco
> telephone provisioning. Basically all request arrived
broken.  
> Currently
> I have a similar problem with a Java program.
>
> http://xen.bot.nu
/josm-request.pcap
>
>
> It is 100% clear that a program like wget works. But as
you can see in
> the last packet in pcap, the XML file isn't transfered
fully. I saw  
> this
> behavior on a big website too, packets that are reset
or have a
> non-normal scenario seems to be ignored/dropped.
>
> Could anyone take a peek at the file and advise what to
do?

I'm going to check it out; although I don't think I will be
able to do  
much if I cannot reproduce the problem locally.  Have you
found a way  
to make it fail?

--
Greetings, alo.

_______________________________________________
Cherokee mailing list
Cherokeecherokee-project.com
http://cherokee-project.com/cgi-bin/mailman/listinf
o/cherokee

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Ok  My
mistake, offlist we have discussed what was wrong with my
code.


Then again, why should I solve it with:

       if (hdl->buffer.len > 0) {
               ret = cherokee_buffer_add_buffer (buffer,
&hdl->buffer);
               cherokee_buffer_move_to_begin
(&hdl->buffer, buffer->size);
               if (hdl->buffer.len == 0)
                       return ret_eof_have_data;

               return ret_ok;
       } else
               return ret_eagain;


While server_info itself can do only the add_buffer method?
Is this a
shortcut because it is assumed to be less that 8k?

So what am I working on?

I'm creating a handler for the OpenStreetMap project, that
uses
MonetDB5/SQL+GIS as backend. In best case to replace
Lighttpd+Ruby+MySQL.



Stefan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


iEYEAREKAAYFAkg+dOIACgkQYH1+F2Rqwn18igCcCMWDq3lL4D5/1r/ypvrf
4x59
5Z8An3XyYj2CPus+EUaHsCgwKn8srR9g
=Qkfe
-----END PGP SIGNATURE-----
_______________________________________________
Cherokee mailing list
Cherokeecherokee-project.com
http://cherokee-project.com/cgi-bin/mailman/listinf
o/cherokee

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Ok  My
mistake, offlist we have discussed what was wrong with my
code.


Then again, why should I solve it with:

       if (hdl->buffer.len > 0) {
               ret = cherokee_buffer_add_buffer (buffer,
&hdl->buffer);
               cherokee_buffer_move_to_begin
(&hdl->buffer, buffer->size);
               if (hdl->buffer.len == 0)
                       return ret_eof_have_data;

               return ret_ok;
       } else
               return ret_eagain;


While server_info itself can do only the add_buffer method?
Is this a
shortcut because it is assumed to be less that 8k?

So what am I working on?

I'm creating a handler for the OpenStreetMap project, that
uses
MonetDB5/SQL+GIS as backend. In best case to replace
Lighttpd+Ruby+MySQL.



Stefan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


iEYEAREKAAYFAkg+dOIACgkQYH1+F2Rqwn18igCcCMWDq3lL4D5/1r/ypvrf
4x59
5Z8An3XyYj2CPus+EUaHsCgwKn8srR9g
=Qkfe
-----END PGP SIGNATURE-----
_______________________________________________
Cherokee mailing list
Cherokeecherokee-project.com
http://cherokee-project.com/cgi-bin/mailman/listinf
o/cherokee

On 29 May 2008, at 11:18, Stefan de Konink wrote:

> While server_info itself can do only the add_buffer
method? Is this a
> shortcut because it is assumed to be less that 8k?

I don't think I have understood the question.
Anyway, let me briefly summarize how a handler internally
works:

- First of all, the handler is instanced by calling its
_new() method.

- Then, the _init() method is called. It ought to prepare
whatever the
   handler needs to reply the request: a data base
connection, open a
   file, build a file list, etc.

- The _add_headers() method is invoked, and the handler
returns the
   request reply headers, if any.

- And finally, the _step() method is called a number of
times. It
   usually returns a chunk of information each time that it
is
   called. Actually, the method returns a code that points
the server
   what has happened inside:

   * ret_ok:     There is new information in the buffer..
   * ret_eagain: No information in the buffer: try again
   * ret_eof:    It is done. All the information has been
sent.
   * ret_eof_have_data: It is an optimization. There is
information in
     the buffer, but you know in advanced that it is the
last chunk. It
     could be translated to two calls: ret_ok + ret_eof.

> So what am I working on?
>
> I'm creating a handler for the OpenStreetMap project,
that uses
> MonetDB5/SQL+GIS as backend. In best case to replace
Lighttpd+Ruby 
> +MySQL.

Sounds pretty interesting.. 

--
Greetings, alo.

_______________________________________________
Cherokee mailing list
Cherokeecherokee-project.com
http://cherokee-project.com/cgi-bin/mailman/listinf
o/cherokee

On 29 May 2008, at 11:18, Stefan de Konink wrote:

> While server_info itself can do only the add_buffer
method? Is this a
> shortcut because it is assumed to be less that 8k?

I don't think I have understood the question.
Anyway, let me briefly summarize how a handler internally
works:

- First of all, the handler is instanced by calling its
_new() method.

- Then, the _init() method is called. It ought to prepare
whatever the
   handler needs to reply the request: a data base
connection, open a
   file, build a file list, etc.

- The _add_headers() method is invoked, and the handler
returns the
   request reply headers, if any.

- And finally, the _step() method is called a number of
times. It
   usually returns a chunk of information each time that it
is
   called. Actually, the method returns a code that points
the server
   what has happened inside:

   * ret_ok:     There is new information in the buffer..
   * ret_eagain: No information in the buffer: try again
   * ret_eof:    It is done. All the information has been
sent.
   * ret_eof_have_data: It is an optimization. There is
information in
     the buffer, but you know in advanced that it is the
last chunk. It
     could be translated to two calls: ret_ok + ret_eof.

> So what am I working on?
>
> I'm creating a handler for the OpenStreetMap project,
that uses
> MonetDB5/SQL+GIS as backend. In best case to replace
Lighttpd+Ruby 
> +MySQL.

Sounds pretty interesting.. 

--
Greetings, alo.

_______________________________________________
Cherokee mailing list
Cherokeecherokee-project.com
http://cherokee-project.com/cgi-bin/mailman/listinf
o/cherokee