This one has been causing me some bother for a while. I have a TcpClient that runs on a thread and trys to connect to the client
client = new TcpClient();
client.Connect(m_Hostname, m_PortNum);
On failure the Connect function throws a SocketException if it cannot connect. Then after say, 10 seconds, it attempts to reconnect. The target client is basically has a listener socket that is only active periodically so it will attempt to reconnect to the target client throughout the lifetime of the program.
The problem is that the message Exception thrown: 'System.Net.Sockets.SocketException' in System.dll is spat out to the debugger every 10 seconds, each time it cannot connect. It seems there is no real way to prevent this from happening. I thought I could potentially check if the target machine is available first before connecting but I cant see this anywhere.
It seems bad to control program flow using exceptions but I am not sure of another way; worst case I'd like to prevent the exception from printing out in the debugger because it causes unnecessary spam.
Related
I am facing some issue in WMQ when trying to establish connection with WMQ Topic from out C# application.
IBM.XMS.XMSException: CWSMQ0006E: An exception was received during the call to the method ConnectionFactory.CreateConnection: CompCode: 2, Reason: 2102.
During execution of the specified method an exception was thrown by another component.
See the linked exception for more information.
at IBM.XMS.Client.WMQ.Factories.WmqConnectionFactory.CreateProviderConnection(XmsPropertyContext connectionProps)
at IBM.XMS.Client.Impl.XmsConnectionFactoryImpl.CreateConnection(String userID, String password)
at IBM.XMS.Client.Impl.XmsConnectionFactoryImpl.CreateConnection()**
WMQ Client Log:
AMQ12984.0.FDC 2018/03/08 06:26:22.700000 Installation1 w3wp 12984 4235 XC035007 xcsCreateThread xecP_E_NO_RESOURCE OK
AMQ12984.0.FDC 2018/03/08 06:26:23.403000 Installation1 w3wp 12984 4235 XC022001 xcsDisplayMessage rrcE_CREATE_THREAD_ERROR OK**
The connectivity works perfectly fine the whole day but sometime in morning it starts throwing the exception. We are reusing the Factory object across difference services but each time service Open - Write Message - Close the connection in factory.
We are using IBM Client V7.5.0.5. This exception is occurring on multiple servers, but on different times, so can't blame processor or server configuration.
We are reusing the Factory object across difference services but each
time service Open - Write Message - Close the connection in factory.
Are you actually closing the connection? Or you letting the framework close the connection which of course it is not? Check your code and explicitly close the connection in your code.
I have a code which disconnects queuemanger when the connection is broken or exception is thrown like below
if (queueManagerreceive != null)
if (queueManagerreceive.IsConnected)
{
if (queuereceive != null)
{
queuereceive.Close();
}
queueManagerreceive.Disconnect();
}
So i have issue with the above code when i have a 'MQRC_RECONNECT_TIMED_OUT'
exception then when it does a queuemanager.Disconnect() it throws an exception "MQRC_CONNECTION_BROKEN" and obviously which breaks the code as an exception is thrown so when i use queuemanager.Close() there was no exception thrown and the service was stable.
What is the difference? what should i use to drop and recreate a new connection?
Please help.
The MQQueueManager.Disconnect() closes all queues/topics/processed opened and closes the connection to queue manager. Calling Disconnect() on an already disconnected connection helps in freeing any resources allocated internally.
MQQueueManager.Close method is actually an inherited method of it's base class and this method closes any internal objects the MQQueueManager has allocated. . But you must always call Disconnect instead of Close because the Disconnect method closes the connection to queue manager while Close does not.
After MQRC_RECONNECT_TIMED_OUT error you have to create a new connection again using new MQQueueManager constructor.
You are getting a MQRC_RECONNECT_TIMED_OUT error which means that an established connection was broken (for whatever reason) and the MQ client attempted to reconnect for 30 minutes but still could not establish connection. You have to understand the reasons for this:
1) Is your queue manager down for that long?
2) Is there a network issue which is preventing connection to queue manager?
3) If your are using a multi-instance queue manager, why application is not getting connected to stand-by instance?
I'm creating a simple (console) application to remote control a video device (encoder) using HTTP requests with C#. I need to send XML data to the device, and the device responds by sending XML data.
The code I'm using to do this request is the following: http://pastebin.com/59CXR3m9
When I try to test this code, the request is created and the stream is written. I can see the "stream created" flag as expected, but then, nothing happens. Application seems to be stuck, even when I'm using a specific low timeout (5 secs for example).
To troubleshoot this, I activated System.Net trace logging. I found a WebException is thrown by GetRequestStream, but for one reason, this exception is not caught by the try/catch in my code. Here's the exception:
System.Net Error: 0 : [1344] Exception in the HttpWebRequest#44223604:: - The underlying connection was closed: The connection was closed unexpectedly.
I can send the complete trace on demand.
I also did another trace with the callstack, showing the exception is thrown by GetRequestStream: http://pastebin.com/vE5QZGBe
I tested this code with another device and it worked fine, so this is something also device-related, but I can't see any reason why that exception would not be caught. And as this can be a production situation, the code has to be able to handle this correctly (and not wait endlessly for a response).
Did somebody already have this type of behavior? Any suggestions are greatly appreciated :)
Thanks!
FYI: I also have a trace of a successful request, if it can help
After I try to close a pipe client, I see the following error in the output console:
A first chance exception of type 'System.Net.Sockets.SocketException' occurred in System.dll
What does it mean? How can I fix it?
See http://blogs.msdn.com/b/davidklinems/archive/2005/07/12/438061.aspx for an explanation of the "first chance exception".
What is a first chance exception?
When an application is being debugged, the debugger gets notified whenever an exception is encountered At this point, the application is suspended and the debugger decides how to handle the exception. The first pass through this mechanism is called a "first chance" exception.
Depending on the debugger's configuration, it will either resume the application and pass the exception on or it will leave the application suspended and enter debug mode. If the application handles the exception, it continues to run normally.
Here is the complete error message:
An exception of type
'System.Web.HttpException' occurred in
System.Web.dll but was not handled in
user code
Additional information: The remote
host closed the connection. The error
code is 0x80070057.
and the offending code:
char[] buffer = oPage.HTML.HTML.ToCharArray();
Page.Response.Write(buffer, 0, buffer.Length);
Page.Response.Flush();
Page.Response.End();
The oPage.HTML.HTML is a string in a custom page object used by our app. The exception triggers on Page.Flush() and appears to be benign -- I just hit "continue" and everything goes along fine. This never appears at run time.
I have chased many, many Google hits down many rabbit holes and have found nothing. Visual Studio 2005, Vista Ultimate (IIS7).
I've been dealing with this same error for a while now, and my understanding is that when Flush is called, there must be a connection on the other end, otherwise, this error is thrown. It's easy to get into a "fire-and-forget" kind of model when writing web pages, but when the client disconnects (in this debugging case, you're the client), there's nowhere to flush to.
There are two solutions I've found to this:
Wrap Response.Flush and catch the exception.
Check Response.IsClientConnected before you call flush.
I'm not 100% sure about the second one...I'm still in the process of checking that one out.
Good luck!