Stefan de Konink | 7 Jun 2012 22:31
Picon
Gravatar

Making "Stable" more stable.

Hi all,

Long time I was totally against supporting really stable development. But 
over the time I have realised that some innovations in Cherokee that did 
fix some bugs, actually introduced more for other parts. Since I know many 
people on this list care for Cherokee and we all know what Alvaro is 
working on in his spare time, it would be a good thing to start fixing 
noticable, small things in Cherokee.

We have a great webserver, a great admin. And it doesn't really matter if 
we are the fastest or not. It actually matters that people that try 
Cherokee end up with the same problems, and the bugtracker is getting 
overloaded. To make some points very clear:

1) The biggest issue in the "stable" branch is the fact that SSL and POST 
support is problematic due to recent Google 'inventions'. With some 
support of Google in the past (and some workarounds by myself) it is 
possible to get a working Cherokee "stable" anyhow.

2) There are so many low hanging fruit bugs around that virtually anyone 
could help fixing them or write tests for them. Tests help to 
reproduce things, and prevent them from happening again in the future.

I know some people on IRC and on this list are actively fixing things in 
Cherokee, they are not getting "incorporated" in the stable. This should 
change, and can only change if the community starts to act.

From now on I would like to ask people to get involved, and commit to fix 
one defect per week from the Google Bugtracker. It is not much, and can be 
done, any bug counts.
(Continue reading)

Jedrzej Nowak | 8 Jun 2012 00:46
Picon
Gravatar

Re: Making "Stable" more stable.

Hey Stefan,

I have some "pending" patches for Admin. I think one is in pull request in github ( for CTK ).

I totally agree with your words. And I will try to manage some time for admin things mostly... ( I have some fixes for market also, and updated market packages ).. I just lack of time...

07-06-2012 22:31, "Stefan de Konink" <stefan <at> konink.de> napisał(a):
Hi all,


Long time I was totally against supporting really stable development. But over the time I have realised that some innovations in Cherokee that did fix some bugs, actually introduced more for other parts. Since I know many people on this list care for Cherokee and we all know what Alvaro is working on in his spare time, it would be a good thing to start fixing noticable, small things in Cherokee.

We have a great webserver, a great admin. And it doesn't really matter if we are the fastest or not. It actually matters that people that try Cherokee end up with the same problems, and the bugtracker is getting overloaded. To make some points very clear:


1) The biggest issue in the "stable" branch is the fact that SSL and POST support is problematic due to recent Google 'inventions'. With some support of Google in the past (and some workarounds by myself) it is possible to get a working Cherokee "stable" anyhow.

2) There are so many low hanging fruit bugs around that virtually anyone could help fixing them or write tests for them. Tests help to reproduce things, and prevent them from happening again in the future.


I know some people on IRC and on this list are actively fixing things in Cherokee, they are not getting "incorporated" in the stable. This should change, and can only change if the community starts to act.

From now on I would like to ask people to get involved, and commit to fix one defect per week from the Google Bugtracker. It is not much, and can be done, any bug counts.

<http://code.google.com/p/cherokee/issues/list?can=2&q=&sort=priority&colspec=ID%20Type%20Status%20Priority%20Milestone%20Owner%20Summary>


Speak out and tell people you are working on things. That includes unreported bugs that you are taking care of, it doesn't really care about what you want to address, it matters it is one bug less to care about. If you are doing a good job in C, the server core is probably what you want to look at. Python might be more your thing if you would like to improve the admin.


Practice what you preach:

The main reason I cannot switch back to stable on all my production machines is the SSL trouble. I would like to commit on the SSL POST on stable. Google has posted a oneliner for eJabberd, I would like to see the method its uses ported, opposed to my own workaround, which is also a one liner, but not really the right way.


I hope some people join :-)


Stefan

P.S. If you can't code, but are extremely wealthy you could also help: place a bounty on your favorite bug to be fixed. If you don't want to cash your bounty, you could place it on another bug ;)


_______________________________________________
Cherokee mailing list
Cherokee <at> lists.octality.com
http://lists.octality.com/listinfo/cherokee
_______________________________________________
Cherokee mailing list
Cherokee <at> lists.octality.com
http://lists.octality.com/listinfo/cherokee
Leonel Nunez | 8 Jun 2012 22:01

[Fwd: Re: Cherokee status ? Removal from Debian]

---------------------------- Mensaje original ----------------------------
Asunto: Re: [Cherokee] Cherokee status ? Removal from Debian
De:     "Leonel Nunez" <listas <at> enelserver.com>
Fecha:  Vie, 8 de Junio de 2012, 1:52 pm
Para:   "PChott" <pchott <at> gmail.com>
--------------------------------------------------------------------------

