Re: Coaxing an error message out of qpid-cpp - unable to connect

[Graham Leggett]

On 10 Oct 2013, at 6:36 PM, Gordon Sim  wrote:

> Yes it does, but the configuration is entirely different between these two 
> clients. In particular I don't believe the 0.8/0-9-1/0-10 client uses 'amqps' 
> to indicate ssl is to be used:
> 
> http://qpid.apache.org/releases/qpid-0.24/programming/book/QpidJNDI.html
> 
> From the examples in section  3.4 I think the "url" you would be looking for 
> would be:
> 
> amqp://guest:guest@client_id/test?maxprefetch=1 
> &brokerlist='tcp://amqp.sandbox.xxx.net:5671?ssl='true'sasl_mechs='EXTERNAL''
> 
> The client_id can be one of your own choosing of course and the username and 
> password won't actually be chosen if you are using EXTERNAL authentication.
> 
> If you want to use a specific certificate you would use:
> 
> amqp://guest:guest@client_id/test?maxprefetch=1
>
> &brokerlist='tcp://amqp.sandbox.xxx.net:5671?ssl='true'&ssl_cert_alias='cert1'&sasl_mechs='EXTERNAL''

Thank you for the clarification, what eventually triggered a successful 
connection was the following URL, which included quotes:

amqp://transcode/queue?maxprefetch='1'&brokerlist='tcp://amqp.${env:SERVER_ENV}.xxx.net:5671?ssl='true'&sasl_mechs='ANONYMOUS''

We've run into the next problem which seems to be a difference between activemq 
and qpid, it seems qpid wants the queues to be statically defined:

javax.jms.JMSException: Error registering consumer: 
org.apache.qpid.AMQException: The name 'video_audio_demux_queue' supplied in 
the address doesn't resolve to an exchange or a queue

Is there a way to dynamically define queues like activemq can?

Regards,
Graham
--


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

RE: Qpid Dispatch Router component

[Steve Huston]

Hi guys,

> -Original Message-
> From: Rob Godfrey [mailto:rob.j.godf...@gmail.com]
> Sent: Thursday, October 10, 2013 11:21 AM
> To: users@qpid.apache.org
> Subject: Re: Qpid Dispatch Router component
> 
> On 10 October 2013 15:35, Ted Ross  wrote:
> 
> >
> > On 10/10/2013 04:38 AM, Rob Godfrey wrote:
> >
> >> My main concern is that I believe that Qpid should be primarily
> >> directed at implementing AMQP standards, and building resuable
> >> toolkits and components that fit into any AMQP network. I'd be very
> >> concerned if we were inventing alternative management protocols, or
> >> building components that only interoperated with other Qpid tools.
> >> So, personally I'd like to see statement around components saying
> >> that they will be fully implementing emerging AMQP Management,
> AMQP
> >> addressing, etc. standards, and that we as a project then ensure we stick
> to these goals.
> >>
> >
> > Rob,
> >
> > Here's where I'm going to have to disagree with you in principle. I
> > believe that Qpid should be primarily directed at innovating with AMQP
> > and helping to drive the AMQP standards where appropriate.  If Qpid
> > doesn't do it, somebody else will.  I should point out that almost
> > everything we do here is well ahead of the standards, including the JMS
> client.
> >
> > The thing I object to in your statement is the direction of flow from
> > the standard to the implementation.  Standards bodies _do not
> > innovate_.  If the emerging standards are such that a particular
> > valuable innovation cannot be done, the standard needs to change or be
> > ignored.  Qpid must not allow itself to be put in the position of
> > meekly sitting and waiting for the tablets to come from on high before
> implementing.
> >
> >
> I'm not saying that there is a direction of standard -> implementation, but
> that if there is a standard we should be implementing it rather than rolling
> our own which conflicts or substantially overlaps.  If we see a standard
> emerging at OASIS and do not believe it is correct then we should be working
> to fix it at that venue.  If we do work which we think is generally 
> applicable to
> other AMQP implementations then we should be considering whether we
> want to push it as a standard at OASiS or elsewhere.

The above is, as I see it, the crux of the matter. I agree with Rob on this 
item. Addressing and management are evolving standards in OASIS and they should 
not be ignored. The argument for evolving "de facto" standards is not really 
pertinent here (in the context of addressing and management). De facto 
standards emerge when some product/idea is developed and turned loose and 
people take off and run with it. In this case, work is ongoing at OASIS and 
other products are (I assume) implementing them. Ignoring that will only invite 
difficulties down the road, especially if Dispatch ends up only able to talk to 
itself. And I REALLY, REALLY want Dispatch to take off - I have big ideas for 
its use already.

As far as the idea of a AMQP router, now that's an opportunity for de facto 
standard(s). As long as it interoperates with any other AMQP 1.0 endpoint that 
uses AMQP standard addressing and it responds correctly to AMQP standard 
management.

Picture yourself as in Cisco's shoes 25-30 years ago. Take it from that 
approach and you'll be golden.

> I absolutely don't think that Qpid should be restricted in scope to simply
> implementing the standards, and I strongly believe that Qpid can be a place
> where we innovate and then work towards bringing behaviours to a
> standards body.  However I also think that when we do so we should state
> up front what it is we are trying to achieve.  I also don't think that qpid 
> should
> become a mini-GitHub for any project that is tangentially related to AMQP to
> simply use as a code repository.
> 
> So, in the case of Dispatch, it certainly seems to include innovative ideas
> which do not form part of any AMQP standard (proposed or current) but also
> seems to hint at overlaps with such (emerging) standards in addressing and
> in management.  In addressing I think it's important that any requirements
> for addressing that you believe are important for Dispatch are discussed and
> considered in the OASIS AMQP work... in the Management space I would
> very much hope that the emerging Management spec for AMQP would
> prove to be a foundation on which functionality could be built and I would be
> concerned for a number of reasons if you felt that Dispatch
> couldn't/shouldn't be using them.

Absolutely.

-Steve


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

Re: Qpid Dispatch Router component

[Ted Ross]

On 10/10/2013 11:20 AM, Rob Godfrey wrote:

On 10 October 2013 15:35, Ted Ross  wrote:


On 10/10/2013 04:38 AM, Rob Godfrey wrote:


My main concern is that I believe that Qpid should be primarily directed
at implementing AMQP standards, and building resuable toolkits and
components that fit into any AMQP network. I'd be very concerned if we were
inventing alternative management protocols, or building components that
only interoperated with other Qpid tools. So, personally I'd like to see
statement around components saying that they will be fully implementing
emerging AMQP Management, AMQP addressing, etc. standards, and that we as a
project then ensure we stick to these goals.


Rob,

Here's where I'm going to have to disagree with you in principle. I
believe that Qpid should be primarily directed at innovating with AMQP and
helping to drive the AMQP standards where appropriate.  If Qpid doesn't do
it, somebody else will.  I should point out that almost everything we do
here is well ahead of the standards, including the JMS client.

The thing I object to in your statement is the direction of flow from the
standard to the implementation.  Standards bodies _do not innovate_.  If
the emerging standards are such that a particular valuable innovation
cannot be done, the standard needs to change or be ignored.  Qpid must not
allow itself to be put in the position of meekly sitting and waiting for
the tablets to come from on high before implementing.



I'm not saying that there is a direction of standard -> implementation, but
that if there is a standard we should be implementing it rather than
rolling our own which conflicts or substantially overlaps.  If we see a
standard emerging at OASIS and do not believe it is correct then we should
be working to fix it at that venue.  If we do work which we think is
generally applicable to other AMQP implementations then we should be
considering whether we want to push it as a standard at OASiS or elsewhere.

I absolutely don't think that Qpid should be restricted in scope to simply
implementing the standards, and I strongly believe that Qpid can be a place
where we innovate and then work towards bringing behaviours to a standards
body.  However I also think that when we do so we should state up front
what it is we are trying to achieve.  I also don't think that qpid should
become a mini-GitHub for any project that is tangentially related to AMQP
to simply use as a code repository.


So here's the root of the issue.  The question is whether or not 
Dispatch is too tangential in its relation to AMQP to be considered 
appropriate to be hosted in Apache Qpid.


You stated later in your email that you don't know what an 
AMQP-compliant router is.  Well, nobody really does because nothing like 
it has ever existed.  The very idea was not even conceivable before 
there was an AMQP 1.0.  But now we have AMQP and a door has been opened 
to create really interesting solutions to difficult problems in 
large-scale distributed computing. Dispatch is an early attempt to 
implement such a solution.  If we decide that by "tangential" we mean 
"beyond the scope of traditional broker-based messaging", then Dispatch 
is clearly tangential and I will go and find another community to host it.


