locked
Synchronous WCF in Silverlight RRS feed

  • Question

  • I have a situation where I do need to lock the UI thread with a Synchronous call to a WCF service.  I am using a service to get information about what server IP address to connect to. This is in an OOB application.  I cannot let the application continue without getting the server information from the WCF service.

    Any ideas?

    Thanks in advance

    Thursday, April 18, 2013 8:34 PM

Answers

  • I decided to put the web service in it's own thread and that makes it truly threaded.  That way I can use the manual set and reset events of the threading.  It seams to be working just fine.

    Thanks for your response.

    • Marked as answer by CSSIWV Friday, April 19, 2013 12:08 PM
    Friday, April 19, 2013 12:08 PM

All replies

  • You should really reconsider the architecture of your application. Blocking the UI thread is neither advised nor generally possible through conventional means - that includes blocking on a WCF call - unless you revert to very dirty tricks like putting the UI thread in an infinite loop polling a background thread that makes the actual call (and burning the CPU) or using a blocking P/Invoke call. If you only need to block the user from interacting with the UI then you should use a BusyIndicator from the SL toolkit.
    Friday, April 19, 2013 8:39 AM
  • The architecture of the application is just fine.  The problem is with an enterprise application that you cannot just hardcode the ip address of the data server into the application in the web.config or app.config.  Simply put I have to get the ip address of the data server to the OOB Silverlight client.  Since they are no longer on the website there is no other way to deliver that IP address to the client without using a web service. It takes a mere 200 milliseconds to get the data from the flat file and pass it to the client.  You would think that it would be fast enough that it would work but the Silverlight application is running on the local machine and not across the internet. The application is actually faster and starts up faster than the web service hard to believe I know.  The web service doesn't return the IP address back fast enough because it is going to the website connecting to the web service and returning no more than 15 characters.  The client app is an OOB application so it fires off the App.xaml.cs file and inside there I am making a call to the web service to get the ip address of origin.  The problem is the web server and service is a little slow at times depending on the usage at peak times. When my main user form shows it is expecting to communicate with the server but the web service didn't return the ip address fast enough and therefore cannot communicate with the data server.  Chicken and the egg, I need the ip address that might take 200 milliseconds or up to 2 seconds during peak times.  I need the ip address first before I can attempt to communicate with the data server and show my main form.  I know stopping the UI is bad practice but I need to slow the UI down enough to get that simple ip address so that the application may finish starting up. I am not asking to stop the UI forever or even 10 seconds just long enough to return 15 characters during peak times.  I just need that small up to 2 second wait in the UI before it continues processing code in the app.xaml.cs.  Every Microsoft applications has a splash screen that it waits for before it can load the application, this is no different. I am not sure the best practice method applies here.  If waiting a max of 2 seconds is the worst thing in the world that ever happens I think the app will be ok.  The only time this is an issue is if the service is unavailable and there is already error handling for that.

    So I really need some ideas to hold it up for 2 second. Manual wait events and threading do not work. The web service is only somewhat Asynchronous and manual wait and reset, set and reset events don't work.

    Friday, April 19, 2013 11:24 AM
  • Hi,

    but my problem is that whatever you want to do after getting the ip address why can't you do that in corresponding Completed event handler?

    You can call StubAsync() method, after method completes you will get that ip address as parameter in the completed event handler. You can further proceed in that completed event handler.

    Can you tell what problem did you face in this?


    One good question is equivalent to ten best answers.

    Friday, April 19, 2013 11:42 AM
  • I decided to put the web service in it's own thread and that makes it truly threaded.  That way I can use the manual set and reset events of the threading.  It seams to be working just fine.

    Thanks for your response.

    • Marked as answer by CSSIWV Friday, April 19, 2013 12:08 PM
    Friday, April 19, 2013 12:08 PM