Hi,
        We were looking at alternate message persistence mechanisms that can 
co-exist in current ActiveMQ code base and we are thinking of a mechanism that 
is somewhat incompatible with the current MessageStore and PersistenceAdapter 
APIs. Unfortunately, the current ActiveMQ broker doesn't allow for such a 
change as the PersistenceAdapter and MessageStore interfaces are referenced 
directly by the RegionBroker and by both the Queue and Topic region 
implementations. Therefore, we are proposing a relatively small backwards 
compatible refactoring of the broker code that would eliminate all dependencies 
on the PersistenceAdapter and MessageStore interfaces from those classes that 
do not use them directly. This refactoring would also allow creation of a 
custom Destination implementation that may use an alternative persistence 
mechanism on a destination by destination basis (which is exactly what we need 
to do).
        The main idea behind the refactoring is to replace many references to 
PersistenceAdapter with a new interface: DestinationFactory:
        public abstract class DestinationFactory { 
        abstract public Destination createDestination(ConnectionContext 
context, ActiveMQDestination destination, DestinationStatistics 
destinationStatistics) throws Exception;
        abstract public Set getDestinations(); 
        abstract public SubscriptionInfo[] 
getAllDurableSubscriptions(ActiveMQTopic topic) throws IOException; 
        abstract public long getLastMessageBrokerSequenceId() throws 
IOException; 
        abstract public void setRegionBroker(RegionBroker regionBroker); 
        } 
        Note that DestinationFactory doesn't mandate any specific persistence 
mechanism. The classes that would reference it instead of PersistenceAdapter 
are: RegionBroker, AbstractRegion, QueueRegion, and TopicRegion. Also, the 
AbstractRegion.createDestination method would be changed from abstract to an 
implementation that uses DestinationFactory to create a destination.
        BrokerService could be changed to use DestinationFactory if one is 
provided. If none is provided, it will create a DestinationFactory 
implementation that instantiates Queue and Topic using PersistenceAdapter as it 
does currently. Hence, full backwards compatibility will be maintained.
        We have a preliminary implementation on local workspace. We can provide 
full patch for review. Appreciate your thoughts. 
        Thanks 
        Maxim Fateev.


Reply via email to