Re: Qpid Dispatch Router 0.8.0 Release Candidate 1

[Adel Boutros]

Small correction:


We are using Proton 0.16.0 with only C++ and Python bindings activated.


From: Adel Boutros
Sent: Friday, March 31, 2017 9:55:32 AM
To: users@qpid.apache.org
Subject: Re: Qpid Dispatch Router 0.8.0 Release Candidate 1


Hello Ganesh,


Please find attached the 3 build logs of the dispatch router 0.8.0 on Linux 
(Red Hat 6.4), Solaris x86 and Solaris Sparc.

Please note we are using Proton 0.16.0 with only C++ bindings activated.


PS: The good news is the code compiles on all 3 OSes but it's the tests which 
are failing. We consider this as a big step forward compared to the previous 
versions where the code didn't even compile on Solaris.


Regards,

Adel


From: Ganesh Murthy 
Sent: Thursday, March 30, 2017 3:10:00 PM
To: users@qpid.apache.org
Subject: Re: Qpid Dispatch Router 0.8.0 Release Candidate 1



- Original Message -
> From: "Adel Boutros" 
> To: users@qpid.apache.org
> Sent: Thursday, March 30, 2017 9:04:01 AM
> Subject: Re: Qpid Dispatch Router 0.8.0 Release Candidate 1
>
> I rechecked quickly and I have different behaviors on different OSes.
>
>
> * Linux :
>
Can you please let us know what Linux flavor you are using so we can try 
locally?
> router_policy_test and system_tests_protocol_family failing as stated
> previously
>
Please also send the complete output of the failing tests.
>
> *Solaris:
>
> Only router_policy_test  is failing.
>
> For system_tests_protocol_family, I have the message "Skipping test..IPV6 not
> enabled"
>
>
> We have some other test failures on Solaris and Linux but we will need to
> debug them and we won't have time at the moment for them. I can send you a
> report with the failures if you wish.
>
This is the commit that fixed DISPATCH-216 on master - 
https://github.com/apache/qpid-dispatch/commit/0a60abbf6b06048e1ac7a71a48da82145fa77036
I verified that the above commit is present in the Qpid Dispatch Router 0.8.0 
Release Candidate 1 qpid-dispatch-0.8.0.tar.gz
>
> Regards,
>
> Adel
>
> 
> From: Ted Ross 
> Sent: Thursday, March 30, 2017 2:48:10 PM
> To: users@qpid.apache.org
> Subject: Re: Qpid Dispatch Router 0.8.0 Release Candidate 1
>
> Adel,
>
> The commits associated with that Jira and PR #140 are included in this
> release candidate.  We'll need to investigate whether it regressed again
> or if the commit didn't fix the problem.
>
> -Ted
>
> On 03/30/2017 11:30 AM, Adel Boutros wrote:
> > Hello Ted,
> >
> >
> > I thought the 0.8.0 release included the fixes to ignore IPv6 tests but it
> > doens't seem to be the case. Ganesh was working on fixing those.
> >
> > Do you confirm they are not included?
> > (http://qpid.2158936.n2.nabble.com/Fwd-GitHub-qpid-dispatch-pull-request-140-DISPATCH-216-Added-code-to-skip-system-te-td7658538.html#a7658571)
> >
> >
> > I launched the CI on the release candidate and got the same IPv6 failures
> > as before
> >
> >
> > The following tests FAILED with ipv6 errors:
> > 12 - router_policy_test (Failed)
> > 19 - system_tests_protocol_family (Failed)
> >
> >
> >
> > 12: Test command: /python278/bin/python
> > "/dispatch-workspace/build-dir/qpid-dispatch/tests/run.py" "-m" "unittest"
> > "-v" "router_policy_test"
> > 12: Test timeout computed to be: 1500
> > 12: Run python module 'unittest': PolicyError: u'Policy \'photoserver\' is
> > invalid: Policy vhost \'photoserver\' user group \'superuser\' option
> > \'remoteHosts\' connectionOption \'::1\' failed to translate:
> > \'\'HostStruct: \\\'::1\\\' failed to resolve: \\\'"HostStruct:
> > \\\'::1\\\' did not resolve to one of the supported address
> > family"\\\'\'\'.'
> >
> >
> > 19: error: [Errno 97] Address family not supported by protocol
> >
> >
> > Regards,
> >
> > Adel
> >
> > 
> > From: Ted Ross 
> > Sent: Wednesday, March 29, 2017 1:32:42 PM
> > To: users@qpid.apache.org
> > Subject: Qpid Dispatch Router 0.8.0 Release Candidate 1
> >
> > The first release candidate for Qpid Dispatch Router 0.8.0 is ready for
> > evaluation.
> >
> > Build Artifacts:
> >
> >  https://dist.apache.org/repos/dist/dev/qpid/dispatch/0.8.0-rc1/
> >
> > New Features:
> >
> >  DISPATCH-103 - Websocket Listeners
> >  DISPATCH-195 - Add support for transactional messages in the Router
> >  DISPATCH-441 - Support password environment variable in qdrouter
> >  config
> >  DISPATCH-467 - Terminus renaming for autoLinks
> >  DISPATCH-529 - Address annotation for Multi-Tenancy
> >  DISPATCH-726 - Connection Property for Failover Servers
> >
> > Improvements:
> >
> >  DISPATCH-113 - expose NodeTracker::last_topology_change in management
> >  DISPATCH-542 - Popup text for clients should indicate if the client
> > is a sender or receiver
> >  DISPATCH-543 - Initial load of topology page fetches too much
> > information
> >  DISPATCH-544 - Add ability to hide the info panel on the left of
> > the topology p

Re: [DISCUSS] Migrate Qpid Broker for Java and Qpid JMS AMQP 0-x Client from SVN to GIT

[Rob Godfrey]

On 30 March 2017 at 12:32, Lorenz Quack  wrote:

> +1 on the migration to git.
>
> Regarding the name of the broker's git repo:
>  * qpid-broker: I agree with others that this might lead to confusions
>with the cpp broker.
>  * qpid-java-broker: I am worried that legal will not be happy with this
>since Java is a trademark. See [1] and [2].
>  * This leaves qpid-broker-for-java and qpid-broker-j.
> Between those two I favour qpid-broker-for-java since that is what was
> decided in [1].  I agree that it is a bit wordy but we won't have to
> type it a lot and it is consistent with the other usages like
> documentation and representation on the web page.
>
>
So my view here is that "Qpid Broker for Java" is essentially the wrong
name in every context :-)  The fact that the Broker is written in Java is
really incidental to its function and unless you are looking at deploying
on a platform that doesn't support Java, it really shouldn't make any
difference to an end user. personally I would have gone for qpidj-broker or
qpid-broker-j for the product name and the repo name.

