[jira] [Resolved] (APLO-101) Support Kafka style durable pub/sub

["Hiram Chirino (Resolved) (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/APLO-101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hiram Chirino resolved APLO-101.
--------------------------------

    Resolution: Fixed
    
> 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