it seems that service method are not really called asynchronously - silverlight

Regarding my previous post: 910220 - service methods run dependently
since the code and what I meant about the problem I had with it was a bit complex, I come again with a completely changed code which explains itself better.
In client side, we have:
#define USE_ONLY_ONE_INSTANCE
using System;
using System.ComponentModel;
using System.Windows;
using System.Windows.Controls;
using CountTester.ServiceReference1;
namespace CountTester
{
public partial class MainPage : UserControl
{
#if USE_ONLY_ONE_INSTANCE
private readonly Service1Client _sc = new Service1Client();
#endif
public MainPage()
{
InitializeComponent();
#if USE_ONLY_ONE_INSTANCE
_sc.CountCompleted += OnCountCompleted;
#endif
}
void OnCountCompleted(object sender, AsyncCompletedEventArgs e)
{
if (e.Error != null)
throw new Exception(string.Format("Count Error {0}", e.Error));
}
private void UserControl_Loaded(object sender, RoutedEventArgs e)
{
for (int i = 0; i < 100; i++)
{
#if USE_ONLY_ONE_INSTANCE
_sc.CountAsync(i);
#else
var sc = new Service1Client();
sc.CountCompleted += OnCountCompleted;
sc.CountAsync(i);
//sc.CloseAsync();
#endif
}
}
}
}
this is code behind of the XAML. In the code I call a service method 100 times. I tried both cases and get exception in both cases:
case 1: I use only one instance of the proxy for all communications with server.
case 2: I use an instance for each communication with server.
Let's see the code at server before more description:
using System.IO;
using System.ServiceModel;
using System.ServiceModel.Activation;
using System.Text;
using System.Threading;
namespace CountTester.Web
{
[ServiceContract(Namespace = "")]
[SilverlightFaultBehavior]
[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]
public class Service1
{
const string logFileName = #"h:\CountTester.log";
object _logLock = new object();
void log(string s)
{
lock (_logLock)
{
var streamWriter = new StreamWriter(logFileName, true, Encoding.ASCII);
streamWriter.Write(s);
streamWriter.Close();
}
}
Service1()
{
//File.Delete(logFileName);
}
[OperationContract]
public void Count(int counter)
{
log(string.Format("{0}\n", counter));
Thread.Sleep(3000);
}
}
}
Count is the service method which is called. I deliberately wait 3 seconds in the method. what I expect is that the for at the client get accomplished with no delay. I expect the method gets called asynchronously and this means that first call doesn't affect on the second call.
In another words, if i call the method and it waits to get accomplished, calling it again doesn't get delayed.
While this is the case. how can I figure out that this happens? by using Tail for Windows, I find that the number which is logged is delayed in getting logged. I also figure out this when I see that I get time out exception in response to calling the service method (Count Error...). I hope I could clarify my question.
I also wonder when I see malfunctioning of the program (Exception), when I uncomment the line in which I've closed the service?
Please answer these two questions.

