Hi Rajith, I cannot find any erlang stuff under http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/. Moreover c++ broker does not support ampq 1.0 at the moment.
Best Regards, Sergey -----Original Message----- From: Rajith Attapattu [mailto:[email protected]] Sent: Monday, May 28, 2012 9:42 PM To: [email protected] Subject: Re: Erlang client for Qpid C++ Broker Erlang does not have a swig binding. Your bet best is to do an Erlang driver. But AFIK drivers can only be in C. Therefore you might have to get a C wrapper around the C++ Even if you get all that going, the difference in the programming paradigms (functional vs oo) might prevent you from getting the best out of erlang and it's capabilities. A more longer term solution is to probably look at using the proton-c stuff (written using C and is AMQP 1.0), where you can get an erlang driver for the AMQP protocol stuff. And then build an API using the idioms that are more suitable for a functional language and erlang. This approach IMO is more suited for getting a more a useful erlang client which can be properly exploited in an erlang env. Rajith On Mon, May 28, 2012 at 2:47 AM, Zhemzhitsky Sergey < [email protected]> wrote: > Hello Carl, > > Thanks a lot for suggestion. > It seems that swig lib does not support erlang currently, but erlang > itself has some ways to interoperate with the native languages. > > > Best Regards, > Sergey > > > -----Original Message----- > From: Carl Trieloff [mailto:[email protected]] > Sent: Saturday, May 26, 2012 12:17 AM > To: [email protected] > Subject: Re: Erlang client for Qpid C++ Broker > > > > 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 K K[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] > > > --------------------------------------------------------------------- > 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]
