Request Timeout 0

Aug 3, 2015 at 1:41 PM
Hi Linvi,
When I use the new version of TweetInvi (0.9.9), any timeout messages I get from Twitter show the timeout as being 0ms.
I have not changed it from the default (which in previous versions was 10000ms).
Obviously the timeout is not 0ms or it wouldn't have timed out.

Example of the exception message:
2015-08-03 14:39:17 - libCommsManager.Helpers.TweetInviExceptionHelpers: Warning: Twitter Exception:
--- Date : 03/08/2015 14:39:17
URL : https://api.twitter.com/1.1/direct_messages/sent.json?count=200&include_entities=False
Code : 408
Error documentation description : Twitter was not able to perform your query within the Timeout limit of 0 ms.

Let me know if you need any additional information.
Cheers,
Josh
Coordinator
Aug 3, 2015 at 1:52 PM
Edited Aug 3, 2015 at 1:56 PM
Hi,

Thank you for the post, I will investigate this issue as soon as possible and release a fix if needed.
Could you please let me know which type of project you are working on.

In the meantime please try the following to fix the issue until further release:
TweetinviEvents.QueryBeforeExecute += (sender, args) =>
{
    args.TwitterQuery.Timeout = TimeSpan.FromSeconds(10);
};
Please share your code too, if possible.

Linvi
Aug 3, 2015 at 2:07 PM
Hi Linvi,
After adding that snippet I'm getting some exceptions that say 10000ms and others that say 0ms.

It's in a Console Application (.NET 4.5).

I can't share the code but if you can't reproduce I can look at putting something together to reproduce it.
Cheers,
Josh
Aug 3, 2015 at 2:40 PM
Edited Aug 3, 2015 at 2:40 PM
I've just checked the logs & found that it was actually a mix of 10000ms and 0ms before adding that snippet too, apologies.
Cheers,
Josh
Coordinator
Aug 3, 2015 at 2:56 PM
It would be great if you could send me a repro solution.
Looking around the code I have no idea how such thing is possible.

The reason I am saying so is that I added some code to make sure the timeout value is correct right before performing the query.
using (var client = new HttpClient(handler))
{
    if (twitterQuery.Timeout != null && twitterQuery.Timeout.Value.TotalMilliseconds > 0)
    {
        client.Timeout = twitterQuery.Timeout.Value;
    }
    else
    {
        client.Timeout = new TimeSpan(0, 0, 10);
    }
    ...
}
Would you please consider trying your code using the Source Code version of Tweetinvi?
Cheers,
Linvi
Aug 3, 2015 at 3:20 PM
Hi Linvi,
Just looking at the src for HttpClientWebHelper & TwitterTimeoutException, it looks like you've changed the way timeouts get set between 0.9.8 and 0.9.9 so that each query can have its own timeout (as could be set using the snippet you supplied me with), but the value printed in the Exception is still taken from ITweetinviSettingsAccessor.

The value on ITweetinviSettingsAccessor won't reflect the value for that query, and also wont reflect the default value used by HttpClientWebHelper (gets set in the snippet you've posted in your last message).

So it looks to me like the timeout is actually correct, but the value printed in the exception is wrong.

Also, I'd have previously set a request timeout with
TweetinviConfig.APPLICATION_WEB_REQUEST_TIMEOUT = 0;
but the new implementation just uses a hardcoded value of 10. Shouldn't it fall back to APPLICATION_WEB_REQUEST_TIMEOUT or is this an intended change?
Cheers,
Josh
Aug 3, 2015 at 3:31 PM
Whoops, I meant it should fall back to the value for that thread, not the application (so CURRENT_WEB_REQUEST_TIMEOUT, not APPLICATION_WEB_REQUEST_TIMEOUT).
Cheers,
Josh
Coordinator
Aug 3, 2015 at 3:42 PM
Thanks for these quick replies. I really appreciate it.
In 0.9.9.0 I have made an important refactoring of the Web Layer with the intention of making each query more customizable.
This is the case of the Timeout property.

As you mentioned each of the ITwitterQuery should be set by default by the APPLICATION_WEB_REQUEST_TIMEOUT.
The hardcoded value is intentional. I wanted to make sure that an invalid set up of the Timeout will not make queries to fail.

I will fix the error reporting issue by using the TwitterQuery instead of the ITweetinviSettingsAccessor.

In the meantime I still want to understand how you can get an error with your code.
If you use the Source Code could you check the properties of the TaskCancelledException?
If not, I will need a repro project to be able to reproduce and fix the issue.

Linvi
Coordinator
Aug 3, 2015 at 3:52 PM
Also could you let me know if your application is multi-thread (threads or async).

Linvi
Aug 3, 2015 at 3:53 PM
Hi Linvi,
I don't think there is any problem other than the value in the Exception being wrong.
I have always had occasional timeouts when the application is first launched (hundreds of requests get sent in parallel, and I assume Twitter has some anti-spam/flood mechanism that drops some of the connections) and so I believe the timeouts to be genuine.

Once the application is running, the timeouts stop and everything runs smoothly (apart from the occasional timeout), as has been the case when using previous versions of Tweetinvi. The only thing that threw me after the update was the timeout value being wrong in the exception.

Unless I've misunderstood what you mean?
Cheers,
Josh
Aug 3, 2015 at 3:54 PM
And it's multi-threaded
Coordinator
Aug 3, 2015 at 3:57 PM
Edited Aug 3, 2015 at 3:57 PM
Oh that's great. I thought all the webrequests were failing because of this setting.

So what you are saying is that sometime, the HttpClient is throwing an exception but most of the time Tweetinvi is working as expected.
The bug you reported is in fact that the message is wrong?

If so, I think we understood each other, and the only issue is the displayed value in the TwitterException.
I will fix this in the next release (0.9.9 branch).

Linvi
Aug 3, 2015 at 4:01 PM
Yeah, I'm now (after what you've said & looking at the src) pretty confident it's just the value in the TwitterException and everything is actually working as intended.
Thanks for your help!
Josh
Coordinator
Aug 3, 2015 at 4:06 PM
In fact, after think about this, there is still an issue. The value of the SettingsAccessor should never be 0.

So there is an issue with multi-threaded default values.
I will try to do repro cases but if I can't may I come back to you?

I would really appreciate some feedback related with the breaking changes and the improvements of 0.9.9.x.
I am wondering what you and other developers think of this update.
Aug 3, 2015 at 4:30 PM
Alright, I'll keep the production code on 0.9.8.2 for now then.

The basic architecture is basically the same as the repro project from https://tweetinvi.codeplex.com/discussions/626398 so I'd imagine that proj should reproduce this.

As for the changes for 0.9.9, I found it fairly simple to upgrade.
The biggest change I had to make was around the process of authorising a new account (no more ITemporaryCredentials being handled manually), but the new method seems slightly simpler.
The changes for sending Tweets makes the API simpler (always nice).
The most important bits for me though are the added functionality of being able to quote a tweet and upload videos which I haven't played with yet but were both things customers have been asking me for.
Overall, very positive!
Cheers,
Josh
Coordinator
Aug 3, 2015 at 10:49 PM
This should now be solved by Tweetinvi 0.9.9.1.
Thanks for your feedback, I really appreciate it.

Cheers,
Linvi
Marked as answer by linvi on 8/3/2015 at 3:49 PM
Aug 4, 2015 at 9:41 AM
Hi Linvi,
That's fixed it.
Thanks for your help & very fast responses!
Cheers,
Josh