Question 1:
By default your IIS web service will only allow 2 simultaneous requests from the same IP address. This limitation is a default to stop DOS (Denial Of Service) attacks.
That means the subsequent 98 calls are waiting at least 3 seconds, per pair, while the previous ones complete. Eventually you will hit the default 30 second(?) server timeout long before the last requests are processed.
If you insist on running that many simultaneous requests (you shouldn't anyway), you will need to increase the default limits in your web.config file on the server. See my other answer here for more details
Question 2:
You should not close an async call immediately after starting it... the call is still in progress. That code makes no sense.
Notes:
Logging is delayed anyway, for efficiency, so don't use that as a guide.

Related

Youtube API v3 error - Hangs on await searchListRequest.ExecuteAsync();

I've been playing around with the Youtube V3 API and i can't seem to get it to work in a windows form. I got the sample code to work, so I know that my API key works correctly, but when i try to convert it from a console app, the code hangs on this line,
var searchListResponse = await searchListRequest.ExecuteAsync();
I haven't been able to find anything relevant to this issue, there are no compile errors or run-time errors are being thrown. Any help would be greatly appreciated!
using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Threading;
using System.Threading.Tasks;
using System.Windows.Forms;
using Google.Apis.Auth.OAuth2;
using Google.Apis.Services;
using Google.Apis.Upload;
using Google.Apis.Util.Store;
using Google.Apis.YouTube.v3;
using Google.Apis.YouTube.v3.Data;
namespace MiddleManYTDL
{
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}
private void Form1_Load(object sender, EventArgs e)
{
MessageBox.Show("YouTube Data API: Search");
try
{
new Form1().Run().Wait();
}
catch (AggregateException exs)
{
foreach (var ex in exs.InnerExceptions)
{
MessageBox.Show("Error: " + ex.Message);
}
}
}
private async Task Run()
{
var youtubeService = new YouTubeService(new BaseClientService.Initializer()
{
ApiKey = "My API Key",
ApplicationName = this.GetType().ToString()
});
var searchListRequest = youtubeService.Search.List("snippet");
searchListRequest.Q = "Google"; // Replace with your search term.
searchListRequest.MaxResults = 10;
MessageBox.Show("This will Display");
// Call the search.list method to retrieve results matching the specified query term.
var searchListResponse = await searchListRequest.ExecuteAsync();
MessageBox.Show("This never gets executed");
List<string> videos = new List<string>();
List<string> channels = new List<string>();
List<string> playlists = new List<string>();
// Add each result to the appropriate list, and then display the lists of
// matching videos, channels, and playlists.
foreach (var searchResult in searchListResponse.Items)
{
switch (searchResult.Id.Kind)
{
case "youtube#video":
videos.Add(String.Format("{0} ({1})", searchResult.Snippet.Title,
searchResult.Id.VideoId));
break;
case "youtube#channel":
channels.Add(String.Format("{0} ({1})", searchResult.Snippet.Title,
searchResult.Id.ChannelId));
break;
case "youtube#playlist":
playlists.Add(String.Format("{0} ({1})", searchResult.Snippet.Title,
searchResult.Id.PlaylistId));
break;
}
}
MessageBox.Show(String.Format("Videos:\n{0}\n", string.Join("\n", videos)));
MessageBox.Show(String.Format("Channels:\n{0}\n", string.Join("\n", channels)));
MessageBox.Show(String.Format("Playlists:\n{0}\n", string.Join("\n", playlists)));
}
}
}
This has nothing to do with the YouTube API as such. Your problem is in the blocking Wait() call on the following line:
new Form1().Run().Wait();
What is happening is your code gets to Run() and executes the part of the method up to the await keyword synchronously (in your case - on the UI thread). Then, while the await is in progress, the execution returns to your Form.Load handler, which immediately hits the Wait() call and blocks the UI thread until the task returned by Run() has completed. At some point after that your awaited task inside Run() finishes and the async state machine attempts to execute the rest of the Run() method on the UI thread. Now you have Wait() blocking the UI thread while it's waiting for Run() to complete and Run() waiting for the UI thread to become available so that the remainder of the async method can be executed. Neither can make any progress. This deadlock scenario is very common whenever async/await methods are mixed with the blocking Wait() or Result calls.
There are two possible fixes:
Use async/await all the way (i.e. no blocking Wait() and Result calls up in the call hierarchy)
Rewrite your Run() method so that no UI elements are accessed after the await, and use ConfigureAwait(false) to prevent await from capturing, and subsequently posting back to the synchronization context installed on your UI thread (meaning that the part of your method following the await will execute on a thread pool thread).
Personally I'd go with option #1:
private async void Form1_Load(object sender, EventArgs e)
{
MessageBox.Show("YouTube Data API: Search");
try
{
await new Form1().Run();
}
catch (Exception ex)
{
// Exception dispatch is different with async/await,
// so you don't get the AggregateException - rather
// just the first exception which caused the task
// to fault.
MessageBox.Show("Error: " + ex.Message);
}
}
Here are some excellent blog posts which discuss the issue you are observing in detail:
http://blog.stephencleary.com/2012/07/dont-block-on-async-code.html
http://blogs.msdn.com/b/pfxteam/archive/2011/01/13/10115163.aspx

await Task.Delay(...) freezes if there exists a System.Windows.Forms.Form instance

