Changing the Azure http version for my website from 2 to 1.1 fixed the problem. It seems the latest version of Flurl does not support http2, which is very odd. Do you guys have a different version of AbpApiClient.cs that does not use Flurl? Maybe HttpClient?
I just finished writing the Android application. Everything is working fine with the localhost server. I changed the ApiUrlConfig.DefaultHostUrl const to point to my live website (previously it was localhost). Then I ran it in the emulator in Debug mode, but got the above exception. I'm not sure why it would do that. The website itself works just fine. Here is the full stack. Does it have anything to do with the fact that I am running it in Debug mode in the emulator?
{Java.IO.IOException: stream was reset: PROTOCOL_ERROR at ModernHttpClient.NativeMessageHandler.SendAsync (System.Net.Http.HttpRequestMessage request, System.Threading.CancellationToken cancellationToken) [0x00428] in /Users/paul/code/paulcbetts/modernhttpclient/src/ModernHttpClient/Android/OkHttpNetworkHandler.cs:135 at BalanceForecasting.ApiClient.AuthenticationHttpHandler.SendAsync (System.Net.Http.HttpRequestMessage request, System.Threading.CancellationToken cancellationToken) [0x00037] in C:\Users\Robert\Documents\BalanceForecastingZero\src\BalanceForecasting.Application.Client\ApiClient\AuthenticationHttpHandler.cs:29 --- End of managed Java.IO.IOException stack trace --- java.io.IOException: stream was reset: PROTOCOL_ERROR at com.squareup.okhttp.internal.spdy.SpdyStream.getResponseHeaders(SpdyStream.java:145) at com.squareup.okhttp.internal.http.SpdyTransport.readResponseHeaders(SpdyTransport.java:104) at com.squareup.okhttp.internal.http.HttpEngine.readNetworkResponse(HttpEngine.java:830) at com.squareup.okhttp.internal.http.HttpEngine.access$200(HttpEngine.java:95) at com.squareup.okhttp.internal.http.HttpEngine$NetworkInterceptorChain.proceed(HttpEngine.java:823) at com.squareup.okhttp.internal.http.HttpEngine.readResponse(HttpEngine.java:684) at com.squareup.okhttp.Call.getResponse(Call.java:272) at com.squareup.okhttp.Call$ApplicationInterceptorChain.proceed(Call.java:228) at com.squareup.okhttp.Call.getResponseWithInterceptorChain(Call.java:199) at com.squareup.okhttp.Call.access$100(Call.java:34) at com.squareup.okhttp.Call$AsyncCall.execute(Call.java:162) at com.squareup.okhttp.internal.NamedRunnable.run(NamedRunnable.java:33) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1162) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:636) at java.lang.Thread.run(Thread.java:764) }
I didn't know about that, thanks! Closing again.
Understood.
One more thing: Caching of User result in UserStore.FindByIdAsync will have a high impact, because that is #1 by count. It's easy enough to cache it there, but I am afraid that it will have unforeseen consequences if I forget to update the cache when a given user is updated. Besides AccountController and AccountAppService, is there any other place where I should invalidate the userid from the cache?
Where does the application query UserRole and UserOrganizationUnit? Why can't I cache those too?
Wow, there are so many calls to UserStore.FindByIdAsync and UserStore.GetRolesAsync in a single page load. Time to do some caching!
I have about 800 users right now. Which is why the execution counts look very high to me, because it's not a lot of users.
I don't use UserOrganizationUnit. I will try the caching you mentioned, thanks!
Reopening. This did not actually fix the issue with numerous queries. I can't tell if it's Abp making them or Zero. Below is a screenshot with Azure with the most numerous queries (sorted descending). The one on the bottom is a query from my application. I don't have multi-tenantcy enabled, my permissions are very straightforward, I have two roles, one user and one admin and that's about it. The amount of database requests is much too high. What can I do about this?
The tables being queries are: AbpUsers AbpRoles The original query above is #3 in the list A join on AbpUserRoles and AbpRoles AbpRoleClaims AbpUserClaims
Ah, yeah, that is probably the case. I disabled notifications too, so it works for me.
It worked well for me. It's a bit more involved than changing permissions, but it actually removes signalr calls.