Hello:

> Hi all,
>
> i just wonder if anything moved around Debian debs. Lionel, have you
> been able to revert removal request?
>
> I may be able to test Debian deb (if there is any unoffical produced).
>
> This is just a ping to know the status and progress.
>
> Cheers,
> Jan
>

I'm contacting Gunnar to see the procedure to return Cherokee to debian
and what I need to do to start maintaining Cherokee officialy in Debian.

Saludos

Leonel
M. David Peterson | 9 Jun 2012 02:25
Gravatar

Cherokee Running on Windows! (Azure)

yeah, lame attempt at drawing attention with the subject line, but the simple fact that we can now use Cherokee as the front facing server to a hybrid-server app backend which in addition to the the classic Azure stack now includes any given Linux or Windows Server stack-based app is pretty damn sweet. 


Step One: Get Cherokee running on an Ubuntu-based instance > http://ubuntu-uswest.cloudapp.net/ < Check!

I'll be spending more time over the weekend and into next week running benchmark comparisons between AWS:EC2 and Azure:Virtual Machines running the same ASP.NET benchmark application being processed by Mono running on Linux, Microsoft .NET via Windows Server 2k12, all of which being handled on the frontend by Cherokee. Once I have something meaningful to report back I will. :-)

--
/M:D

M. David Peterson
Co-Founder & Chief Architect, 3rd&Urban, LLC
Email: m.david <at> 3rdandUrban.com
Voice: (801) 742-1064
Web: http://mdavidpeterson.com
_______________________________________________
Cherokee mailing list
Cherokee <at> lists.octality.com
http://lists.octality.com/listinfo/cherokee
M. David Peterson | 9 Jun 2012 02:31
Gravatar

Re: Cherokee Running on Windows! (Azure)

On Fri, Jun 8, 2012 at 6:25 PM, M. David Peterson <m.david <at> 3rdandurban.com> wrote:
the simple fact that we can now use Cherokee as the front facing server

... on Windows Azure (is what should have been included in my previous email which, just in case any of you are unaware, the new release of Azure includes, amongst other things, the ability to run Linux and Windows Server-based virtual machines alongside the rest of the Azure stack: http://weblogs.asp.net/scottgu/archive/2012/06/07/meet-the-new-windows-azure.aspx

Sorry for any confusion!

--
/M:D

M. David Peterson
Co-Founder & Chief Architect, 3rd&Urban, LLC
Email: m.david <at> 3rdandUrban.com
Voice: (801) 742-1064
Web: http://mdavidpeterson.com
_______________________________________________
Cherokee mailing list
Cherokee <at> lists.octality.com
http://lists.octality.com/listinfo/cherokee
Locke Bircher | 9 Jun 2012 02:41
Gravatar

Re: Cherokee Running on Windows! (Azure)

Very interesting. I look forward to see what sort of performance difference you see in EC2 vs. Azure Virtual Machines. In my experience I was not happy with EC2.

-Locke

On Fri, Jun 8, 2012 at 8:31 PM, M. David Peterson <m.david <at> 3rdandurban.com> wrote:
On Fri, Jun 8, 2012 at 6:25 PM, M. David Peterson <m.david <at> 3rdandurban.com> wrote:
the simple fact that we can now use Cherokee as the front facing server

... on Windows Azure (is what should have been included in my previous email which, just in case any of you are unaware, the new release of Azure includes, amongst other things, the ability to run Linux and Windows Server-based virtual machines alongside the rest of the Azure stack: http://weblogs.asp.net/scottgu/archive/2012/06/07/meet-the-new-windows-azure.aspx

Sorry for any confusion!


--
/M:D

M. David Peterson
Co-Founder & Chief Architect, 3rd&Urban, LLC
Email: m.david <at> 3rdandUrban.com
Voice: (801) 742-1064
Web: http://mdavidpeterson.com

_______________________________________________
Cherokee mailing list
Cherokee <at> lists.octality.com
http://lists.octality.com/listinfo/cherokee


_______________________________________________
Cherokee mailing list
Cherokee <at> lists.octality.com
http://lists.octality.com/listinfo/cherokee
Stefan de Konink | 10 Jun 2012 02:21
Picon
Gravatar

Stable-more-Stable Weekly update

Hi,

It is a few days after the initial announcement, and received some 
blessings already for the effort. Cherokee is not dead, and got the code 
to prove it :-)

On Thu, 7 Jun 2012, Stefan de Konink wrote:

> 1) The biggest issue in the "stable" branch is the fact that SSL and POST 
> support is problematic due to recent Google 'inventions'. With some support 
> of Google in the past (and some workarounds by myself) it is possible to get 
> a working Cherokee "stable" anyhow.

