Hello.
I have just updated my code base to use couchbase as distributed cache and lock provider.
Everything goes fine.
During my tests, I have noticed a behavior about distributed locks for BackgroundJobWorker.
The class implementation uses constant "AbpBackgroundJobWorker" string as lock key.
I have maybe 50 microservices and each microservice has their own database and each database has own "AbpBackgroundJobs" table.
Each microservice runs this BackgroundJobWorker periodically (a bit often) and on every call the lock is activated using same lock key ("AbpBackgroundJobWorker"). I use Volo.Abp.BackgroundJobs.EntityFrameworkCore library to store job queue on database.
Since microservices has their own separate databases, blocking microservices with same lock-key seems to me a little bit inefficient. This blockage goes up depending on the number of microservices.
I suggest appending the database name as a suffix to the lock key or add an option to set this key separately for each microservice so that microservices do not block each other.
I would like to alter this implementation according to my suggestion, but I like to ensure that I do not miss any logic that made you use same lock-key.
Do you have any comment about this issue?
Thanks. Murat
I also want to add this line; if I knew that polymorhism is blocked by Abp’s design choice, I would never, ever start using abp. I wish I knew at the beginning. I was actively advocating the framework to my network for their sake of good, now I understand that I mistakenly lead them to into a nightmare. Sorry for them. My bad.
Hi again. I don’t prefer to implement two seperate implementations and controllers. This really makes no sense. You take serious amount of power off from our hands with this limitation. What is left in the language if you exclude the inheritence and polimorphism. Too disappointed.
Thanks anyway
Hello
I am experiencing a strange behaviour when using abp generate-proxy cli command.
Below there is a few lines of codes;
//towns service contract public interface ITownsAppService : ICrudAppService<TownDto, Guid, GetTownsInput, TownCreateDto, TownUpdateDto>, ILookupService { }
//my lookup service interface public interface ILookupService { Task<PagedResultDto<LookupDto<Guid>>> GetListAsLookupAsync(LookupRequestDto input); }
//towns service implementation public class TownsAppService : CrudAppService<Town, TownDto, Guid, GetTownsInput, TownCreateDto, TownUpdateDto>, ITownsAppService {...}
//towns service controller [RemoteService(Name = MasterServiceRemoteServiceConsts.RemoteServiceName)] [Area("master-service")] [ControllerName("Town API")] [ApiVersion("1.0")] [Route("api/master-service/towns")] public class TownController : AbpController, ITownsAppService {...}
when i run the following command; abp generate-proxy -t csharp -u https://localhost:xxx/ -m master-service --without-contracts
Proxy codes are generated for ILookupsService not for ITownsAppService, as you can see my controller and my service implemtation inherits ITownsAppService directly and ILookupService indirectly.
[Dependency(ReplaceServices = true)] [ExposeServices(typeof(ILookupService), typeof(TownClientProxy))] public partial class TownClientProxy : ClientProxyBase<ILookupService>, ILookupService
So when i try to access ITownsAppService, i got interface not implemented error as you can figure out.
If I rename ILookupService to ILookupAdaptor, proxy generation skips to generate proxy files for towns. No output created.
Is there a way to fix this issue?
Murat Gürer
Hi. Thanks for your support. 👍
I tested code and it does its job as expected.
I have further questions about the topic;
1 - I am curious about the unexpected side effects of this workaround. Is there any?
2 - Should I suspect about other entities for this issue?
3 - Is this buggy behavior efcore-wise problem or is it specific to OpenIddictApplication entity?
Thanks
Is that postgres db that you select as dbms? I suspect about some wierd behaviour on timestamped columns.
I can provide a sample proj that I genererated recently.
Nope. I wont share any codes, logs with you. Check your frameworks codes? If you dont able to reproduce that behavior, we will consider what we can do then.
I dont get it. Are you serious?
I already saw the concurrency exception log and came here to ask what is going on? You want me add logs to the app.
The behaviour is not related to my very own codes. Even a new blank application behaves as I mentioned before. If you try it for yourself, you will see the record in the OpenIddictApplication table gets updated on each call to connect/token endpoint with client_credentials granttype.