INT-3338: MongoMS: add priority and sequence

[artembilan]

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

[artembilan]

Let me know and I'll go ahead with docs.
From other side should we add the same ability for the MongoDbMessageStore?
BTW, the last one needs more refactoring for its vulnerabilities as it doesn't have indexes and updates entire group instead of only one last message.

[garyrussell]

Looks ok to me but I don't know mongo 😄

Regarding MDMS, maybe just add the field; that way we can always add the sort in a point release if someone asks for it because then it wouldn't be a breaking change.

[artembilan]

Pushed

[garyrussell]

I see this is original code, but why are these DESCENDING (newest first).

[artembilan]

This is my trick: keep the latest group info and do update only for one document in collection.
And if we don't specify any sort the index is used by default and that one, which includes fields in query. In most cases we use groupIdQuery and it specifies GROUP_ID field. As far as we have only one index which starts with it, that one is selected to get a document for select and update - performance, though!
And that's why I added an important para in docs: to avoid priority/non-priority indexes ambiguity.
If you wish I can add comments here.

[garyrussell]

I see, yes - I hadn't read the documentation 😄

Yes, comments will help (needed) but perhaps we can also detect the improper use and log a WARN? Or, even throw an exception - this message store cannot be used as a MGS and CMS at the same time - select a different collection name for each usage.

...

Maybe could add another method to `PriorityCapableChannelMessageStore

    boolean isGroupStoreOperationsPermitted();

and then, when using it as an MGS from correlators etc...

if (store instance of PriorityCapableChannelMessageStore 
        && ((PCMS) store).isPriorityEnabled()) {
    Assert.isTrue(((PCMS) store).isGroupStoreOperationsPermitted());
}

...

Or, maybe best, refactor them so that the CMS is a super class and the full MGS is a subclass. That way, the mistake can't happen.

RedisChannelMessageStore
|-> RedisMessageGroupStore

[artembilan]

Pushed the solution, when we don't need to worry about MS type and auto-indexing. To use explicit
sort (of course based on index) fix the problem with the same collection, but different type of MSs

[garyrussell]

I don't see how this "only update the last document" trick can work with a priority queue because now the "last" record might get released before other messages and the metadata will be wrong.

Further, surely we really don't need to update this metadata (on the "last" record) when the store is only being used to back a QueueChannel (priority or not), so why take the overhead?

It seems to me that a separate CMS is really needed.

[artembilan]

Agreed.
Actually I see now that we can merge both MongoDB to one and fallback to internal MessageReadingMongoConverter, if MappingMongoConverter isn't provided and new useSerialization property is specified as false. Otherwise it needs enough work to support several MSs. According your comment it will be 4 classes.

[artembilan]

Pushed the new stuff - MongoDbChannelMessageStore

[garyrussell]

?? You decided not to promote this to BasicMessageGroupStore after all ?

[artembilan]

No-no. It will be here after rebase to my JDBC PR 😄

[artembilan]

Pushed
Ready for final review

[garyrussell]

programlisting within note doesn't render properly - I will move it out of note.

[artembilan]

Doh. Need to check docs before push anyway. Thanks

[garyrussell]

Merged