WIP: [#1715] Jakarta Messaging 3.1 Shared Topic Support#2229
Draft
mattrpav wants to merge 4 commits into
Draft
Conversation
… advisory handling - serviceRemoteConsumerAdvisory() used an exact class check (data.getClass() == ConsumerInfo.class) which silently drops any ConsumerInfo subclass. Change to instanceof so subclasses are accepted by the advisory processing path. - DemandForwardingBridgeSupport for subscriptions with same name
When multiple consumers share a durable subscription and ack messages out of order, a blind overwrite of LastAck can move the ack position backward. On restart, the recovery cursor replays already-acked messages. Check the update with a forward-only check so LastAck only advances. Test demonstrates recovery cost when lastAckedSequence regresses due to blind overwrite during out-of-order acks. Two durable subscriptions share a topic; the fast subscription acks 499 of 500 messages in reverse order. Without the forward-only guard in MessageDatabase, lastAck regresses to sequence 1 and recovery scans all 499 entries.
…upport Introduces protocol version 13, extending v12 with the fields needed to carry JMS 3.1 shared subscription state across the wire and through KahaDB recovery: ConsumerInfo + shared, durable (via SharedConsumerInfo) SubscriptionInfo + shared (via SharedSubscriptionInfo) ExceptionResponse + errorCode Message + deliveryTime The v13 MarshallerFactory clones the v12 marshaller map and replaces only the ten marshallers affected. OpenWireFormat already resolves the factory reflectively by version, so no version switch is required. Because OpenWire marshals a throwable as type and message only, the JMSException errorCode does not survive the round trip. The separate errorCode field carries it, and ExceptionResponse.getException() reapplies it to the reconstructed exception. Nothing here activates at the default store version: v13 is selected only when a broker sets storeOpenWireVersion to 13. Tests assert that gate directly -- deliveryTime, errorCode and the shared flags all fail to cross a v12 wire, and v12 continues to yield plain ConsumerInfo and SubscriptionInfo instances. ActiveMQErrorCode and SharedSubscriptionKey have no callers yet; they are scaffolding for the shared subscription broker work that follows. Adds 89 tests: round trips for all ten replaced marshallers in tight and loose encodings, the errorCode reconstruction branches, and null-clientId handling in SharedSubscriptionKey.
- SharedTopicBrokerService (server-side entry point) - SharedTopicConnectionFactory (client-side entry point)
mattrpav
changed the title
4 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Jakarta Messaging specification calls out the Shared Topics are essentially a separate region from non-Shared topics. This works in our favor, as we can leverage *Region separation and implement this along side current topic support and not have to overhaul existing topic and subscription behavior.
Note: The SharedTopicBrokerService and SharedTopicConnectionFactory are intended to be transitional classes. This approach would allow us to release the feature as experimental/preview (if we chose) and keep the code path out of the stable current broker code. Once the implementation feels right, the last step would be to merge SharedTopicBrokerService -> BrokerService, etc.
TCK status run against this tree:
91% pass: 899 tests (824 passed, 75 failed, 0 hung)