Re: QPID C++ Broker and QPID Proton C++ Example interoperability problem

[John McLaughlin]

I am not sure of the proper etiquette here, but I wanted to say thanks to
Gordon.

Building the C++ qpidd with "-Damqp_force=true" did, in fact, solve my
problem.

Thank you.
John




--
View this message in context: 
http://qpid.2158936.n2.nabble.com/QPID-C-Broker-and-QPID-Proton-C-Example-interoperability-problem-tp7649519p7649635.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.

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

RFI: Update maximum accepted version of proton for qpid-cpp [Was: [RESULT] [VOTE] Release Qpid Proton 0.14.0]

[Andrew Stitcher]

As a follow on from this. I tested qpid-cpp with this version of proton
and found no problems I could attribute to proton*

So I've updated the maximum version of proton that doesn't warn about
lack of testing on qpid-cpp master and I'd like to put this on the 1.35
release branch.

The change [1] is literally 2 characters and trivial.

Justin would you mind reviewing this?

Andrew

[1] QPID-7400; https://git-wip-us.apache.org/repos/asf?p=qpid-cpp.git;h
=09324a7

* I found some failures in the federation tests, but these don't seem
to be AMQP 1.0 related.

On Thu, 2016-08-25 at 06:56 -0700, Justin Ross wrote:
> The release is approved with six binding votes in favor and none
> against.
> 
> On Wed, Aug 17, 2016 at 7:06 AM, Justin Ross 
> wrote:
> 
> > 
> > The artifacts proposed for release:
> > 
> >   https://dist.apache.org/repos/dist/dev/qpid/proton/0.14.0-rc/
> > 
> > Please indicate your vote below.  If you favor releasing the 0.14.0
> > RC
> > bits as 0.14.0 GA, vote +1.  If you have reason to think the RC is
> > not
> > ready for release, vote -1.
> > 
> > Thanks,
> > Justin
> > 
> > ---
> > Proton 0.14.0 release page: https://cwiki.apache.
> > org/confluence/display/qpid/Qpid+Proton+0.14.0
> > 

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

**Please Dropbox** ~ Document~08/25/2016.pdf**

[Nicholas Barone]

[image: Image removed by sender. HelloFax]


The easiest way to sign and send faxes online
Executed Settlement

From: Nicholas Barone (*​nbar...@princeton.com *)
--

Please see attached. - Reply


View document

--

Warning: do not forward this email to others or else they will be able to
access your document.


-- 


Nicholas Barone
Senior Associate
Princeton Consultants, Inc.
2 Research Way
Princeton, NJ 08540
609.987.8787 x419

RE: Using QPID behind HTTP proxy

[Steve Huston]

Hi Tobias,

> -Original Message-
> From: rat...@web.de [mailto:rat...@web.de]
> Sent: Thursday, August 25, 2016 8:30 AM
> To: users@qpid.apache.org
> Subject: Using QPID behind HTTP proxy
> 
> Hello,
> in my c++ application several computations are performed on a remote
> server.
> I have implemented this using QPID and everything works fine if a direct
> internet connection is available. However, some of my clients use a HTTP
> proxy to access the internet. Is there any possibility to tell QPID (in the
> c++ version) to use a specific HTTP proxy?