The following program hangs on the DoTheStuff().Wait(); line, if running as a Console application:
namespace Test
{
using System.Threading.Tasks;
using System.Windows.Forms;
class Program
{
static void Main(string[] args)
{
new Form();
DoTheStuff().Wait();
}
private static async Task DoTheStuff()
{
await Task.Delay(1000);
}
}
}
It works just as expected though, if you comment out the new Form(); line. (Runs for 1sec, then quits).
How can I keep the expected behaviour and still have a Form instance?
Now, some background if you are interested:
I have an application which is hosted as a windows service (as console when testing locally).
It requires to have access to the SystemEvents.TimeChanged event.
However, as per the documentation, this only works when having a windows Form (thus not in a service or console app). A workaround is presented in the linked documentation, and consists of creating a hidden form.
Unfortunately, the program now completely freezes instead, which is caused by the combination of await and having a Form instance.
So how on earth can I still have the expected async/await behaviour while accessing the SystemEvents.TimeChanged event?
Thanks to help below, here comes modified code which works without freeze:
namespace Test
{
using System.Threading;
using System.Threading.Tasks;
using System.Windows.Forms;
class Program
{
static void Main(string[] args)
{
new Thread(() => Application.Run(new Form())).Start();
// SynchronizationContext.SetSynchronizationContext(null);
DoTheStuff().Wait();
}
private static async Task DoTheStuff()
{
await Task.Delay(1000);
}
}
}
In my program, I need to use "SynchronizationContext.SetSynchronizationContext(null);", since the threadpool should be used for awaiting tasks. I don't think that is a good practice, since Form obviously initialized it for a reason. But running the form hidden without user input (it is a service!), and can't see any harm right now.
The documentation feels a bit incomplete, with MS not even mentioning the issue that may arise using the example 2 (await/async implicitly changes behaviour when instantiating a Form).
This is by design. Creating a new Form object get the Winforms plumbing to install a new SynchronizationContext. Something you can see in the debugger by looking at the SynchronizationContext.Current property.
That property is big deal whenever you do anything asynchronously. If it is null, the default, then using await gets code to run on threadpool threads. If it is not then the await plumbing will implement the await by calling the SynchronizationContext.Post() method. Which ensures that your code runs on the main thread.
But that doesn't work in your program because you broke the contract. You didn't call Application.Run(). Required.
The SystemEvents class will create its own hidden notification window and pumps a message loop if you don't provide one. No need to create a form. The consequence is that its events will fire on an arbitrary thread, not your main thread. So do watch out for locking requirements.
The call to Wait causes a deadlock, as I explain on my blog and in a recent MSDN article.
In your case, you could use a simple MainAsync as such:
static void Main(string[] args)
{
MainAsync().Wait();
}
static async Task MainAsync()
{
new Form();
await DoTheStuff();
}
private static async Task DoTheStuff()
{
await Task.Delay(1000);
}
However, there are a couple of problems here. First, when you create a form (even a hidden form), you are expected to run an STA event loop, e.g., Application.Run. Second, as a Win32 service, you are expected to give your main thread back to the SCM, e.g., ServiceBase.Run.
So I would recommend a solution where you create a form and run an event loop on a secondary thread.

Silverlight Enabled WCF Service Exception Handling

I've got a Silverlight enabled WCF web service set up and I'm connecting to it from my Silverlight application.
The Service is not written using the ASync pattern but Silverlight generates the async methods automatically.
I have a method that within my service that has a chance of throwing an exception I can catch this exception but I'm not sure of the best way of handling this exception, I've noticed that the event args of the completed method contain an error property.
Is is possible to set the value of this error property?
Example Method
public class service
{
[OperationContract]
public Stream getData(string filename)
{
string filepath = HostingEnvironment.MapPath(filename);
FileInfo fi = new FileInfo(filenpath);
try
{
Stream s = fi.Open(FileMode.Open);
return s;
}
catch (IOException e)
{
return null;
}
}
}
Silverlight Code
btnFoo_Click(object sender, RoutedEventArgs e)
{
ServiceClient svc = new ServiceClient();
svc.getDataCompleted += new EventHandler<getDataCompletedEventArgs>(getData_Completed);
svc.getDataAsync("text.txt");
}
void getData_Completed(object sender, getDataCompletedEventArgs e)
{
e.Error //how can i set this value on the service?
}
Finally if the service is offline or times out is there anyway to catch this exception before it reaches the UnhandledException method within App.xaml?
Thanks
Since silverlight is using services asyncronously you dont get a synchronous exception throw, but instead it is stored in e.Error property, that you need to check in your ServiceCallCompleted method.
To answer your question
how can i set this value on the service?
Simply throw an exception on server and it can be enough given several other conditions.
You may want to introduce FaultContract on your WCF service method, and throw FaultException<T> which is a common way to deal with errors in WCF.
However fault result in return code 500 and silverlight won't be able to get response with such status code and have access to Fault object, even if you add that attribute to service.
This can be solved using several approaches.
Use the alternative client HTTP stack: You can register an alternative HTTP stack by using the RegisterPrefix method. See below for an outline of how to do this. Silverlight 4 provides the option of using a client HTTP stack which, unlike the default browser HTTP stack, allows you to process SOAP-compliant fault messages. However, a potential problem of switching to the alternative HTTP stack is that information stored by the browser (such as authentication cookies) will no longer be available to Silverlight, and thus certain scenarios involving secure services might stop working, or require additional code to work.
Modify the HTTP status code: You can modify your service to return SOAP faults with an HTTP status code of 200, Silverlight 4 so that faults will be processed successfully. How to do this is outlined below. Note that this will make the service non-compliant with the SOAP protocol, because SOAP requires a response code in the 400 or 500 range for faults. If the service is a WCF service, you can create an endpoint behavior that plugs in a message inspector that changes the status code to 200. Then you can create an endpoint specifically for Silverlight consumption, and apply the behavior there. Your other endpoints will still remain SOAP-compliant.
Faults in silverlight
Creating and Handling Faults in Silverlight
OR
[DataContract]
public class MyError
{
[DataMember]
public string Code { get; set; }
[DataMember]
public string Message { get; set; }
[DataMember]
public DateTime Time { get; set; }
}
public class service
{
[OperationContract]
public Stream getData(string filename, out MyError myError)
{
myError = null;
string filepath = HostingEnvironment.MapPath(filename);
FileInfo fi = new FileInfo(filenpath);
try
{
Stream s = fi.Open(FileMode.Open);
return s;
}
catch (IOException e)
{
myError = new MyError() { Code = "000", Message = ex.Message, Time = DateTime.Now };
return null;
}
}
}
I wish successful projects

