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] > >
