Atividades de "DominaTang"

hi

https://docs.abp.io/en/abp/latest/Unit-Of-Work#conventions

Finally figure out the reason, after deploy the code to Azure kubernetes, NgInx has two settings default to 60 seconds, need to change the value there https://ubiq.co/tech-blog/increase-request-timeout-nginx/

Thanks, Domina

hi

https://docs.abp.io/en/abp/latest/Unit-Of-Work#conventions

I use a timer, the API call is time out at 60 seconds. However, according to Ocelot document, the default gateway time out is 90 seconds. So where this 60 seconds time out come from? Unit of work?

hi

https://docs.abp.io/en/abp/latest/Unit-Of-Work#conventions

I read the document. Disable unit of work of entrance to avoid long file operations make Db transactions too long, otherwise, more chance of deadlock for database transactions.

Is there a way to dump data to database immediately, I add true flag to each of Insert/Update method call. But seems it doesn't work. And why gateway thinks the first operation failed and try the second time to make the same call?

hi

There are some timeout settings that you can use in your MongoDB connection string.

https://www.mongodb.com/docs/manual/reference/connection-string/

I don't have long transaction, the entrance API the UnitOfWork is disabled. with the process, any place needs Db access, I create a new unit of work with new transaction.

I found a very strange behavior, in every repository Insert/Update call, I give auto save parameter true and wrap with an unit of work, however, it until around 20 seconds later after API is done, then the new data would shown in Db, I can see number of records increasing via MongoDb. But UI subscribe to the API method already done and show an intermediate status of progress.

I have a question, if the entrance App Service method has [UnitOfWork] disabled, do I need to add this to every app service methods for the whole stack?

There is also Blob code called, I see exception below, though the Save method is await _container.SaveAsync(fileNamePath, bytes, true);

Azure.RequestFailedException: The specified container already exists. RequestId:c84c6932-d01e-0065-7d95-ea64f5000000 Time:2023-09-19T01:06:57.2040621Z Status: 409 (The specified container already exists.) ErrorCode: ContainerAlreadyExists

Content: <?xml version="1.0" encoding="utf-8"?><Error><Code>ContainerAlreadyExists</Code><Message>The specified container already exists. RequestId:c84c6932-d01e-0065-7d95-ea64f5000000 Time:2023-09-19T01:06:57.2040621Z</Message></Error>

Headers: Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0 x-ms-request-id: c84c6932-d01e-0065-7d95-ea64f5000000 x-ms-client-request-id: 2a718994-11d6-4088-8cf6-5a77e3014d89 x-ms-version: 2023-01-03 x-ms-error-code: ContainerAlreadyExists Date: Tue, 19 Sep 2023 01:06:56 GMT Content-Length: 230 Content-Type: application/xml

at Azure.Storage.Blobs.ContainerRestClient.CreateAsync(Nullable1 timeout, IDictionary2 metadata, Nullable1 access, String defaultEncryptionScope, Nullable1 preventEncryptionScopeOverride, CancellationToken cancellationToken) at Azure.Storage.Blobs.BlobContainerClient.CreateInternal(PublicAccessType publicAccessType, IDictionary`2 metadata, BlobContainerEncryptionScopeOptions encryptionScopeOptions, Boolean async, CancellationToken cancellationToken, String operationName)**

hi

is it because Abp gateway's auto feature?

Is your project a microservice? Otherwise, it does not have a gateway project. Do you use a reverse proxy?

Yes, it is Micro Service project. I modify settings to this: "QoSOptions": { "ExceptionsAllowedBeforeBreaking": 1, "DurationOfBreak": 1000, "TimeoutValue": 1200000 } Seems work as expected locally. But not deployed site yet. I also met a very weird null reference exception at the line, _entityAppServe.GetById (uniqueId); which _entityAppService is a App Service in another Micro Service, it means _entityAppService is null, it is not always happen, but occasionally happens, I don't understand why.

Now I suspect it is because that Request Time out settings of .Host project, I tested locally, since change the settings, has no impact. Locally testing can always process large data, but for deployed code, the application throw exception at certain amount of data. I also noticed that the request is triggered again when first request failed, is it because Abp gateway's auto feature?

Hi @maiiming,

I sent you exception call stack via email.

The code disable entrance API's unit of work, because the whole process involves other resources access which might take long time, wrap data access code by unit of work at the steps need to access database.

Thanks, Domina

From Angular App, console: POST https://localhost:44325/signalr-hubs/messaginghub/negotiate?negotiateVersion=1 502

From Gateway log: web-gateway_4420d4f8-1]: [13:53:47 DBG] requestId: 0HMT7TSEGNSB6:0000000D, previousRequestId: no previous request id, message: Downstream url is http://localhost:45186/signalr-hubs/messaginghub/negotiate?negotiateVersion=1 [web-gateway_4420d4f8-1]: [13:53:47 DBG] requestId: 0HMT7TSEGNSB6:0000000D, previousRequestId: no previous request id, message: IHttpRequester returned an error, setting pipeline error [web-gateway_4420d4f8-1]: [13:53:47 WRN] requestId: 0HMT7TSEGNSB6:0000000D, previousRequestId: no previous request id, message: Error Code: ConnectionToDownstreamServiceError Message: Error connecting to downstream service, exception: System.Net.Http.HttpRequestException: An error occurred while sending the request. [web-gateway_4420d4f8-1]: ---> System.IO.IOException: The response ended prematurely.

Figured out the reason. It is because of wrong grand type setting (should use grand type "code", but the angular app users resource owner.