The only way to know if a project will have long-term value is to let it 
run for awhile.  It's a form of incubation.  We need a way, as you 
suggest, of deciding what to incubate.  We then need a way to decide 
when a sub-project has failed and should be abandoned. Given that we 
have no such guidelines in place, I intend to go forward with the same 
process we used for the JMS project.  If there arises a consensus in the 
community that Dispatch does not, or might not belong in Qpid, I will 
not go forward.


In the mean time, I will try to fill in some of the gaps in information
that you've identified.

-Ted



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

Re: Coaxing an error message out of qpid-cpp - unable to connect

[Gordon Sim]

On 10/10/2013 05:08 PM, Graham Leggett wrote:

More investigation has shown that someone had hard coded the qpid ampq v1.0 
driver directly into the code, which was taking precedence. With that removed 
we're now getting further, but still not out of the woods:

javax.jms.JMSException: Failed to parse entry: Not an AMQP URL 
amqps://amqp.sandbox.xxx.net:5671?jms.prefetchPolicy.queuePrefetch=1 due to : 
Not an AMQP URL: 
amqps://amqp.sandbox.xxx.net:5671?jms.prefetchPolicy.queuePrefetch=1

The URL worked fine with qpid-java-amqp-1-0-client-jms, but suddenly doesn't 
work with qpid-java-client - does the older JMS driver support SSL?


Yes it does, but the configuration is entirely different between these 
two clients. In particular I don't believe the 0.8/0-9-1/0-10 client 
uses 'amqps' to indicate ssl is to be used:


http://qpid.apache.org/releases/qpid-0.24/programming/book/QpidJNDI.html

From the examples in section  3.4 I think the "url" you would be 
looking for would be:


amqp://guest:guest@client_id/test?maxprefetch=1 
&brokerlist='tcp://amqp.sandbox.xxx.net:5671?ssl='true'sasl_mechs='EXTERNAL''


The client_id can be one of your own choosing of course and the username 
and password won't actually be chosen if you are using EXTERNAL 
authentication.


If you want to use a specific certificate you would use:

amqp://guest:guest@client_id/test?maxprefetch=1
	 
&brokerlist='tcp://amqp.sandbox.xxx.net:5671?ssl='true'&ssl_cert_alias='cert1'&sasl_mechs='EXTERNAL''



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

Re: Coaxing an error message out of qpid-cpp - unable to connect

[Robbie Gemmell]

The AMQP 1.0 client and AMQP 0-10 client dont share a common configuration,
and it looks like you are mixing the two.

See
http://qpid.apache.org/releases/qpid-0.24/programming/book/QpidJNDI.html#section-jms-connection-urlfor
documentation for the 0-10 client Connection URLs.

You might want to try something like:
amqp://user:pass@clientid/vhost?brokerlist='tcp://host:port?ssl='true''

Robbie

On 10 October 2013 17:08, Graham Leggett  wrote:

