[
https://issues.apache.org/jira/browse/BOOKKEEPER-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13568271#comment-13568271
]
Mridul Muralidharan commented on BOOKKEEPER-312:
------------------------------------------------
I am not sure which is the actual subset which is generated in the report
above, but I ran findbugs explicitly and these are the results I got, and
explainations of the same :
a) Correctness (5).
a.1) Null pointer dereference.
This is mandated by the jms spec weirdly.
Each of the 5 cases have an explicit comment above them which states that an
NPE is to be thrown as part of the operation.
b) Bad practise (63)
b.1) Confusing method names (30)
Javacc generated methods.
b.2) Incorrect definition of Serializable class (2)
Protobuf generated code.
b.3) Method with Boolean return type returns explicit null (31)
This is explicitly used in our code - we make use of a Boolean return value;
and it is interpreted as true, false or null (when there are parse errors, etc).
Non standard, but explicitly written and expected use : note, this is only
within the selector evaluation and highly specific to the function evaluations
within selector : DOES NOT leak to outside the selector package.
c) Internationalization (4)
javacc generated code.
d) Malicious code vulnerability (5)
The subtree of bugs refers to javacc generated code.
e) Performance (2)
One of them is from generated code, the other is unavoidable.
f) Dodgy code (22)
f.1) Dead local store (1)
This is being reported since javac is inlining a final variable : within the
code, the variable is used (and so not dead store) - just than findbugs does
not 'see' it since it operated on bytecode.
f.2) Null pointer dereference (17)
These are all from error reporting code. Example:
if (null == topic) throw new InvalidDestinationException("Illegal destination "
+ topic);
f.3) switch fall through (1)
javacc generated code
f.4) Unread field (2)
javacc generated code.
f.5) useless control flow.
protobuf generated code.
I had done this analysis a while back : but had lost the responses (might be in
one of the bugs/review comments ? not sure).
Since our code has moved a bit, it is good to verify that no new bugs were
introduced anyway !
If there are any other bugs/warnings reported by findbugs which does not match
this list (or generated by some other command - I just ran with default mvn
findbugs:findbugs), please do let me know !
> 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: BOOKKEEPER-312.diff, hedwig-client-jms.patch.10
>
>
> 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