On the legal concerns, I don't see why the git repo name would be different
from a legal standpoint to the maven artefact names... if we believe that
the git repo name is an issue then we should also be changing the maven
names... and again I would think that "qpid-broker-for-java" would be a
stupid maven artefact name too :-)

-- Rob


> Kind regards,
> Lorenz
>
> [1] https://issues.apache.org/jira/browse/QPID-7341
> [2] http://qpid.2158936.n2.nabble.com/Apache-Qpid-Java-naming-co
> ncerns-td7648059.html
>
>
>
> On 30/03/17 11:12, Oleksandr Rudyy wrote:
>
>> +1 for migration from svn to git
>>
>> I would use qpid-java-broker as a name for the repo, as it is a bit
>> shorter
>> than qpid-broker-for-java.
>> I'd also be Ok with 'qpid-broker-for-java'  as a name for the repo. In
>> general I prefer full names over the abbreviations or truncations of the
>> words. Mixing abbreviation with full words looks a bit unusual to me.
>> Thus,
>> I would vote against 'qpid-broker-j'.
>>
>> Kind Regards,
>> Alex
>>
>> On 27 March 2017 at 14:15, Justin Ross  wrote:
>>
>> I like qpid-broker-j best of the alternatives proposed.  I think
>>> qpid-broker alone will cause a little confusion.
>>>
>>> On Mon, Mar 27, 2017 at 3:41 AM, Rob Godfrey 
>>> wrote:
>>>
>>> On 27 March 2017 at 12:35, Robbie Gemmell 
 wrote:

 On 27 March 2017 at 10:47, Rob Godfrey 
>
 wrote:
>>>
 On 27 March 2017 at 11:31, Keith W  wrote:
>>
>> Hi all
>>>
>>> Now the Qpid Broker for Java and Qpid JMS AMQP 0-x Client are
>>> separated [1]/[2], I'd like to propose the final two remaining Qpid
>>> components are migrated from SVN to GIT.
>>>
>>> * Qpid Broker for Java
>>> * Qpid JMS AMQP 0-x Client
>>>
>>> This will give us a consistent, Git based, version control approach
>>> across the whole project and therefore a simpler 'getting involved'
>>> story that should benefit the community as a whole.
>>>
>>> The source code migration will maintain source code history,
>>>
>> including
>>>
 existing release branches and tags made since r1673693/QPID-6481 [3]