> On 10 Oct 2013, at 4:57 PM, Gordon Sim  wrote:
>
> >> I have tried qpid-java-client (expecting it to work) and
> qpid-java-amqp-1-0-client-jms (expecting it to give me a clear "protocol
> not supported" error) v0.24 and v0.18, and all 4 fail with the same
> "java.net.SocketException: Broken pipe".
> >
> > Sorry its been so difficult. You need different configuration properties
> to switch between the 1.0 client and the earlier one.
>
> More investigation has shown that someone had hard coded the qpid ampq
> v1.0 driver directly into the code, which was taking precedence. With that
> removed we're now getting further, but still not out of the woods:
>
> javax.jms.JMSException: Failed to parse entry: Not an AMQP URL amqps://
> amqp.sandbox.xxx.net:5671?jms.prefetchPolicy.queuePrefetch=1 due to : Not
> an AMQP URL: amqps://
> amqp.sandbox.xxx.net:5671?jms.prefetchPolicy.queuePrefetch=1
>
> The URL worked fine with qpid-java-amqp-1-0-client-jms, but suddenly
> doesn't work with qpid-java-client - does the older JMS driver support SSL?
>
> >> Can anyone confirm whether any of the Qpid Java code interoperates in
> any way with the Qpid C++ code?
> >
> > Yes, it definitely does. The first thing I'd try is getting a simple
> example working without SSL, then redo with SSL enabled. That will make any
> issues easier to pinpoint I believe.
>
> SSL is required in our system, so getting it working without doesn't help
> us. We have the ability to sniff the connection through SSL and debug it,
> so it isn't a problem (until the problem above).
>
> Regards,
> Graham
> --
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>

Re: Coaxing an error message out of qpid-cpp - unable to connect

[Graham Leggett]

On 10 Oct 2013, at 6:08 PM, Graham Leggett  wrote:

> javax.jms.JMSException: Failed to parse entry: Not an AMQP URL 
> amqps://amqp.sandbox.xxx.net:5671?jms.prefetchPolicy.queuePrefetch=1 due to : 
> Not an AMQP URL: 
> amqps://amqp.sandbox.xxx.net:5671?jms.prefetchPolicy.queuePrefetch=1
> 
> The URL worked fine with qpid-java-amqp-1-0-client-jms, but suddenly doesn't 
> work with qpid-java-client - does the older JMS driver support SSL?

As an alternative I tried to modify the URL to be 
amqp://amqp.sandbox.xxx.net:5671?ssl=true&jms.prefetchPolicy.queuePrefetch=1, 
and now I get the following equally mystifying error:

javax.jms.JMSException: Failed to parse entry: Virtual host found between 
indicies 7 and 25 
amqp://amqp.sandbox.xxx.net:5671?ssl=true&jms.prefetchPolicy.queuePrefetch=1
   ^ due to : Virtual host found at index 7: 
amqp://amqp.sandbox.xxx.net:5671?ssl=true&jms.prefetchPolicy.queuePrefetch=1

Anyone know why the qpid-client JMS API should find virtual hosts offensive?

Regards,
Graham
--


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

Re: Coaxing an error message out of qpid-cpp - unable to connect

[Graham Leggett]

On 10 Oct 2013, at 4:57 PM, Gordon Sim  wrote:

>> I have tried qpid-java-client (expecting it to work) and 
>> qpid-java-amqp-1-0-client-jms (expecting it to give me a clear "protocol not 
>> supported" error) v0.24 and v0.18, and all 4 fail with the same 
>> "java.net.SocketException: Broken pipe".
> 
> Sorry its been so difficult. You need different configuration properties to 
> switch between the 1.0 client and the earlier one.

More investigation has shown that someone had hard coded the qpid ampq v1.0 
driver directly into the code, which was taking precedence. With that removed 
we're now getting further, but still not out of the woods:

javax.jms.JMSException: Failed to parse entry: Not an AMQP URL 
amqps://amqp.sandbox.xxx.net:5671?jms.prefetchPolicy.queuePrefetch=1 due to : 
Not an AMQP URL: 
amqps://amqp.sandbox.xxx.net:5671?jms.prefetchPolicy.queuePrefetch=1

The URL worked fine with qpid-java-amqp-1-0-client-jms, but suddenly doesn't 
work with qpid-java-client - does the older JMS driver support SSL?

>> Can anyone confirm whether any of the Qpid Java code interoperates in any 
>> way with the Qpid C++ code?
> 
> Yes, it definitely does. The first thing I'd try is getting a simple example 
> working without SSL, then redo with SSL enabled. That will make any issues 
> easier to pinpoint I believe.

SSL is required in our system, so getting it working without doesn't help us. 
We have the ability to sniff the connection through SSL and debug it, so it 
isn't a problem (until the problem above).

Regards,
Graham
--


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

Re: Qpid Dispatch Router component

[Rob Godfrey]

On 10 October 2013 15:35, Ted Ross  wrote:

>
> On 10/10/2013 04:38 AM, Rob Godfrey wrote:
>
>> My main concern is that I believe that Qpid should be primarily directed
>> at implementing AMQP standards, and building resuable toolkits and
>> components that fit into any AMQP network. I'd be very concerned if we were
>> inventing alternative management protocols, or building components that
>> only interoperated with other Qpid tools. So, personally I'd like to see
>> statement around components saying that they will be fully implementing
>> emerging AMQP Management, AMQP addressing, etc. standards, and that we as a
>> project then ensure we stick to these goals.
>>
>
> Rob,
>
> Here's where I'm going to have to disagree with you in principle. I
> believe that Qpid should be primarily directed at innovating with AMQP and
> helping to drive the AMQP standards where appropriate.  If Qpid doesn't do
> it, somebody else will.  I should point out that almost everything we do
> here is well ahead of the standards, including the JMS client.
>
> The thing I object to in your statement is the direction of flow from the
> standard to the implementation.  Standards bodies _do not innovate_.  If
> the emerging standards are such that a particular valuable innovation
> cannot be done, the standard needs to change or be ignored.  Qpid must not
> allow itself to be put in the position of meekly sitting and waiting for
> the tablets to come from on high before implementing.
>
>
I'm not saying that there is a direction of standard -> implementation, but
that if there is a standard we should be implementing it rather than
rolling our own which conflicts or substantially overlaps.  If we see a
standard emerging at OASIS and do not believe it is correct then we should
be working to fix it at that venue.  If we do work which we think is
generally applicable to other AMQP implementations then we should be
considering whether we want to push it as a standard at OASiS or elsewhere.

I absolutely don't think that Qpid should be restricted in scope to simply
implementing the standards, and I strongly believe that Qpid can be a place
where we innovate and then work towards bringing behaviours to a standards
body.  However I also think that when we do so we should state up front
what it is we are trying to achieve.  I also don't think that qpid should
become a mini-GitHub for any project that is tangentially related to AMQP
to simply use as a code repository.

So, in the case of Dispatch, it certainly seems to include innovative ideas
which do not form part of any AMQP standard (proposed or current) but also
seems to hint at overlaps with such (emerging) standards in addressing and
in management.  In addressing I think it's important that any requirements
for addressing that you believe are important for Dispatch are discussed
and considered in the OASIS AMQP work... in the Management space I would
very much hope that the emerging Management spec for AMQP would prove to be
a foundation on which functionality could be built and I would be concerned
for a number of reasons if you felt that Dispatch couldn't/shouldn't be
using them.


> So here's my proposed statement regarding Dispatch:
>
> Qpid Dispatch is an implementation of an AMQP-compliant router. Dispatch
> is pursuing a specific approach to routing and addressing that may differ
> from other approaches.  The implementation will conform to all relevant
> emerging standards (Management, Addressing, and Security) to the extent
> that it is practical.  In the event that there are parts of the
> specifications that are not practical to implement, we shall provide
> specifics to the standards committee in an effort to improve the
> specifications.
>
>
Around AMQP compliance that seems reasonable, but from the rest of that
statement I'm not sure what "AMQP-compliant router" means... How does a
router differ from a broker?  Would you expect any special client APIs to
form part of the router package or not?  Would you expect any other
implementations of Dispatch, or is it intended only to be in C?  Is it
intended to be embedded in other programs or always to act as a stand-alone
executable?

What I'm getting at with a scope statement is that we should be clear at
the outset of projects what we are looking to achieve.  We may deliberately
leave thing very open, but then we should state that clearly too.

In order to be able to have a clear story about how the components of Qpid
fit together I think we should be clear before we set out on the journey of
a component what we are looking to do (and what we are explicitly not
looking to do).  For previous components I don't think we've done that well
enough (and for the upcoming JMS client I want to go back and rectify that
omission).

-- Rob

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

Re: Coaxing an error message out of qpid-cpp - unable to connect

[Gordon Sim]

On 10/10/2013 03:33 PM, Graham Leggett wrote:

On 10 Oct 2013, at 4:08 PM, Gordon Sim  wrote:


Do you have the AMQP 1.0 plugin for the broker? It would be in the module-dir, 
the default for which should be indicated by /usr/sbin/qpidd --help

My guess is that it is not there or is not being loaded. Without it qpidd only 
speaks 0-10.


I guess not:

[root@localhost ~]# ls -al /usr/lib64/qpid/daemon
total 1688
drwxr-xr-x 2 root root   4096 Oct 10 04:41 .
drwxr-xr-x 4 root root   4096 Jul 12 08:35 ..
-rwxr-xr-x 1 root root 366432 Jul 12 08:35 acl.so
-rwxr-xr-x 1 root root 997240 Jul 12 08:35 msgstore.so
-rwxr-xr-x 1 root root 131144 Jul 12 08:35 replicating_listener.so
-rwxr-xr-x 1 root root  54320 Jul 12 08:35 replication_exchange.so
-rwxr-xr-x 1 root root 156992 Jul 12 08:35 ssl.so

(I am using qpid-cpp v0.18 as published by CERN: 
http://linux.web.cern.ch/linux/mrg/)


As Alex pointed out, 0.18 did not yet include support for AMQP 1.0.


My question now becomes, what qpid JMS client speaks 0-10?


The main Qpid JMS client speaks 0-10 (as well as 0-8 and 0-9)


I have tried qpid-java-client (expecting it to work) and qpid-java-amqp-1-0-client-jms (expecting 
it to give me a clear "protocol not supported" error) v0.24 and v0.18, and all 4 fail 
with the same "java.net.SocketException: Broken pipe".


Sorry its been so difficult. You need different configuration properties 
to switch between the 1.0 client and the earlier one.



Can anyone confirm whether any of the Qpid Java code interoperates in any way 
with the Qpid C++ code?


Yes, it definitely does. The first thing I'd try is getting a simple 
example working without SSL, then redo with SSL enabled. That will make 
any issues easier to pinpoint I believe.



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

Re: Coaxing an error message out of qpid-cpp - unable to connect

[Oleksandr Rudyy]

Hi Graham,

The JMS client exception stack trace indicates that you are using AMQP
1.0 JMS client with 0.18 Broker which does not speak AMQP 1.0. The
support for AMQP 1.0 was introduced in 0.20 version of Qpid cpp
broker.

0.18 Broker supports only AMQP 0.10. You can use Qpid JMS Client which
speaks AMQP 0-8/0-9/0-9-1/0-10 protocols. That client should be
already on your classpath ( qpid-client-0.24.jar,
qpid-common-0.24.jar).
Please, have a look at examples at [1] to see how to connect that
client to the Broker. You can declare
org.apache.qpid.jndi.PropertiesFileInitialContextFactory as
java.naming.factory.initial in your jndi.properties which should
provide the right connection factory and destinations for you.

If you need to use AMQP 1.0 then you have to upgrade the Broker.

Kind Regards,
Alex

[1] 
http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/example/src/main/java/org/apache/qpid/example/


>> When the client tries the connect, the qpid-client v0.24 reports a 
>> "java.net.SocketException: Broken pipe" and then hangs solid, the hang solid 
>> most probably due to bug https://issues.apache.org/jira/browse/QPID-5113. 
>> What I am after is why the "java.net.SocketException: Broken pipe".
>
> Digging further with ssldump, I find that the SSL connections are completing 
> successfully, the client and server then try to negotiate the protocol, and 
> the server puts the phone down on the connection as follows:
>
> 1 5  6.8968 (0.0001)  C>S  ChangeCipherSpec
> 1 6  7.0251 (0.1282)  C>S  Handshake
>   Finished
> 1 7  7.0273 (0.0022)  S>C  ChangeCipherSpec
> 1 8  7.0273 (0.)  S>C  Handshake
>   Finished
> 1 9  7.0349 (0.0075)  C>S  application_data
> ---
> 41 4d 51 50 00 01 00 00AMQP
> ---
> 1 10 7.1535 (0.1185)  S>C  application_data
> ---
> 41 4d 51 50 01 01 00 0aAMQP
> ---
> 1 11 7.2002 (0.0467)  S>C  Alert
> level   warning
> value   close_notify
> 17.2011 (0.0008)  S>C  TCP FIN
> 1 12 7.2405 (0.0394)  C>S  application_data
> ---
> 00 00 00 50 02 00 00 00 00 53 10 c0 43 04 a1 1d...P.S..C...
> 6c 6f 63 61 6c 68 6f 73 74 2e 6c 6f 63 61 6c 64localhost.locald
> 6f 6d 61 69 6e 28 35 32 33 39 29 3a 32 a1 19 61omain(5239):2..a
> 6d 71 70 2e 73 61 6e 64 62 6f 78 2e xx xx xx xxmqp.sandbox.
> xx xx xx xx 2e 6e 65 74 70 00 01 00 00 60 00 ff.netp`..
> ---
> 17.5397 (0.2992)  C>S  TCP RST
>
> Is this a mismatch between the protocol on client and server?
>
> The client says "41 4d 51 50 00 01 00 00", the server then responds "41 4d 51 
> 50 01 01 00 0a" and puts the phone down. Am I right in assuming that "00 01 
> 00 00" and "01 01 00 0a" are protocol version numbers?
>
> The client jars are as follows:
>
> -rw-r--r-- 1 root transcode  471270 Oct 10 05:40 qpid-client-0.24.jar
> -rw-r--r-- 1 root transcode 1379470 Oct 10 05:41 qpid-common-0.24.jar
> -rw-r--r-- 1 root transcode   25942 Oct 10 05:41 slf4j-api-1.6.4.jar
>
> Are these compatible with a v0.18 qpid-cpp server?
>
> Regards,
> Graham
> --
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>

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

Re: Coaxing an error message out of qpid-cpp - unable to connect

[Graham Leggett]

On 10 Oct 2013, at 4:08 PM, Gordon Sim  wrote:

> Do you have the AMQP 1.0 plugin for the broker? It would be in the 
> module-dir, the default for which should be indicated by /usr/sbin/qpidd 
> --help
> 
> My guess is that it is not there or is not being loaded. Without it qpidd 
> only speaks 0-10.

I guess not:

[root@localhost ~]# ls -al /usr/lib64/qpid/daemon
total 1688
drwxr-xr-x 2 root root   4096 Oct 10 04:41 .
drwxr-xr-x 4 root root   4096 Jul 12 08:35 ..
-rwxr-xr-x 1 root root 366432 Jul 12 08:35 acl.so
-rwxr-xr-x 1 root root 997240 Jul 12 08:35 msgstore.so
-rwxr-xr-x 1 root root 131144 Jul 12 08:35 replicating_listener.so
-rwxr-xr-x 1 root root  54320 Jul 12 08:35 replication_exchange.so
-rwxr-xr-x 1 root root 156992 Jul 12 08:35 ssl.so

(I am using qpid-cpp v0.18 as published by CERN: 
http://linux.web.cern.ch/linux/mrg/)

My question now becomes, what qpid JMS client speaks 0-10?

I have tried qpid-java-client (expecting it to work) and 
qpid-java-amqp-1-0-client-jms (expecting it to give me a clear "protocol not 
supported" error) v0.24 and v0.18, and all 4 fail with the same 
"java.net.SocketException: Broken pipe".

Can anyone confirm whether any of the Qpid Java code interoperates in any way 
with the Qpid C++ code?

Regards,
Graham
--


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

Re: Coaxing an error message out of qpid-cpp - unable to connect

[Gordon Sim]

On 10/10/2013 01:56 PM, Graham Leggett wrote:

The stack trace on the client side is as follows for each failed connection:

java.net.SocketException: Broken pipe
 at java.net.SocketOutputStream.socketWrite0(Native Method)
 at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:109)
 at java.net.SocketOutputStream.write(SocketOutputStream.java:153)
 at sun.security.ssl.OutputRecord.writeBuffer(OutputRecord.java:377)
 at sun.security.ssl.OutputRecord.write(OutputRecord.java:363)
 at 
sun.security.ssl.SSLSocketImpl.writeRecordInternal(SSLSocketImpl.java:830)
 at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:801)
 at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:122)
 at 
org.apache.qpid.amqp_1_0.framing.ConnectionHandler$BytesOutputHandler.processBytes(ConnectionHandler.java:418)
 at 
org.apache.qpid.amqp_1_0.framing.ConnectionHandler$FrameToBytesSourceAdapter.getBytes(ConnectionHandler.java:305)
 at 
org.apache.qpid.amqp_1_0.framing.ConnectionHandler$SequentialBytesSource.getBytes(ConnectionHandler.java:371)
 at 
org.apache.qpid.amqp_1_0.framing.ConnectionHandler$BytesOutputHandler.run(ConnectionHandler.java:404)
 at java.lang.Thread.run(Thread.java:724)

The command line options for qpid-cpp are as follows:

qpidd 3027  0.5  0.8 299072  4336 ?Ssl  06:07   0:04 
/usr/sbin/qpidd --data-dir /var/lib/qpidd --daemon -t --port 5672 --ssl-cert-db 
sql:/etc/pki/nssdb --ssl-cert-name Server-Cert --ssl-port 5671 
--ssl-require-client-authentication --ssl-sasl-no-dict


Do you have the AMQP 1.0 plugin for the broker? It would be in the 
module-dir, the default for which should be indicated by /usr/sbin/qpidd 
--help


My guess is that it is not there or is not being loaded. Without it 
qpidd only speaks 0-10.


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

Re: Qpid Dispatch Router component

[Gordon Sim]

On 10/10/2013 12:09 PM, Rob Godfrey wrote:

On 10 October 2013 12:46, Gordon Sim  wrote:

On 10/10/2013 10:58 AM, Rob Godfrey wrote:

I think the point of Qpid (vs. any other messaging
implementation at Apache or elsewhere) is to implement the AMQP
specification.


I have no disagreement when the AMQP specification is what is currently
published.

My concern is where that is defined to be an expanding, all-encompassing
effort that ring fences whole areas of behaviour and sets itself up as the
only legitimate avenue for exploration.


Do you believe that is what the OASIS TCs are doing?  If so in which areas?


The idea of a general policy that any Qpid component must support any 
emerging standard from those TCs in a particular area and cannot explore 
alternatives or anything that may overlap does feel very much like this.


I am not saying that is what you meant, merely expressing that I would 
not be comfortable with such a policy if it was.



Expanding beyond the current specification needs a more diverse source of
ideas and a more open, transparent and collaborative process.


While I agree that a more open process is most definitely desirable, I
would argue that the OASIS TCs (sadly) currently have a much more diverse
membership than Qpid committers.Also note that you do not need to be a
member of OASIS to comment on work going on there.  If you (or anyone else)
believe that the work going on in OASIS is misguided you should comment
there [1], not here.


While involved at OASIS I did comment. However, I am not now seeking to 
reform the AMQP work at OASIS. Any such effort should indeed take place 
there and not here.


Neither am I trying to subvert it. I have no issue with you or anyone 
else working on projects within Qpid related to specifications you are 
progressing at OASIS, providing anyone else can join in and contribute 
ideas.


All I am saying is that I don't consider OASIS to have authority over 
what other work goes on in Qpid, again provided that work is done in an 
open and collaborative manner which listens to criticism of the approach.


Collaboration doesn't have to mean that everyone agrees on one point of 
view. A degree of exploration of alternatives is in my view healthy at 
this point provided we all conform to the underlying specification as 
published and strive to ensure the various voices in the community are 
heard and that whatever is produced serves the needs of those using it.


I myself will very happily contribute to, align with and support any 
effort that I see emerging with genuine widespread support from existing 
communities. If that is a spec from OASIS, great. If it's an idea from 
one of the other implementers, great. I want any additional standard to 
be adopted on merit not by fiat.


In the end I believe we want the same thing, we have the same goal of 
richer interoperability and I do firmly believe that while in theory we 
have different views on how best to achieve that we can collaborate 
effectively on the practical side of aiding AMQP adoption and on 
concrete issues we are as often as not likely to find a happy compromise.


Now, as to improving the process at Qpid and building a more diverse set 
of contributors, that I am very much interested in and this is the 
perfect place to discuss it. I would be eager to hear from anyone with 
ideas that could help.



While I may not be entirely happy with the OASIS process, the value in AMQP
is in standardisation.


The value is in practical interoperability and interchangeability.

Though I personally don't think OASIS is the best route to achieving 
that, I respect your view that it is. There should be room for both of 
us to help users reap the benefits that AMQP promised.



 If Qpid can be a place where multiple parties can
come together and work together then it may be a good place for de-facto
standards to emerge.


I want to be really clear on this point as it comes up several times 
here and in previous mails.


I said that I believe the emergence of de-facto standards is something 
to be nurtured and encouraged. I think Qpid can have a part in that, but 
I think it can *only* be a part. It *must* involve other communities, 
projects and products. So I am certainly *not* suggesting that I believe 
that work at Qpid should be taken as a de-facto standard.


[...]

Historically Qpid has not been seen as a neutral place.  For better or
worse, there are a preponderance of committers from one organisation.  In
order to counter perceptions of a lack of neutrality I think work has to be
done to bring more people in before we try to sell ourselves as a neutral
venue for emerging standards.


Again, just so there is no misunderstanding, I am *not* 'selling Qpid' 
as such a venue...



 Until we can actually demonstrate that Qpid
is such a place I think it is presumptuous of us to try to claim de-facto
standards for our work.


...and I have made no such claim.

A de-facto standard is not something you ca

Re: Coaxing an error message out of qpid-cpp - unable to connect

[Graham Leggett]

On 10 Oct 2013, at 2:56 PM, Graham Leggett  wrote:

> When the client tries the connect, the qpid-client v0.24 reports a 
> "java.net.SocketException: Broken pipe" and then hangs solid, the hang solid 
> most probably due to bug https://issues.apache.org/jira/browse/QPID-5113. 
> What I am after is why the "java.net.SocketException: Broken pipe".

Digging further with ssldump, I find that the SSL connections are completing 
successfully, the client and server then try to negotiate the protocol, and the 
server puts the phone down on the connection as follows:

1 5  6.8968 (0.0001)  C>S  ChangeCipherSpec
1 6  7.0251 (0.1282)  C>S  Handshake
  Finished
1 7  7.0273 (0.0022)  S>C  ChangeCipherSpec
1 8  7.0273 (0.)  S>C  Handshake
  Finished
1 9  7.0349 (0.0075)  C>S  application_data
---
41 4d 51 50 00 01 00 00AMQP
---
1 10 7.1535 (0.1185)  S>C  application_data
---
41 4d 51 50 01 01 00 0aAMQP
---
1 11 7.2002 (0.0467)  S>C  Alert
level   warning
value   close_notify
17.2011 (0.0008)  S>C  TCP FIN
1 12 7.2405 (0.0394)  C>S  application_data
---
00 00 00 50 02 00 00 00 00 53 10 c0 43 04 a1 1d...P.S..C...
6c 6f 63 61 6c 68 6f 73 74 2e 6c 6f 63 61 6c 64localhost.locald
6f 6d 61 69 6e 28 35 32 33 39 29 3a 32 a1 19 61omain(5239):2..a
6d 71 70 2e 73 61 6e 64 62 6f 78 2e xx xx xx xxmqp.sandbox.
xx xx xx xx 2e 6e 65 74 70 00 01 00 00 60 00 ff.netp`..
---
17.5397 (0.2992)  C>S  TCP RST

Is this a mismatch between the protocol on client and server?

The client says "41 4d 51 50 00 01 00 00", the server then responds "41 4d 51 
50 01 01 00 0a" and puts the phone down. Am I right in assuming that "00 01 00 
00" and "01 01 00 0a" are protocol version numbers?

The client jars are as follows:

-rw-r--r-- 1 root transcode  471270 Oct 10 05:40 qpid-client-0.24.jar
-rw-r--r-- 1 root transcode 1379470 Oct 10 05:41 qpid-common-0.24.jar
-rw-r--r-- 1 root transcode   25942 Oct 10 05:41 slf4j-api-1.6.4.jar

Are these compatible with a v0.18 qpid-cpp server?

Regards,
Graham
--


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

Re: Qpid Dispatch Router component

[Ted Ross]

On 10/10/2013 04:38 AM, Rob Godfrey wrote:
My main concern is that I believe that Qpid should be primarily 
directed at implementing AMQP standards, and building resuable 
toolkits and components that fit into any AMQP network. I'd be very 
concerned if we were inventing alternative management protocols, or 
building components that only interoperated with other Qpid tools. So, 
personally I'd like to see statement around components saying that 
they will be fully implementing emerging AMQP Management, AMQP 
addressing, etc. standards, and that we as a project then ensure we 
stick to these goals.


Rob,

Here's where I'm going to have to disagree with you in principle. I 
believe that Qpid should be primarily directed at innovating with AMQP 
and helping to drive the AMQP standards where appropriate.  If Qpid 
doesn't do it, somebody else will.  I should point out that almost 
everything we do here is well ahead of the standards, including the JMS 
client.


The thing I object to in your statement is the direction of flow from 
the standard to the implementation.  Standards bodies _do not 
innovate_.  If the emerging standards are such that a particular 
valuable innovation cannot be done, the standard needs to change or be 
ignored.  Qpid must not allow itself to be put in the position of meekly 
sitting and waiting for the tablets to come from on high before 
implementing.


So here's my proposed statement regarding Dispatch:

Qpid Dispatch is an implementation of an AMQP-compliant router. Dispatch 
is pursuing a specific approach to routing and addressing that may 
differ from other approaches.  The implementation will conform to all 
relevant emerging standards (Management, Addressing, and Security) to 
the extent that it is practical.  In the event that there are parts of 
the specifications that are not practical to implement, we shall provide 
specifics to the standards committee in an effort to improve the 
specifications.


-Ted


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

Coaxing an error message out of qpid-cpp - unable to connect

[Graham Leggett]

Hi all,

I am currently trying to swap in qpid-cpp v0.18 to replace an unreliable 
activemq server installation. The connection is protected with client 
certificates.

When the client tries the connect, the qpid-client v0.24 reports a 
"java.net.SocketException: Broken pipe" and then hangs solid, the hang solid 
most probably due to bug https://issues.apache.org/jira/browse/QPID-5113. What 
I am after is why the "java.net.SocketException: Broken pipe".

I switched on what I thought was trace debugging in qpid-cpp using the "-t" 
command line option, but all I got was the trace below:

Oct 10 06:08:59 localhost qpidd[3027]: 2013-10-10 06:08:59 [Network] trace 
Accepting SSL connection.
Oct 10 06:08:59 localhost qpidd[3027]: 2013-10-10 06:08:59 [Network] trace 
Accepting SSL connection.
Oct 10 06:08:59 localhost qpidd[3027]: 2013-10-10 06:08:59 [Network] trace 
Accepting SSL connection.
Oct 10 06:08:59 localhost qpidd[3027]: 2013-10-10 06:08:59 [Network] trace 
Accepting SSL connection.
Oct 10 06:08:59 localhost qpidd[3027]: 2013-10-10 06:08:59 [Network] trace 
Accepting SSL connection.
Oct 10 06:08:59 localhost qpidd[3027]: 2013-10-10 06:08:59 [Network] trace 
Accepting SSL connection.
Oct 10 06:08:59 localhost qpidd[3027]: 2013-10-10 06:08:59 [Network] trace 
Accepting SSL connection.
Oct 10 06:08:59 localhost qpidd[3027]: 2013-10-10 06:08:59 [Network] trace 
Accepting SSL connection.
Oct 10 06:09:02 localhost qpidd[3027]: 2013-10-10 06:09:02 [Security] debug 
RECV [127.0.0.1:5671-127.0.0.1:50899]: INIT(
0-0)
Oct 10 06:09:02 localhost qpidd[3027]: 2013-10-10 06:09:02 [Security] debug 
RECV [127.0.0.1:5671-127.0.0.1:50898]: INIT(
0-0)
Oct 10 06:09:02 localhost qpidd[3027]: 2013-10-10 06:09:02 [Security] debug 
SENT [127.0.0.1:5671-127.0.0.1:50898]: INIT(
0-10)
Oct 10 06:09:02 localhost qpidd[3027]: 2013-10-10 06:09:02 [Security] debug 
SENT [127.0.0.1:5671-127.0.0.1:50899]: INIT(
0-10)
Oct 10 06:09:02 localhost qpidd[3027]: 2013-10-10 06:09:02 [Security] debug 
RECV [127.0.0.1:5671-127.0.0.1:50893]: INIT(
0-0)
Oct 10 06:09:02 localhost qpidd[3027]: 2013-10-10 06:09:02 [Security] debug 
SENT [127.0.0.1:5671-127.0.0.1:50893]: INIT(
0-10)
Oct 10 06:09:02 localhost qpidd[3027]: 2013-10-10 06:09:02 [Security] debug 
RECV [127.0.0.1:5671-127.0.0.1:50894]: INIT(
0-0)
Oct 10 06:09:02 localhost qpidd[3027]: 2013-10-10 06:09:02 [Security] debug 
RECV [127.0.0.1:5671-127.0.0.1:50895]: INIT(
0-0)
Oct 10 06:09:02 localhost qpidd[3027]: 2013-10-10 06:09:02 [Security] debug 
SENT [127.0.0.1:5671-127.0.0.1:50895]: INIT(
0-10)
Oct 10 06:09:02 localhost qpidd[3027]: 2013-10-10 06:09:02 [Security] debug 
RECV [127.0.0.1:5671-127.0.0.1:50897]: INIT(
0-0)
Oct 10 06:09:02 localhost qpidd[3027]: 2013-10-10 06:09:02 [Security] debug 
SENT [127.0.0.1:5671-127.0.0.1:50897]: INIT(
0-10)
Oct 10 06:09:02 localhost qpidd[3027]: 2013-10-10 06:09:02 [Security] debug 
SENT [127.0.0.1:5671-127.0.0.1:50894]: INIT(
0-10)
Oct 10 06:09:02 localhost qpidd[3027]: 2013-10-10 06:09:02 [Security] debug 
RECV [127.0.0.1:5671-127.0.0.1:50896]: INIT(
0-0)
Oct 10 06:09:02 localhost qpidd[3027]: 2013-10-10 06:09:02 [Security] debug 
SENT [127.0.0.1:5671-127.0.0.1:50896]: INIT(
0-10)

Is there some kind of command line option over and above the -t that tells 
qpid-cpp to log errors? If I had an error message, I could debug this, right 
now all I have is a disconnect followed by silence.

The stack trace on the client side is as follows for each failed connection:

java.net.SocketException: Broken pipe
at java.net.SocketOutputStream.socketWrite0(Native Method)
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:109)
at java.net.SocketOutputStream.write(SocketOutputStream.java:153)
at sun.security.ssl.OutputRecord.writeBuffer(OutputRecord.java:377)
at sun.security.ssl.OutputRecord.write(OutputRecord.java:363)
at 
sun.security.ssl.SSLSocketImpl.writeRecordInternal(SSLSocketImpl.java:830)
at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:801)
at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:122)
at 
org.apache.qpid.amqp_1_0.framing.ConnectionHandler$BytesOutputHandler.processBytes(ConnectionHandler.java:418)
at 
org.apache.qpid.amqp_1_0.framing.ConnectionHandler$FrameToBytesSourceAdapter.getBytes(ConnectionHandler.java:305)
at 
org.apache.qpid.amqp_1_0.framing.ConnectionHandler$SequentialBytesSource.getBytes(ConnectionHandler.java:371)
at 
org.apache.qpid.amqp_1_0.framing.ConnectionHandler$BytesOutputHandler.run(ConnectionHandler.java:404)
at java.lang.Thread.run(Thread.java:724)