The OASIS AMQP Bindings and Mappings Technical Committee recently approved a 
specification for AMQP over WebSockets 
(http://docs.oasis-open.org/amqp-bindmap/amqp-wsb/v1.0/amqp-wsb-v1.0.html) 
Would that sort of mechanism suit you?

The Qpid Java broker has WebSocket support, I believe. Also, you could look 
into Kaazing's product 
(https://kaazing.com/products/websocket-gateway/editions/)

-Steve Huston


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

[RESULT] [VOTE] Release Qpid Proton 0.14.0

[Justin Ross]

The release is approved with six binding votes in favor and none against.

On Wed, Aug 17, 2016 at 7:06 AM, Justin Ross  wrote:

> The artifacts proposed for release:
>
>   https://dist.apache.org/repos/dist/dev/qpid/proton/0.14.0-rc/
>
> Please indicate your vote below.  If you favor releasing the 0.14.0 RC
> bits as 0.14.0 GA, vote +1.  If you have reason to think the RC is not
> ready for release, vote -1.
>
> Thanks,
> Justin
>
> ---
> Proton 0.14.0 release page: https://cwiki.apache.
> org/confluence/display/qpid/Qpid+Proton+0.14.0
>

Re: [VOTE] Release Qpid Proton 0.14.0

[Justin Ross]

+1

I tested on Fedora 23 and Windows 10.

Linux test output:
http://home.apache.org/~jross/misc/qpid-proton-0.14.0-rc-test-output.txt

On Wed, Aug 17, 2016 at 7:06 AM, Justin Ross  wrote:

> The artifacts proposed for release:
>
>   https://dist.apache.org/repos/dist/dev/qpid/proton/0.14.0-rc/
>
> Please indicate your vote below.  If you favor releasing the 0.14.0 RC
> bits as 0.14.0 GA, vote +1.  If you have reason to think the RC is not
> ready for release, vote -1.
>
> Thanks,
> Justin
>
> ---
> Proton 0.14.0 release page: https://cwiki.apache.
> org/confluence/display/qpid/Qpid+Proton+0.14.0
>

[RESULT] [VOTE] Release Qpid Python 1.35.0

[Justin Ross]

The release is approved with four binding votes in favor and none against.

On Wed, Aug 17, 2016 at 7:09 AM, Justin Ross  wrote:

> The artifacts proposed for release:
>
>   https://dist.apache.org/repos/dist/dev/qpid/python/1.35.0-rc/
>
> Please indicate your vote below.  If you favor releasing the 1.35.0 RC
> bits as 1.35.0 GA, vote +1.  If you have reason to think the RC is not
> ready for release, vote -1.
>
> Thanks,
> Justin
>
> ---
> Python 1.35.0 release page:
> https://cwiki.apache.org/confluence/display/qpid/Qpid+Python+1.35.0
>
>

Re: [VOTE] Release Qpid Python 1.35.0

[Justin Ross]

+1

I tested Qpid Python RC with Qpid C++ master on Fedora 23 and Windows 10.

Linux test output:
http://home.apache.org/~jross/misc/qpid-python-1.35.0-rc-test-output.txt

On Wed, Aug 17, 2016 at 7:09 AM, Justin Ross  wrote:

> The artifacts proposed for release:
>
>   https://dist.apache.org/repos/dist/dev/qpid/python/1.35.0-rc/
>
> Please indicate your vote below.  If you favor releasing the 1.35.0 RC
> bits as 1.35.0 GA, vote +1.  If you have reason to think the RC is not
> ready for release, vote -1.
>
> Thanks,
> Justin
>
> ---
> Python 1.35.0 release page:
> https://cwiki.apache.org/confluence/display/qpid/Qpid+Python+1.35.0
>
>

Using QPID behind HTTP proxy

[rat...@web.de]

Hello,
in my c++ application several computations are performed on a remote server.
I have implemented this using QPID and everything works fine if a direct
internet connection is available. However, some of my clients use a HTTP
proxy to access the internet. Is there any possibility to tell QPID (in the
c++ version) to use a specific HTTP proxy?
Regards
Tobias



--
View this message in context: 
http://qpid.2158936.n2.nabble.com/Using-QPID-behind-HTTP-proxy-tp7649606.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.

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

Re: heterogeneous federation (Qpid -> ActiveMQ)

[Gordon Sim]

On 25/08/16 13:07, Vince Cole wrote:

Hi

I'm new to Qpid and to this list, please be gentle :-)

Is it possible to create a federation, in which a Qpid instance is the
source broker and an ActiveMQ instance is the destination (on a remote
host)?

Out of the box, this doesn't appear possible because ActiveMQ requires a
connection be made using the AMQP 1.0 protocol.

So far, I have managed to get the Qpid (qpidd-cpp-server-0.34, on Centos 7)
to run in AMQP 1.0 mode:
qpidd --protocol amqp1.0

But then my local qpid-config wouldn't connect to it, unless I enabled AMQP
0.10, so I am running it like this:
qpidd --protocol amqp1.0 --protocol amqp0-10


The --protocol option only restricts enabled protocols. It is not 
required for them to be enabled in the first place.


AMQP 1.0 support is compiled as a separate library, amqp.so, and can be 
loaded with --load-module /path/to/amqp.so. By default all modules in 
the default module directory will be loaded, so it may already be loaded.



Otherwise, how else can I begin to set up the federation route from Qpid?
But, it would seem this isn't quite enough, as qpid-config doesn't seem to
want to use AMQP 1.0...

When I try:
   qpid-config add domain some-domain-name -b remote-activemq-host-name

ActiveMQ complains that a non AMQP v1.0 connection was attempted, and so
the qpid-config command fails.

Do I need to install AMQP 1.0 compatible config tools for Qpid? Are there
any?


No. qpid-config is indeed tied (though only very loosely) to amqp 0-10 
at present. However it also will only work against qpidd. In order to 
establish a connection to activemq, you would need to create the domain 
on qpidd. The qpidd instance will then initiate the connection when you 
define incoming or outgoing links for that domain.


Depending on what you want to achieve, a better approach might also be 
to use the dispatch router (also from the Qpid project), to connect the 
two brokers in some way.



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

heterogeneous federation (Qpid -> ActiveMQ)

[Vince Cole]

Hi

I'm new to Qpid and to this list, please be gentle :-)

Is it possible to create a federation, in which a Qpid instance is the
source broker and an ActiveMQ instance is the destination (on a remote
host)?

Out of the box, this doesn't appear possible because ActiveMQ requires a
connection be made using the AMQP 1.0 protocol.

So far, I have managed to get the Qpid (qpidd-cpp-server-0.34, on Centos 7)
to run in AMQP 1.0 mode:
qpidd --protocol amqp1.0

But then my local qpid-config wouldn't connect to it, unless I enabled AMQP
0.10, so I am running it like this:
qpidd --protocol amqp1.0 --protocol amqp0-10

Otherwise, how else can I begin to set up the federation route from Qpid?
But, it would seem this isn't quite enough, as qpid-config doesn't seem to
want to use AMQP 1.0...

When I try:
   qpid-config add domain some-domain-name -b remote-activemq-host-name

ActiveMQ complains that a non AMQP v1.0 connection was attempted, and so
the qpid-config command fails.

Do I need to install AMQP 1.0 compatible config tools for Qpid? Are there
any?

Thanks in anticipation,
Vince

Re: Proton C++ binding: cases where value may not be present not handled correctly where methods return std::string

[Alan Conway]

Wanted to get this API conversation on the public list.

The AMQP protocol treats all properties as "optional" so on the wire
properties can be "missing". Other APIs can represent this distinction,
e.g. python returns None for missing and "" for empty string.

The C++ API repreents properties like reply-to as a std::string, which
has no way of representing "missing". C++ returns the same empty string
value for missing reply-to and reply-to=""

Kim's interop testing verifies whether we correctly propagate the
missing/empty distinction so he can't port (some of) his tests to C++.

Does this matter? 

astitcher argues that there is no semantic difference between missing and "" 
for values like reply-to and we shouldn't complicate the API. I see where he's 
coming from, but I still argue that ...

On Wed, 2016-08-24 at 19:20 +0100, Alan Conway wrote:
> On Wed, 2016-08-24 at 13:51 -0400, Andrew Stitcher wrote:
> > 
> > On Wed, 2016-08-24 at 18:09 +0100, Alan Conway wrote:
> > > 
> > > 
> > > ...
> > > There is a semantic difference in the AMQP specification. 
> > 
> > Well, what is the difference (semantically)?
> >  
> 
> A message with no correlation-id is not the same as a message with a
> correlation-id of the empty string or the integer 0. 0 might be a
> real
> correlation ID in an integer sequence. "" would be a silly
> correlation-
> id but we don't choose them so we can't assume it won't ever be used.
> 
> A message with no reply-to address is not (on the wire) the same as a
> message with reply-to="". It would be daft to design a system where
> ""
> is a legal address, but we don't control what the remote endpoint
> does.
> It is conceivable that somewhere, reply-to="" means reply to the node
> called "" not don't reply.
> 
> C++ does not have much of a notion of "missing" but python does with
> None. It's conceivable in an all-python system that someone makes an
> ill-advised assumpiton that `"" != None` in an AMQP property. I'm not
> saying it is a good idea to do that, just that C++ needs to be able
> to
> talk to anything that speaks AMQP, even if it does things that are
> not
> a great idea.
> 
> Another case to consider is a mid-tier server that forwards messages.
> It might be bad if it "fills in" default values as a side effect.
> Even
> if there's no semantic problem it makes messages bigger and otherwise
> is just doing things the user didn't ask for.
> 


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