[ 
https://issues.apache.org/jira/browse/TS-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14366754#comment-14366754
 ] 

Dzmitry Markovich commented on TS-3312:
---------------------------------------

[~amc], currently when we return a connection to the pool  (when we call 
release() ) it sets it's inactivity timeout to transaction timeout, so if there 
is no activity on this connection it will be closed after transaction timeout 
(which is much smaller then keep alive timeout). The patch changes this 
behavior and sets it to keep alive timeout. And when we will have an active 
transaction on this connection the timeout will be updated with transaction 
timeout again. 

imagine:
transaction inactivity timeout = 10sec and keep alive timeout = 100sec

So before:
connection->transaction start-> set inactivity timeout to 10sec ->transaction 
end->return connection to the pool-> connection closed after 10 seconds

after the fix:
connection->transaction start-> set inactivity timeout to 10sec ->transaction 
end->return connection to the pool-> set inactivity timeout to 100 sec -> 
connection closed after 100 seconds

in case transaction not ends in 10 sec in both cases connection will be closed 
after 10 secs.

So, technically we have to use both timeouts (transaction and keep alive). One 
controls max time that connection can stay live with no activity on 
activetransaction, and other one controls the max time connection can stay live 
with out any active transactions.

Let me know if it make sense.



> KA timeout to origin does not seem to honor configurations
> ----------------------------------------------------------
>
>                 Key: TS-3312
>                 URL: https://issues.apache.org/jira/browse/TS-3312
>             Project: Traffic Server
>          Issue Type: Bug
>          Components: Core, HTTP
>            Reporter: Leif Hedstrom
>            Assignee: Brian Geffon
>             Fix For: 5.3.0
>
>         Attachments: keep_alive3.diff
>
>
> Doing some basic testing, with the following settings:
> {code}
> CONFIG proxy.config.http.keep_alive_no_activity_timeout_out INT 120
> CONFIG proxy.config.http.transaction_no_activity_timeout_out INT 30
> {code}
> I see ATS timing out the origin sessions after 30sec, with a 
> {code}
> CONFIG proxy.config.http.transaction_no_activity_timeout_out INT 30
> {code}
> What's also interesting, after I made a config change per Geffon's suggestion:
> {code}
> CONFIG proxy.config.http.origin_min_keep_alive_connections INT 10
> {code}
> I see the following in the diagnostic trace:
> {code}
> [Jan 21 14:19:19.416] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0] [release 
> session] session placed into shared pool
> [Jan 21 14:19:49.558] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0] 
> [session_bucket] session received io notice [VC_EVENT_INACTIVITY_TIMEOUT], 
> reseting timeout to maintain minimum number of connections
> [Jan 21 14:20:19.633] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0] 
> [session_bucket] session received io notice [VC_EVENT_INACTIVITY_TIMEOUT], 
> reseting timeout to maintain minimum number of connections
> [Jan 21 14:20:19.670] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0] 
> [session_pool] session 0x1cc5aa0 received io notice [VC_EVENT_EOS]
> {code}
> So, not only is it resetting the timeout twice, it also gets a VC_EVENT_EOS. 
> I first though it was the origin that closed the connection, but from what I 
> could tell, the timeout on the origin was set to 60s.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to