The command line options for qpid-cpp are as follows:

qpidd 3027  0.5  0.8 299072  4336 ?Ssl  06:07   0:04 
/usr/sbin/qpidd --data-dir /var/lib/qpidd --daemon -t --port 5672 --ssl-cert-db 
sql:/etc/pki/nssdb --ssl-cert-name Server-Cert --ssl-port 5671 
--ssl-require-client-authentication --ssl-sasl-no-dict

Regards,
Graham

RE: Unable to connect to broker via Qpid JMS-over-AMQP client

[Branden Smith]

Makes sense; thank you for your help.

Branden

-Original Message-
From: Robbie Gemmell [mailto:robbie.gemm...@gmail.com] 
Sent: Wednesday 2013.10.09 17:43
To: users@qpid.apache.org
Subject: Re: Unable to connect to broker via Qpid JMS-over-AMQP client

The 1.0 client has no built in failover handling so you would either need
to handle that yourself, or use a messaging framework that supports doing
such things for you.

To quote Rob Godfrey (who wrote the [prototype] AMQP 1.0 JMS client, and
co-wrote AMQP 1.0) from a few days ago:

"As to failover, I think that is better handled at an application level
(either directly, or using a library or framework which provides such
behaviour).  Since there is currently no special handling of failover in
AMQP, the functionality would be common with any JMS provider and as such
should be able to be built on top of the JMS client rather than within it.
Moreover our experience around failover is that depending on the
application use case the type of failover required can be very different
(transient topic subscriptions and transacted persistent point to point
generally (but not always) require different failover semantics for
example)."

