An attempt was made to access a socket in a way forbidden by its access permissions in Azure Web Apps

7
votes

I'm running a webapi on an Azure website that makes calls to external web services. The webapi handles approximately 2K-3K requests per minute.

Periodically, lots of socket errors start occurring that indicate: "An attempt was made to access a socket in a way forbidden by its access permissions". This error seems to occur regardless of the ip address of the external web service.

At first, I thought it might be ephemeral port exhaustion, but I've limited "connectionManagement" to a maximum of 100 connections.

What would be causing this?

Thanks very much. Happy to provide whatever information might be helpful.

Update 6/1: - doesn't work per 6/2

I added the following to my web.config system.net section:

<defaultProxy enabled="false" useDefaultCredentials="false">
   <proxy/>
   <bypasslist/>
   <module/>
</defaultProxy>

It appears to have helped as I haven't seen this issue in the last 6 hours. I have no idea why this would actually help though as I'm not using any proxy-related stuff.

Any thoughts?

Update 6/2:

Adding the defaultProxy doesn't actually appear to help. The problem is still occurring. Back to the drawing board.

1
socketsazureasp.net-web-apiazure-web-app-service
Did you ever find out what the error was? I think I may be running into something similar. – runxc1 Bret Ferrier
I have not figured out the issue yet. It definitely appears to be Azure website related. When I switch my code to AWS everything works fine. – Jonathan
I have found that in changing the size of the website, which forces it to be serves from a different VM that the issue goes away for a few days... – runxc1 Bret Ferrier
Does your site use any libraries like Glimpse? – runxc1 Bret Ferrier
I am not using Glimpse. Why do you think something like that might be the problem? – Jonathan

1 Answers

3
votes

I've finally figured out the cause of this problem. The issue was occurring due to port exhaustion.

I was using an NLog email target which was grabbing and holding onto too many SMTP connections over time (despite the 100 max connection limit). After removing the email target, the issue no longer occurs. I haven't figured out why NLog was exhibiting this behavior.