qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fraser Adams <fraser.ad...@blueyonder.co.uk>
Subject Re: Erlang client for Qpid C++ Broker
Date Fri, 25 May 2012 07:18:43 GMT
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

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:orudyy@gmail.com]
> Sent: Thursday, May 24, 2012 8:28 PM
> To: users@qpid.apache.org
> 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
> Kind Regards,
> Alex Rudyy
> On 24 May 2012 16:18, Zhemzhitsky Sergey<Sergey_Zhemzhitsky@troika.ru>  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: users-unsubscribe@qpid.apache.org For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org

To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

View raw message