Robbie

On 9 October 2013 22:06, Branden Smith  wrote:

> Thanks for the heads-up (and the link to the 1.0 example); I wondered why
> the package names were different.
>
> I'm not seeing anything either in the linked example or in my quick scan
> of the source code which references failover or multi-broker URLs. Does
> that mean that client-side failover capability is no longer available, as
> of Qpid's AMQP 1.0 release?
>
> Thanks,
>
>
> Branden Smith
> Lead Platform Architect
> bsm...@liaison.com
>
> Liaison Technologies, Inc.
> 3157 Royal Drive | Suite 200 | Alpharetta, Georgia 30022
> www.liaison.com | 866.336.7378
>
> -Original Message-
> From: Robbie Gemmell [mailto:robbie.gemm...@gmail.com]
> Sent: Wednesday 2013.10.09 16:03
> To: users@qpid.apache.org
> Subject: Re: Unable to connect to broker via Qpid JMS-over-AMQP client
>
> The documentation you are referencing is actually for the completely
> seperate AMQP 0-8/0-9/0-9-1/0-10 JMS client, rather than the AMQP 1.0 JMS
> client you are trying to use, which should explain most of your issues. The
> 1.0 client was the result of prototyping work during creation of AMQP 1.0
> itself, and is very loosely documented.
>
> You can see a example for the 1.0 JMS client here:
>
> https://svn.apache.org/viewvc/qpid/trunk/qpid/java/amqp-1-0-client-jms/example/src/main/java/org/apache/qpid/amqp_1_0/jms/example/
>
> I would ignore the majority of the example itself as it isnt particularly
> nice, but the properties should get you going.
>
> Robbie
>
>
> On 9 October 2013 20:53, Branden Smith  wrote:
>
> > I'm having trouble connecting to a message broker (HornetQ 2.4.0-beta1)
> > using the Qpid JMS-over-AMQP client (
> > http://qpid.apache.org/releases/qpid-0.24/programming/book/QpidJMS.html
> ).
> >  I've run into two major roadblocks; for the first, I think that I have a
> > work-around, but the second is still frustrating my progress:
> >
> > ~~
> > QUESTION 1
> > ~~
> >
> > The first problem I'm having is that the specified connection factory
> > (org.apache.qpid.jndi.PropertiesFileInitialContextFactory) does not
> appear
> > to support programmatic declaration of the JNDI properties, as is implied
> > in the documentation.  The documentation indicates that these properties:
> >
> > java.naming.factory.initial =
> > org.apache.qpid.jndi.PropertiesFileInitialContextFactory
> > connectionfactory.qpidConnectionfactory = amqp://guest:guest@clientid
> > /test?brokerlist='tcp://localhost:5672'
> > destination.topicExchange = amq.topic
> >
> > are loaded from a file on the classpath *outside* of the Qpid client
> > library, then the InitialContext is constructed from the resulting
> > Properties object:
> >
> > Properties properties = new Properties();
> >
> > properties.load(this.getClass().getResourceAsStream("hello.properties"));
> > Context context = new InitialContext(properties);
> >
> > However, my attempt to duplicate this approach resulted in a
> > NamingException with a "No Provider URL specified" message. Examination
> of
> > the source of PropertiesFileInitialContextFactory (
> >
> http://grepcode.com/file/repo1.maven.org/maven2/org.apache.qpid/qpid-amqp-1-0-client-jms/0.22/org/apache/qpid/amqp_1_0/jms/jndi/PropertiesFileInitialContextFactory.java
> )
> > shows why: the getInitialContext(Hashtable) method requires a property to
> > be defined with key Context.PROVIDER_URL ("java.naming.provider.url").
> >  Furthermore, the method requires that the value of that property point
> to
> > a file path on the local file system.
> >
> > As far as I can tell, the documentation never indicates a need for
> > java.naming.provider.url to be defined, nor does it require that the
> value
> > refer to a local file; the implication from the docs is that properties

