synchronizing on OAuth.class is problematic about eve-esi HOT 10 CLOSED

No, we only want to refresh/update the access token once, that is why that part is synchronized.
We have to wait until it's refreshed or we can't update, anyway.

Could you explain what kind of problems you're getting with it?

from eve-esi.

The synchronized block should start at

We can do that change after #75 as everything is prepared already.

@eve-gatt Do you use the library in production?

from eve-esi.

I'm going to look into this.
I think we need a stronger link between the refresh token and the access token, and the updating of both

from eve-esi.

No, we only want to refresh/update the access token once

Yeah, that makes sense, but that synchronized block means that only 1 thread can update any access token at a time doesn't it?

Could you explain what kind of problems you're getting with it?

Yeah, I suspect the http call is never returning and so all my other threads get queued behind it. I'm trying this for now to see if it helps:

con.setConnectTimeout(10000);
con.setReadTimeout(10000);

@eve-gatt Do you use the library in production?

In that I've got about 40 or so corpies using it daily, yes.

from eve-esi.

Specifically, the error I got at 03:17 this morning was:

WARNING: Thread Thread[worker-pilot-tracker-5,5,main] has been blocked for 60090 ms, time limit is 60000 ms 
io.vertx.core.VertxException: Thread blocked 
  	at net.troja.eve.esi.auth.OAuth.getAccessTokenData(OAuth.java:118) 
  	at net.troja.eve.esi.auth.OAuth.applyToParams(OAuth.java:47) 
  	at net.troja.eve.esi.ApiClient.updateParamsForAuth(ApiClient.java:834) 
  	at net.troja.eve.esi.ApiClient.invokeAPI(ApiClient.java:711) 
  	at net.troja.eve.esi.api.LocationApi.getCharactersCharacterIdLocation(LocationApi.java:93) 

from eve-esi.

Default Timeout is very likely 300s, so that connection just returns very late, but too late for vertx.
I hope your timeout changes work as expected!

The change to OkHttp probably also helps in this case.

from eve-esi.

I thought the default timeout was 0, i.e. infinity. The vertx part is just a warning and I could extend that if there was a valid case for a thread taking > 1min. Let's see how setting an explicit timeout works. Unfortunately this occurs so infrequently that it's difficult to test. I'm not even sure how to simulate it.

from eve-esi.

So I would just say lets wait for it and if it still exists, try another fix.
Simulating it would mean you have to drop or slow down those special packages but I think that's way too complicated.

from eve-esi.

Work-in-progress PR (#79) up for this.

from eve-esi.

Released in 3.0.0

from eve-esi.