INT-2426: Add Idempotent Receiver EIP pattern

[artembilan]

JIRA: https://jira.spring.io/browse/INT-2426

DO NOT MERGE YET

It's just an initial commit, like a PoC to review before further work.

[artembilan]

Pushed the fix according to Travis complaint

[garyrussell]

I understand what you are doing here but when skipDuplicate is false this is really a transformer not a filter.

It makes me feel a bit queasy.

Maybe we can work around it with the namespace ?

<int:idempotent-consumer filter="true|false" />

rather than <idempotent-filter/> as mentioned in the JIRA.

[artembilan]

Thanks for feedback. You confirmed my concerns.
Let me rework it to more appropriate solution.

[garyrussell]

Actually, do we really need to use an MGS at all? We don't really need to store the whole message, just the key.

[artembilan]

Yes, I thought about that too. But it might be really usefull for end application to analize messages in store for cases like Idempotent Receiver.

I'm working now under solution to retrieve message from group by filter...

[garyrussell]

Yes, but remember the MGS has 3 tables; we really only need one table for this use case.

[garyrussell]

Maybe a MetadataStore would be best (and provide a JDBC implementation). I really don't see much benefit in storing the entire message "just in case" someone wants to examine them.

[artembilan]

OK. Let's implement it just with MetadataStore!
MGS option we can add on demand.

[artembilan]

Pushed

[garyrussell]

Should be a ConcurrentMetadataStore to support concurrency and clustered environments. Use putIfAbsent() for atomicity.

[artembilan]

Good.
Let me know if everything other is Ok and I'll add docs tomorrow

[garyrussell]

All ok; except my previous comment about it not really being a filter when skipDuplicate is false.

[artembilan]

except my previous comment about it not really being a filter when skipDuplicate is false.

Yes, as you see I renamed that option to the filter = true/false.
And right, in the Namespace it will be <idempotent-filter>.

[artembilan]

<idempotent-receiver>.

[garyrussell]

Perhaps it should be an advice rather than a discrete component.

Design a receiver to be an Idempotent Receiver--one that can safely receive the same message multiple times.

<request-handler-advice-chain>
    <idempotent-receiver filter="true/false" discard-channel="foo" />
</requestHandler-advice-chain>

Since we're adding behavior to an endpoint rather than defining a receiver as a component.

[artembilan]

Hey! That's cool!
Having it is Advice we can come back to the selector as an alternative to the indempotent-key.
It allows end-user to have any custom filtering strategy and get gain from DUPLICATE header.

Thanks. Will do tomorrow!

[artembilan]

Pushed. See commit comments.
@snicoll, take a look, please, to the IdempotentReceiverAutoProxyCreator.
Is that a correct implementation to apply Advices beans to other beans?

Thank you help anyway!

[artembilan]

The annotation support will be soon

[artembilan]

Pushed @IdempotentReceiver support.
There is still needed somehow to overcome this case:

@MessageEndpoint
class MyService {

    @ServiceActivator(inputChannel="testChannel")
    public Object service(Object payload) {
         ....
   }

}

[garyrussell]

interceptor

[garyrussell]

Also document that, if not set, the message will proceed with the duplicate message header.

[artembilan]

But I did in the class level JavaDocs

[artembilan]

However I see your point: copy/paste artefact 😄

[artembilan]

Pushed.
Since we can support several <idempotent-receiver> for one endpoint, I've changed @IdempotentReceiver to support several interceptors as well.

[artembilan]

Pushed Docs

[garyrussell]

Ready to merge after you review my doc polishing: garyrussell@6bff6b9

[garyrussell]

More polish: garyrussell@48d4fe5

[garyrussell]

Merged as ff2b15e