Re: Qpid Dispatch Router component

[Rob Godfrey]

On 10 October 2013 12:46, Gordon Sim  wrote:

> On 10/10/2013 10:58 AM, Rob Godfrey wrote:
>
>> I think the point of Qpid (vs. any other messaging
>> implementation at Apache or elsewhere) is to implement the AMQP
>> specification.
>>
>
> I have no disagreement when the AMQP specification is what is currently
> published.
>
> My concern is where that is defined to be an expanding, all-encompassing
> effort that ring fences whole areas of behaviour and sets itself up as the
> only legitimate avenue for exploration.
>

Do you believe that is what the OASIS TCs are doing?  If so in which areas?


>

Expanding beyond the current specification needs a more diverse source of
> ideas and a more open, transparent and collaborative process.
>
>
While I agree that a more open process is most definitely desirable, I
would argue that the OASIS TCs (sadly) currently have a much more diverse
membership than Qpid committers.  Also note that you do not need to be a
member of OASIS to comment on work going on there.  If you (or anyone else)
believe that the work going on in OASIS is misguided you should comment
there [1], not here.

While I may not be entirely happy with the OASIS process, the value in AMQP
is in standardisation.  If Qpid can be a place where multiple parties can
come together and work together then it may be a good place for de-facto
standards to emerge.