>>>
>>> The intention would be for all future releases to be made from git.
>>> This would include any future maintenance releases from 6.0.x and
>>> 6.1.x (which would remain combined broker/client releases).
>>>
>>> Qpid Broker for Java:
>>>
>>> Current SVN location: https://svn.apache.org/repos/asf/qpid/java/
>>> Proposed GIT repo: git://git.apache.org/qpid-broker
>>> -for-java.git
>>> 
>>>
>>
>>
>> Do we have to make the repo name quite so wordy? :-) git://
>> git.apache.org/qpid-broker.git would work for me.
>>
>>
>>
>>> The existing GIT mirror at git://git.apache.org/qpid-java.git would
>>>
>> cease.
>
>> Qpid JMS AMQP 0-x Client:
>>>
>>> Current SVN location: https://svn.apache.org/repos/
>>> asf/qpid/qpid-jms-amqp-0-x/
>>> Proposed GIT repo: git://git.apache.org/qpid-jms-amqp-0-x.git
>>>
>>> The existing GIT mirror at git://git.apache.org/qpid-jms-
>>>
>> amqp-0-x.git
>>>
 would become the 'live' repo..
>>>
>>> Thoughts?
>>>
>>> No objections on the client side, and OK on the broker side with the
>> proviso that I'd prefer a shorter repo name :-)
>>
>> -- Rob
>>
>>
>> [1] http://qpid.2158936.n2.nabble.com/DISCUSS-Drop-the-AMQP-0-x-
>>> client-from-the-Qpid-for-Java-7-0-release-td7657770.html
>>> [2] https://issues.apache.org/jira/browse/QPID-7622
>>> [3] https://issues.apache.org/jira/browse/QPID-6481
>>>
>>>
> I'm also not hugely fond of 'qpid-broker-for-java' as a repo name.
> Using only 'qpid-broker' doesn't necessarily do a great job of

RE: Accessing queues with '/' in name in Rest API [qpid java broker 6.0.4]

[Antoine Chevin]

Hello Rob,

Olivier and I re-checked the global address domain feature and it seems it
does not resolve the global addresses correctly.
When I create the queue 'queueA' on the broker and I set the
globalAddressDomains to '/domain/subdomain', and then I register a listener
with JMS for the queue '/domain/subdomain/queueA' I get an 'amqp-not-found'.
Is this expected?

When I told you it worked, I think I had a zombie queue
'/domain/subdomain/queueA' from my previous attempt to use '/' in queue
names that made it "work" :-(.

Thank you,
Regards,
Antoine

-Original Message-
From: Rob Godfrey [mailto:rob.j.godf...@gmail.com]
Sent: jeudi 2 mars 2017 16:07
To: users@qpid.apache.org
Subject: Re: Accessing queues with '/' in name in Rest API [qpid java
broker 6.0.4]

On 2 March 2017 at 15:11, Antoine Chevin  wrote:

> Thank you Rob for the very detailed answer.
> I saw in the code
> (org.apache.qpid.server.protocol.v1_0.Session_1_0#remoteLinkCreation)t
> hat the exchange lookup is skipped if the address starts with a '/'.
> I intend to use a '/' in the beginning because I don't want the
> exchange lookup.
> Do you think it is a good approach?
>
>
So the intent here is that addresses that start with "/" are considered to
be "global" addresses as previously described, addresses that start with
"/" but match one of the gloabAddressDomains for the virtual host would
route within the virtual host to the appropriate destination, names that
begin with "/" but don't match one of the domains for the vhost would be
sent via federation to a remote broker (when that code gets completed -
obviously we don't have federation of that kind in the Java Broker
currently).

So having a name which begins with "/" may work right now, but it's
reasonably likely it might break in the future.  In general I would avoid
"/" as well as "?", ";", ",", "[", "]", "|", "(", and ")" in queue names.

Is the plan that all your queues will start with the same //...
prefix, or will different queues have different prefixes?

-- Rob


> Thank you,
> Regards,
> Antoine
>
> -Original Message-
> From: Rob Godfrey [mailto:rob.j.godf...@gmail.com]
> Sent: jeudi 2 mars 2017 11:09
> To: users@qpid.apache.org
> Subject: Re: Accessing queues with '/' in name in Rest API [qpid java
> broker 6.0.4]
>
> On 2 March 2017 at 10:46, Antoine Chevin  wrote:
>
> > Thank you Rob for the answer. Yes it really helps!
> > I noticed that addresses in the form /
> > are also used with AMQP 1-0. Is it expected?
> >
> >
> It is part of how the Java Broker maps the AMQP 0-x
> Exchange/Binding/Queue model into the AMQP 1.0 address space, yes.
>
> In short when the Java Broker receives a message to an address X it
> first looks to see if there is an exchange X, then if there is a queue
> X, then if X contains a / it looks to see if the part before the / is
> an exchange name, and if so it sends to that exchange with the part
> after the / being used as the routing key.
>
> When the Java Broker receives a request to consume from an address X
> it first looks to see if there is a Queue X, then if there is an
> Exchange X (in which case it creates a temporary queue and binds with
> an empty binding key), and then if X contains a / and the part before
> the X is an exchange name it will create a temporary queue and bind
> that to the exchange with the binding key being the part of X after the /.
>
> Note the asymmetry on send and consume that on send it first looks for
> an exchange and on consume it first looks for a queue.
>
> (There are a few more rules for the globalAddressDomains and for
> system addresses like $management, but the above is the general rule).
>
> -- Rob
>
>
> > Thank you,
> > Regards,
> > Antoine
> >
> > On 1 March 2017 at 20:25, Olivier Mallassi
> > 
> > wrote:
> >
> > > Rob, all
> > >
> > > Thank you rob for this. Could you please share more details
> > > regarding not using the "/"?
> > >
> > >
> > So there are a couple of reasons why I think not using a / makes sense:
> >
> > 1) Because of exactly the REST / encoding issue that you ran into -
> > using characters that often need escaping can cause a lot of issues
> > in config files, parameters etc...  depending upon where the queue
> > name might be used you may end up encoding that / one, two or even
> > more times... this gets messy fast
> >
> > 2) Because in AMQP addressing we've been imaging the / as a
> > separator when using some sort of topological address scheme for
> > addressing in federated networks... for instance you might have a
> > queue for orders in you dongle department of your widget division of
> > your company foo.com... and you might expose that address as
> > //foo.com/widget/dongle/orders  whereas someone connected directly
> > to
> the
> broker would just see the queue as "orders"
> > (though they could also address it by its full "global" name).  The
> > Java Broker already makes some allowance for this with the notion of
> > "globalAddressDomains" which you can set on

