I have an XNA client which communicates with a WCF service to operate.
The XNA application is actually a multiplayer pokergame.
When I run the WCF service locally, everything works well.
However, I lately deployed my WCF service into Azure. Now when I launch the client,
it starts OK, buttons are responsive and clickable.
The same is when I launch another client, and there is now an option to start a game
(as there are 2 players).
Again, the StartGame button is clickable for both clients.
However, once the game commences, the UI hangs and becomes unresponsive.
I can't reproduce this locally. This only happens while using the Azure service.
Note I'm not using any callbacks from the server back to the client, my client continuously polls the server and operates according that information.
Any ideas?
Solved. Problem was I had another service function being called continuously, not on a new thread. While executing locally, traffic was fast enough to overcome this.
However, running remotely caused application to hang due to the synchronous calls.
Related
I configured Windows 2012R2 with IIS 8.5 and turned on the new suspend option.
According to the documentation the state is written to disk and resources freed up.
I have a site that is strong on SignalR, when the site is started there is always a never-exiting thread that keeps track of parameters of a game, users come to the site, play the game and the state is saved in the database.
Before when the site terminated it would load everything from database to restore the game-state, which worked fine but it took a REAL long time before the site would start (sometimes up to 5 minutes).
Now I configured the suspend option and it looks to work fine, site starts up in matter of seconds, BUT the never-ending thread.. has ended.
What could be the culprit? Is there an event that is called when the site goes into suspend or comes out of suspend instead of a cold startup?
It's not a good idea to run background threads within IIS. See http://haacked.com/archive/2011/10/16/the-dangers-of-implementing-recurring-background-tasks-in-asp-net.aspx/
Possible solution is to have a Windows Service (I recommend TopShelf for easy bootstrap) that runs your background operations and communicates with your ASP.NET via API.
See this question: IIS Background thread and SignalR
I have previously built WPF apps that host their own WCF service running on a custom port. Which is a great simple way for other apps to send messages between each other.
I have recently inherited a Silverlight 4 app from a client and they would like a way to send messages to it. I figured that WCF would be a simple way, but it is not possible to host a service in Silverlight.
What is a good, simple, way to send messages/communicate with a Silvelight app?
I have seen a little about the LocalMessageSender but I have no experience with it, can a WPF app, running on a different machine send a message to a Silverlight application using the LocalMessageSender class?
(Polling from the Silverlight app is not a prefered option)
I dont mind having to run the app in out of browser mode to get around some issues if need be.
EDIT Updated question
You can add Silverlight enabled WCF services and communicate with them like you did in the WPF app.
just so you know, SL only supports basicHttpBinding and (new in SL4) netTcpBinding. The later is intended for Intranet scenarios. As tchrikch said, you should be able to reference your service just by adding a simple reference in Visual Studio. As for the communication part, this may prove to be a little difficult. I would suggest looking at HTML5 WebSockets and see if you can push messages to the client from the server that way. I've only recently started looking at this as a solution for one of our projects but haven't had time to look any deeper.
HTH
Steve
I would like to start a new instance of a wcf service host from another (UI) application. I need the service to be out of process because I want to make use of the entire 1.4GB memory limit for a 32bit .NET process.
The obvious method is to use System.Diagnostics.Process.Start(processStartInfo) but I would like to find out whether it is a good way or not. I am planning on bundling the service host exe with the UI application. When I start the process, I will pass in key parameters for the WCF service (like ports and addresses etc). The UI application (or other applications) will then connect to this new process to interact with the service. Once the service has no activity for a while, it will shut itself down or the UI can explicitly make a call to shut the service down.
You can definitely do this:
create a console app which hosts your ServiceHost
make that console app aware of a bunch of command line parameters (or configure them in the console app's app.config)
launch the console app using Process.Start() from your UI app
That should be fairly easy to do, I'd say.
Perhaps I'm completely offbase here, but I don't think there is a 1.4 GB memory limit for .NET processes. The memory allocated for each process is managed by the OS. For 32-bit opeating systems, there is a 4 GB memory space available, but that is shared among all of the processes. So while it may appear that there is only 1.4 GB available, it's not technically true.
The only reason I bring that up is to say that the other way to approach this would be to load your WCF service inside a separate AppDomain within your UI application. The System.AppDomain class can be thought of as a lightweight process within a process. AppDomains can also be unloaded when you are finished with them. And since WCF can cross AppDomain boundaries as well as process boundaries, it's simply another consideration.
If you are not familiar with AppDomains, the approach that #marc_s recommended is the most straightforward. However, if you are looking for an excuse to learn about AppDomains, this would be a great opportunity to do so.
I have seen this issue on google, however, nobody seems to be able to solve it. I am writing a Windows Mobile app that utilizes a WCF service that I created. When I deploy this app to the device, it runs fine as do other non-mobile apps that consume this web service. When I debug it (bluetooth or usb cradle connected), SOME of the web service calls will break causing a "The remote connection to the device has been lost..." error and instantly closes the app without any further debug information. Others won't break it at all and allow me to continue debugging. Also, about 5% of the time, the web service calls that do break it, allow me to debug it but most of the time, it gives me that error and crashes.
Any idea what is causing this? I am at a loss.
Thank you in advance
Are you sure that this is happening because it is a mobile device?
Sometimes, we get this while debuging a WCF client or service due to a timeout.
Is it always the same services that give you this error? Does it happen as soon as you enter the service?
If it is specific services, is there anything special about them?
Update: It was due to a third party SDK that was crashing my client that was consuming the web service. All works well now.
I'm part of a distributed development team. We all work through terminal services, accessing a remote server where our applications are located.
We're working on a project in which a client application consumes a WCF service, which exposes all the business logic functionality.
In our development process, a developer is often asked to develop an entire use case from user interface to database access, including the service and the business logic.
In such cases the developer must be able to debug the functions/methods on the server side that she/he has build for a given use case. The problem with that is that the service must be run and when another developer needs to debug his/her work, an exception is thrown (I think it is 'AddressAlreadyInUseException' not sure) and the 2nd developer is not able to perform any kind of debugging at the service. This happens even thought we (off course) have different windows usernames and hence we are working in different sessions.
It's still possible for the client app. to continue working with the 'original' service instance since we're catching the exception at the service, but debbugging is impossible. And if the first developer stops the wcf service then the app. fails.
I would like to know if you could have any recomendation for us. My be there's some sort of tool available (even if we must pay for it) that could somehow isolate each developers' workspace at the server... or may be we just need to change something in the way we work.
I would be very grateful for any kind of advice or clue.
Best regards,
Gonzalo
I would recomend that each developer had their own copy of the server services.
When we develop, each developer has a full environment on their machine. As things are completed, they are checked in to the version control system. When the other developers get the lastest version, new functionality is spread to the other developers.
If I understand your setup, all developers are working against the same server, in this case a programming error of one developer will stop all development.
Hey man, the debugger connects through IP communication. That means if a service or process binds a listener, no other service or process can bind this IP port a second time.
That is the reason for throwing the exception.
In Citrix you have the Virtual IP configuration.
You can also consider to place a VM on the server that serves only for one developer. This would also solve this problem