> [...]
>
>  I think that any such efforts at de-facto standardisation
>> must first reach out to other AMQP implementers and ensure there is a
>> broad
>> agreement on direction.  If the Qpid project can be a vehicle for doing
>> this, then great - however currently that is not how Qpid is operating and
>> I would be very concerned at us trying to claim any sort of work done
>> within Qpid as a "de-facto" standard.
>>
>
> Indeed and that of course is a straw man since no one is suggesting that
> we claim any such thing.
>
> However I would be very concerned if the OASIS TCs, with such limited
> representation, were enshrined as authorities over any and every aspect of
> work they choose to start.
>
> At present there is sadly no AMQP-wide community. While Qpid is far from
> perfect, it is at least, as an Apache project, founded on the  ethos of
> open, community driven collaboration. It has rules for governance that
> provide the means to correct deviations from that. Everything we do should
> be open and subject to debate and consensus.
>

Indeed... I would very much like to have an AMQP-wide community
established.  If Qpid can become the home of that then that is great,
however in order to facilitate that then I believe the first step would be
to be good AMQP citizens and work with and implement the emerging standards
that are currently being progressed (or be clear in our objections to said
work).

Historically Qpid has not been seen as a neutral place.  For better or
worse, there are a preponderance of committers from one organisation.  In
order to counter perceptions of a lack of neutrality I think work has to be
done to bring more people in before we try to sell ourselves as a neutral
venue for emerging standards.  Until we can actually demonstrate that Qpid
is such a place I think it is presumptuous of us to try to claim de-facto
standards for our work.  With greatest respect to those involved, that is
the way that leads to the next QMF.

I want users of Qpid to be assured that components or libraries that they
can get here will work interoperably with any AMQP implementation that
follows the standards.


>
> Reaching out to - and collaborating with - other implementations and
> communities is something I personally feel we must do more of in order to
> realise the promise behind AMQP. Starting those discussions here seems like
> one (though certainly not the only) reasonable way to begin however.
>
>
>
-- Rob

[1] https://www.oasis-open.org/committees/comments/index.php?wg_abbrev=amqp


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

Re: Qpid Dispatch Router component

[Gordon Sim]

On 10/10/2013 10:58 AM, Rob Godfrey wrote:

I think the point of Qpid (vs. any other messaging
implementation at Apache or elsewhere) is to implement the AMQP
specification.


I have no disagreement when the AMQP specification is what is currently 
published.


My concern is where that is defined to be an expanding, all-encompassing 
effort that ring fences whole areas of behaviour and sets itself up as 
the only legitimate avenue for exploration.


Expanding beyond the current specification needs a more diverse source 
of ideas and a more open, transparent and collaborative process.


[...]

I think that any such efforts at de-facto standardisation
must first reach out to other AMQP implementers and ensure there is a broad
agreement on direction.  If the Qpid project can be a vehicle for doing
this, then great - however currently that is not how Qpid is operating and
I would be very concerned at us trying to claim any sort of work done
within Qpid as a "de-facto" standard.


Indeed and that of course is a straw man since no one is suggesting that 
we claim any such thing.


However I would be very concerned if the OASIS TCs, with such limited 
representation, were enshrined as authorities over any and every aspect 
of work they choose to start.


At present there is sadly no AMQP-wide community. While Qpid is far from 
perfect, it is at least, as an Apache project, founded on the  ethos of 
open, community driven collaboration. It has rules for governance that 
provide the means to correct deviations from that. Everything we do 
should be open and subject to debate and consensus.


Reaching out to - and collaborating with - other implementations and 
communities is something I personally feel we must do more of in order 
to realise the promise behind AMQP. Starting those discussions here 
seems like one (though certainly not the only) reasonable way to begin 
however.


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

Re: Qpid Dispatch Router component

[Rob Godfrey]

On 10 October 2013 11:49, Gordon Sim  wrote:

> On 10/10/2013 09:38 AM, Rob Godfrey wrote:
>
>> My main concern is that I believe that Qpid should be primarily directed
>> at
>> implementing AMQP standards, and building resuable toolkits and components
>> that fit into any AMQP network.  I'd be very concerned if we were
>> inventing
>> alternative management protocols, or building components that only
>> interoperated with other Qpid tools.
>>
>> So, personally I'd like to see statement around components saying that
>> they
>> will be fully implementing emerging AMQP Management, AMQP addressing, etc.
>> standards, and that we as a project then ensure we stick to these goals.
>>
>
> Interoperability with other AMQP compliant components both in and out of
> Qpid and Apache is certainly key. That is what AMQP is all about and what
> Qpid should be about.
>
> Faithful implementation of the existing AMQP specification is clearly a
> requirement as that is central to the charter of the project. Where any
> auxiliary or emerging specifications are adopted by a component, whether
> they are AMQP related or not, they should be compliant with that.
>
> However, having a general policy where all Qpid components are required to
> implement whatever 'emerging standards' come out of the OASIS AMQP TCs is
> not something I am comfortable with.
>

Saying that all Qpid components implement all emerging standards is clearly
not what I am saying, because not all standards are appropriate for all
components.  However I think the point of Qpid (vs. any other messaging
implementation at Apache or elsewhere) is to implement the AMQP
specification.  I'd generally question why work was being carried out in
Qpid (as opposed to elsewhere) if the work is not based on existing or
emerging AMQP standards.


>
> The Qpid community as a whole needs to have a say in how future features
> will work through an open, collaborative process (open to _anyone_, even
> those primarily involved with other AMQP related projects or products).
>
>
i completely agree.


> Personally I think this would be better for AMQP as well. Allowing and
> encouraging the emergence of grass-roots driven, de-facto 'standards'
> developed in and between open, collaborative and transparent communities
> and backed up by proven interoperable implementations, which can then form
> the basis for official de-jure standardisation.
>
>
Possibly, but I think that any such efforts at de-facto standardisation
must first reach out to other AMQP implementers and ensure there is a broad
agreement on direction.  If the Qpid project can be a vehicle for doing
this, then great - however currently that is not how Qpid is operating and
I would be very concerned at us trying to claim any sort of work done
within Qpid as a "de-facto" standard.  Where there is qork going on in AMQP
then we as the Qpid community should be ensuring that we feed back to that
and raise questions/objections as necessary (whether we are part of the
OASIS group or not - feedback from the public is possible).

-- Rob

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

Re: Qpid AMQP 1.0 - How does it all hang together? - was Re: Qpid Dispatch Router component

[Gordon Sim]

On 10/09/2013 08:04 PM, Ted Ross wrote:

There are a lot of new ideas floating around, some of them overlapping.
I think Qpid is a perfect place to explore and develop new technologies
based on AMQP.  This will cause some confusion and force us to work at
articulating what we are doing and thinking, and it will be people like
you who will prompt the important discussions.


Very well said, I heartily agree!

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

Re: Qpid Dispatch Router component

[Gordon Sim]

On 10/10/2013 09:38 AM, Rob Godfrey wrote:

My main concern is that I believe that Qpid should be primarily directed at
implementing AMQP standards, and building resuable toolkits and components
that fit into any AMQP network.  I'd be very concerned if we were inventing
alternative management protocols, or building components that only
interoperated with other Qpid tools.

So, personally I'd like to see statement around components saying that they
will be fully implementing emerging AMQP Management, AMQP addressing, etc.
standards, and that we as a project then ensure we stick to these goals.


Interoperability with other AMQP compliant components both in and out of 
Qpid and Apache is certainly key. That is what AMQP is all about and 
what Qpid should be about.


Faithful implementation of the existing AMQP specification is clearly a 
requirement as that is central to the charter of the project. Where any 
auxiliary or emerging specifications are adopted by a component, whether 
they are AMQP related or not, they should be compliant with that.


However, having a general policy where all Qpid components are required 
to implement whatever 'emerging standards' come out of the OASIS AMQP 
TCs is not something I am comfortable with.


The Qpid community as a whole needs to have a say in how future features 
will work through an open, collaborative process (open to _anyone_, even 
those primarily involved with other AMQP related projects or products).


Personally I think this would be better for AMQP as well. Allowing and 
encouraging the emergence of grass-roots driven, de-facto 'standards' 
developed in and between open, collaborative and transparent communities 
and backed up by proven interoperable implementations, which can then 
form the basis for official de-jure standardisation.


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

Re: Authenticating with AMQP Messenger API

[Gordon Sim]

On 10/09/2013 09:35 PM, Marko Asplund wrote:

Hi,

What's the correct way to authenticate to an AMQP server using the
Messenger API?
I've tried including authentication information in the AMQP address as
described in org.apache.qpid.proton.messenger.Messenger javadoc like this:

amqp://user1:pwd1@127.0.0.1:5672/topic://test.foo


The java version of the messenger API currently only supports ANONYMOUS 
and not PLAIN which would be needed to authenticate with a username and 
password.


