How to control keepalive connections for upstream before the version of 1.15.3

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

How to control keepalive connections for upstream before the version of 1.15.3

yf chu
The Nginx document said that there are two upstream-related directives introduced in the version of 1.15.3:  "keepalive_requests" and "keepalive_timeout".  But the directive "keepalive" has already been instroduced in the version of 1.1.4. So I want to know how does Nginx handle the keepalive connections for upstream before the version 1.15.3 was released. When will the keepalive connections for upstream be closed?


 


_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|

Re: How to control keepalive connections for upstream before the version of 1.15.3

Maxim Dounin
Hello!

On Mon, Feb 25, 2019 at 03:45:27PM +0800, yf chu wrote:

> The Nginx document said that there are two upstream-related
> directives introduced in the version of 1.15.3:  
> "keepalive_requests" and "keepalive_timeout".  But the directive
> "keepalive" has already been instroduced in the version of
> 1.1.4. So I want to know how does Nginx handle the keepalive
> connections for upstream before the version 1.15.3 was released.
> When will the keepalive connections for upstream be closed?

Before the introduction of "keepalive_requests" and
"keepalive_timeout" directives in 1.15.3, upstream connections
were simply kept open by nginx, regardless of the number of
requests made in these connections, or the time these connections
were idle.  Connections were closed when the upstream server
decided to close them, or when a connection was evicted from the
cache by other connections.

--
Maxim Dounin
http://mdounin.ru/
_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|

Re:Re: How to control keepalive connections for upstream before the version of 1.15.3

yf chu
But if a connection to upstream is dead or there are some other network problems in this connection, how could Nginx handle it, will the HTTP requests on this connection be affected? For example, is it possible that the HTTP requests on this connection is hanging until timeout?  






At 2019-02-25 20:22:56, "Maxim Dounin" <[hidden email]> wrote: >Hello! > >On Mon, Feb 25, 2019 at 03:45:27PM +0800, yf chu wrote: > >> The Nginx document said that there are two upstream-related >> directives introduced in the version of 1.15.3: >> "keepalive_requests" and "keepalive_timeout". But the directive >> "keepalive" has already been instroduced in the version of >> 1.1.4. So I want to know how does Nginx handle the keepalive >> connections for upstream before the version 1.15.3 was released. >> When will the keepalive connections for upstream be closed? > >Before the introduction of "keepalive_requests" and >"keepalive_timeout" directives in 1.15.3, upstream connections >were simply kept open by nginx, regardless of the number of >requests made in these connections, or the time these connections >were idle. Connections were closed when the upstream server >decided to close them, or when a connection was evicted from the >cache by other connections. > >-- >Maxim Dounin >http://mdounin.ru/ >_______________________________________________ >nginx mailing list >[hidden email] >http://mailman.nginx.org/mailman/listinfo/nginx


 


_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|

Re: Re: How to control keepalive connections for upstream before the version of 1.15.3

Maxim Dounin
Hello!

On Mon, Feb 25, 2019 at 09:46:56PM +0800, yf chu wrote:

> But if a connection to upstream is dead or there are some other
> network problems in this connection, how could Nginx handle it,
> will the HTTP requests on this connection be affected? For
> example, is it possible that the HTTP requests on this
> connection is hanging until timeout?  

If a connection is silently dead, nginx will have to wait till a
relevant timeout expires.  If a network error occurs, nginx will
be able to detect this and will act accordingly.  If a network
error or timeout occurs when re-using a keepalive connection,
nginx will retry a request as per proxy_next_upstream (and will
allow an additional retry attempt to make sure even requests to a
single upstream server a retryed).

Note this doesn't really depend on using keepalive connections, as
well as keepalive_requests and keepalive_timeout directives.  
Though some network problems may become more obvious when using
keepalive connections.  In particular, a statefull firewall
between nginx and a backend can be a problem if states are dropped
after some inactivity timeout, and using keepalive_timeout may
help to mitigate such problems (though using proxy_socket_keepalive
or removing the firewall might be a better way to go).

The main goal of the keepalive_timeout directive is to avoid the
race between closing of a connection by the upstream server and
using this connection for another request, most importantly in
case of non-idempotent requests which cannot be retried.

The main goal of the keepalive_requests directive is to make sure
connections will be closed periodically and connection-specific
memory allocations will be freed.

--
Maxim Dounin
http://mdounin.ru/
_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|

Re: Re: How to control keepalive connections for upstream before the version of 1.15.3

ramirezc
I'm use Nginx  proxy to tomcat, tomcat have two parameters manage keep
alive, first one is keepAliveTimeout : how the connection idle time; second
is maxKeepAliveRequests : how the connection reuse counts;

when use Nginx version before the version of 1.15.3, Nginx can't know when
tomcat will be close connection, so online have 502 error;

I'm analysis network packages, find have two reasons cause 502 error to
occur; but there have same root reason;

fist reason : tomcat keepalive time is arrived and close handle, but nginx
don't know that; cause recv() failed (104: Connection reset by peer) while
reading response header from upstream;

second reason : tomcat have send tcp fin package , but nginx also send
request to it; case upstream prematurely closed connection while reading
response header from upstream;

I have adjust the size of keepAliveTimeout, but the problem still occur,
because use nginx with version before 1.15.3;

how can I slove this problem?

Posted at Nginx Forum: https://forum.nginx.org/read.php?2,283137,286282#msg-286282

_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|

Re: Re: How to control keepalive connections for upstream before the version of 1.15.3

Francis Daly
On Tue, Nov 19, 2019 at 09:48:23PM -0500, wu560130911 wrote:

Hi there,

> when use Nginx version before the version of 1.15.3, Nginx can't know when
> tomcat will be close connection, so online have 502 error;

> I have adjust the size of keepAliveTimeout, but the problem still occur,
> because use nginx with version before 1.15.3;
>
> how can I slove this problem?

If it is important in your use case that when keepalive works, keepalive
honours the extra limits; then you probably should either stay with the
same nginx version and disable keepalive; or update to the newer version
and use the extra limits.

Any other change that involves "deploy a modified version of nginx",
is probably more work than just "update".

Good luck with it,

        f
--
Francis Daly        [hidden email]
_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx