You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Oleksandr Rudyy <or...@gmail.com> on 2012/05/24 18:27:52 UTC

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 <Se...@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


RE: Erlang client for Qpid C++ Broker

Posted by Zhemzhitsky Sergey <Se...@troika.ru>.
Hi Rajith,

In case of any positive progress we’ll let you know.

Regards,
Sergey

From: Rajith Attapattu [mailto:rajith77@gmail.com]
Sent: Tuesday, May 29, 2012 5:13 PM
To: users@qpid.apache.org; Zhemzhitsky Sergey
Subject: Re: Erlang client for Qpid C++ Broker

Please keep us posted on your progress.
Other folks who are looking for the same could potentially use your solution until we come up with a proper longer term solution.

Rajith
On Tue, May 29, 2012 at 8:20 AM, Zhemzhitsky Sergey <Se...@troika.ru>> wrote:
>Sorry if I gave the wrong impression. What I meant was that you can use "proton-c" to get an erlang driver and then use that as the basis for creating an erlang client.
>In time the c++ broker will also speak AMQP 1.0 That's why I mentioned this as a potential longer term solution!
>I'm afraid I don't see a short term solution that could help you immediately.
I see. I suppose I will try linked-in drivers or NIFs as a short-term solution.


Best Regards,
Sergey

-----Original Message-----
From: Rajith Attapattu [mailto:rajith77@gmail.com<ma...@gmail.com>]
Sent: Tuesday, May 29, 2012 3:33 PM
To: users@qpid.apache.org<ma...@qpid.apache.org>
Subject: Re: Erlang client for Qpid C++ Broker

On Tue, May 29, 2012 at 5:09 AM, Zhemzhitsky Sergey < Sergey_Zhemzhitsky@troika.ru<ma...@troika.ru>> wrote:

> Hi Rajith,
>
> I cannot find any erlang stuff under
> http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/.
>

Sorry if I gave the wrong impression. What I meant was that you can use "proton-c" to get an erlang driver and then use that as the basis for creating an erlang client.
In time the c++ broker will also speak AMQP 1.0 That's why I mentioned this as a potential longer term solution!
I'm afraid I don't see a short term solution that could help you immediately.

Rajith

Moreover c++ broker does not support ampq 1.0 at the moment.
>
> Best Regards,
> Sergey
>
> -----Original Message-----
> From: Rajith Attapattu [mailto:rajith77@gmail.com<ma...@gmail.com>]
> Sent: Monday, May 28, 2012 9:42 PM
> To: users@qpid.apache.org<ma...@qpid.apache.org>
> 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 <
> Sergey_Zhemzhitsky@troika.ru<ma...@troika.ru>> 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:cctrieloff@redhat.com<ma...@redhat.com>]
> > Sent: Saturday, May 26, 2012 12:17 AM
> > To: users@qpid.apache.org<ma...@qpid.apache.org>
> > 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:Barys_Ilyushonak@troika.ru<ma...@troika.ru>]
> > > Sent: Friday, May 25, 2012 11:32 AM
> > > To: users@qpid.apache.org<ma...@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<ma...@blueyonder.co.uk>]
> > > Sent: Friday, May 25, 2012 11:20 AM
> > > To: users@qpid.apache.org<ma...@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<ma...@gmail.com>]
> > >> Sent: Thursday, May 24, 2012 8:28 PM
> > >> To: users@qpid.apache.org<ma...@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<Se...@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<http://www.troika.ru/eng/Contacts/system.wbp>
> > >>>
> > >> -----------------------------------------------------------------
> > >> --
> > >> -- To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org<ma...@qpid.apache.org> For
> > >> additional commands, e-mail: users-help@qpid.apache.org<ma...@qpid.apache.org>
> > >>
> > >>
> > >> -----------------------------------------------------------------
> > >> --
> > >> -- To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org<ma...@qpid.apache.org> For
> > >> additional commands, e-mail: users-help@qpid.apache.org<ma...@qpid.apache.org>
> > >>
> > >
> > > ------------------------------------------------------------------
> > > --
> > > - To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org<ma...@qpid.apache.org> For
> > > additional commands, e-mail: users-help@qpid.apache.org<ma...@qpid.apache.org>
> > >
> > >  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: users-unsubscribe@qpid.apache.org<ma...@qpid.apache.org> For
> > > additional commands, e-mail: users-help@qpid.apache.org<ma...@qpid.apache.org>
> > >
> >
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org<ma...@qpid.apache.org> For
> > additional commands, e-mail: users-help@qpid.apache.org<ma...@qpid.apache.org>
> >
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org<ma...@qpid.apache.org> For
> > additional commands, e-mail: users-help@qpid.apache.org<ma...@qpid.apache.org>
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org<ma...@qpid.apache.org> For
> additional commands, e-mail: users-help@qpid.apache.org<ma...@qpid.apache.org>
>
>


Re: Erlang client for Qpid C++ Broker

Posted by Rajith Attapattu <ra...@gmail.com>.
Please keep us posted on your progress.
Other folks who are looking for the same could potentially use your
solution until we come up with a proper longer term solution.

Rajith

On Tue, May 29, 2012 at 8:20 AM, Zhemzhitsky Sergey <
Sergey_Zhemzhitsky@troika.ru> wrote:

> >Sorry if I gave the wrong impression. What I meant was that you can use
> "proton-c" to get an erlang driver and then use that as the basis for
> creating an erlang client.
> >In time the c++ broker will also speak AMQP 1.0 That's why I mentioned
> this as a potential longer term solution!
> >I'm afraid I don't see a short term solution that could help you
> immediately.
>
> I see. I suppose I will try linked-in drivers or NIFs as a short-term
> solution.
>
>
> Best Regards,
> Sergey
>
> -----Original Message-----
> From: Rajith Attapattu [mailto:rajith77@gmail.com]
> Sent: Tuesday, May 29, 2012 3:33 PM
> To: users@qpid.apache.org
> Subject: Re: Erlang client for Qpid C++ Broker
>
> On Tue, May 29, 2012 at 5:09 AM, Zhemzhitsky Sergey <
> Sergey_Zhemzhitsky@troika.ru> wrote:
>
> > Hi Rajith,
> >
> > I cannot find any erlang stuff under
> > http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/.
> >
>
> Sorry if I gave the wrong impression. What I meant was that you can use
> "proton-c" to get an erlang driver and then use that as the basis for
> creating an erlang client.
> In time the c++ broker will also speak AMQP 1.0 That's why I mentioned
> this as a potential longer term solution!
> I'm afraid I don't see a short term solution that could help you
> immediately.
>
> Rajith
>
> Moreover c++ broker does not support ampq 1.0 at the moment.
> >
> > Best Regards,
> > Sergey
> >
> > -----Original Message-----
> > From: Rajith Attapattu [mailto:rajith77@gmail.com]
> > Sent: Monday, May 28, 2012 9:42 PM
> > To: users@qpid.apache.org
> > 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 <
> > Sergey_Zhemzhitsky@troika.ru> 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:cctrieloff@redhat.com]
> > > Sent: Saturday, May 26, 2012 12:17 AM
> > > To: users@qpid.apache.org
> > > 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: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<Se...@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 K  K[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
> > >
> > >
> > > --------------------------------------------------------------------
> > > - 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
> >
> >
>

RE: Erlang client for Qpid C++ Broker

Posted by Zhemzhitsky Sergey <Se...@troika.ru>.
>Sorry if I gave the wrong impression. What I meant was that you can use "proton-c" to get an erlang driver and then use that as the basis for creating an erlang client.
>In time the c++ broker will also speak AMQP 1.0 That's why I mentioned this as a potential longer term solution!
>I'm afraid I don't see a short term solution that could help you immediately.

I see. I suppose I will try linked-in drivers or NIFs as a short-term solution.


Best Regards,
Sergey

-----Original Message-----
From: Rajith Attapattu [mailto:rajith77@gmail.com] 
Sent: Tuesday, May 29, 2012 3:33 PM
To: users@qpid.apache.org
Subject: Re: Erlang client for Qpid C++ Broker

On Tue, May 29, 2012 at 5:09 AM, Zhemzhitsky Sergey < Sergey_Zhemzhitsky@troika.ru> wrote:

> Hi Rajith,
>
> I cannot find any erlang stuff under
> http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/.
>

Sorry if I gave the wrong impression. What I meant was that you can use "proton-c" to get an erlang driver and then use that as the basis for creating an erlang client.
In time the c++ broker will also speak AMQP 1.0 That's why I mentioned this as a potential longer term solution!
I'm afraid I don't see a short term solution that could help you immediately.

Rajith

Moreover c++ broker does not support ampq 1.0 at the moment.
>
> Best Regards,
> Sergey
>
> -----Original Message-----
> From: Rajith Attapattu [mailto:rajith77@gmail.com]
> Sent: Monday, May 28, 2012 9:42 PM
> To: users@qpid.apache.org
> 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 < 
> Sergey_Zhemzhitsky@troika.ru> 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:cctrieloff@redhat.com]
> > Sent: Saturday, May 26, 2012 12:17 AM
> > To: users@qpid.apache.org
> > 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: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<Se...@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 K  K[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
> >
> >
> > --------------------------------------------------------------------
> > - 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
>
>

Re: Erlang client for Qpid C++ Broker

Posted by Rajith Attapattu <ra...@gmail.com>.
On Tue, May 29, 2012 at 5:09 AM, Zhemzhitsky Sergey <
Sergey_Zhemzhitsky@troika.ru> wrote:

> Hi Rajith,
>
> I cannot find any erlang stuff under
> http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/.
>

Sorry if I gave the wrong impression. What I meant was that you can use
"proton-c" to get an erlang driver and then use that as the basis for
creating an erlang client.
In time the c++ broker will also speak AMQP 1.0
That's why I mentioned this as a potential longer term solution!
I'm afraid I don't see a short term solution that could help you
immediately.

Rajith

Moreover c++ broker does not support ampq 1.0 at the moment.
>
> Best Regards,
> Sergey
>
> -----Original Message-----
> From: Rajith Attapattu [mailto:rajith77@gmail.com]
> Sent: Monday, May 28, 2012 9:42 PM
> To: users@qpid.apache.org
> 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 <
> Sergey_Zhemzhitsky@troika.ru> 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:cctrieloff@redhat.com]
> > Sent: Saturday, May 26, 2012 12:17 AM
> > To: users@qpid.apache.org
> > 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: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<Se...@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 K  K[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
> >
> >
> > ---------------------------------------------------------------------
> > 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
>
>

RE: Erlang client for Qpid C++ Broker

Posted by Zhemzhitsky Sergey <Se...@troika.ru>.
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:rajith77@gmail.com] 
Sent: Monday, May 28, 2012 9:42 PM
To: users@qpid.apache.org
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 < Sergey_Zhemzhitsky@troika.ru> 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:cctrieloff@redhat.com]
> Sent: Saturday, May 26, 2012 12:17 AM
> To: users@qpid.apache.org
> 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: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<Se...@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 K  K[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
>
>
> ---------------------------------------------------------------------
> 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


Re: Erlang client for Qpid C++ Broker

Posted by Rajith Attapattu <ra...@gmail.com>.
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 <
Sergey_Zhemzhitsky@troika.ru> 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:cctrieloff@redhat.com]
> Sent: Saturday, May 26, 2012 12:17 AM
> To: users@qpid.apache.org
> 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: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<Se...@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 K  K[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
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>

RE: Erlang client for Qpid C++ Broker

Posted by Zhemzhitsky Sergey <Se...@troika.ru>.
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:cctrieloff@redhat.com] 
Sent: Saturday, May 26, 2012 12:17 AM
To: users@qpid.apache.org
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: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<Se...@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


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


Re: Erlang client for Qpid C++ Broker

Posted by Carl Trieloff <cc...@redhat.com>.

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: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<Se...@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


RE: Erlang client for Qpid C++ Broker

Posted by Zhemzhitsky Sergey <Se...@troika.ru>.
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<Se...@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


Re: Erlang client for Qpid C++ Broker

Posted by Fraser Adams <fr...@blueyonder.co.uk>.
"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<Se...@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


RE: Erlang client for Qpid C++ Broker

Posted by Zhemzhitsky Sergey <Se...@troika.ru>.
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<Se...@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

Re: Erlang client for Qpid C++ Broker

Posted by Fraser Adams <fr...@blueyonder.co.uk>.
Hi Boris,
Remember I said that we integrated qpid with Apache ActiveMQ via Camel, 
I was trying to illustrate an analogous position not an identical one, 
so we have a Camel based component that subscribes to messages off a 
qpid broker and republishes to an ActiveMQ broker, which is simply a 
bridge and not a lot different logically than the suggestion to use the 
java qpid broker as a bridge between different AMQP versions.

I think that Gordon Sim had done some work investigating bridging to 
rabbitmq, but I don't know how much success he had.

my suspicion is that using the java broker as a bridge is the option 
most likely to succeed.

Frase


On 25/05/12 08:32, Ilyushonak Barys wrote:
> 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<Se...@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
>
>
> ---------------------------------------------------------------------
> 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


RE: Erlang client for Qpid C++ Broker

Posted by Ilyushonak Barys <Ba...@troika.ru>.
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<Se...@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


Re: Erlang client for Qpid C++ Broker

Posted by Fraser Adams <fr...@blueyonder.co.uk>.
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<Se...@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


RE: Erlang client for Qpid C++ Broker

Posted by Zhemzhitsky Sergey <Se...@troika.ru>.
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 <Se...@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