qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Zhemzhitsky Sergey <Sergey_Zhemzhit...@troika.ru>
Subject RE: Erlang client for Qpid C++ Broker
Date Fri, 25 May 2012 10:38:15 GMT
Hi Frase,

I agree with your points and if not requirements of our latency-critical system, message bridge
would be one of the solutions.

Best Regards,
Sergey

-----Original Message-----
From: Fraser Adams [mailto:fraser.adams@blueyonder.co.uk] 
Sent: Friday, May 25, 2012 12:31 PM
To: users@qpid.apache.org
Subject: Re: Erlang client for Qpid C++ Broker

"is like to shoot sparrows with a cannon "

Well it's messy, but effective :-)

I don't know erlang at all, but one option might be to use the SWIG based approach which has
been used for Perl and an alternative Python client (and I think some others), these use SWIG
as a binding layer to the qpid::messaging C++ API

I've no idea if this is even possible with erlang/SWIG, but if it's technically possible then
I'd say that's a good bet to look into especially if performance is a big part of the equation
with you. I've only casually played with the Perl binding but it seems to rock, IIRC my noddy
sample Perl code ran faster than the equivalent Java code - in one moment of obtuseness I
was tempted to write a thin JMS veneer to qpid::messaging using SWIG.

Anyway, I don't disagree with a purist view that the most reliable system is one that doesn't
contain any components :-) I've found myself arguing exactly the same thing many times, but
ultimately integration is about compromises and about solving practical problems. I've currently
got a scenario where I have to bridge between AMQP and FTP, so I do feel your pain :-/

You've got no actual evidence that this approach is actually going to be unreliable, and ultimately
it's going to be delivering more messages than an unintegrated set of components :-> personally,
I'd stand up a prototype and start delivering some benefits whilst I looked for a more elegant
solution.

Frase


On 25/05/12 08:51, 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:Barys_Ilyushonak@troika.ru]
> Sent: Friday, May 25, 2012 11:32 AM
> To: users@qpid.apache.org
> 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:fraser.adams@blueyonder.co.uk]
> Sent: Friday, May 25, 2012 11:20 AM
> To: users@qpid.apache.org
> 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: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
broker.
>>
>> 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: users-help@qpid.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
> 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: 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

Mime
View raw message