activemq-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hiram Chirino (Created) (JIRA)" <j...@apache.org>
Subject [jira] [Created] (APLO-101) Support Kafka style durable pub/sub
Date Mon, 05 Dec 2011 23:32:40 GMT
Support Kafka style durable pub/sub
-----------------------------------

                 Key: APLO-101
                 URL: https://issues.apache.org/jira/browse/APLO-101
             Project: ActiveMQ Apollo
          Issue Type: New Feature
          Components: apollo-broker, apollo-stomp
            Reporter: Hiram Chirino
            Assignee: Hiram Chirino
             Fix For: 1.0-beta6



You can combine the Queue Browser (APLO-99) and and Queue Message Sequence (APLO-100) features
to implement durable pub/sub in a way which results in even better performance
than the Topic Durable Subscriptions feature can provide.  

To use this approach, your subscribing application must be able to keep track 
of the last sequence number processed from the destination.  The application 
would typically store this as part of the unit of work it performs to process 
the message.

In this scenario, you use multiple queue browsers against queue.  The browsing
subscriptions will use the `include-seq`, `from-seq`, and `browser-end` so that
they can resume receiving messages from the queue from the last known sequence.

Example:

    SUBSCRIBE
    id:mysub
    destination:/queue/foo
    browser:true
    browser-end:false
    include-seq:seq
    from-seq:503
    
    ^@

If you are starting a new consumer, you can either set `from-seq:0` to 
receive a copy of all the messages that has been sent to the queue or you
can use `from-seq:-1` to skip over all the message that exist in the queue
and only receive new messages.

Since the consuming application records the last sequence that was processed,
you can use the default auto acknowledge mode but still avoid message loss.

Since this approach does not consume the messages from the queue, you should
either:

* Send messages to the queue with an expiration time so that they are automatically
  delete once the expiration time is reached.
* Periodically run a normal consumer application which can cursor the queue
  and delete messages are are deemed no longer needed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message