There is a JIRA open for that: 
https://issues.apache.org/jira/browse/PROTON-421



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

Re: Qpid AMQP 1.0 - How does it all hang together? - was Re: Qpid Dispatch Router component

[Rob Godfrey]

This is an excellent post which I think highlights the need for us to
properly define the scopes of our current components, their roadmaps, and
the vision we have for Qpid and AMQP 1.0.

I know some people have already replied in thread, but would it seem like a
good idea if we used these questions to help us formulate some sort of
documentation for our site where we can provide answers both to others
looking to get started with the project, but also perhaps to ourselves?

-- Rob


On 9 October 2013 20:22, Fraser Adams  wrote:

> Hey all,
> The thread below on the dev list has prompted me to ask something that
> I've tentatively mentioned before, but am still a bit embarrassed to raise
> 'cause it probably makes me seem a bit stupid :-( here goes anyway.
>
>
> So I've kind of held off going down the AMQP 1.0 path partly due to lack
> of time, but also partly due to lack of understanding of how it "all hangs
> together", the new website helps a bit - but TBH I'm still left scratching
> my head somewhat.
>
> I'll try to explain:
>
> Now I know that Proton is intended to be a component usable beyond just
> the Qpid "product set", but there's a "protocol engine" and a "messenger
> API" and I'm not even that clear on the relationship between the two of
> those - for example could one use the protocol engine completely
> independently (is there an engine API?) or is the messenger API intended to
> be the lowest "unit of currency", what would be the benefit using the raw
> engine?
>
> Then beyond that there's the relationship with say qpidd and
> qpid::messaging. Now I'm aware that when the Proton libraries are detected
> qpidd and qpid::messaging get built with Proton support, I'm "guessing"
> that in that case the relationship analogous to that of qpid::client where
> qpid::client was the low level AMQP speaking API and qpid::messaging
> provides a higher level abstraction, so I *think* that's the relationship
> with Proton there - but I'm not sure? Is the proton API close to the AMQP
> 1.0 specification in say the way that qpid::client was?
>
>
> But then there's more nuance, so I'm aware that with AMQP 1.0 there's a
> more peer-to-peer relationship and indeed the Proton tests seem to have
> msgr-recv and msgr-send talking directly to each other without a broker. So
> that leads me to ask the question what's the relationship with the broker -
> in other words what services are provided in messenger, what are enhanced
> in qpid::messaging and what are layered on top of that via the broker (and
> how does the addressing and routing work?).
>
> Some examples of where I'm befuddled include how does subscription work at
> a peer to peer level? For example I think that exchange nodes are only
> something I've heard discussed in the context of qpidd and similarly I
> think the same is true of message selectors, so does Proton only provide
> low level network connectivity and data serialisation (and possibly single
> client queue) and all the other stuff needed for connecting a network of
> clients are part of the broker services.
>
> I suppose what I'm really asking is what "services" are provided at each
> "layer" of the Qpid "stack" - clearly you can do useful stuff with just
> Proton - but what stuff and what are the limits? What would you then get
> from qpid:messaging and what then does the broker throw into the mix. Are
> there any diagrams that illustrate this sort of relationship?
>
> The dispatch router adds yet more nuance into the mix. From my (limited)
> understanding it seems to offer at least some of the same services as the
> broker - but I'm not quite sure what. In my case I've got a very large
> federated topology and I have lots of left hand systems feeding in to fewer
> systems towards the right. Given that it's only on the right hand side
> broker that I have lots of consumers doing complex subscriptions and the
> rest of the brokers are employing fairly simple queue routes I'm thinking
> that the dispatch router could ultimately be something to "tidy up" the
> left hand side of my system - but I'm not quite sure.
>
> Apologies if these seem silly questions, I'm sure that the answers are
> obvious to those who've been involved at the architectural stages, but
> ultimately from my perspective the overall holistic architecture isn't
> totally clear.
>
> Even at a basic level I've not actually noticed anything in the
> programming book http://qpid.apache.org/**releases/qpid-0.24/**
> programming/book/index.htmlthat
>  seems to mention even how to connect via AMQP 1.0 vice 0.10. I think
> that it has been mentioned on the mailing list by Gordon so I'm sure I
> could dig the info out, but is it missing from the docs (or am I just not
> looking hard enough). On a similar note for Proton the msgr-send and
> msgr-recv examples are fine as far as it goes, but I'm thinking that to
> figure out how to do anything more complex my best 

Re: Qpid Dispatch Router component

[Rob Godfrey]

On 9 October 2013 19:06, Ted Ross  wrote:

> Rob,
>
> These are good points.  Let me start with management.
>
> I view Dispatch as a bit of a testing ground for the emerging AMQP
> Management specification.  I would claim that at this point, the
> specification is not ready for prime-time.  With regard to the address, the
> specification uses "$management".  Perhaps I'm mistaken, but I took that to
> mean "place-holder for an as-yet unspecified literal string".  Clearly
> there needs to be a way to address multiple distinct container agents
> through the same connection or link.  If this is not the case, then it will
> need to be addressed in the technical committee.
>
>
"$management" is meant as a literal.  When you pair this with global
addressing you can define addresses for each of the management nodes in
separate container instances //$management //$management, etc... moreover you may wish to have the management node at
each instance aware of the management nodes of instances to which it is
connected, thus by issuing the discover commands to the management node at
the local router you have connected to you can potentially find all
management nodes in the connected network.


> I've personally been tracking both the management and addressing
> specifications circulating through the technical committee and I expect
> that Dispatch will conform to (and in fact prove out) both specifications.
>  I'm not aware of any other project within Qpid that is implementing the
> management specification (perhaps the Java broker is).
>
>
My main concern is that I believe that Qpid should be primarily directed at
implementing AMQP standards, and building resuable toolkits and components
that fit into any AMQP network.  I'd be very concerned if we were inventing
alternative management protocols, or building components that only
interoperated with other Qpid tools.

So, personally I'd like to see statement around components saying that they
will be fully implementing emerging AMQP Management, AMQP addressing, etc.
standards, and that we as a project then ensure we stick to these goals.


> With regard to interaction with other Qpid and Apache projects, Dispatch
> is already proved interoperable with the Proton Messenger and
> qpid::messaging clients.  It should also be usable as interconnect between
> clients and the Qpid brokers via AMQP 1.0 and between multiple brokers as a
> federation interconnect.  Some experimentation has been done using the
> ActiveMQ broker as well.
>
> With regard to protocols, I would be opposed to trying to implement AMQP
> 0-* due to the asymmetric nature of those protocols.  I do think, however,
> that Dispatch could make a very good platform for an edge concentrator for
> lighter protocols like MQTT.
>
>
I guess what I'm driving at is that it would be good to have a proper
scope/charter statement for each of our "components" that we as a project
had broad agreement on which do restrict us from just dropping anything we
feel like into a component.  I'd like to do that for Dispatch before we
elevate it, and I think we should ensure that we also have such statements
for the JMS client (which I think should be easy) and Proton (which may be
a little trickier).

Cheers,
Rob


> Regards,
>
> -Ted
>
>
> On 10/09/2013 12:20 PM, Rob Godfrey wrote:
>
>> Hi Ted,
>>
>> I think before we make this a full sub project, it would be good to have
>> clarity on exactly the proposed scope of Dispatch, how it is expected to
>> interact with other components within Qpid, or within wider AMQP networks.
>> I think in retrospect we didn't do this clearly enough with Proton (for
>> example).
>>
>> Moreover I would personally like to understand which AMQP standards it
>> will
>> be looking to implement, and which not.  For instance I notice this line
>> in
>> the docs for Dispatch:
>>
>> *Address**Description* /_local/agentThe management agent on the attached
>>
>> router/container. This address would be used by an endpoint that is a
>> management client/console/tool wishing to access management data from the
>> attached container.
>> Which doesn't seem to conform with the proposed management specification
>> for AMQP, nor does the document make any mention of how dispatch is to be
>> managed.
>>
>>
>> Cheers,
>> Rob
>>
>>
>> On 9 October 2013 17:22, Ted Ross  wrote:
>>
>>  The AMQP Router project (Qpid Dispatch, announced previously on the user
>>> list) is gaining in community interest and is nearing the point where a
>>> first release is appropriate. In preparation for a release, I proposethat
>>> this sub-project follow the lead of both Proton and the AMQP1.0 JMS
>>> projects. This involves:
>>>
>>> 1. Moving the code from qpid/extras to
>>> 
>>> http://svn.apache.org/repos/asf/qpid/dispatch
>>> 
>>> >
>>>
>>> ,
>>> 2. Requesting, by vote, the creation of a JIR