Enabling AMQP 1.0 on Qpid C++ Broker

[mottese]

Hi, I have a Qpid JMS (1.11.1) client trying to connect to a Qpid C++
(1.36.0) broker. I recently recompiled my qpid broker alongside Qpid Proton
and saw the message that AMQP 1.0 support was enabled. When my client tried
to connect, they kept getting a "transport connection remotely closed"
message. I did some more reading and found in the qpid-cpp repo's
docs/amqp-1.0.txt:

To enable 1.0 support in qpidd, the amqp module must be loaded. This
allows the broker to recognise the 1.0 protocol header alongside the
0-10 one. If installed, the module directory should be configured such
that this happens automatically. If not, use the --load-module option
and point to the amqp.so module.

I looked around the qpid-cpp and qpid-proton source, build, install
directories and was never able to find an amqp.so. It seems that I need this
for AMQP 1.0 support to be enabled on the broker. Do you know where I'd find
this?

Max



--
View this message in context: 
http://qpid.2158936.n2.nabble.com/Enabling-AMQP-1-0-on-Qpid-C-Broker-tp7661828.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: Enabling AMQP 1.0 on Qpid C++ Broker

[Jakub Scholz]

I think that might depend on the OS etc. In my build on CentOS 7 it is in
/usr/lib64/qpid/daemon/ ...

$ ls /usr/lib64/qpid/daemon/
amqp.so  linearstore.so  xml.so

When the module is loaded, the broker log should print following message
when starting:
2017-03-31 18:23:12 [Broker] info Loaded protocol AMQP 1.0

Thanks & Regards
Jakub

On Fri, Mar 31, 2017 at 8:14 PM, mottese  wrote:

> around the qpid-cpp and qpid-proton source, build, install
> directories and was never able to find an amqp.so. It seems that I need
> this
> for AMQP 1.0 support to be enabled on the broker. Do you know where I'd
>

RE: [EXTERNAL] Re: Enabling AMQP 1.0 on Qpid C++ Broker

[mottese]

Hmm. I'm on RHEL5 (sadly. We're upgrading to 7 soon). And in my [install 
location]/lib64/qpid/daemon I only have an ha.so and store.so. I also am not 
seeing that log message. I'm not sure why I would see that amqp 1.0 was enabled 
when doing the cmake command but then not be able to find this library.

Max

