JPA Retrieving Outbound Gateway produced no reply when zero entities in database [INT-3333]

[spring-operator]

Médéric Martin opened INT-3333 and commented

In JpaOutboundGateway.java, an empty result is considered like no channel-reply :

if (OutboundGatewayType.RETRIEVING.equals(this.gatewayType)) {
result = this.jpaExecutor.poll(requestMessage);
}
if (result == null || !producesReply) {
return null;
}

A select request with an empty result is maybe a value expected in the channel-reply.

---

Affects: 4.0 M3

Reference URL: http://forum.spring.io/forum/spring-projects/integration/124469-jpa-retrieving-outbound-gateway-produced-no-reply-when-zero-entities-in-database

Referenced from: pull request #3907

2 votes, 5 watchers

[spring-operator]

Artem Bilan commented

Actually the empty list doesn't have value as well as a null payload does.

If you configure requires-reply="false" such results will be dropped and your downstream flow won't do anything.
It is standard and typical behavior for gateways with null result to send.

Don't forget that you are in the loosely-coupled environmet and your JPA RETRIEVING gateway doesn't know anything about other components in your application.
To make your business logic worked you should provide some tricks and hooks to your message flow.
E.g.:

<int:chain>
     <int-jpa:retrieving-outbound-gateway jpa-query="count(e) from MyEntity e" expect-single-result="true"/>
     <int:filter expression="payload > 0" discard-channel="emptyListChannel"/>
     <int-jpa:retrieving-outbound-gateway jpa-query="from MyEntity"/>
</int:chain>

This trick uses a <int:filter> to ckeck the value of previous count query for the same entity and select criteria and if it is 0, the message will be discarded to separate flow, where you can make the desired logic for empty result. Otherwise it continues to the real query for the list of entities and here you can make another business logic on result from chain's outbound-channel.

The same behaviuor we have with <jdbc:outbound-gateway> and <int-jdbc:stored-proc-outbound-gateway>. I'd say it is standard for all outbound-gateways.

So, let us know and we will mark it as 'Won't fix'

[spring-operator]

Médéric Martin commented

I understand what you said.
Retrieving no reply from a request select is recurring and is not coupled with Business logic. Considered "null" and an "empty result" as synonymous in case of JPA is questionable in my mind... And this will complicate all retrieving code ...

[spring-operator]

Artem Bilan commented

No, I didn't mean JPA. That position is for payload object in EIP concepts. The empty list in general is as bad for messaging as the null payload: the Splitter pattern.
If youo worry about complexity of your code, you always can use entityManager directly:

<int:service-activator expression="@entityManager.createQuery('from MyEntity').resultList"/>

[spring-operator]

Médéric Martin commented

Thanks for your time and your reactivity.

[spring-operator]

Artem Bilan commented

OK, Martin.

We hope you have a workaround for your case, but we keep this issue open for future requests and have an idea to introduce ignoreEmptyResult for similar cases for all gateways which may produce an empty List (JPA, JDBC etc.)

[spring-operator]

Médéric Martin commented

Yes thanks, we'll use a filter expression like you said until an ignoreEmptyResult exists ;)

[spring-operator]

swati satpute commented

Hi is this new ignoreEmptyResult feature available in latest release. i havent seen yet.

[spring-operator]

Artem Bilan commented

Not, yet.

Since JIRA is in the OPEN state, that means that the fix hasn't been done yet.

Thank you for "heads up" anyway.
And with such a "+1" will consider to implement it in the current 4.3 version.

Feel free to consider that Contribution as well!

[spring-operator]

swati satpute commented

Hi Artem,
I will introduce this fix into springintegration stream.
thanks for information on contribution.

[spring-operator]

Artem Bilan commented

Hello swati satpute!

Yes, I have your CLA on the table and thank you for letting to know that are still interested in the contribution.

Not sure, though, what you mean with the " fix into springintegration stream", as we are talking here about those components which can produce the reply as an empty list.

My idea was about the boolean ignoreEmptyResult into the AbstractReplyProducingMessageHandler alongside with the existing requiresReply.
And check the value in those implementors who may produce an empty list result.

Let me know if you need anything else to go ahead.

[spring-operator]

Artem Bilan commented

One more request on the matter: https://stackoverflow.com/questions/63379438/spring-integration-jpa-gateway-act-on-empty-result

[spring-operator]

Chris commented

We would appreciate this feature in our Spring Integration projects as well (y) !

[spring-operator]

Artem Bilan commented

Another "empty list" concern: https://stackoverflow.com/questions/73985642/spring-integration-jdbc-outbound-gateway-advice-for-handling-empty-result-sets.

I think since we have now AbstractMessageSplitter.discardChannel:

/**
 * Specify a channel where rejected Messages should be sent. If the discard
 * channel is null (the default), rejected Messages will be dropped.
 * A "Rejected Message" means that split function has returned an empty result (but not null):
 * no items to iterate for sending.
 * @param discardChannel The discard channel.
 * @since 5.2
 */
public void setDiscardChannel(MessageChannel discardChannel) {

It is fully valid to return empty iterables from components like this JPA Outbound Gateway.

I'll probably look into this today to propose some fix which may be treated as a breaking change for the current behavior, but it is still valid to introduce it in the current 6.0 major release.

[spring-operator]

Artem Bilan commented

Closed in favor of: #3907