We have one WCF Service hosted on IIS and there is an WebApp the calls the WCF Service using BasicBinding.
The Service hangs from time to time, I think after a large number of calls.
Sine we host both the WCF Service and the WebApp, is it possible to check if the WebApp closes the connection with the Service.
I am thinking any tool out of the box.
Answering my own question was never my intention. Anyway, I'v fond a very good tool called TCPView.
https://learn.microsoft.com/en-us/sysinternals/downloads/tcpview
I run in on same Server as my WCf Service and could see the list of all open connections.
Best Ragreds
Related
I'm trying to create a web service that serve around 100 client, include file uploading. Fast respond is a requirement. For such kind of scenario I usually create a WCF web service and hosted in IIS with BasicHttpBinding. It works, but is there a "better" way to archive the same thing? Thanks!
I've looked building a WCF with web socket and host it at server as a window service, but it seems a little complicate:\
I have several services running. I can call everyone from a client application. I am trying to call into one service from another service (same application - they are hosted in an application for testing but can also run as a windows service).
The call I use to do this from the client is simply create the factory and CreateChannel and then open.
When I do this in a service trying to connect to another service I don't get an error it just hangs and eventually times out. I have no idea what is wrong.
I am using net.pipe://localhost/test as my endpoint and transport.
This was really stupid but (and) I will post the issue to help others that may run into this...
All of my service was running single threaded so when I called into another service it was blocking itself. I now start my threads on backgroundworker threads and the issue is gone.
Thanks
I am creating a client application that downloads and displays market data from Yahoo! for a university project, but that also sends out notifications to mobiles (so far using Google cloud messaging). So far it's a WPF client and the "server" is a class library - so far working. What I was wondering, is can you mix this server with a WCF service - the WCF service I was planning on using for registering devices, as well as accepting and parsing commands.
So I would call .Start() on my server object, and it will be constantly running in the background, while a WCF REST service runs alongside it - or would I be better simply having a thread running on the server that can accept input... sorry if this is confusing, but just wondering if it can, or has been done before or any advice. :)
Just to explain a bit better
The client front end and the "server" are running on the same machine - I was calling it a server because it is not only updating the front end, but sending out GCM notifications at the same time. I was wondering if maybe a WCF service could be added to make it simpler to handle adding devices to a database ("server" reads a list of device reg ids from a database, sends notifications to these) by allowing an android app to details via REST or something similiar
I would explore wrapping the class library in a Windows Service (which is essentially a process that runs continuously, and can be stopped/started/paused) and keep your WCF service as a web service for client communication.
How the WCF client service communicates with the Windows service is up to you - whether you store the data in a shared database, keep it in memory and have another WCF layer communicating between the two, etc. A shared database would be the most straightforward, especially if you want to persist the data for use by other apps/services as well.
WCF Service would be useful if you had one notification service on your server with multiple WPF client application connecting to it. If you have just one application running on the same server then not sure if it will be worth the overhead.
The usual pattern is to host WCF service in IIS, that way it always starts whenever first request is received. WCF is very flexible though, therefore you can host in in Windows Service, Console Application, etc.
The team I work with has recently migrated from a self hosted setup to IIS hosting of thier web services. The migration went 'smoothly' however we are now seeing some funny behaviour on our server.
If we make a simple request call from our client to our server to get some data from our DB everything works as expected. If we make a call from our client to our server and then the server makes a call to a 3rd party service (hosted off site) then we're seeing a massive increase in response time. A call like this used to take less than a few seconds, since migrating to IIS hosting the response time is over a few minutes.
Has anyone seen this behaviour before? Is it possible that we're having issues with credentials between the IIS hosted server and the 3rd party service?
As long as the bindings haven't changed and you are using the same service identity (i.e. Windows account) then you should get the same performance.
Have you checked whether the service is using static variables and/or multi-threading logic? You could be having resource contention problems with the proxy to the 3rd party service. You'll need to provide more detail about service to get a more specific recommendation.
I posted about this before to a degree, but after a few days of reading I have a better understanding of WCF and would like to get a bit of feedback before I start working on it.
I basically need to develop a server/client system. The "server" application (c# net console app) will be ran on a machine with a MySQL database, all software installation packages, and whatever else we need local to it. The "client" application (c# net console app) will be ran on the rest of our machines, and will maintain a direct connection to the server software. Using a web front-end, our administrators will be able to install software packages to the clients, create new services, etc.
Since we own all of the machines, and have to configure them anyways, Server Push is not a problem. We don't have to worry about firewalls or any sort of NAT settings as we can just go in and open the ports required for it to operate.
What initially confused me about WCF is I assocated a "WCF Service" with a server. However, since the majority of operations are actually going to be run on the "WCF Service", this is my logic.
1) Make the "client" application actually a "WCF Service" so that the exposed functions are actually ran on the proper machines.
2) Have the "server" application actually a "WCF Client", and issue all of the instructions/commands from here, and just use the return value to update the database/etc.
Would this be the proper method to go follow or should I look into WCF Duplex (Looked extremely confusing at first glance) or just start with raw sockets?
from what I gatther you're trying to do, you're correct. That is the client machines should really have a TCP/IP "server" running on them, and the centeral server machine would have the Tcp/IP "Client".
That way the TCP/IP client (The app running on your server machine) can initiate calls to each of the client machines.
Keep in mind also that a single application can be both a tcp/ip client and server. So your app that's running on the server machine could in turn also be a tcp/ip server that your admin uses to do stuff using a browser. Which effectively means that service is an HTTP service.
So, it is not a client/server thing. It is a hub-and-spoke arrangement of distributed computing. I think, WCF can very well be used. You have multiple servers and a coordinator (the client to all of these servers) that gets the work done from various servers and update the database.
So WCF is well-suited for you. The benefit of WCF is the easy configurability and handling the communication part. You don't have to take much pain for the management of sockets.