Hi Rob, Thanks for the reply. I am using CSE linux and 0.12 of QPID Regards, Meghna
-----Original Message----- From: Rob Godfrey [mailto:[email protected]] Sent: Friday, January 20, 2012 3:24 PM To: [email protected] Subject: Re: Qpid Java Broker High Availability solution? Hi Meghna, your question seems to be about building the C++ code, so you might be better reposting this with a different subject line, as Praveen and I were discussing the Java Broker. In order to help the C++ guys help you it would probably also be helpful to let them know which operating system / version you are trying to build this on. Cheers, Rob On 20 January 2012 10:45, Senthil Kumar, Sinduja (GE Healthcare) < [email protected]> wrote: > Hi Praveen and Rob, > I am new to QPID. Can anyone of you help me in creating QPID > libraries and binaries. This is very urgent and important. > I downloaded the QPID from the suggested mirror on the HOME website of > QPID. I gave boostrap [.....qpid0.12/cpp]./bootstrap and then > ./configure too. > But finding some problem when giving make. [.....qpid0.12/cpp]make The > errors are File > "/home/guest/sinduja/QPID/qpid-0.12/qpid-0.12/python/qpid/ops.py", > line 236, in load_types_from_xml > spec = mllib.xml_parse(file) > File > "/home/guest/sinduja/QPID/qpid-0.12/qpid-0.12/python/mllib/__init__.py > ", > line 80, in xml_parse > p.parse(source) > File > "/usr/lib64/python2.6/site-packages/_xmlplus/sax/expatreader.py", > line 109, in parse > xmlreader.IncrementalParser.parse(self, source) File > "/usr/lib64/python2.6/site-packages/_xmlplus/sax/xmlreader.py", > line 123, in parse > self.feed(buffer) > File > "/usr/lib64/python2.6/site-packages/_xmlplus/sax/expatreader.py", > line 216, in feed > self._parser.Parse(data, isFinal) > File > "/usr/lib64/python2.6/site-packages/_xmlplus/sax/expatreader.py", > line 396, in external_entity_ref > "") > File "/usr/lib64/python2.6/site-packages/_xmlplus/sax/saxutils.py", > line 523, in prepare_input_source > f = urllib2.urlopen(source.getSystemId()) > File "/usr/lib64/python2.6/urllib2.py", line 124, in urlopen > return _opener.open(url, data, timeout) File > "/usr/lib64/python2.6/urllib2.py", line 381, in open > protocol = req.get_type() > File "/usr/lib64/python2.6/urllib2.py", line 242, in get_type > raise ValueError, "unknown url type: %s" % self.__original > ValueError: unknown url type: > /home/guest/sinduja/QPID/qpid-0.12/qpid-0.12/python/qpid/specs/amqp-0- > 10 > .dtd > > Can someone help me on this....Am I doing the right version of QPID ?. > I have just started with QPID. So only if I make this running , I can > proceed further. > > Regards, > Meghna > > > > > -----Original Message----- > From: Rob Godfrey [mailto:[email protected]] > Sent: Friday, January 20, 2012 3:06 PM > To: [email protected] > Subject: Re: Qpid Java Broker High Availability solution? > > Hi Praveen, > > On 14 January 2012 02:47, Praveen M <[email protected]> wrote: > > > Hi, > > > > Are there any java broker high availability/clustering solutions > > that are currently present? I tried googling around and didn't find > > anything to my luck. > > > > Can you please suggest a HA strategy that you've used working with > > the > > > Qpid Java Broker? > > > > > So where I work we have two separate strategies for "HA" and disaster > recovery. > > For HA we use synchronous replication of the BDB store, with external > software monitoring the availability of the primary broker machine. > If the primary broker machine goes down, the external software starts > up the secondary broker machine, which points to the synchronously > replicated instance of the store... it can also handle reassignment of > the IP address / DNS name. > > For DR we take regular snapshots of the BDB store files and ship these > using an FTP-like mechanism to a DR site. Clearly with this solution > you run the risk of loss as you only have a snapshot from a known > point in time, not from the very moment the system went down. > > > > I found a Message Federation design proposal document, but I'm > > guessing it's not implemented yet (Please correct me if I'm wrong). > > > > > There is an alpha/beta implementation of Message Federation in the > Java Broker, which follows the same design as that in the C++ broker > and uses the same toolset to create routes. This code is broken in > the most recent releases of the Java Broker, but should work "better" > from trunk... however I'm not going to give any guarantees on it's > suitability for a production system right now (I hope to be doing some > serious testing/fixing over the next couple of months). > > > > I plan to spin off two brokers on two different machines and use a > > failover connection model to route messages to one if the other goes > > down. This works well for message enqueues. > > But still, I'd run the risk of not being able to process the > > messages in the broker that just went down (until it's back up). It > > will be nice to know if someone had solved a similar problem by > > other strategies/solutions available with the broker. > > > > Also, has someone tried replicating the database used for the > > persistent store to solve this problem (BDB/Derby ?) > > > > > As above, we use replication, but managed by hardware/external software. > I've not yet tried using BDB's own HA solutions to provide replication. > > > > Please do share your experience in this area. > > > > > Hope this helps, > Cheers, > Rob > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:[email protected] > > --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
