Introduction
Contains the basic (hedwig agnostic) aspects of the provider implementation
This package enforces (to a large part) the constraints expected by JMS api and maintains state and
manages the lifecycle of rest of the provider system.
It depends only on message package.
It is decoupled from actual nitty-gritties of the hedwig specific aspects via a Facade - which
encapsulates all functionalities required off hedwig.
It is envisioned that we will have additional implementations for the facade as time goes by :
- Test mockup facade to test provider aspects decoupled from hedwig
- Facade's to experiment with add and/or modify functionality exposed to provider (support for
Queue for example without modifying existing code).
- Facade's to experiment with add and/or modify functionality to hedwig itself.
- This space for rent :-)
Missing functionality
Various aspects of JMS are currently unsupported - the detailed list is long, but the main caveats
with the provider currently are :
- No support for Queues : Hedwig currently does not have a notion of JMS queue's for us to leverage.
- 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.
- Note that everything is durable in hedwig - so we do not support NON_PERSISTENT delivery mode.
- 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.
- 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.
- 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.
- Hedwig only supports marking all messages until seq-id as received : while JMS indicates abilit
y to acknowledge individual messages.
This distinction is currently unsupported. Investigating if we can do something about it.
- 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 honour this for undelivered messages from server - but if stop is called while there are
pending messages yet to be delivered to a listner (or buffered in subscriber for receive),
then they will be delivered irrespective of stop().
Hopefully I am not missing any of the big points ...