Hi, I have been using the CXF WS-RM component for a while. And I can say, I am enjoying it. Right now, among others, I am experimenting with some ideas to get more control over its behavior and more robustness in certain situation. I would like to share these ideas. In particular, I am describing the three related issues whose possible solution may affect the current RMStore API and wanted to ask your opinion before CXF 2.4.0 comes out.
1. Retry Behavior at Source Sequence Currently, there is no maximum retry count and a retry can run forever if the message is not acknowledged. I would like to introduce an optional parameter to configure the maximum retry count. If the retry count reaches this limit, the status of the message can be set to undelivered or failed. The failed message can be removed from the retransmission queue and may only be retried after a manual intervention. For this change, it is necessary to introduce this property itself and this is simple. In addition, it is to decide whether to store the status information of the message in the storage. In this case, the retry count information becomes persistent. I think we can omit storing this count information per message as it incurs increased access to the storage. However, if all the unacknowledged messages in a sequence are set failed, the sequence should be marked as failed in the storage so that they can be excluded from being restarted at the next start up. 2. SourceSequence's Expire handling This field is stored in the source sequence but it does not seem to be used during the restart of the endpoints to decide which messages must be placed in the retransmission queue. This value along with the sequence status value described in 1 should be used to control the retry behavior of the old unacknowledged messages. 3. Sequence caching in memory Currently, the source and destination sequences are loaded into memory from the storage at the startup of the endpoints. This may consume an increased amount of unnecessary memory if many of the sequences are not active while not yet expired. This situation may happen when several conditions are satisfied, for example, when the sequence termination policy configured to limit the number of unacknowledged messages per sequence, occurring frequent transmission errors, and messages generated at a high rate. For the source sequence, using the change suggested for point 1 and 2, we can decrease the number of active source sequences. In this case, only those active source sequences can be read from the storage and their associated unacknowledged messages can be placed in the retransmission queue. For the destination sequence, the situation is different (as there is no retry) and some no-expiration-set sequences may remain alive although they may be used only infrequently or perhaps not at all. The good news, however, is that we need the sequence only when a message with that particular sequence ID arrives. In this case, some fixed number of destination sequences can be held in memory and a destination sequence can be looked up in the storage upon this cache miss. To achieve this on-demand loading of the destination sequences, I added in RMStore a new method to retrieve a single destination sequence instance given its sequence ID. In addition, considering points 1 and 2, I would like to have sequence retrieval methods to retrieve the expired or failed sequences. Here, I am not sure how I should name them (or rather use an additional filter parameter to the getSourceSequences method). In either case, this affects the RMStore interface unless we opt for introducing another API, I wanted to get your suggestion before 2.4 comes out. I would greatly appreciate your suggestion. Best regards, Aki