From: Jakub Scholz-2 [via Qpid] 
[mailto:ml-node+s2158936n7661829...@n2.nabble.com]
Sent: Friday, March 31, 2017 12:26 PM
To: Ottesen, Max 
Subject: [EXTERNAL] Re: Enabling AMQP 1.0 on Qpid C++ Broker

I think that might depend on the OS etc. In my build on CentOS 7 it is in
/usr/lib64/qpid/daemon/ ...

$ ls /usr/lib64/qpid/daemon/
amqp.so  linearstore.so  xml.so

When the module is loaded, the broker log should print following message
when starting:
2017-03-31 18:23:12 [Broker] info Loaded protocol AMQP 1.0

Thanks & Regards
Jakub

On Fri, Mar 31, 2017 at 8:14 PM, mottese <[hidden 
email]> wrote:

> around the qpid-cpp and qpid-proton source, build, install
> directories and was never able to find an amqp.so. It seems that I need
> this
> for AMQP 1.0 support to be enabled on the broker. Do you know where I'd
>


If you reply to this email, your message will be added to the discussion below:
http://qpid.2158936.n2.nabble.com/Enabling-AMQP-1-0-on-Qpid-C-Broker-tp7661828p7661829.html
To unsubscribe from Enabling AMQP 1.0 on Qpid C++ Broker, click 
here.
NAML




--
View this message in context: 
http://qpid.2158936.n2.nabble.com/Enabling-AMQP-1-0-on-Qpid-C-Broker-tp7661828p7661830.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.

can somebody help explain on_sendable and threading (qpid-proton / C++)?

[Daniel Pocock]

Hi all,

I came across a discussion about on_sendable[1] only being called once.
This is what I had observed creating my own application.  Usually, the
first time on_sendable is called, my application doesn't have any
messages to send (there is a data structure in RAM, populated from
another thread) to the on_sendable method just returns without doing
anything and the container never calls it again.

To work around that, I just let the other thread call the
proton::sender::send() method directly whenever it has a message.  Is
that a valid solution, or should the proton::sender::send() method only
be called in the same thread as the container?

Could anybody annotate the API docs to indicate which methods are
considered thread safe?

If it is not wise to call proton::sender::send() from other threads, how
do I tell the container thread to call on_sendable() from time to time
to check if there are new messages to be sent?

Regards,

Daniel



1.
http://qpid.2158936.n2.nabble.com/Proton-Python-on-sendable-behavior-td7652138.html

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

Logging ThreadId in Java broker logs

[Ramayan Tiwari]

Hi All,

After looking logback's PatternLayout, I don't think its possible to log
thread id by simply supplying a pattern for it. Has anyone looked into ways
to achieve it?

I would like to have thread ids in the log lines as well, since it appears
to be me that same thread name gets assigned for multiple threads (eg,
housekeeping task). Please correct me if that is not the case.

Thanks
Ramayan

RE: [EXTERNAL] Re: Enabling AMQP 1.0 on Qpid C++ Broker

[mottese]

I ended up figuring it out. Even though I build qpid-cpp-1.36.0 after proton, 
for some reason in the CMakeCache.txt file, it had BUILD_AMQP:BOOL=OFF. I 
switched that to ON and now everything is working great.

Max

From: Jakub Scholz-2 [via Qpid] 
[mailto:ml-node+s2158936n7661829...@n2.nabble.com]
Sent: Friday, March 31, 2017 12:26 PM
To: Ottesen, Max 
Subject: [EXTERNAL] Re: Enabling AMQP 1.0 on Qpid C++ Broker

I think that might depend on the OS etc. In my build on CentOS 7 it is in
/usr/lib64/qpid/daemon/ ...

$ ls /usr/lib64/qpid/daemon/
amqp.so  linearstore.so  xml.so

When the module is loaded, the broker log should print following message
when starting:
2017-03-31 18:23:12 [Broker] info Loaded protocol AMQP 1.0

Thanks & Regards
Jakub

On Fri, Mar 31, 2017 at 8:14 PM, mottese <[hidden 
email]> wrote:

> around the qpid-cpp and qpid-proton source, build, install
> directories and was never able to find an amqp.so. It seems that I need
> this
> for AMQP 1.0 support to be enabled on the broker. Do you know where I'd
>


If you reply to this email, your message will be added to the discussion below:
http://qpid.2158936.n2.nabble.com/Enabling-AMQP-1-0-on-Qpid-C-Broker-tp7661828p7661829.html
To unsubscribe from Enabling AMQP 1.0 on Qpid C++ Broker, click 
here.
NAML




--
View this message in context: 
http://qpid.2158936.n2.nabble.com/Enabling-AMQP-1-0-on-Qpid-C-Broker-tp7661828p7661833.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.