this time I have a particular question.
I have a WCF exposed in our server. If you just call it from the browser, you can see the wsdl, so it is working.
Our partner has to call this WCF with a soap request (old, but this is a requirement). We don't see any request from their network, also in the IIS log.
Now, they told us our service returns "java.io.IOException: Async IO operation failed (3), reason: RC: 107".
I'm quite surprised, since, first of all, we wrote the WCF in C#, of course not Java. Further, how is it possible they send a request but we don't see it neither in the IIS log?
The error
java.io.IOException: Async IO operation failed (3), reason: RC: 107".
Is the error their client is throwing.
This means that the client call doesnt reach your endpoint.
There is very likely a network connection issue along the way.
Eg a firewall blocking the port , or blocking the origin of the call etc.
Some routing problem etc...
You may need to get a network guy to track why their call doesnt reach the your WCF service.
Related
We are trying to host a send-only endpoint within a WCF service. Due to its fire-and-forget nature, the WCF hosting option here isn't really what we are looking for, since we don't want to wait for the messagehandler to have to reply. In other words, all our WCf methods are void/Task.
However, we are having trouble figuring out how to deal with properly shutting down the endpoint. WCF doesn't really have a lifecycle API to use to handle shutdown behaviour.
So my questions are as follows:
Do send-only endpoints need to be shutdown?
If so, how would I do this in a WCF service?
You don't 'need' to shut down a send-only endpoint. It is more critical for processing endpoints to shutdown gracefully, as there may be messages in-flight being processed.
Recently, we migrated one of our existing web service to WCF service with basic http binding (hosted in IIS). The problem is whenever user sending a long running request (>5min) to the service, the client keep on waiting for server response until closing it manually. After analysing the Wireshark and Firewall logs we found the reason, the default HTTP session timeout set for 300 sec in firewall due to this firewall remove the long running session from the table after 5min.
We can resolve this by increasing HTTP session timeout in firewall but the complexity is we can control it at server side firewall but we can’t control at client side(each client will have different ISP and IT Policy). So my network admin suggested to implement the keep-alive mechanism (sending heart beat message to server) but it doesn’t worked for me.
I tried following things while implementing keep-alive mechanism,
First, I tried to send echo messages to server with the same channel
which created for long running request but it was failed since the
channel already waiting for response.
Then I tried to send echo message to server for every four min with
separate channel but there is not impact on the issue since it using
the brand new connections.
I tried with async service calling pattern but there is no impact.
Finally, I tried by adding the Keep-Alive (Keep-Alive: max=100,
timeout=1801) header for each request and response at both client and
server side again there is no impact on the issue.
So, could you please help me to resolve this issue?
We have an existing Websphere MQ Queue Manager (running fine, no issues). This has for each "method" a pair of queues: Request and Response.
We'd like to put a web service front end over this for the benefit of some apps we have that cannot call MQ but can call web services.
Of course, Web Services can be synchronous but our MQ is async...and I am not sure how to get around this.
Example:
App calls webservice...web service waits for response.
Webservice calls MQ Request queue and puts the message.
of course, the response will be on a different channel...so my thinking is that the webservice would have to read all the messages on the queue and only remove the correct one (by some identifier such as GUID).
Has anyone got any previous design knowledge on solving this?
The web service does need to read all the response messages, you can perform a correlate get. When the request is put on the request queue you use the request message id and wait on the response queue for the response message with the correlation id. MQ handles this very efficiently.
Here is another stackoverflow answer that shows some code for performing a correlated get
Issue in Correlating request message to resp message in Java Client to access MQ Series
I am using wsdualhttpbinding to connect the client and WCF Service. My client likes to invoke a long running request and wanted a periodic status update, hence I have choosen callbackcontracts. that worked fine. However It publishes for all clients who have just been loaded and has not requested that operation.
Is it possible to direct the callbacks to the requestor alone, though all clients are loaded.
I received an answer from this forum. Sharing this.
http://social.msdn.microsoft.com/Forums/en/wcf/thread/c0fce1de-9793-48fa-8e4d-329297ac54d3
I am load testing my webservice
and get a
System.ServiceModel.CommunicationException
when I use 10 threads to communicate to it (without any sleep in between) - basically testing 10 conenctions at a time - through a windows application
An error occurred while receiving the HTTP response to http://localhost/XXX/XXXService.asmx. This could be due to the service endpoint binding not using the HTTP protocol. This could also be due to an HTTP request context being aborted by the server (possibly due to the service shutting down). See server logs for more details.
Why would this happen and how to best resolve it
Also is this the way how asp.net application will interact with it too - is threading the best way to do the load testing
To begin with, you might want to try using WCF for new web services development. Microsoft now considers ASMX web services to be "legacy technology", and suggests that all new development use WCF.
Next, you might want to find out what happened. The exception isn't lying to you. There was an HTTP protocol error. You could look at the network traffic using Fiddler, to see what the problem is.
You might also look in the server event log.