ExecuteAsync randomly fails in WPF application

157 views
Skip to first unread message

Kindler Chase

unread,
May 22, 2012, 3:03:59 PM5/22/12
to rest...@googlegroups.com
When running the following in a WPF application, the ExecuteAsync method will receive an error response from the Rest Service being called sometimes. However, when run in a console app, there is never an error response. Any suggestions would be appreciated.

private static void TestRest()
{
var client = new RestClient( "http://example.com" );
var request = new RestRequest
 {
 Resource = "my/resource/",
 Method = Method.GET,
 RequestFormat = DataFormat.Json,
 };

request.AddHeader( "Accept", "application/json, text/javascript, */*" );
request.AddParameter( "format", "json" );
request.AddParameter( "key1", "value1" );
request.AddParameter( "key2", "value2" );
request.AddParameter( "key3", "value3" );

Uri restUrl = client.BuildUri( request );
Trace.WriteLine( restUrl.AbsoluteUri, "Rest URL" );

client.ExecuteAsync<MyClass>( request, RestCallback );
}

private static void RestCallback( IRestResponse<MyClass> response, RestRequestAsyncHandle handle )
{
string msg;
if( response.StatusCode == HttpStatusCode.OK && response.Data != null
&& response.Data.StatusCode.ToLower() == "ok" )
{
msg = "response is valid.";
}
else
{
msg = "response is not valid.";
msg += string.Format( "HttpStatusCode: {0}. Description: {1}",
 response.StatusCode,
 response.StatusDescription );

if( response.Data != null )
{
// StatusCode will intermittently return an error in an WPF application, 
// but not a Console Application. The StatusMessage is always empty.
msg += string.Format( "Status Code: {0}", response.Data.StatusCode );
msg += string.Format( "Status Message: {0}", response.Data.StatusMessage );
}
}

Trace.WriteLine( msg );
}

John Sheehan

unread,
May 23, 2012, 3:45:30 AM5/23/12
to rest...@googlegroups.com
What's the error?

Kindler Chase

unread,
May 23, 2012, 11:11:03 AM5/23/12
to rest...@googlegroups.com
There is not an error returned. I cannot successfully/reliably reproduce this issue; but, it only occurs within the WPF application. I don't know if there is some odd caching issue or something else... but, the error will typically be resolved by restarting the application. 

fwiw: I've appended the querystring with a random sequence, but the error will still appear sometimes.

Any ideas on where to begin troubleshooting this would be appreciated.


On Wednesday, May 23, 2012 2:45:30 AM UTC-5, John Sheehan wrote:
What's the error?

Andy Cutright

unread,
May 23, 2012, 12:09:29 PM5/23/12
to rest...@googlegroups.com
You're certain the server is responding with the correct response when using the WPF application? 

Kindler Chase

unread,
May 23, 2012, 12:16:09 PM5/23/12
to rest...@googlegroups.com
I am certain; the test code is identical in both the Console app and the WPF app. I realize this sounds flaky, especially since I cannot reliably reproduce the issue. I've only seen this occur in the WPF application, though. Then again, I've test much less in the console app since the majority of the time I'm working on the WPF app.

Is there some sort of caching mechanism that happens with RestSharp?

Andy Cutright

unread,
May 23, 2012, 12:36:54 PM5/23/12
to rest...@googlegroups.com
The code being the same isn't the question I'm asking exactly. I'd set up a proxy & verify you're actually getting the correct outgoing and incoming data. It could very well be something in the client side, though I don't believe RestSharp in itself does any caching. 

From what you say it does seem likely there's something client side, especially given you've tweaked the parameters. 

Andrew Young

unread,
May 23, 2012, 3:35:58 PM5/23/12
to rest...@googlegroups.com
If its a particularly difficult big to diagnose I would suggest pulling he source and debugging at the point where it sets the response error status.

John Sheehan

unread,
May 24, 2012, 7:54:44 PM5/24/12
to rest...@googlegroups.com
It's possible it's the connection pool being exhausted or something
like that. Enable network tracing to try capturing it:
http://msdn.microsoft.com/en-us/library/ty48b824.aspx
Reply all
Reply to author
Forward
0 new messages