You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Jacques Le Roux <ja...@les7arts.com> on 2025/11/26 17:51:55 UTC
Re: Wrong delegator used for events ?
Hi Florian,
What is the situation now?
TIA
Jacques
Le 28/10/2025 à 11:33, Florian Motteau a écrit :
> Hi all,
>
> I've been investigating a strange issue when running tests with OFBiz lately.
>
> I'm running tests using Derby, through such commands : ./gradlew 'ofbiz -t component=salesBU -t case=generateRecurrenceDate' --debug-jvm
>
> So I'm using the "test" delegator, which uses the embedded Derby database.
>
> In the logs, I noticed that OFBiz tries to connect to a postgresql datasource, which is not available. I found that it tries to connect to the
> "default" delegator (group-name=org.apache.ofbiz). This connection fails while trying to delete ServiceSemaphore :
>
> 2025-10-28 10:27:50,542 |OFBiz-batch-4 |GenericDelegator |E| Failure in removeByCondition operation for entity [ServiceSemaphore]:
> org.apache.ofbiz.entity.GenericDataSourceException: Generic Entity Exception occurred in deleteByCondition (Unable to establish a connection with
> the database. (Unable to acquire a new connection from the pool)). Rolling back transaction.
> org.apache.ofbiz.entity.GenericDataSourceException: Generic Entity Exception occurred in deleteByCondition (Unable to establish a connection with
> the database. (Unable to acquire a new connection from the pool))
>
> After some investigations, I found that, as far as I understand, OFBiz will force the use the "default" delegator whenever the
> EntityExpr::makeWhereString is used. This method calls EntityExpr::checkRhsType, with "null" a second parameter, which causes "checkRhsType" to
> fallback to the "default" delegator.
>
> https://github.com/apache/ofbiz-framework/blob/82ed9a8d4dbf3259cb3d8bc219d36206d160b339/framework/entity/src/main/java/org/apache/ofbiz/entity/condition/EntityExpr.java#L199
>
>
> At some point I thought that it was be related to the events, but I'm not sure anymore :).
>
> My goal was to find out why this connection was attempted during tests (and clean my logs files), but I feel that it may be a bigger issue.
>
> Is this behavior correct/intented ? Why would we choose a different delegator in a method which role is to construct a SQL request ?
>
> Thank you in advance for any feedback/guidance
>
> Florian
>
Re: Wrong delegator used for events ?
Posted by Jacques Le Roux <ja...@les7arts.com>.
Hi Florian,
Yes a Jira seems useful to me
TIA
Jacques
Le 27/11/2025 à 09:01, Florian Motteau via dev a écrit :
> Hi Jacques, I just introduced a small hack that skips the ServiceSemaphore initial removal when we are in the CI, just to clean the logs. But I did
> not go any further in resolving the underlying situation :(...It is pretty low level, I might have to ask for help if I want to get to the bottom of
> this.
>
> Maybe I should create an issue so that it's not just on the dev ML ?
>
> Le 26/11/2025 à 18:51, Jacques Le Roux a écrit :
>> Hi Florian,
>>
>> What is the situation now?
>>
>> TIA
>>
>> Jacques
>>
>>
>> Le 28/10/2025 à 11:33, Florian Motteau a écrit :
>>> Hi all,
>>>
>>> I've been investigating a strange issue when running tests with OFBiz lately.
>>>
>>> I'm running tests using Derby, through such commands : ./gradlew 'ofbiz -t component=salesBU -t case=generateRecurrenceDate' --debug-jvm
>>>
>>> So I'm using the "test" delegator, which uses the embedded Derby database.
>>>
>>> In the logs, I noticed that OFBiz tries to connect to a postgresql datasource, which is not available. I found that it tries to connect to the
>>> "default" delegator (group-name=org.apache.ofbiz). This connection fails while trying to delete ServiceSemaphore :
>>>
>>> 2025-10-28 10:27:50,542 |OFBiz-batch-4 |GenericDelegator |E| Failure in removeByCondition operation for entity [ServiceSemaphore]:
>>> org.apache.ofbiz.entity.GenericDataSourceException: Generic Entity Exception occurred in deleteByCondition (Unable to establish a connection with
>>> the database. (Unable to acquire a new connection from the pool)). Rolling back transaction.
>>> org.apache.ofbiz.entity.GenericDataSourceException: Generic Entity Exception occurred in deleteByCondition (Unable to establish a connection with
>>> the database. (Unable to acquire a new connection from the pool))
>>>
>>> After some investigations, I found that, as far as I understand, OFBiz will force the use the "default" delegator whenever the
>>> EntityExpr::makeWhereString is used. This method calls EntityExpr::checkRhsType, with "null" a second parameter, which causes "checkRhsType" to
>>> fallback to the "default" delegator.
>>>
>>> https://github.com/apache/ofbiz-framework/blob/82ed9a8d4dbf3259cb3d8bc219d36206d160b339/framework/entity/src/main/java/org/apache/ofbiz/entity/condition/EntityExpr.java#L199
>>>
>>>
>>> At some point I thought that it was be related to the events, but I'm not sure anymore :).
>>>
>>> My goal was to find out why this connection was attempted during tests (and clean my logs files), but I feel that it may be a bigger issue.
>>>
>>> Is this behavior correct/intented ? Why would we choose a different delegator in a method which role is to construct a SQL request ?
>>>
>>> Thank you in advance for any feedback/guidance
>>>
>>> Florian
>>>
Re: Wrong delegator used for events ?
Posted by Florian Motteau via dev <de...@ofbiz.apache.org>.
Hi Jacques, I just introduced a small hack that skips the
ServiceSemaphore initial removal when we are in the CI, just to clean
the logs. But I did not go any further in resolving the underlying
situation :(...It is pretty low level, I might have to ask for help if I
want to get to the bottom of this.
Maybe I should create an issue so that it's not just on the dev ML ?
Le 26/11/2025 à 18:51, Jacques Le Roux a écrit :
> Hi Florian,
>
> What is the situation now?
>
> TIA
>
> Jacques
>
>
> Le 28/10/2025 à 11:33, Florian Motteau a écrit :
>> Hi all,
>>
>> I've been investigating a strange issue when running tests with OFBiz
>> lately.
>>
>> I'm running tests using Derby, through such commands : ./gradlew
>> 'ofbiz -t component=salesBU -t case=generateRecurrenceDate' --debug-jvm
>>
>> So I'm using the "test" delegator, which uses the embedded Derby
>> database.
>>
>> In the logs, I noticed that OFBiz tries to connect to a postgresql
>> datasource, which is not available. I found that it tries to connect
>> to the "default" delegator (group-name=org.apache.ofbiz). This
>> connection fails while trying to delete ServiceSemaphore :
>>
>> 2025-10-28 10:27:50,542 |OFBiz-batch-4 |GenericDelegator
>> |E| Failure in removeByCondition operation for entity
>> [ServiceSemaphore]:
>> org.apache.ofbiz.entity.GenericDataSourceException: Generic Entity
>> Exception occurred in deleteByCondition (Unable to establish a
>> connection with the database. (Unable to acquire a new connection
>> from the pool)). Rolling back transaction.
>> org.apache.ofbiz.entity.GenericDataSourceException: Generic Entity
>> Exception occurred in deleteByCondition (Unable to establish a
>> connection with the database. (Unable to acquire a new connection
>> from the pool))
>>
>> After some investigations, I found that, as far as I understand,
>> OFBiz will force the use the "default" delegator whenever the
>> EntityExpr::makeWhereString is used. This method calls
>> EntityExpr::checkRhsType, with "null" a second parameter, which
>> causes "checkRhsType" to fallback to the "default" delegator.
>>
>> https://github.com/apache/ofbiz-framework/blob/82ed9a8d4dbf3259cb3d8bc219d36206d160b339/framework/entity/src/main/java/org/apache/ofbiz/entity/condition/EntityExpr.java#L199
>>
>>
>> At some point I thought that it was be related to the events, but I'm
>> not sure anymore :).
>>
>> My goal was to find out why this connection was attempted during
>> tests (and clean my logs files), but I feel that it may be a bigger
>> issue.
>>
>> Is this behavior correct/intented ? Why would we choose a different
>> delegator in a method which role is to construct a SQL request ?
>>
>> Thank you in advance for any feedback/guidance
>>
>> Florian
>>