Re: [PR] MINOR: remove limit of 1k socket connections with systemd

[Lukas Tribus]

Hello,

On Wed, Sep 18, 2019 at 1:14 AM PR Bot  wrote:
> Description:
>systemd by default limits the max open files to 1k, which also limits
>the socket connections to 1k, the service script must be told to
>remove the limit.

Since haproxy is started as root we have the privilege to bump the
ulimit ourselfs. We cannot rely on init scripts or systemd to set
correct values. The values are computed automatically based on maxconn
configuration and then set accordingly by haproxy itself.


So we don't really care about systemd or actual system default limits.


Lukas

[PR] MINOR: remove limit of 1k socket connections with systemd

[PR Bot]

Dear list!

Author: Björn Jacke 
Number of patches: 1

This is an automated relay of the Github pull request:
   MINOR: remove limit of 1k socket connections with systemd

Patch title(s): 
   MINOR: remove limit of 1k socket connections with systemd

Link:
   https://github.com/haproxy/haproxy/pull/280

Edit locally:
   wget https://github.com/haproxy/haproxy/pull/280.patch && vi 280.patch

Apply locally:
   curl https://github.com/haproxy/haproxy/pull/280.patch | git am -

Description:
   systemd by default limits the max open files to 1k, which also limits
   the socket connections to 1k, the service script must be told to
   remove the limit.

Instructions:
   This github pull request will be closed automatically; patch should be
   reviewed on the haproxy mailing list (haproxy@formilux.org). Everyone is
   invited to comment, even the patch's author. Please keep the author and
   list CCed in replies. Please note that in absence of any response this
   pull request will be lost.

Connection reuse for HTTP/2?

[David Pirotte]

Hi all,

Is there a way to multiplex frontend HTTP/2 (GRPC) connections onto a shared 
pool of backend HTTP/2 connections?

My testing shows that one frontend connection with multiple concurrent requests 
will reuse one backend connection, but multiple frontend connections will not 
share backend connections.

Cheers,
Dave

[PR] MINOR: remove limit of 1k socket connections with systemd

[PR Bot]

Dear list!

Author: Björn Jacke 
Number of patches: 1

This is an automated relay of the Github pull request:
   MINOR: remove limit of 1k socket connections with systemd

Patch title(s): 
   MINOR: remove limit of 1k socket connections with systemd

Link:
   https://github.com/haproxy/haproxy/pull/280

Edit locally:
   wget https://github.com/haproxy/haproxy/pull/280.patch && vi 280.patch

Apply locally:
   curl https://github.com/haproxy/haproxy/pull/280.patch | git am -

Description:
   systemd by default limits the max open files to 1k, which also limits
   the socket connections to 1k, the service script must be told to
   remove the limit.

Instructions:
   This github pull request will be closed automatically; patch should be
   reviewed on the haproxy mailing list (haproxy@formilux.org). Everyone is
   invited to comment, even the patch's author. Please keep the author and
   list CCed in replies. Please note that in absence of any response this
   pull request will be lost.

Re: PATCH: install golang-1.13 during travis-ci build as it is required for BoringSSL

[Christopher Faulet]

Le 17/09/2019 à 09:48, Илья Шипицин a écrit :

Willy, can you apply this ?

boringssl builds are bloody murder

пн, 16 сент. 2019 г. в 16:14, Илья Шипицин >:


please see attached patch



Merged.

--
Christopher Faulet

Re: BUG/MEDIUM: spoe: engine-id is necessary if not health check

[Christopher Faulet]

Le 16/09/2019 à 03:40, Kevin Zhu a écrit :

Sorry Crhistopher, have you look at this mail ?

On Mon, 2 Sep 2019 at 16:11, Kevin Zhu > wrote:


Hi Christopher

SPOE engine-id is all same when nbproc is more than 1, the clients all
group under same engine, and same stream-id and frame-id frames may come at
same time. So we alway need engine-id to identify client's and frames.
Best Regards



Hi Kevin,

Don't be sorry. I was busy when received your mail and after I forgot to review 
it. So, thanks for the reminder.


There are 2 parts in your patch. First, about the SPOE engine-id when there is 
more than 1 process, you're right. The engine-id is the same for all instances 
and it's a problem. But if we are fixing this part, we might as well fix it for 
the threads too. For now, the Async mode does not work with several threads just 
because of the engine-id. It is pretty easy to fix, thus I will do it too.


Then, about the mandatory nature of the engine-id, I'm disagree. For 2 reasons. 
First, because health-checks does not provide it. Second, because it is only 
required for the async mode. We can imagine to not send it when this mode is 
explicitly disabled. From the protocol point of view, I prefer to keep it optional.


I can amend your patch to get only part to generate a different engine-id per 
process if you are ok. Then I'll do a fix to have a different engine-id 
per-thread too and always allow the async mode.


--
Christopher Faulet

Re: PATCH: install golang-1.13 during travis-ci build as it is required for BoringSSL

[Илья Шипицин]

Willy, can you apply this ?

boringssl builds are bloody murder

пн, 16 сент. 2019 г. в 16:14, Илья Шипицин :

> please see attached patch
>