From activemq-dev-return-223-apmail-geronimo-activemq-dev-archive=geronimo.apache.org@geronimo.apache.org Wed Mar 08 18:50:57 2006 Return-Path: Delivered-To: apmail-geronimo-activemq-dev-archive@www.apache.org Received: (qmail 35011 invoked from network); 8 Mar 2006 18:50:56 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 8 Mar 2006 18:50:56 -0000 Received: (qmail 25367 invoked by uid 500); 8 Mar 2006 18:50:55 -0000 Delivered-To: apmail-geronimo-activemq-dev-archive@geronimo.apache.org Received: (qmail 25342 invoked by uid 500); 8 Mar 2006 18:50:55 -0000 Mailing-List: contact activemq-dev-help@geronimo.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: activemq-dev@geronimo.apache.org Delivered-To: mailing list activemq-dev@geronimo.apache.org Received: (qmail 25327 invoked by uid 99); 8 Mar 2006 18:50:55 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 08 Mar 2006 10:50:55 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=HTML_MESSAGE X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [206.169.0.56] (HELO astra.reveredata.com) (206.169.0.56) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 08 Mar 2006 10:50:54 -0800 Received: from reveredata.com (tango.revere.local [192.168.254.10]) by astra.reveredata.com (8.13.3/8.13.3) with ESMTP id k28IoR4c078169 for ; Wed, 8 Mar 2006 13:50:28 -0500 (EST) (envelope-from LEdelstein@reveredata.com) Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C642E1.2D0585DE" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830 Subject: improve master/slave topology Date: Wed, 8 Mar 2006 10:50:31 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: improve master/slave topology thread-index: AcZC4SzI94qZsgwvQmi9I8nb3JHhjQ== From: "Edelstein, Lawrence" To: X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N ------_=_NextPart_001_01C642E1.2D0585DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable (Sorry not to reply to Ning Li's message, but I just subscribed to the = list, and don't know how to reply to it without it being in my inbox.) =20 This is just my quick na=EFve stab at how resynching might work: =20 - When the master is notified of a slave, it makes a persistent = note of the slave's identity (presumably URI). - When the master goes down, the slave begins operating as it = does now. It also starts a new transacted message queue (the "resynch = queue") for all the messages and acknowledgements it's going to process = while it is in the hot seat. - When the master comes back up: o Before it begins responding to messages, it looks for its = persistent note, and finds the slave. =20 o It connects to the slave and tells it that their places are = reversed. The Servant Has Become The Master. Biblical scholars and = Police fans laugh. (FROM NOW ON, I'LL REFER TO THE BROKERS USING THEIR = NEW ROLES.) The new slave will not process messages from anybody but = the new master. o The new slave begins consuming resynch messages from the queue, = as well as those new messages that come from its new master via the good = ole' master-slave protocol, processing each in the same way. Er, = somehow. =20 If I correctly understand how clients work, then the next step should = not require any notification to the clients: =20 - The slave and master agree to swap places. The swap takes = place atomically with respect to all of the ongoing synchronization = processing between them. (NOW I'LL REFER TO THE BROKERS IN THE ROLES = THEY HAD BEFORE FAILOVER.) =20 At this point the slave stops processing requests, and the master = starts; clients should be able to failover just as they do now. =20 If someone wants to point me the way to relevant code, I'll check it = out. Perhaps I've really oversimplified things...if so, please tell me = where. =20 Larry Edelstein Revere Data San Francisco, CA =20 =20 =20 =20 --- on Mon March 6, Ning Li wrote: --- =20 Maybe a broker-broker synchronization protocol is the ultimate solution, = just we are not sure how to get there. Any recommendation or = suggestions? =20 =20 - ABOUT REVERE - Revere provides finance and business professionals with superior data = and analytics on companies traded publicly in the U.S. Our approach is = based on precise classification and identification of key business = relationships. The Revere Complete product suite combines the Revere = Research analysis platform and the Revere RealTime market data = application. Revere Complete integrates comprehensive financial and = market information - real-time quotes, sector and option analytics, = charts, news, fundamental data, and sophisticated screening - with = unique content derived from Revere's own independent research:=20 - The Revere Hierarchy, a patented classification system that provides = unmatched detail in specifying a company's business activities and = identifying exact competitors - Revere Relationships, a database mapping a company to its key = competitors, customers, suppliers, and strategic partners =20 www.reveredata.com ------_=_NextPart_001_01C642E1.2D0585DE--