Bug 1284 is fixed. Yes, a one-liner, but one that probably makes more 
sense than my previously attempt. Take a look, apply the patch, and you 
will see it works. Sadly Google decided that Chrome 20 will disable 
False-Start again. The bright side is: we finally have it working!

<http://code.google.com/p/cherokee/issues/detail?id=1284>

In the past few days I have closed many tickets, if you feel this was too 
fast or incorrect, please let us know. I would also ask you if you do 
have a reproducable bug: try to see if you can make a QA-test out of it.
There are almost 300 examples (yes, we have almost 300 QA-tests!) to get 
inspiration from.

Things I would like to address before our next update;

1) The community section of cherokee-project.org is down for ages. We need 
to address that.

2) I'm pretty happy that git is a distributed versioning system, but I 
would love to apply all the fixes that have been made in the previous few 
days to our stable branch. Which means I would have to be in the git team.

3) Lets have a great start of the summer and set the next release date of 
the stable branch to 21st of june. That means we have less than two weeks 
to take care of a proper release candidate, and should ask people to make 
packages for their distribution of choice. In true Cherokee style this 
release will have a songname: you might be able to guess what the song 
would be :-)

Stefan
Etienne Desautels | 11 Jun 2012 17:39
Picon
Favicon

Bugs and Cherokee State


Hi,

I'm glad to read that someone (Stefan de Konink), want to give some love to the "stable" branch of Cherokee. I
was on the point of changing to something else (probably Nginx). And I'm sure I'm not the only one. The list
was mostly dead, the community seems to collapse quickly. This is bad signs for an open source project.

Here are the issues that bugs me:

1. Recently my client upgrade Firefox from 3.6 to version 10 ESR. Result: all pages of their site served
under HTTPS are a lot slower (at least 3x slower).

After a few tests the problem really seem to come from the combination of Firefox 10+, SSL/TLS and Cherokee
(1.2.101). I tried many sites that can be view in HTTPS and HTTP with Firefox 10 and Firefox 3.6 and most
sites served by Cherokee were more slow only with Firefox 10 under HTTPS. I didn't see any significant
differences with site served by other servers.

The slowness really come from the server, not the browser. If I look in Firebug on the network panel, my
typical page under HTTPS and FF10 take around 1.15 sec. to load, most of this time is waiting. Same page with
FF3.6 under HTTPS took 200 ms.

2. The Timeout settings are not respected under SSL/TLS. To whatever value I set the timeout setting
(via
general > network settings > timeout
or
vserver > behavior > restrictions > timeout),
the server always timeout after 15 sec.

It's with cherokee 1.2.101 on Ubuntu 10.04 with uwsgi (-t 600) and over SSL.

I ask about this one on the list before and I only got 1 answer of someone having the same problem.

3. The Google Chrome bug.

I can open issues in the tracker if needed.

One last think, I really think that Alvaro didn't dealt with his transition really well. He didn't give any
news for a long time and after that it say that it will work on a new Cherokee. That sounds to most Cherokee
users like "I will not fix your bugs". But the problem is that for most people the most important thing in web
server is that it work and work now. After struggling with many SSL related bugs (and some not SSL related)
hearing that from Alvaro make me feel that I bet on the wrong horse.

Etienne
Stefan de Konink | 11 Jun 2012 18:06
Picon
Gravatar

Re: Bugs and Cherokee State

Hi Etienne,

> The slowness really come from the server, not the browser. If I look in 
> Firebug on the network panel, my typical page under HTTPS and FF10 take 
> around 1.15 sec. to load, most of this time is waiting. Same page with 
> FF3.6 under HTTPS took 200 ms.

Could you check if the same things happens using the *latest* stable 
github version? There are quite some stability changes in so I hope it is 
actually fixed. If not, please let us know.

Stefan
Stefan de Konink | 12 Jun 2012 11:02
Picon
Gravatar

Re: Bugs and Cherokee State

On Mon, 11 Jun 2012, Etienne Desautels wrote:

> 1. Recently my client upgrade Firefox from 3.6 to version 10 ESR. 
> Result: all pages of their site served under HTTPS are a lot slower (at 
> least 3x slower).

I have tested in Chrome with and without false-start 
(--disble-ssl-false-start) and it becomes clear that the first request in 
the keep-alive request takes about one second 'extra', the one second 
sounds like a programmed timeout to me.

Thus although we have 'fixed' the POST breakage, which is obviously a step 
in the right direction, figuring out where this one second comes from (a 
delay induced by the webserver, or a anticipation from the client on the 
webserver not doing something yet) sounds like a good thing more people 
can help with using CHEROKEE_TRACE=all.

I have asked Etienne to log a bug in the Google Bugtracker.

Stefan

Gmane