[
https://issues.apache.org/jira/browse/BOOKKEEPER-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13551830#comment-13551830
]
Mridul Muralidharan commented on BOOKKEEPER-312:
------------------------------------------------
$ git apply ~/Desktop/hedwig-client-jms.patch.9
/home/mridulm/Desktop/hedwig-client-jms.patch.9:8075: trailing whitespace.
/home/mridulm/Desktop/hedwig-client-jms.patch.9:8077: trailing whitespace.
/home/mridulm/Desktop/hedwig-client-jms.patch.9:8078: trailing whitespace.
/home/mridulm/Desktop/hedwig-client-jms.patch.9:8080: trailing whitespace.
/home/mridulm/Desktop/hedwig-client-jms.patch.9:8087: trailing whitespace.
warning: squelched 476 whitespace errors
warning: 481 lines add whitespace errors.
$ git status
# On branch trunk
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: pom.xml
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# hedwig-client-jms/
no changes added to commit (use "git add" and/or "git commit -a")
Which is the expected result of applying this patch.
> Implementation of JMS provider
> ------------------------------
>
> Key: BOOKKEEPER-312
> URL: https://issues.apache.org/jira/browse/BOOKKEEPER-312
> Project: Bookkeeper
> Issue Type: Sub-task
> Reporter: Mridul Muralidharan
> Assignee: Mridul Muralidharan
> Fix For: 4.3.0
>
> Attachments: hedwig-client-jms.patch, hedwig-client-jms.patch.1,
> hedwig-client-jms.patch.2, hedwig-client-jms.patch.3,
> hedwig-client-jms.patch.4, hedwig-client-jms.patch.5,
> hedwig-client-jms.patch.9, hedwig-client-jms.patch.9
>
>
> The JMS provider implementation conforming to the 1.1 spec.
> The limitations as of now are :
> 1) No support for Queue's : Hedwig currently does not have a notion of JMS
> queue's for us to leverage.
> 2) No support for noLocal : Hedwig DOES NOT conform to JMS model of
> connection -(n)-> session -(n)-> publisher/subscriber. Each session has a
> hedwig connection.
> Currently I am simulating noLocal, but this IS fragile and works for the
> duration of connection - ONLY until the message id is still in a LRUCache. As
> mentioned before, this is a kludge, and not a good solution.
> 3) Note that everything is durable in hedwig - so we do not support
> NON_PERSISTENT delivery mode.
> 4) Calling unsubscribe on a durable subscription will fail if it was NOT
> created in the current session.
> In hedwig, to unsubscribe, we need the subscription id and the topic ...
> To simulate unsubscribe(), we store the subscriberId to topicName mapping
> when a create* api is invoked. Hence, if create* was NOT called, then we have
> no way to infer which topic the subscription-id refers to from hedwig, and so
> cant unsubscribe.
> The workaround is - simply create a durable subsriber just as a workaround of
> this limitation - the topicName will be known to the user/client anyway.
> 5) Explicit session recovery is not supported.
> Reconnection of hedwig session (either explicitly or implicitly by underlying
> client implementation) will automatically trigger redelivery of
> un-acknowledged messages.
> 6) Because of the above, setting the JMSRedelivered flag is almost impossible
> in a consistent way.
> Currently, we simulate it for redelivery due to provider side events :
> rollback of txn, exception in message listener (primarily).
> At best we can simulate it with a kludge - at risk of potentially running out
> of resources ... this is being investigated : but unlikely to have a clean
> fix.
> 7) Hedwig only supports marking all messages until seq-id as received : while
> JMS indicates ability to acknowledge individual messages.
> This distinction is currently unsupported.
> 8) JMS spec requires
> "A connection's delivery of incoming messages can be temporarily stopped
> using its stop() method. It can be restarted using its start() method. When
> the connection is stopped, delivery to all the connection’s MessageConsumers
> is inhibited: synchronous receives block, and messages are not delivered to
> MessageListeners."
> We honor this for undelivered messages from server - but if stop is called
> while there are pending messages yet to be delivered to a listener (or
> buffered in subscriber for receive), then they will be delivered irrespective
> of stop().
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
