I can use this program on my own computer, but I can not use on the server.
Server use supreme authority Administrator to open the program.
Server WCF HTTP Activation Feature with .NET4.5 is opening.
Server endpoint address use "http://localhost" like following
endpoint address="http://localhost" binding="basicHttpBinding" bindingConfiguration="NewBinding0" name="ProductService" contract="ProductService.IWCFProductService"
Wrong Message:
The communication object, System.ServiceModel.ServiceHost, cannot be used for communication because it is in the Faulted state.
Stack trace at System.ServiceModel.Channels.CommunicationObject.Close(TimeSpan timeout)
at System.ServiceModel.ServiceHostBase.System.IDisposable.Dispose()
at FileUtilityHelperService.Program.Main(String[] args)
This simply means that there has been an unexpected exception somewhere in your code. The error message "...because it is in the Faulted state" means that communication between the server and the client is unusable.
What you need is better error handeling.
Use try/catch around your code that can potentially generate an exception
Always order exeptions from the most specific to the least specific
You would probably like to log your errors to a file or database, log4net is great for this (and comes as a nuget package)
Related
I am working on a .NET API that runs inside of a docker container. At some point it makes a call to a Python Flask API that is also running in a container.
var response = await httpClient.GetAsync("http://service-name:8000/actual/url")
which then produces the following error:
System.Net.Http.HttpRequestException: Resource temporarily unavailable
---> System.Net.Sockets.SocketException (11): Resource temporarily unavailable
at System.Net.Http.ConnectHelper.ConnectAsync(String host, Int32 port, CancellationToken
cancellationToken)
Has anyone had experience with this before and potentially knows a solution? I cant find much on the web about it at all. I have some seen some mentions of the issue potentially being related to the Flask API not using async methods but that doesnt make sense to me.
The Flask API produces the appropriate responses when accessed through a web browser or Postman using localhost:8000/actual/url and the container logs these responses. I have tried using the localhost URL in the .NET API but that does not work either.
If anymore information is needed please leave a comment and I will do my best to update the post quickly.
-- Christie
TLDR
A reason for the "Resource temporarily unavailable" error is when during name resolution the DNS Server responds with RCODE 2 (Server failure).
Long answer
I noticed the same behavior in a dotnet application running in a dotnet runtime alpine docker container. Here are the results of my investigation:
The error message "Resource temporarily unavailable" corresponds to the EAGAIN error code which gets returned by various functions from the C standard library. At first I suspected the connect() function because the C# stack trace indicates the error happening during the ConnectAsync() call of the c# socket. And indeed the EAGAIN error code appears in the man page of connect() with this description: "No more free local ports or insufficient entries in the routing cache".
I simulated a system with depleted local ports and noticed that a different exception gets thrown in that case, which rules out local port availability as a root cause for the original exception. Regarding the other mentioned cause in the man page it turns out that the routing cache was removed from Linux in 2012. commit
I started to look around for EAGAIN in the source of the musl C lib which is used in the dotnet runtime alpine docker container. After a while I finally noticed the gethostbyname2_r function which is used for resolving a domain name to an ip address via DNS. During System.Net.Sockets.Socket.ConnectAsync() the hostname is still a string and the name resolving happens in native code using the gethostbyname2_r function (or one of its variations).
The final question is: When does gethostbyname2_r return the EAGAIN error code? It's when the RCODE field in the header of the DNS Response has the value 2, which stands for "Server failure". source line 166
To verify this result I ran a simple mock DNS server which always returns the RCODE 2 in the DNS response. The resulting c# exception along with the stack trace matched the original exception exactly.
I've an application (on production environment) that makes a lot of concurrent (multithreading) calls to WCF services (.Net Framework 4.0, SOAP BasicHttpBinding). Sometimes, the last request throws a TimeoutException:
System.TimeoutException: The request channel timed out while waiting for a reply after...
I can't reproduce it on a local envrionment, so it's difficult to apply changes to try. Anyway I've increased the timeout but the exception is throwing equally (later evidently). I've traced the server searching for inter-threading locks or Oracle locks, but I couldn't find anything.
I've activated internal code traces and I've deduced that the request didn't reach my server code, so, watching the IIS traces I've found an HTTP error ~2' after the request:
sc-status sc-substatus sc-win32-status time-taken
500 0 64 118265
But the timeout exceptions is thrown later depending on the wcf binding configuration. So I have two questions:
Why WCF is not catching that http error and remains waiting for response? I've searched for the error but I have high values on servicethrottling parameters.
Why the server is throwing that error without getting the server code not even an on an IDispatchMessageInspector I've implemented to log some data on request and response?
In a UWP application, I can set something like this to enable self-signed certificates when connecting StreamSocket to an SSL-enabled host:
streamSocket.Control.IgnorableServerCertificateErrors.Add(ChainValidationResult.InvalidName);
streamSocket.Control.IgnorableServerCertificateErrors.Add(ChainValidationResult.Untrusted);
await streamSocket.ConnectAsync(new HostName("localhost"), "993", SocketProtectionLevel.Tls12);
However, I would like to make it possible for the application to examine which errors actually occurred during the connection. I thought I'd use this:
streamSocket.Information.ServerCertificateErrors
However, this collection is empty in my tests. It only gets populated in case when streamSocket.Control.IgnorableServerCertificateErrors is empty and thus the connection is aborted with an exception. I would like to have the connection established (i.e. SSL errors ignored) but still have these errors recorded and available for the application (like I did before with SslStream and .NET Framework). Is it possible?
In my opinion, if we add ChainValidationResult.InvalidName and ChainValidationResult.Untrusted to the StreamSocketControl.IgnorableServerCertificateErrors before we run the StreamSocket.ConnectAsync method, it will ignore the SSL server errors. That we can not get any ChainValidationResult in StreamSocketInformation.ServerCertificateErrors.
We should be able to use the StreamSocket.ConnectAsync method without adding the ChainValidationResult.InvalidName and ChainValidationResult.Untrusted.
There is an official sample about StreamSocket, please refer the Certificates in Scenario5.
We should be able to use try-catch to catch the exception of the StreamSocket.ConnectAsync method. Then we can get the ChainValidationResult in StreamSocketInformation.ServerCertificateErrors and we can add the ChainValidationResult to the StreamSocketControl.IgnorableServerCertificateErrors. Also we should be able to use the StreamSocket.ConnectAsync again.
I am facing the following problem on one server only on another server or locally it is working properly.
I am using IIS6 Windows 2003. Is there any setting related problem?
System.ServiceModel.CommunicationObjectFaultedException: The
communication object, System.ServiceModel.Channels.ServiceChannel,
cannot be used for communication because it is in the Faulted state.
Server stack trace: at
System.ServiceModel.Channels.CommunicationObject.Close(TimeSpan
timeout) Exception rethrown at [0]: at
System.Runtime.Remoting.Proxies.RealProxy.
You cannot use a channel that has been faulted. You will need to recreate a new channel.
My toolkit has inbuilt support for this so that you can seamlessly make another call to the channel. It handles this scenario internally.
See http://neovolve.codeplex.com/releases/view/53499.
First, we need to find out what the real problem or issue is. For this set includeExceptionDetailInFaults to true as below in you service App.Config file:
serviceDebug includeExceptionDetailInFaults="true"
Then you will get the real exception detail when you catch an exception. I was getting AccessDeniedException. So I ran this command from Power Shell:
netsh http add urlacl url=http://+:8080/ user=Domainxxx\UserNamexxx. Problem solved.
I am trying to connect to a remote queue using c#.
I tried many ways to connect to the remote queue but it always fails with common errors like: MQRC_CHANNEL_CONFIG_ERROR or MQRC_HOST_NOT_AVAILABLE.
What I am doing is this:
string channel = "QM_TEST.SVRCONN";
string hostname = "<serverIp>";
string queueName = "QM_TEST";
string port = 1414;
props.Add(MQC.HOST_NAME_PROPERTY, hostname);
props.Add(MQC.CHANNEL_PROPERTY, channel);
props.Add(MQC.PORT_PROPERTY, port );
props.Add(MQC.TRANSPORT_PROPERTY, MQC.TRANSPORT_MQSERIES_MANAGED);
MQQueueManager mqQueue = new MQQueueManager(queueName, props);
I have tried changing this but all failed.
I think that my problem is the server configurations..
can you point me to a full guide to how to configure a server and connect to it with .net?
My problem is connecting to a REMOTE server using .net and not to a local server.
Thank you!
The problem was that the CCSID between the client and the server were different.
http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/index.jsp?topic=%2Fcom.ibm.mq.csqzaf.doc%2Fcs12480_.htm
On the client side I had to put
Environment.SetEnvironmentVariable("MQCCSID", "437");
Thats why I got:
MQRC_CHANNEL_CONFIG_ERROR
I'm guessing the problem (or at least a problem) is here:
MQQueue mqQueue = new MQQueueManager(queueName, props);
This should be
queueManager = new MQQueueManager(queueManagerName, properties);
If you have installed the WebSphere MQ client to the default location, there are many sample programs under the following directory:
C:\Program Files (x86)\IBM\WebSphere MQ\tools\dotnet\samples\cs\base\
There are a number of sample programs there for various tasks. If you have the latest V7.1 client installed then you will see the following programs:
SimpleAsyncPut
SimpleClientAutoReconnectGet
SimpleClientAutoReconnectPut
SimpleGet
SimpleMessageProperties
SimplePublish
SimplePut
SimpleReadAhead
SimpleSharingConversation
SimpleSubscribe
SimpleXAGet
SimpleXAPut
There are also WCF and XMS samples.
If you need the client code, please see my response to another SO question here for links.
Update:
Here's the normal diagnostic process.
If the WMQ components were installed by relocating libraries or classes from somewhere else, perform an install using the full vendor-supplied client media. This includes troubleshooting utilities such as trace, dspmqver, etc. It also resolves any library or class mismatch issues.
Use the pre-compiled client programs to test the connection. The amqsputc, amqsgetc and amqsbcgc programs require the MQSERVER environment variable as described here. The Q program from SupportPac MA01 is a separate download but has the advantage of NOT requiring any environment variables, CCDT files or other dependencies.
If the sample programs fail, check the QMgr's error logs at [WMQ install]/qmgrs/[QMgr name]/errors/AMQERR01.LOG for messages. Also check for FDC files and errors in [WMQ install]/errors.
If no errors on the QMgr side, attempt the connection again while using a client-side trace as described here and here.
Most client problems are resolved through installation of the full WMQ client as supplied by IBM. (Conversely that implies most people are installing by grabbing DLL or JAR files.) If the problem persists, error log inspection on the QMgr and client side usually reveals the underlying cause. If these do not work then tracing usually diagnoses the remaining issues.
UPDATE 2:
Per the error messages posted at MQSeries.net, the channel has a security exit set. A security exit is external code that the channel calls out to when starting a channel. There is no way to know what the exit expects or does without having access to the code or docs of the exit. If the exit is written in-house, you'll need to talk to the programmer to figure out what it requires. If the exit is a commercial product then you will need to get the documentation for it.
Alternatively, alter the channel so that SCYEXIT is blank to disable the exit.
The data posted at MQSeries.net was as follows:
MQ9575: DCE Security: failed to get the user's login name.
EXPLANATION:
System call 192.168.50.55 to get the login name of the user running WebSphere
MQ client application process 5 failed with error value -1. This occurred in
security exit function create_cred. The exit will now attempt to open channel
using the DCE default login context.
ACTION:
If you wish to run using the DCE default login context take no action. If you
wish to run using the user's login name as the DCE security exit principal
examine the documentation for the operating system on which you are running MQ
clients and reconfigure the operating system as necessary to allow the
192.168.50.55 call to succeed.
Note that it states the call is failing in the security exit.