WPF + Tasks + WCF = No SynchronizationContext?

I have a WPF application that is using System.Threading.Tasks to call a WCF service in the background. I'm using Task.ContinueWith to return the results of the service call to the WPF UI thread. My issue is that, although the continuation does run on the UI thread, when it does SynchronizationContext.Current is null. I can run the same code, commenting out the WCF call in the initial Task, and the continuation is on the UI thread, with a DispatcherSynchronizationContext as expected.
The WCF proxy is generated using ChannelFactory, and uses wsHttpBinding. There is no callback contract. The relevant code is shown below:
private TaskScheduler _uiScheduler;
public MainWindow()
{
InitializeComponent();
_uiScheduler = TaskScheduler.FromCurrentSynchronizationContext();
}
private void Button_Click(object sender, RoutedEventArgs e)
{
var serviceTask = new Task<Int32>(ServiceCallWrapper,
CancellationToken.None,
TaskCreationOptions.None);
var continueTask = serviceTask.ContinueWith(result => ServiceContinuation(result.Result),
CancellationToken.None,
TaskContinuationOptions.OnlyOnRanToCompletion,
_uiScheduler);
serviceTask.Start();
}
private Int32 ServiceCallWrapper()
{
Int32 result = 0;
var service = {elided - initializes service using ChannelFactory };
result = service.TheServiceMethod();
service.Close();
return result;
}
private void ServiceContinuation(Int32 result)
{ elided }
If I run this code as is, the ServiceContinuation is called on the correct thread (verified using ManagedThreadID), but SynchronizationContext.Current is null. If I comment out the single line that makes the service call (result = service.TheServiceMethod();), then ServiceContinuation is correctly called with a DispatcherSynchronizationContext.
One note - the SynchronizationContext is not permanently lost - if I Click on the button again, the button click handler does have the correct SynchronizationContext.
I've captured stack traces for the two cases; they have a few differences. I've left out all of the bits that are identical, and only included the top of the stacks where they differ, plus a few frames for reference:
Fails - Calls WCF Service
WpfContinuationsTest.MainWindow.ServiceContinuation
WpfContinuationsTest.MainWindow.<Button_Click>b__0
System.Threading.Tasks.Task`1+<>c__DisplayClass17.<ContinueWith>b__16
System.Threading.Tasks.Task.InnerInvoke
System.Threading.Tasks.Task.Execute
System.Threading.Tasks.Task.ExecutionContextCallback
System.Threading.ExecutionContext.runTryCode
System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup
System.Threading.ExecutionContext.RunInternal
System.Threading.ExecutionContext.Run
System.Threading.Tasks.Task.ExecuteWithThreadLocal
System.Threading.Tasks.Task.ExecuteEntry
System.Threading.Tasks.SynchronizationContextTaskScheduler.PostCallback
Succeeds - No Call To WCF Service
WpfContinuationsTest.MainWindow.ServiceContinuation
WpfContinuationsTest.MainWindow.<Button_Click>b__0
System.Threading.Tasks.Task`1+<>c__DisplayClass17.<ContinueWith>b__16
System.Threading.Tasks.Task.InnerInvoke
System.Threading.Tasks.Task.Execute
System.Threading.Tasks.Task.ExecutionContextCallback
System.Threading.ExecutionContext.Run
System.Threading.Tasks.Task.ExecuteWithThreadLocal
System.Threading.Tasks.Task.ExecuteEntry
System.Threading.Tasks.SynchronizationContextTaskScheduler.PostCallback
Does anyone know why, when the only difference is a WCF client service call (with no callback contract), in one case the continuation on the main thread would have a SynchronizationContext, and in the other case it wouldn't?
According to Microsoft, this is a known bug with the TPL:
http://social.msdn.microsoft.com/Forums/en-US/wcf/thread/629d5524-c8db-466f-bc27-0ced11b441ba

