From commits-return-17427-apmail-activemq-commits-archive=activemq.apache.org@activemq.apache.org Mon Dec 5 23:45:04 2011 Return-Path: X-Original-To: apmail-activemq-commits-archive@www.apache.org Delivered-To: apmail-activemq-commits-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 7BB3579E2 for ; Mon, 5 Dec 2011 23:45:04 +0000 (UTC) Received: (qmail 40614 invoked by uid 500); 5 Dec 2011 23:45:04 -0000 Delivered-To: apmail-activemq-commits-archive@activemq.apache.org Received: (qmail 40594 invoked by uid 500); 5 Dec 2011 23:45:04 -0000 Mailing-List: contact commits-help@activemq.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@activemq.apache.org Delivered-To: mailing list commits@activemq.apache.org Received: (qmail 40587 invoked by uid 99); 5 Dec 2011 23:45:04 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 05 Dec 2011 23:45:04 +0000 X-ASF-Spam-Status: No, hits=-2001.2 required=5.0 tests=ALL_TRUSTED,RP_MATCHES_RCVD X-Spam-Check-By: apache.org Received: from [140.211.11.116] (HELO hel.zones.apache.org) (140.211.11.116) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 05 Dec 2011 23:45:02 +0000 Received: from hel.zones.apache.org (hel.zones.apache.org [140.211.11.116]) by hel.zones.apache.org (Postfix) with ESMTP id 2ABD4C91C1 for ; Mon, 5 Dec 2011 23:44:41 +0000 (UTC) Date: Mon, 5 Dec 2011 23:44:41 +0000 (UTC) From: "Hiram Chirino (Resolved) (JIRA)" To: commits@activemq.apache.org Message-ID: <1441287918.43325.1323128681176.JavaMail.tomcat@hel.zones.apache.org> In-Reply-To: <476917083.43269.1323127960267.JavaMail.tomcat@hel.zones.apache.org> Subject: [jira] [Resolved] (APLO-101) Support Kafka style durable pub/sub MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 X-Virus-Checked: Checked by ClamAV on 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