I host a WCF Service on IIS and have the following binding in web.config:
<bindings>
<wsHttpBinding>
<binding name="transactionalBinding"
transactionFlow = "true"
sendTimeout = "00:00:01"
receiveTimeout = "00:00:01"
openTimeout = "00:00:01"
closeTimeout = "00:00:01">
<security mode="Transport">
<transport clientCredentialType="None" proxyCredentialType="None" realm=""/>
</security>
</binding>
</wsHttpBinding>
</bindings>
In my service method I sleep for 10 seconds. I do not get a timeout exception when calling my service method from a client.
Is there any meaning in defining timeouts in server side bindings?
I do not get a timeout exception when calling my service method from a client.
TL;DR: because WCF timeouts by default are one minute so naturally a server operation that only takes 10 seconds isn't going to timeout. The timeouts you have specified on the server would only affect transmission not execution of your method. (you aren't calling anything else)
You are specifying the timeouts in the server config. What you need to do is specify the timeouts in the client's config file, specifically SendTimeout. Essentially whatever end is making the call, needs to specify the operation timeout. Probably not relevant in your case but if your "server" in turn made another WCF call to another service, you would want your own timeout there too.
MSDN:
SendTimeout – used to initialize the OperationTimeout, which governs the whole process of sending a message, including receiving a reply message for a request/reply service operation. This timeout also applies when sending reply messages from a callback contract method.
Generally, WCF client and server configs should match one another and unless you are using Add Service Reference/Refresh Service Reference each time the server contracts and/or config change, the client won't know about it. By the way, avoid the latter because it duplicates your model and can lead to runtime errors if they are out of sync. Not to mention service contracts can get out of sync.
A passing thought
And this brings up one of the problems of WCF configuration via config files, they are subject to runtime errors impossible to find at compile time.
A better practice is to do away with config files completely and do programatic configuration via a common assembly that both your client and server use. Specify bindings in code along with your timeouts.
That way both server and client are always in sync with regards to WCF configuration.
With both client and server agreeing on timeouts would have addressed some issues.
Tell me more
WCF the Manual Way… the Right Way
Related
I have a WCF service in my application.
When the amount of data that passes from server to client is small I do not have problems.
The problems come when there's a big amount of data.
The proxy method runs a stored procedure that retrives data in an acceptable time.
The method server side return correctly,
BUT it takes more that two minutes to return properly to the client and continue the execution client side.
During this period if I stop the application it seems that no actions are in execution.
I don't know if it's an IIS problem or a configuration of the net.tcp binding.
The only thing I'm able to do is to execute the proxy in an external application and it that case I no have problems.
EDIT***
This is the binding configuration:
<binding name="NetTcpBinding_INService" closeTimeout="24.00:00:00" maxReceivedMessageSize="2147483647"
openTimeout="24.00:00:00" receiveTimeout="24.00:00:00" sendTimeout="24.00:00:00">
<security mode="None" />
</binding>
I host a public service (so I can't control client PC clocks). I'm using
<security mode="TransportWithMessageCredential">
<message clientCredentialType="UserName" />
</security>
The max time difference allowed (MaxClockSkew) is 5 minutes.
What is the definitive way to disable this functionality and / or make it really large like 2 days?
The only safe, simple way I can think of is to just use transport credentials under https and pass the username and password to every method call. Surely I don't have to resort to this?
I've looked at https://msdn.microsoft.com/en-us/library/aa738468.aspx and I don't fully understand it - i.e. where to apply in my world. I just use add service reference and the default proxies at present. Can it be defaulted in the server so that adding/updating a client reference picks it up?
We have a logging service that works by pushing into an MSMQ queue and then a persistence service that pulls out of that queue to drop into a database. Both services are WCF. Recently, though the logging service has continued to work without issue, the persistence service has stopped working, and it throws the following error when trying to open:
An error occurred while opening the queue:Generic error code. (-1072824319, 0xc00e0001). The message cannot be sent or received from the queue. Ensure that MSMQ is installed and running. Also ensure that the queue is available to open with the required access mode and authorization.
Obviously, this error is less than helpful. I've tried switching the persistence service to use the same app pool as the logging service, creating a new app for the service, restarting MSMQ, and restarting the servers - but no dice. I'm out of ideas, so any suggestions would be greatly appreciated.
Service Binding
Here's the binding on the services:
<msmqIntegrationBinding>
<binding exactlyOnce="true" durable="true" serializationFormat="Xml" maxReceivedMessageSize="2147483647" closeTimeout="00:00:30" sendTimeout="00:00:30" receiveTimeout="00:00:30" timeToLive="24:00:00" receiveRetryCount="1" maxRetryCycles="1" retryCycleDelay="00:10:00" receiveErrorHandling="Move">
<security mode="Transport"/>
</binding>
</msmqIntegrationBinding>
It hasn't changed since deployment many moons ago, but it looks like the service hasn't been working for just over a month.
EDIT: Well, reinstalling MSMQ on all servers didn't seem to help (in fact, just seemed to mess up my queue access even more). Groovy.
EDIT2: Even if I switch to netMsmqBinding in place of msmqIntegrationBinding, I get the same error.
EDIT3: If I create the queue local to the server instead of on another server, it works. So something about going to the other server is the issue. Restarting DTC doesn't resolve.
EDIT4: I can use a queue on another server, just not the MSMQ server. So it must be something with the connection to the MSMQ server (or the MSMQ server itself).
EDIT5: Ports 1801, 135, 2103, and 2105 are all open between the service server and the queue server.
EDIT6: DTCPing comes back with successes.
I've a WCF service that only about 15-20 clients are calling once every three minutes. I have PerfMon hooked up to it, and it's showing that I have 2147483698 Instances. That can't be, can it? I have maxConcurrentInstances="1000" in the web.config and I'm using Multiple and PerSession Concurrency and InstanceMode respectively.
This WCF service is also causing some other problems like making lsass.exe use all the available CPU.
Edit More Info
It is hosted in IIS 6 and is using an endpoint with WsHttpBinding:
<wsHttpBinding>
<binding name="WSHttpBinding_IWCFService"
maxBufferPoolSize="524288" maxReceivedMessageSize="1048576">
<readerQuotas maxDepth="32" maxStringContentLength="65536" maxArrayLength="16384"
maxBytesPerRead="4096" maxNameTableCharCount="16384" />
<security mode="Message">
<message clientCredentialType="Certificate" negotiateServiceCredential="true"
algorithmSuite="Default" />
</security>
</binding>
</wsHttpBinding>
I have the Concurrency set to Multiple to because I want the Service Objects that are created to be able to handle more than one request at a time (ie multiple threads). I suppose I could make the InstanceMode Single, instead of PerSession, but would that make a difference here?
Edit Next Morning
So, I got on this morning and opened PerfMon, everything was flatlined at 0. I removed then created the the service in IIS, and also restarted the service by modifying the config. I then watched the Instances climb up to 1000 (the max in my config), at which point no more calls were coming in. I restarted the service again using the config, the number of Instances immediately dropped to 0, then 5 seconds later shot up to 2 billion again.
I feel like part of this might just be that Perfmon doesn't know how to handle whatever madness is being thrown at it from the WCF service.
The problem does seem to be that the channel is not always being closed properly in this particular version of the client and unfortunately, I can't get to them all at the moment. (I have another version of the client and service that has about 130 clients and this isn't a problem.) Is there some configuration I could set the service up as to help the problem? From what I've read, Single InstanceMode and Multiple Concurrency would be appropriate. It would solve the Instance problem and still give me asynchronous access, and I don't have to worry about cross threading issues because the service methods only update tables in a DB.
Thoughts?
It sounds like the instances are not being disposed of correctly.
As a test you could append the following line of code to the implementation (in the service) of the method(s) being called by the clients, and see if the number of instances reduces:
OperationContext.Current.InstanceContext.
ReleaseServiceInstance();
You could also try switching to per-call and get rid of the concurrency stuff (I can't tell from your question if that option would be suitable for what you are doing)? Per call will create a separate instance for every method call that a client makes, and dispose of the instance afterwards.
There is a nice article that goes into all the details of instance management here, hopefully you will find something helpful there :)
I'm trying to get IIS6 to work reliably with a WCF service I have hosted in a separate Windows Service application on the same machine. Users connect to IIS via some HTTP exposed services, which is working fine, and then IIS needs to get some information from the Windows service to put in the HTTP response. I also need a callback channel between the Windows Service and IIS.
After a lot of effort I got it working with a netTcpBinding and everything would be rosey for 5 or 10 minutes but after that IIS would report the WCF channel as being faulted and then clam up and stop processing any requests until the worker process got recycled and the whole thing repeated.
I've been trying to swap to a netNamedPipeBinding but IIS refuses or is refused access to the pipe with an "There was no endpoint listening at net.pipe://localhost/mypipename" error. I can connect to the pipe fine from a console app.
So my question is has anyone got either of those two bindings working with IIS as a client or have any other approaches?
We are using IIS 7 hosting about 20 services with the net.tcp and net.pipe bindings and it's working fine.
Your problem with the pipe looks like a misconfiguration to me. If it helps, this is how we have them configured:
Server:
<endpoint address ="" binding="fooBinding"
contract="Bla.IBlaAPI"
bindingConfiguration="BlaAPI.BindingConfig">
Binding config:
<binding name="BlaAPI.BindingConfig"
receiveTimeout = "10:50:00"
sendTimeout = "10:50:00"
maxReceivedMessageSize="2147483647"
maxBufferSize="2147483647"
maxBufferPoolSize="2147483647"
transactionFlow="false">
<readerQuotas maxDepth="32"
maxStringContentLength="2147483647"
maxArrayLength="2147483647"
maxBytesPerRead="8192"
maxNameTableCharCount="2147483647" />
<security mode="None"/>
</binding>
Note that we are using long timeouts and have really high quotas for message size and etc. because we are passing some big chunks of data through this service. You can adjust for your own needs. We have the security set to "none" because the service is only being contacted from the local machine which is secured. Again, your mileage may vary.
Client:
<endpoint name="Bla.Bindings.BlaAPI" address="net.pipe://localhost/bla/IBlaAPI.svc"
behaviorConfiguration="BlaAPI.ServiceBehavior"
binding="netNamedPipeBinding" bindingConfiguration="BlaAPI.BindingConfig"
contract="Bla.IBlaAPI" />
About the Faulted state problem, please note that if an unhandled exception occurs during execution of the service code, the service instance will remain in Faulted state until it is closed properly. To avoid this, either handle exceptions at service top-level or use, for example, Enterprise Library Excexption Handling blocks.
Re NetNamedPipeBinding and "There was no endpoint listening at net.pipe://localhost/mypipename"
Is your web application impersonating its users? The above error is what you get if you try to access a WCF service via the named pipe binding, in a security context whose logon token has membership of NETWORK USERS. The WCF client-side channel stack doesn't distinguish between access denied errors and "not found" errors, when it attempts to read the shared memory object created by the service to publish the name of the pipe in use. (See http://blogs.charteris.com/blogs/chrisdi/archive/2008/05.aspx etc)
Impersonation tokens in an IIS application will always have NETWORK USERS membership.
Can you show me the code you use to dispose of the wcf client proxy?
Never use 'using' on a wcf proxy, as it will not dispose correctly every time. This can possibly lead to the faulted state.