Additional information from my testing:
Disabling the Backgound job system entirely using IsJobExecutionEnabled=false, stops the issue described above, so it's very likely something was introduced since 13.1.1 that affects the Background job processing / database connection use.
Thanks, Sam.
Angular + ASP.NET Core version 8.0 ANZ version 13.2.0
Greetings;
We have upgraded to version 13.2.0 from 13.1.1 and are now encountering backend connection errors immediately on startup:
ERROR 2024-05-24 22:33:40,227 [14 ] oft.EntityFrameworkCore.Database.Command - Failed executing DbCommand (2ms) [Parameters=[@__Now_0='?' (DbType = DateTime), @__p_1='?' (DbType = Int32)], CommandType='Text', CommandTimeout='300']
SELECT a
.Id
, a
.CreationTime
, a
.CreatorUserId
, a
.IsAbandoned
, a
.JobArgs
, a
.JobType
, a
.LastTryTime
, a
.NextTryTime
, a
.Priority
, a
.TryCount
FROM AbpBackgroundJobs
AS a
WHERE NOT (a
.IsAbandoned
) AND (a
.NextTryTime
<= @__Now_0)
ORDER BY a
.Priority
DESC, a
.TryCount
, a
.NextTryTime
LIMIT @__p_1
ERROR 2024-05-24 22:33:40,263 [14 ] Microsoft.EntityFrameworkCore.Query - An exception occurred while iterating over the results of a query for context type 'LSSPortal.EntityFrameworkCore.LSSPortalDbContext'.
System.InvalidOperationException: This MySqlConnection is already in use. See https://fl.vu/mysql-conn-reuse
at MySqlConnector.Core.ServerSession.StartQuerying(ICancellableCommand command) in //src/MySqlConnector/Core/ServerSession.cs:line 288
at MySqlConnector.Core.CommandExecutor.ExecuteReaderAsync(CommandListPosition commandListPosition, ICommandPayloadCreator payloadCreator, CommandBehavior behavior, Activity activity, IOBehavior ioBehavior, CancellationToken cancellationToken)
at MySqlConnector.MySqlCommand.ExecuteReaderAsync(CommandBehavior behavior, IOBehavior ioBehavior, CancellationToken cancellationToken) in //src/MySqlConnector/MySqlCommand.cs:line 357
at MySqlConnector.MySqlCommand.ExecuteDbDataReader(CommandBehavior behavior) in /_/src/MySqlConnector/MySqlCommand.cs:line 290
at Microsoft.EntityFrameworkCore.Storage.RelationalCommand.ExecuteReader(RelationalCommandParameterObject parameterObject)
at Microsoft.EntityFrameworkCore.Query.Internal.SingleQueryingEnumerable1.Enumerator.InitializeReader(Enumerator enumerator) at Pomelo.EntityFrameworkCore.MySql.Storage.Internal.MySqlExecutionStrategy.Execute[TState,TResult](TState state, Func
3 operation, Func3 verifySucceeded) at Microsoft.EntityFrameworkCore.Query.Internal.SingleQueryingEnumerable
1.Enumerator.MoveNext()
Note, these repeat over a few minutes and then exhaust the connection pool, rendering the backend non-functional. This appears to start with the Background job system.
We have not upgraded any MySql components and this is NOT an issue on version 13.1.1. This upgrade from 13.1.1 to 13.2.0 was quite easy relative to past upgrades and we've done many. Although we are using MySql (have been for years), this would likely happen with the SQL provider as well, although I have not tested that.
I'll continue to look in to this as time permits, but I thought it should be reported as this release is quite new.
Sam.
Thanks @ismcagdas, I just simply fixed inline.
Not sure if anyone is aware, but the 12.0.1 project template fro the backend, downloaded from the ASPNETZERO portal does not have the .NET framework version update to net7.0.
It is still set to net6.0.
@ismcagdas, good stuff, cheers!
Greetings;
Judging from the commit here -> https://github.com/aspnetboilerplate/aspnetboilerplate/blob/dev/src/Abp.AspNetCore/AspNetCore/Mvc/Auditing/HttpContextClientInfoProvider.cs I see that you were already aware that GetComputerName() is currently throwing an exception because of a null Address being passed to Dns.GetHostEntry().
For now, I've patched the code for myself. Any word on when the official NuGet will be updated?
Cheers, Sam.
Hi @mmukkara, you've closed the reader on benefitOption.BenefitOptionPlans by using ToList(), however it looks to me like the reader on benefitOption may still be open on the same command once you reach the foreach loop.
This may be causing the problem, even though you're iterating through BenefitOptionOutputDto.BenefitOptionPlans.
Thanks for the suggestions @ismcagdas. Although we have everything working, I'll have a look at https://valor-software.com/ngx-bootstrap/#/accordion
Hi @mdframe, we use the tables rowexpansion feature on the frontend. There are a couple of tricky parts on the angular side. Below is a sample client-side abridged code with the key parts:
<p-table #dataTable
(onLazyLoad)="getSupplementalMaintenanceList($event)"
[value]="primengTableHelper.records"
dataKey="supplementalMaintenanceList.id"
rows="{{primengTableHelper.defaultRecordsCountPerPage}}"
[paginator]="false"
[lazy]="true"
[scrollable]="true"
ScrollWidth="100%"
[responsive]="primengTableHelper.isResponsive"
[resizableColumns]="primengTableHelper.resizableColumns">
.
.
.
<ng-template pTemplate="body" let-record="$implicit" let-rowData let-expanded="expanded">
<tr>
<td style="width: 3em">
<div>
<a href="#" [pRowToggler]="rowData">
<i [ngClass]="expanded ? 'pi pi-chevron-down' : 'pi pi-chevron-right'"></i>
</a>
</div>
</td>
.
.
.
<ng-template pTemplate="rowexpansion" let-record let-rowData>
<div class="primeng-datatable-container">
<td style="width: 3em"></td>
<td colspan="6">
<span>
<supplementalMaintenanceListDetail></supplementalMaintenanceListDetail>
</span>
</td>
</div>
</ng-template>
</p-table>
And the .ts file for the parent will have the child defined as a component:
@ViewChild('supplementalMaintenanceListDetail') supplementalMaintenanceListDetail: SupplementalMaintenanceListDetailComponent;
The important parts are the dataKey="supplementalMaintenanceList.id" and the <ng-template pTemplate="rowexpansion" let-record let-rowData>. The dataKey will get passed to the child component when you expand the row.
Notice the <supplementalMaintenanceListDetail></supplementalMaintenanceListDetail>? That is the child table bundled as an angular component. It receives the parent id.
That's about all you have to do on the client side - fairly basic.
As far as the server side, you don't need to do anything special are far as the basic CRUD operations are concerned. The parent will use it's service, while the child will use it's own. The child will of course need to have the parent ID filled in on it's entity member in order to perform the CRUD operations.
Hope that helps. Sam.