Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Local backup when recieving System.Net.WebException #49

Open
AnnabellBrocker opened this issue Feb 11, 2020 · 1 comment
Open

Local backup when recieving System.Net.WebException #49

AnnabellBrocker opened this issue Feb 11, 2020 · 1 comment

Comments

@AnnabellBrocker
Copy link

Hey everyone,

if the connection is not stable (maybe because of wrong url or other stuff) I would like to make a local backup. so far everything is already implemented. But when for example I entered the wrong url, the whole execution takes a very long time. During this time my application is frozen.
I guess the timeout is quite long, so the idea would be that the timeout needs to be smaller so that the user does not get the feeling of a frozen application.

Here is my code:

var lrs = new RemoteLRS(
trackingInitializer.LRS,
trackingInitializer.BasicAuthUsername,
trackingInitializer.BasicAuthPassword
);

try
{
StatementLRSResponse lrsResponse = lrs.SaveStatement(statement);
if (lrsResponse.success)
{
....Do Stuff ....
}
}
catch(Exception e)
{
... save local backup ....
}

@reedmclean
Copy link
Contributor

The plan is to eventually cut a new version of this library that makes asynchronous HTTP requests so that waiting for a response doesn't block the current thread. However, that "eventually" is pretty far out, and we don't have a definitive timeline. Whenever we're able to get to it, that should largely address this issue,

Until then, I would recommend an alternative strategy outside of the library to account for this requirement. A couple of options I thought of:

  1. You could make your own test requests to the endpoint to verify connectivity before calling SaveStatement. This could either be immediately before you call lrs.SaveStatement, or it could be on a background job that keeps track of the current connectivity status. You don't need to worry about getting a successful response back; you only need to verify that there is a response at all. You can configure the timeout on the test request to your preference, and then only call SaveStatement once you've verified connectivity.
  2. You could spin up another thread and use it to call lrs.SaveStatement in the background. That way, the long-running request doesn't block the rest of your application while it waits for the response. I found this article that describes some ways to accomplish this: https://markheath.net/post/starting-threads-in-dotnet

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants