I have wcf service hosted in iis 7.0.
It was working well for the past year, but now suddenly it's crashing and restarting every few minutes.
I looked at the trace file, and I see the error but I don't know what it means. I tried googling it but no luck. I checked the settings in IIS. It looks ok.
This is how my trace looks like. If someone can help me understand this trace, it will be good.
This are pure assumptions, but as far I guess by looking at your traces and what you wrote:
You are using a net.pipe WCF host
The endpoint address of your host is net.pipe://tstwebashitv... something, so you are not using a the net.pipe://localhost/... format (assuming tstwebashitv is not a server name, and your net.pipe is not remote)
The service used to work for a long time
So I assume there is a possibility that another named pipe WCF host is running on the same machine, and might cause conflict.
That's why I suggest to check those points:
Have net.pipe endpoints adresses under this format: net.pipe://localhost/something instead of net.pipe://something.
Check HostNameComparisonMode setting in the NetNamePipeBinding section : it is better to set it to Exact to ensure running hosts receives messages addressed to them.
Basically, if the HostNameComparisonMode is not set, then the StrongWildcard default mode is used and the host name in the net.pipe address is discarded.
If you have a net pipe address set as 'net.pipe://something', then "something" is considered as a server name and is discarded. So several host running that way could conflict together.
Related
I just implemented a simple WCF server using net.tcp.
First, I use 127.0.0.1 as server address and client able to connect the WCF service.
Everything is Ok. But when I try to use the internal IP 192.x.x.x I get an error:
No connection could be made because the target machine actively refused it
Any idea what may cause this?
Best Wishes
PS: I disabled auth on WCF. Even turn off firewall all...Not worked...
Well, I got this error message when I forgot to install necessary components. see link Configuring WCF Service with netTcpBinding
(summary of steps)...
Go to "Programs and Features" (usually in control panel)
Go to "Turn Windows features on or off"
(assuming VS2012) Go to ".NET Framework 4.5 Advanced Services"->"WCF Services"
Enable "TCP Activation"
Do you use 192.x.x.x on both client and server? I remember seeing an issue a while back in which for TCP the client and server names needed to match (something related to one of the message properties), so if you define the service with "localhost" and the client with <machine name> there would be a problem.
The physical client and service addresses can differ if the logical address is the same and the server endpoint has been configured with a "listenUri" and the client behaviour is configured to use a <clientVia> address. In our case, this is required in for our proxy/firewall configuration. In effect, the client calls the firewall and the server listens locally for a forwarded request.
For an IIS-hosted service, check the following:
The Application pool is started and looks correct (.NET 4 etc/security)
For NET.TCP, ensure the "Allowed Protocols" in the Web Site/Application (via advanced settings) are configured correctly: e.g. http,net.tcp
For a non-IIS hosted service, you may need to configure a Namespace Reservation (URLACL). http://msdn.microsoft.com/en-us/library/ms733768.aspx
Also ensure the appropriate Windows Services are running, e.g. Net.Tcp listener.
If you're running from within visual studio in debug mode, ensure your solution port numbers match. I have seen several instances where I had Properties>Web>Auto-Assign Port - selected and the endpoint from, in this case my silverlight app, didn't match the port auto generated. I usually change the port to 1318 in my .web.
Today I found out that this error will also show up if you have a circular reference in your WCF Service Class. I had a method that was calling itself infinitely and causing this error message, which led me here.
So if none of the other suggestions work, check your code to see if you're doing any recursive functionality and make sure you're not caught in an infinite loop.
I resolved this issue by either commenting this setting in the application configuration:
<defaultProxy>
<proxy bypassonlocal="False" usesystemdefault="True" proxyaddress="http://127.0.0.1:8888" />
</defaultProxy>
or, running Fiddler which would take the WCF call at 127.0.0.1 and then forward it.
The complete scenario is, I encountered the same issue with WCF calls made to one of the service. The calls would fail with top level error message "There was no endpoint listening at http://LinuxIP:Port/...", and service trace viewer log showing inner exception to be "No connection could be made because the target machine actively refused it 127.0.0.1:8888
".
The reason was that I had put this configuration in my application to capture the outgoing traffic in Fiddler. If this configuration is in place then the Fiddler needs to be running for the WCF calls to make it to the intended destination. If Fiddler is not running this error will be there. Comment this setting in such scenarios, and the WCF call will go to the destination.
I am hosting 3 WCF services inside windows services.Each WCF service contains Multiple endpoints. Right now, i am host all my endpoints thru TCP binding on different ports.
Is there any way to host all these end points from different wcf services on same port?
Sure is! You can use the Net.TCP Port Sharing service.
Net.TCP Port Sharing on MSDN
I just looked into that, out of curiosity. The behavior I discovered seems so strange that I almost don't want to put it here. But it worked in my case, so maybe it's doing the same for you:
I am getting the AddressAlreadyInUseException when I'm trying to host 2 services (i.e., 2 separate ServiceHost instances) on the same net.tcp port with portSharingEnabled="True" set on the netTcpBinding for both. That happens with or without the Net.Tcp Port Sharing Service running. The exception is thrown even if I only start one of the services (and I verified via netstat that there was no other listener on that same port on the machine, plus, I ran the app with elevated privileges).
Now, the funny thing is, the AddressAlreadyInUseException is not thrown when I set PortSharingEnabled = False, and yet both services are fully working!! Once again, with or without the Port Sharing Service running. I could even successfully connect to those services from a different machine.
An important note to make, however, is that the above only applies if the services are hosted within the SAME PROCESS! It does blow up if I try to start another instance of the app that's listening on the same port, but a different base address. But I'm assuming you're hosting those 3 WCF services inside the same Windows Service?
So, even though it doesn't seem right, my answer would be to disable PortSharingEnabled and see if it works with different BaseAddresses on the same port (provided they're all inside the same process).
As far as I know you not only have to enable port sharing on the configuration (or via code), you also have to manually start the Windows Port Sharing service.
That's the reason why I (having similar problem) didn't want to use port sharing, to make it easier for deployment rather than having to mess with other things the user may or may not know.
I have a performance issue with WCF services hosted in IIS using net.tcp bindings.
We recently ported our system from COM+ to WCF and tests indicate a performance degradation. I've been looking at performance counters on the server and the CPU utilisation is very low (< 10%), there is plenty of available memory, disk reads are normal etc... I also checked WCF performance counters and the number of outstanding calls is low (at most 1 at any given time), number of calls per second is quite low (16 calls per second for a service that is being used the most by the system). All of our services are configured to be per call and single threaded...
I have already played around with throttling and set all values for all of the settings to 100 (the server is an 8 core machine and my understanding is that the actual throttling values end up being what you set multiplied by the number of CPU). I don't think there is an issue there.
I have also made sure that the client is using it's connections efficiently (not creating new ones where there is an existing tcp connection that can be used)
The current web application hosts about 50 services (yep, that is 50!) and at the moment I am trying to eliminate this as the source of the problem. I am looking into hosting the services in multiple web applications and I'd also like to have them use different ports but I am having some problems with that and I can't find a step by step instructions on the internet anywhere so I am hoping somebody here will be able to help me :)
Here is what I've tried to do so far:
1) I added another binding to Default Web Site in IIS (that is I've got two net.tcp bindings, one is set to use "808:*" binding information and the other one uses "809:*")
2) I've made sure these ports are allowed to go through the firewall
3) Then I've tried to configure each individual web application to filter ports (this is a snippet from web.config where I want to use port 808):
<serviceHostingEnvironment>
<baseAddressPrefixFilters>
<add prefix="net.tcp//<servername>:808"/>
</baseAddressPrefixFilters>
</serviceHostingEnvironment>
When I try to connect to this service I get a The service at the endpoint address 'net.tcp://<servername>/SomeService.svc' is unavailable for the protocol of the address
If I remove the <serviceHostingEnvironmentgt; bit. What am I doing wrong here?
Other service, for example the ones that I want to be available on port 809 are not available at all, the error message I get telling me that the endpoint does not exist, it looks like IIS is not listening on that port at all. The firewall, as already mentioned, definitely allows this port through.
Any ideas or perhaps suggestions on what the best setup when having this many services hosted would be are much appreciated!
Thanks!
It is an old post - but...
About the endpoint error - try to set net binding information on the application and not on the site level.
So, I previously posted about my troubles in moving a working WCF service from my local machine to the development server. The problem was that when moving it over all of the references were by machine name rather than ip. Since i was not accessing it on the domain, I couldn't see the machine name and couldn't access the references. Here was my previous post (.NET WCF service references use server name rather than IP address causing issues when consuming).
I found a solution, but wanted to make sure that this is the proper solution to my issue. And also ask if anyone else had any other input? The solution was to change the IIS site binding. I found the solution at (http://blogs.msdn.com/wenlong/archive/2007/08/02/how-to-change-hostname-in-wsdl-of-an-iis-hosted-service.aspx). The only thing is that I may have to do this for every site as the application that i work with is not hosted and is a web-based solution installed at each site. So i'm possibly going to have to include a script in the build for each site.
I would think that I would be able to make this change in the .config file?
The right way to handle this is to set and explicit host-header in IIS for the Web Site instance. Now, assuming you've only got one host-header applied to the Web Site instance that should be all that you need. However, if you have multiple host-headers configured you will also need to explicitly tell WCF which host to expose itself via. This is done with the configuration element under the element to bind the service to that specific domain.
I have a Web application and a WCF service hosted on the same Windows 2003 development server. They each have their own IIS website node responding to drs.displayscreen.web and drs.displayscreen.service host headers respectively. The hosts file contains entries for both headers pointing back to 127.0.0.1. The web site has a service reference to drs.displayscreen.service.
Both applications work perfectly when their application pool uses the 'Network Service' account.
I need to perform some COM processing under the hood on the service so I want to run the applications under a customised identity. Both sites run on a new application pool.
When I change the application pool identity to use a new windows account created for the purpose, I get the following (inner) exception:
[EndpointNotFoundException: Could not connect to http://drs.displayscreen.service/Handler.svc. TCP error code 10060: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond 192.168.98.2:8080. ]
192.168.98.2:8080 is the address of a DNS server that is no longer in use. It is not referenced anywhere in the solution. It is not referenced by ipconfig at all.
I have made sure that the new account is a member of IIS_WPG and I have run aspnet_regiis -ga . I have also given the account explicit permission to read the hosts file.
Why does the application attempt to use the defunct DNS server to resolve the temporary url (drs.displayscreen.service) instead of the hosts file entry? It has to be a permission of some sort because it does not have this problem when running under the network service account. Help!!
Well, it appears that the answer might involve a bug in the .Net framework. I found a blog posting that clued me in to the fact that the MS .Net implementation of SocketCache.GetSocket might cache invalid sockets and another one that suggests a workaround/hack in the form of an explicit don't-use-proxies configuration setting.
We don't actually use a proxy server in the environment where this problem cropped up but it appears that SocketCache.GetSocket is overridden or behaves differently when the don't-use-proxies setting is in place. Strangely, removing the setting causes the problem to come back so obviously the SocketCache is not repaired when a valid ip/hostname is discovered and successfully used. According to the author of the first post mentioned above, the bug does not exist in Mono. :)