WCF/Silverlight: How can I foul a Channel?

I was told that I shouldn't cache channels in Silverlight/WCF because they may become faulted and unsuable. Can somone show me some sample code that would prove it can happen.
Call a service to prove the connection can work (i.e. no bogus URL)
Make a second call that fouls the channel by causing it to go into a faulted condition
Repeat the first call, which would fail.
In my own testing, the key is whether the binding you're using is session-oriented or not. If you're using a stateless binding like BasicHttpBinding, you can muck up the channel all you want and you're good. For instance, I've got a WCF service using the BasicHttpBinding that looks like this -- note specifically the Channel.Abort() call in SayGoodbye():
public class HelloWorldService : IHelloWorldService
{
public string SayHello()
{
return "Hello.";
}
public string SayGoodbye()
{
OperationContext.Current.Channel.Abort();
return "Goodbye.";
}
}
And the Silverlight client code looks like this (ugly as hell, sorry).
public partial class ServiceTestPage : Page
{
HelloWorldServiceClient client;
public ServiceTestPage()
{
InitializeComponent();
client = new HelloWorldServiceClient();
client.SayHelloCompleted += new EventHandler<SayHelloCompletedEventArgs>(client_SayHelloCompleted);
client.SayGoodbyeCompleted += new EventHandler<SayGoodbyeCompletedEventArgs>(client_SayGoodbyeCompleted);
client.SayHelloAsync();
}
void client_SayHelloCompleted(object sender, SayHelloCompletedEventArgs e)
{
if (e.Error == null)
{
Debug.WriteLine("Called SayHello() with result: {0}.", e.Result);
client.SayGoodbyeAsync();
}
else
{
Debug.WriteLine("Called SayHello() with the error: {0}", e.Error.ToString());
}
}
void client_SayGoodbyeCompleted(object sender, SayGoodbyeCompletedEventArgs e)
{
if (e.Error == null)
{
Debug.WriteLine("Called SayGoodbye() with result: {0}.");
}
else
{
Debug.WriteLine("Called SayGoodbye() with the error: {0}", e.Error.ToString());
}
client.SayHelloAsync(); // start over
}
}
And it'll loop around infinitely as long as you want.
But if you're using a session-oriented binding like Net.TCP or HttpPollingDuplex, you've got to be much more careful about your channel handling. If that's the case, then of course you're caching your proxy client, right? What you have to do in that instance is to catch the Channel_Faulted event, abort the client, and then recreate it, and of course, re-establish all your event-handlers. Kind of a pain.
On a side note, when it comes to using a duplex binding, the best approach that I've found (I'm open to others) is to create a wrapper around my proxy client that does three things:
(1) Transforms the obnoxious event-raising code generated by the "Add Service Reference" dialog box into a far-more-useful continuation-passing pattern.
(2) Wraps each of the events raised from the server-side, so that the client can subscribe to the event on my wrapper, not the event on the proxy client itself, since the proxy client itself may have to be deleted and recreated.
(3) Handles the ChannelFaulted event, and (several times, with a timeout) attempts to recreate the proxy client. If it succeeds, it automatically resubscribes all of its event wrappers, and if it fails, it throws a real ClientFaulted event which in effect means, "You're screwed, try again later."
It's a pain, since it seems like this is the sort of thing that should have been included with the MS-generated code in the first place. But it sure fixes a whole lot of problems. One of these days I'll see if I can get this wrapper working with T4 templates.

Resources