i have hosted my project on azure server of Asp.net MVC, and i have used azure sql, its work fine, but number of times while performing any operation , i.e. when fire calls from controller it gives error like,
"An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full Ip"
and after few minutes its starts to work fine,
can anyone tell me why this error is throwing or is there any solution for this??
This is most probably client side issue (ASP.Net app side). This could happen if you do A LOT of simultaneous socket connections or do not dispose connections properly. Please double check your application and make sure that:
You properly close all database connections (use using() or call Dispose()).
You properly close any other socket connection (if any).
If your code is fine, you can try to use Transient Fault Handling App Block. It won't solve the issue itself but could help your app to workaround it.
Related
We have an IOS application which only listens on a INADDR_ANY socket connection for inbound connection using CFSocketCreate/CFSocketGetNative/CFSocketCreateRunLoopSource/CFStreamCreatePairWithSocket etc (to display debug information via HTTP).
(So it falls into the category "Listening for and accepting incoming TCP connections").
If the first incoming socket connection happens on a new installed app we run into the error mentioned above. As we do neither use Bonjour nor getpeername() I wonder where the problem is. Obviously it doesn't matter how the dialog is closed, our program works. But it is of course annoying for us (QA is harder) and our customers.
Any idea what could be the problem ?
I looked into all the questions related here, but I think we are not using one of the 'banned' APIs triggering the dialog
If I set a breakpoint to the stream:handleEvent: function of the NSStreamDelegate the popup appears before NSStreamEventOpenCompleted, so it appears some internals of the NSStream processing cause this.
on the debug console this appears btw:
[connection] nw_connection_copy_connected_path [C1] Client called nw_connection_copy_connected_path on unconnected nw_connection 2022-04-06 17:28:55.811551+0200 GenMob[35630:3181485] [] tcp_connection_is_cellular No connected path
I did fiddle together a small demo app downloadable from https://github.com/leopatras/cfsocket.
For the record, we ended up rewriting our code to use plain Berkeley sockets together with the GCD dispatch_source machinery ... there is a working socket server sample not triggering the local network prompt at https://github.com/leopatras/GCDSimpleSocketServer/
The dispatch_source_zzz functions allow a similar event driven approach like the CFStreamCreatePairWithSocket function. In comparison to https://github.com/leopatras/cfsocket it needs even less code. If the local network prompt is always triggered is questionable, it may depend from other parameters such as the used dev certificate/provisioning profile.
I had an intensive exchange with the Apple support about this topic,
(they weren't able to reproduce our problem initially, but after retrying on several devices they got it too) : they did recommend using the new Network framework functions instead of Berkeley sockets (See https://developer.apple.com/documentation/network?language=objc) and I tried hard to use them however I failed to create a simple reliable working echo server with those functions in obj-C (didn't try the Swift route).
I built an Web API with Delphi using FireDac and an HTTPServer component: The application is using a dbms powered by firebird.
Everything was working fine until I the moment I started to simulate multiple requests to the same API endpoint. This is causing internal server exceptions reporting that a second trasaction is being opened when there are already a transaction opened.
I know that all connections are being closed after being used and objects are being destroyed in order to prevent memory leaks but I couldn't understand why do the application triggers the exception.
Any help or toughs that might drive me to a solution?
Multiple requests will be processed concurrently by the HTTP server.
So if two clients try to access the same resource (URL) at the same time, the server will need two sets of database connections and data access components.
If your application uses distinct objects - one set per client - and does this in a thread safe way, both connection should work fine.
However if you use only one datamodule to serve all incoming HTTP requests, proper serialization is required. It does not help to close connections after use, the connections must be used only from one thread at a time.
So to understand the potential reason of the error, more information about the actual design of your server is needed.
I have a server application which runs on a Linux machine. I can connect this application from Windows/Linux machines and can send/recieve data. After a few hours, something occurs and I get following error on the client side.
On Windows: An existing connection was forcibly closed by the remote host
On Linux: Connection timed out
I have made a search on the web and found some posts which suggest to increase/decrease OS's keep alive time. However, it didin't work for me.
Can I found a soultion to this problem or should I simply try to reconnect to the server when the connection is forcibly closed?
EDIT: I have tracked the situation. I sent a data to the remote node and sent another data after waiting 5 hours. Sending side sent the first data, but whet the sender sent the second data it didn't response. TCP/IP stack of the sender repeated this 5 times by incrementing the times between retries. Finally, sender reset the connection. I can't be sure why this is happening (Maybe because of a firewall or NAT - see Section 2.4) but I applied two different approach to solve this problem:
Use TCP/IP keep alive using setsockopt (Section 4.2)
Make an application level keep alive. This is more reliable since the first approach is OS related.
It depends on what your application is supposed to do. A little more information and perhaps the code you use for listening and handling connections could be of help.
Regardless, technically a longer keep alive time, should prevent the OS from cutting you off. So perhaps it is something else causing the trouble.
Such a thing could be router malfunction or traffic causing your keep-alive packet to get lost.
If you aren't already testing it on a LAN (without heavy trafic) I suggest doing so.
It might also be due to how your socket is handled (which I can't determine from your question)
This article might help.
Non blocking socket with timeout
I'm not used to how connections are handled on Linux, but I expect the OS won't cut off a connection unnecessary.
You can re-establish connection as a recovery, but you need to take into account that not all disconnects are gentle, and therefore you could end up making recovery on a connection you actually wish to be closed.
Since it is TCP, it will do its best to make a gentle disconnect, but you can send a custom message telling the server or client not to re-establish the connection right before disconnecting. That way you be absolutely sure, despite that it should be unnecessary to do so.
I create a queue connection factory in Websphere using WebSphere MQ messaging provider.
Using JNDI to get this resource, and try to create queue connection in the same host.
The first time, everything works, but When I will to second time , it will throw a JMS Exception:
javax.jms.JMSException: Failed to create queue connection
at com.ibm.ejs.jms.JMSCMUtils.mapToJMSException(JMSCMUtils.java:141)
at com.ibm.ejs.jms.JMSQueueConnectionFactoryHandle.createQueueConnection(
JMSQueueConnectionFactoryHandle.java:90)
There is SO little information in the post it is hard to do anything but guess. First thing I'd look for is if the application or queue are set for exclusive use. Of course this assumes that you are opening the queue for input and that detail isn't mentioned in the question. Having the linked exception which would provide the actual WMQ reason and completion codes could tell you for sure but these also are not provided in the question.
Many shops consider it a Sev-1 defect if JMS code does not print linked exceptions. This is not a WMQ-specific thing but rather a case of printing out all the diagnostic information available regardless of the transport provider. In case you want more info on this, please see the WMQ Ifocenter JMS exception handling topic.
The Max Connection is there in WAS console. if connection getting more than Max connection and not release the resource (QueueConnection, QueueSender and QueueSession) than at the time of next connection it will fail to get the connection from connection pool. After restarting the Server only you can release the connection. this can be resolve by close all the resource(QueueConnection, QueueSender and QueueSession) properly in code.
Notice how I say not connecting rather than just being slow.
This has been very difficult to reproduce, I am yet to get it to happen consistently and even went to far as to move the application on to a fresh machine thinking it was hardware related but alas, new machine - same issue.
Some captures with Fiddler seems to indicate that the connection is never completed.
Any suggestions on further investigative measures?
Apologies in advance for the vagueness of the question, I am just at a loss.
Can you instrument it from the IIS side? Request tracing could tell you if something is taking so long that the request times out before it returns . . .
Are you attempting to connect via HTTPS? I've had issues in the past when trying to run on my local box and I initiate a HTTPS connection which isn't supported by cassini. When a HTTPS connection fails it's not always obvious why.