Late to the thread -- why not use cqpid swig lib to erlang?
On 05/25/2012 03:51 AM, Zhemzhitsky Sergey wrote: > Hi guys, > > Introduction of new java brokers just to bridge erlang or any other clients > is like to shoot sparrows with a cannon to my mind. It's a pity that amqp > protocol versions are not interoperable. > Fortunately programming languages provide different ways to make calls to a > native code. > > > Best Regards, > Sergey > > > -----Original Message----- > From: Ilyushonak Barys [mailto:[email protected]] > Sent: Friday, May 25, 2012 11:32 AM > To: [email protected] > Subject: RE: Erlang client for Qpid C++ Broker > > Hi, Frase > > Thank you very much for the explanation. > The one more thing we can do is to move our clients to rabbitmq directly. > As far as we use camel a lot, it looks much easier than adopt qpid java to > rabbitmq client. > > But. The way we would like to achieve - is to keep qpid c++ performance. So, > we are going to investigate it. > > Regards, > Boris > > -----Original Message----- > From: Fraser Adams [mailto:[email protected]] > Sent: Friday, May 25, 2012 11:20 AM > To: [email protected] > Subject: Re: Erlang client for Qpid C++ Broker > > Hi Guys, > I think that's a fair point, though to be fair the approach Alex suggested is > really just an instance of a message bridge, which is a standard Integration > Pattern. It's clearly not ideal but ultimately you have an integration > problem to solve. We've had similar scenarios bridging between qpid and > ActiveMQ - in our case we used Apache Camel as it has a qpid endpoint and > integrates well with ActiveMQ, but ultimately the issues are pretty similar > to yours. > > Also in many topologies it's pretty common to federate brokers - I guess it > depends on your architecture but a fairly common pattern in a geographically > distributed system would be for clients to publish to a local broker and for > that broker to be federated to other locations, it might be slightly > counterintuitive but in that sort of scenario you are likely to improve > reliability of the overall system and certainly improve things from the > perspective of the publishing client. Clearly if your architecture comprised > a single C++ broker with clients publishing/consuming directly to it then > there's a potential reduction in reliability due to probabilities (MTBF) > being multiplicative on components connected in series. > > One option (though adds a little more complexity) would be to to stand up a > couple of parallel instances of the Java broker and load balance between > them, that's useful from a scaling perspective if you have "peaky" > performance characteristics but more usefully if one falls over the other > carries on. > > Sorry that I can't be of more practical help, but hopefully I can reassure > you that the sort of problems/choices/compromises you're having to make are > pretty common sometimes it's a case of gritting teeth and doing what's "least > worst" as opposed to elegant - that'll be the difference between engineering > and theory :-) > > I expect most of us are going to be faced with "comedy" integration problems > when AMQP 1.0 starts to roll out. I *really hope* hint hint!!! > that the qpid brokers for AMQP 1.0 are going to be bilingual 0.10/1.0 or I'm > going to have some fun.... > > Good luck > Frase > > > On 25/05/12 07:47, Zhemzhitsky Sergey wrote: >> Hi Alex, >> >> Thanks a lot, but this sounds pretty horrible, I suppose. >> Introducing new java brokers just to forward messages to c++ broker >> increases complexity of the overall system and decreases its reliability. >> >> Best Regards, >> Sergey >> >> >> -----Original Message----- >> From: Oleksandr Rudyy [mailto:[email protected]] >> Sent: Thursday, May 24, 2012 8:28 PM >> To: [email protected] >> Subject: Re: Erlang client for Qpid C++ Broker >> >> Hi Sergey, >> >> You cannot use 0.9.1 amqp client with broker supporting only 0.10 amqp >> protocol. >> >> Java Qpid Broker supports both 0.10 and 0.9.1 protocols. >> >> You can publish messages with Erling client into Qpid Java Broker (or >> RabitMQ broker) and use Qpid java client to consume messages from that >> broker and publish them into c++ Qpid broker. >> >> Kind Regards, >> Alex Rudyy >> >> On 24 May 2012 16:18, Zhemzhitsky Sergey<[email protected]> >> wrote: >>> Hi there, >>> >>> I have to use qpid c++ broker 0.12 from erlang. >>> Are there any erlang clients that can be used to connect to the qpid c++ >>> broker, except for rabbitmq client? >>> If there isn’t, have anybody succeeded in connecting rabbitmq erlang client >>> that supports amqp 0.9.1 to the qpidd c++ broker that supports amqp 0.10 >>> only? >>> >>> Best Regards, >>> Sergey >>> >>> >>> _______________________________________________________ >>> >>> The information contained in this message may be privileged and conf >>> idential and protected from disclosure. If you are not the original >>> intended recipient, you are hereby notified that any review, >>> retransmission, dissemination, or other use of, or taking of any action in >>> reliance upon, this information is prohibited. If you have received this >>> communication in error, please notify the sender immediately by replying to >>> this message and delete it from your computer. Thank you for your >>> cooperation. Troika Dialog, Russia. >>> If you need assistance please contact our Contact Center (+7495) 258 >>> 0500 or go to www.troika.ru/eng/Contacts/system.wbp >>> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] For >> additional commands, e-mail: [email protected] >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] For >> additional commands, e-mail: [email protected] >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] For additional > commands, e-mail: [email protected] > > B KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB > [ X ܚX KK[XZ[ > \ \ ][ X ܚX P\Y > \X K ܙ B ܈Y][ۘ[ [X[ K[XZ[ > \ \ Z[\Y > \X K ܙ B B > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
