activemq-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hiram Chirino (Resolved) (JIRA)" <>
Subject [jira] [Resolved] (APLO-101) Support Kafka style durable pub/sub
Date Mon, 05 Dec 2011 23:44:41 GMT


Hiram Chirino resolved APLO-101.

    Resolution: Fixed
> Support Kafka style durable pub/sub
> -----------------------------------
>                 Key: APLO-101
>                 URL:
>             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)
> 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:
>     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:!default.jspa
For more information on JIRA, see:


View raw message