Re: possible bug with CumReq info stat

2015-02-05 Thread Willy Tarreau
Hi Lukas, On Mon, Feb 02, 2015 at 10:06:43PM +0100, Lukas Tribus wrote: > >>> There is no SSL protected repo. I'm surprized that you found the > >>> haproxy.org > >>> site slow, usually it's reasonably fast. Are you sure you weren't > >>> cloning from 1wt.eu instead, which is the slow master ? > >

RE: possible bug with CumReq info stat

2015-02-02 Thread Lukas Tribus
>>> There is no SSL protected repo. I'm surprized that you found the >>> haproxy.org >>> site slow, usually it's reasonably fast. Are you sure you weren't >>> cloning from 1wt.eu instead, which is the slow master ? >>> >> >> Would it be possible to get the haproxy org on github to be synced with >>

Re: possible bug with CumReq info stat

2015-02-02 Thread Warren Turkal
All fair points. Too bad you don't have the haproxy org on github. It would be nice if that were a trustworthy source. With regard to the slowness, I am using the following remote config: $ git remote -v origin http://git.haproxy.org/git/haproxy-1.5.git/ (fetch) origin http://git.haproxy.org/git/h

Re: possible bug with CumReq info stat

2015-02-02 Thread Willy Tarreau
On Mon, Feb 02, 2015 at 09:34:37AM -0800, Warren Turkal wrote: > On Sat, Jan 31, 2015 at 4:57 AM, Willy Tarreau wrote: > > > There is no SSL protected repo. I'm surprized that you found the > > haproxy.org > > site slow, usually it's reasonably fast. Are you sure you weren't cloning > > from 1wt.

Re: possible bug with CumReq info stat

2015-02-02 Thread Warren Turkal
On Sat, Jan 31, 2015 at 4:57 AM, Willy Tarreau wrote: > There is no SSL protected repo. I'm surprized that you found the > haproxy.org > site slow, usually it's reasonably fast. Are you sure you weren't cloning > from 1wt.eu instead, which is the slow master ? > Would it be possible to get the h

Re: possible bug with CumReq info stat

2015-01-31 Thread Willy Tarreau
Hi Warren, On Tue, Jan 27, 2015 at 03:04:16PM -0800, Warren Turkal wrote: > The definition of the global.req_count at include/types/global.h line 109 > is an unsigned int. The print code it treating it as a signed int. The > attached commit fixes that. Thanks, I've applied it to both 1.5 and 1.6.

Re: possible bug with CumReq info stat

2015-01-28 Thread Warren Turkal
BTW, the patch in the previous mail was based on the master branch of the haproxy-1.5 repo if that matters. Thanks, wt On Tue, Jan 27, 2015 at 3:04 PM, Warren Turkal wrote: > The definition of the global.req_count at include/types/global.h line 109 > is an unsigned int. The print code it treati