[jira] [Commented] (BOOKKEEPER-312) Implementation of JMS provider

["Sijie Guo (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/BOOKKEEPER-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13528587#comment-13528587 ] 

Sijie Guo commented on BOOKKEEPER-312:
--------------------------------------

marked it for 4.3.0 since its parent jira BOOKKEEPER-308 is marked for 4.3.0.
                
> 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
>
>
> 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