Azure-docs: agentKeepALive recommendation probably not a great choice

[tony-gutierrez]

This library has had a possible socket bug for a year now. There doesnt seem to be a great alternative, mainly because most environments have faster and more ports than Azure app services.
https://github.com/node-modules/agentkeepalive/issues/57

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 99e6469b-0c90-c4ba-cf41-354ea4919ea2
• Version Independent ID: 80944b77-6b15-5f0b-5388-ee4430dd090e
• Content: Best practices and troubleshooting for Node.js - Azure App Service
• Content Source: articles/app-service/app-service-web-nodejs-best-practices-and-troubleshoot-guide.md
• Service: app-service-web
• GitHub Login: @ranjithr
• Microsoft Alias: ranjithr

[DashleenBhandari-MSFT]

@tony-gutierrez , Thanks for raising this issue. I will check and update you.

[DashleenBhandari-MSFT]

Hi Tony,
Apologies for the delay.
Could you please try using the connection pooling that comes along with the Node version itself?
AgentKeepAlive is a node module. Connection pooling in the node module is built by open source community.
The Node runtime comes with the agent that can do connection pooling. In earlier versions of the node it did not function properly.
The newer node version may be better and we can try the connection pooling available with the module itself. Please let us know if this helps you.

[tony-gutierrez]

The problem with normal node keep alive is that azure services
(notification hub, service bus, etc) tend to forcefully close the socket
after 120 seconds of being open (active or not). Then node tries to reuse
the socket for the next request, and find it's closed, and the request
fails.

This is not an issue with most other servers that aren't related to
Microsoft services.

Agent keepalive now has a setting to kill the socket after a certain time
since open (TTL). That can be set to less than 120 for MS servers, but does
not eliminate econnreset errors, especially with notification hub.

I would challenge anyone at Microsoft to write a sample node app for a
Windows app service, that uses keep alive and sends high traffic to
notification hub node sdk, without socket errors. I'm not convinced it is
possible.

On Wed, May 8, 2019, 1:31 AM DashleenBhandari-MSFT [e-mail]
wrote:

Hi Tony,
Apologies for the delay.
Could you please try using the connection pooling that comes along with
the Node version itself?
AgentKeepAlive is a node module. Connection pooling in the node module is
built by open source community.
The Node runtime comes with the agent that can do connection pooling. In
earlier versions of the node it did not function properly.
The newer node version may be better and we can try the connection pooling
available with the module itself. Please let us know if this helps you.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MicrosoftDocs/azure-docs/issues/29600#issuecomment-490353153,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADVCNM2YBTJ6Q3VAUAAQHZDPUJQSDANCNFSM4HGWUZMQ
.

[DashleenBhandari-MSFT]

@tony-gutierrez , I would request you to open a support case with Azure App Services team. We would like to work closer with you.
Please let me know if you have a support plan already to open the support case.

[DashleenBhandari-MSFT]

@tony-gutierrez Please let us know if you need further assistance in opening a support ticket with us.

[tony-gutierrez]

Ill attempt to find time to look into this with support, but feel that if MS is going to provide such a low port and slow port recycling to app service users, they should provide a solid port recycling strategy that does not rely on a buggy open agentkeepalive library with stalled development.

[DashleenBhandari-MSFT]

@tony-gutierrez , Thanks for the feedback and I will share this with the product group. It will definitely help if you will be able to open the support ticket.

[gunzip]

hi @tony-gutierrez, I've seen another comment of you here: https://github.com/Azure/azure-storage-node/issues/455#issuecomment-407094425

in the end, do you suggest to use the agentkeepalive library or go with the native nodejs agent support ? can you share some settings that worked well for you ? we're in the same route.

[tony-gutierrez]

@gunzip If you are hosting on an Azure app service, or talking to Azure APIs (cosmos, etc) you need agentkeepalive.

This is because microsoft servers drop a socket after 120seconds....whether it is active or idle. So no socket should live longer than that in your code. It's really dumb.

Here is what I use:

{
        keepAlive: true,
        maxSockets: 25,
        maxFreeSockets: 10,
        timeout: 60000,
        freeSocketTimeout: 30000, //not used if using normal agent
        socketActiveTTL: 110000 //ms lameness
    }

you might want to adjust maxSockets ....its per host, so the math is basically how many hosts are you reaching out to on a regular basis, and trying to keep that * maxSockets under the appservice limit...which is 160 or so, don't remember exactly.

[tony-gutierrez]

As far as the bugs in agentkeepalive, no one could ever replicate the race condition, and in general it seems to be working pretty well. So my original complaint in the issue is probably not valid.

[jmsims2]

@tony-gutierrez Trying to get this to work on azure app service now...seeing intermittent ECONNRESET, terribly frustrating. Did you use this with expressjs or another library? Trying to integrate it now, but can't tell if it's working or not? How did you test to know it was working? Any help would be greatly appreciated!

[tony-gutierrez]

I used express, with the configuration above. My belief is that you will never see 0 connreset errors on an azure app service.

[jmsims2]

Thanks @tony-gutierrez. We have a weird setup where we are making a lot of outbound connections to various Dynamics 365 or Salesforce CRM systems. We have never seen an issue with salesforce using their jsforce library, but see these with connecting to Dynamics using request-promise. Switching to axios and going to try using an agent with it, just trying to work through the implications of one client using an agent and another not.