We Keep Coding

Azure App Service - An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full

I am running an Azure App Service instance and after about a day or so with perhaps 15-30 people using the site, no one can access the MySQL database anymore and they just get this error when initiating a request:
"An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full"
I have many instances that work just fine with MSSQL (all of my other App Services have SSL's), but this is my first App Service that has given this error (and just so happens to be a MySQL database). This particular instance that has the issue also currently does not have an SSL, but I'm not sure if that has anything to do with the issue.
I have tried mimicking all settings from my working App Services and it still does not work. I'm not sure exactly how to diagnose the issue. All of my database calls are being closed and I am disposing of the connections, and also they all use the "using" statement, yet I still get this error. Any guidance would be greatly appreciated. Thanks.

An operation on a socket could not be performed
because the system lacked sufficient buffer space or
because a queue was full
The above error is usually not because of the MySQL but it is because of the OS on top the MySQL is running.
There are two OS level reasons for this the first one is related to the memory allocation and the other one would regarding the TCP port allocation.
The above error will be encountered is the MySQL program gets more memory (RAM) than OS itself so much so that the OS can't function properly, and you will get the error.
The second reason would be that the port which is used is higher than the allowed TCP “ephemeral” ports. For windows the limit is set to 5000. Since you are using MYSQL and MYSQL default TCP port is 3306 . This probably is not the reason.
Now to remedy the memory related issue we have to edit the boot.ini file in which we have to remove the /3gb switch as it will prevent the applications from accessing extra memory and will give more memory to the OS.
To edit the boot.ini we can either do it through Bootcfg which is a command line tool for editing boot.ini another way to edit the boot.ini would be through a text editor ideally notepad. You can open the boot.ini by running the following command.
notepad.exe Boot.ini
Refer this MSDOC on editing Boot.ini
you can also refer this Artilcle by Dan Benediktson on the same issue.

Using ClickOnce to automatically update company application with personal FTP server

This is my first Stack Overflow question so apologies if this isn't great...
I'm sure this is something either super simple I am missing or something very complex that I've gotten myself into, but I am using ClickOnce for the first time to create an automated updater for a company application I developed.
The application itself was originally written in VB but I have translated it into C#. We use this to automate a database of assets, which changes very frequently. I have been tasked to allow it to complete automated updates to keep from confusing some of the techs with uninstall/reinstalling the application weekly.
I volunteered to make an FTP server using a personal server machine I use at home. Normally this machine would be used for local networking but I've wanted to create an FTP server for some time (this is my first FTP server too).
So I went on my way, set the publish location for the build to ftp://[IP.ADDRESS]:21/Folder/Subfolder and the Installation folder URL to http://[IP.ADDRESS]:21/Folder/Subfolder
Long story short, when I try to test an update (changing only the assembly version), I am an error:
System.Deployment.Application.DeploymentDownloadException: Downloading http://[IP.ADDRESS]:21/Folder/Subfolder/applciation.application did not succeed ---> System.Net.WebException: The server committed a protocol violation.
I did some research and tried adding an SSL certificate and changed the update path to https://[IP.ADDRESS]:21/Folder/Subfolder/ then tested that. This time around, I get this error:
System.Deployment.Application.DeploymentDownloadException: Downloading http://[IP.ADDRESS]:21/Folder/Subfolder/applciation.application did not succeed ---> System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a send. --> System.IO.IOException: The handshake failed due to an unexpected format.
I cannot tell if this is progress or if I moved backwards here LOL. I've been jumping back and forth and going to many threads to try to figure out where this is going wrong. I'm also having a pretty tricky time finding out if this is an error with how I've set up ClickOnce or if this is an error in how I have set up FTP with IIS.
Apologies if this is not enough information, I can provide more if necessary. Also apologies if this is too much information! Any help or guidance is appreciated!

I'm guessing you're working for a small company and infrastructure/resources are at a premium. With that in mind I'll offer some suggestions:
Does your company have a network shared drive? I don't like ClickOnce, but I have deployed it to network shares in the past with success. This has the benefit of you not needing to deal with security.
Have you considered migrating this to a web application? Web development seemed really daunting when I was a native app developer, but with Blazor and ASP.NET Core it's become a lot more accessible. This would completely get rid of the need for updating the application.
Consider an alternative deployment route. ClickOnce is not incredibly well supported.
I'd be remiss if I didn't throw a red flag on security. FTP is a very old protocol and is basically insecure by design. Hosting it on your home server means that you're transmitting the app over the public internet... What would happen if someone outside your company installed the application?

Oracle Rightnow Unable to connect to remote server

I am using Oracle Right now CRM. while opening the cloud application users are getting the error messages quite often, not all the time. first we thought it was because of the bandwidth usage so we tried allocation 1:1, 10 MBPS leased line for it. but still the same error is throwing.
http://textuploader.com/kyt2

Are you behind a firewall? The RightNow app requires that quite a few hosts be opened up to outgoing traffic. The list of hosts can be found in the RightNow Environmental Configuration Guides (https://cx.rightnow.com/app/answers/detail/a_id/2364/kw/Environmental%20configuration%20guide).
Find your CX version and check to make sure that outgoing traffic is open to all required hosts including:
*.custhelp.com
*.rightnowtech.com
*.rightnow.com
*.rnttraining.com
*.livelook.com and *.livelook.net (for co-browse functionality)
*.birst.com (for Enterprise Analytics functionality)
*.hivelive.com (for Oracle RightNow Social functionality)
*.rnengage.com
The guides contain other notes around network requirements that my be helpful.

Delayed Write Failed on Windows 2003 Clustered Fileshare

I am trying to solve a persistent IO problem when we try to read or write to a Windows 2003 Clustered Fileshare. It is happening regularly and seem to be triggered by traffic. We are writing via .NET's FileStream object.
Basically we are writing from a Windows 2003 Server running IIS to a Windows 2003 file share cluster. When writing to the file share, the IIS server often gets two errors. One is an Application Popup from Windows, the other is a warning from MRxSmb. Both say the same thing:
[Delayed Write Failed] Windows was unable to save all the data for the file \Device\LanmanRedirector. The data has been lost. This error may be caused by a failure of your computer hardware or network connection. Please try to save this file elswhere.
On reads, we are also getting errors, which are System.IO.IOException errors: "The specified network name is no longer available."
We have other servers writing more and larger files to this File Share Cluster without an issue. It's only coming from the one group of servers that the issue comes up. So it doesn't seem related to writing large files. We've applied all the hotfixes referenced in articles online dealing with this issue, and yet it continues.
Our network team ran Network Monitor and didn't see any packet loss, from what I understand, but as I wasn't present for that test I can't say that for certain.
Any ideas of where to check? I'm out of avenues to explore or tests to run. I'm guessing the issue is some kind of network problem, but as it's only happening when these servers connect to that File Share cluster, I'm not sure what kind of problem it might be.
This issue is awfully specific, and potentially hardware related, but any help you can give would be of assistance.
Eric Sipple

I've heard of AutoDisconnect causing similar issues (even if the device isn't idle). You may want to try disabling that on the server.

I am having similar problems:
writing to a machine that is also part of a Windows 2003 R2 NLB cluster sometimes results in "Delayed Write Failed" or "the semaphore has timed out" or "the specified network name is no longer available"
this is reproducible for the same files, even after rebooting all machines involved
if I rename the problem-files (some of which are quite small), the problem remains
if I write the files to another location (fysical disk) on the same machine, the problem remains
I uninstalled all anti-virus software, problem remains
I have reset the tcp-ip stack, problem temporarily disappears, but after some time the problem returns for the same files
PARTLY SOLVED the problem:
I deleted (not stopped) the host from the NLB cluster. Problem solved.
Seems to have to do something with writing to a share on a server that is also part of a network load balancing cluster
I have not yet found other people posting NLB cluster related file write problems. However, I did find many posts complaining about similar problems, none of which seem to have been solved.
Anne

I've seen other people reporting the "delayed write failed" error. One recommendation was to adjust the size of the cache, there's a utility from sysinternals (http://technet.microsoft.com/en-us/sysinternals/bb897561.aspx) that will allow you to do that.

SQL Server 2000 intermittent connection exceptions on production server - specific environment problem?

We've been having intermittent problems causing users to be forcibly logged out of out application.
Our set-up is ASP.Net/C# web application on Windows Server 2003 Standard Edition with SQL Server 2000 on the back end. We've recently performed a major product upgrade on our client's VMWare server (we have a guest instance dedicated to us) and whereas we had none of these issues with the previous release the added complexity that the new upgrade brings to the product has caused a lot of issues. We are also running SQL Server 2000 (build 8.00.2039, or SP4) and the IIS/ASP.NET (.Net v2.0.50727) application on the same box and connecting to each other via a TCP/IP connection.
Primarily, the exceptions being thrown are:
System.IndexOutOfRangeException: Cannot find table 0.
System.ArgumentException: Column 'password' does not belong to table Table.
[This exception occurs in the log in script, even though there is clearly a password column available]
System.InvalidOperationException: There is already an open DataReader associated with this Command which must be closed first.
[This one is occurring very regularly]
System.InvalidOperationException: This SqlTransaction has completed; it is no longer usable.
System.ApplicationException: ExecuteReader requires an open and available Connection. The connection's current state is connecting.
System.Data.SqlClient.SqlException: Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.
And just today, for the first time:
System.Web.UI.ViewStateException: Invalid viewstate.
We have load tested the app using the same number of concurrent users as the production server and cannot reproduce these errors. They are very intermittent and occur even when there are only 8/9/10 user connections. My gut is telling me its ASP.NET - SQL Server 2000 connection issues..
We've pretty much ruled out code-level Data Access Layer errors at this stage (we've a development team of 15 experienced developers working on this) so we think its a specific production server environment issue.

The Invalid Viewstate error is pretty common in a high traffic web site. Though, if you recently moved to multiple web servers, make sure you're sharing the same machine key so Viewstate is signed with the same key on all servers. http://www.codinghorror.com/blog/archives/000132.html
Based on the other errors I'd guess that you are using shared connections across multiple threads. Are your connections stored in static variables, Application state, Session state, or other object that's used across multiple requests? Maybe there's a hashtable somewhere containing connections, commands, or transactions. None of the ADO.Net objects are thread safe. So, make sure you only use them in a single threaded fashion.
Another possibility is you're passing around the ADO.NET objects and not consistently disposing of them and managing their scope. Maybe they're cached in the request context or some such?

I know you don't want to hear this, but people smarter than I have said it (check out McConnell's Code Complete if you don't believe me):
It's probably your code, and your gut is probably correct:
My gut is telling me its ASP.NET - SQL
Server 2000 connection issues..
The Errors being thrown are quite specific, and contextually, they look like they're just trying to connect and having a hard time -- which if it only happens in the client's environment, could be indicative of a setting not set correctly for the VM to access TCP connections on the host machine (under a different instance).
Are you sure that none of your code has changed since before the move, and that your previous environment had logging like this enabled? It may have been happening (to a lesser degree) before, but your environment didn't catch it because you didn't have logging enabled.
If that's not the issue, and I'm reading your post correctly: You're running a server on a guest instance provided by the client on their pipe and bandwidth? If that's the case, then quite possibly (around the same time as that upgrade) some routing configuration was changed, or firewall changes were made, or whatever box the instance is on had some change made now that it handles your stuff differently.
If you can't reproduce it in your environment, and you are 100% certain that it isn't your code; then logically it can only be their environment that is the issue.

Lads, just as an update, it turned out that the problem was VMWare related under heavy usage - what a fun week! We're changing the code around to suit the VMWare environment and we've seen some improvement already.
Thanks for the suggestions, I appreciate it.