Keepalive connections from Apigee to target

[ozanseymen]

Do we have any documentation about how Apigee handles keepalives when talking to target servers?

The only piece of documentation I could find is about keepalive.timeout.millis in target endpoint configuration.

E.g. are we always doing keepalive even if client hasn't asked for keepalives in northbound request? Settings around pool size, etc.

[#2 · Accepted solution]

@Ozan Seymen , There are few properties in http.properties file using which you can configure the outbound calls keep-alive accordingly on on-perm and contact support if you want on cloud .

# 0  = turn off 
# >0 = turn on
# <0 = respect what is there in the NB request
# defaults to -60000
#HTTPClient.keepalive.timeout.millis=-60000.

Also make sure your LB has necessary settings on the NB side .

[#3 · Accepted solution]

@Ozan Seymen , There are few properties in http.properties file using which you can configure the outbound calls keep-alive accordingly on on-perm and contact support if you want on cloud .

# 0  = turn off 
# >0 = turn on
# <0 = respect what is there in the NB request
# defaults to -60000
#HTTPClient.keepalive.timeout.millis=-60000.

Also make sure your LB has necessary settings on the NB side .

[ozanseymen]

I can't understand the significance of the 3rd option (respect NB request).

Shouldn't Apigee always use keep alive on the southbound irrespective of client preference on the northbound? Why does Apigee target communication get tied to northbound communication?

BTW - keepalive is the default behaviour in HTTP 1.1. So connection must be keepalive even if client is not actively sending keepalive header. http://tools.ietf.org/html/rfc2616#section-8.1.2. So how Apigee understands what client wants is still a mystery to me.

[mdunker]

Agreed -- as long as southbound connection is to a relatively small list of targets, we should strive to keep the target connections alive, especially when using https.

I guess the third option would be where the target is unlikely to be called again any time soon (extremely low bandwidth API) or only by the current caller (maybe the target is specified in the request, or there is machine to machine communication where the target is specific to the current caller). Definitely not normal cases, but possible.

[#6 · Accepted solution]

Hi @oseymen@apigee.com , want to update this thread with my latest findings

#1 As you mentioned, Apigee treats all the calls as keep-alive (keepalive is the default behaviour in HTTP 1.1) but it's up to the server to either respond with connection:keep-alive or connection:close.

#2 An HTTP/1.1 client assumes an HTTP/1.1 connection will remain open after a response unless the response contains a Connection: close header. However, clients and servers still can close idle connections at any time. Not sending Connection: close does not mean that the server promises to keep the connection open forever

#3 The below property in the http.properties or the keep-alive property at target endpoint can be used to close an idle connection.

# The number of mimiseconds a Server Side channnel will be kept open
# defaults to 120,000 
#HTTPServer.keepalive.timeout.millis=120000

[#7]

If we specify a value for the keep alive timeout in the HTTPTargetConnection(different from HTTPServer.keepalive.timeout.millis in the http.properties file on the message processor), which one takes priority?

@Maruti Chand