Re: [qpid-proton-cpp] default_container does not implement thread safety at all?

[Adel Boutros]

Hello,

As Alan said, we have for example "abused" the schedule in C++. Today we run 
the container on another thread and we have a shared queue between the 
container threads and the other threads. We call schedule very frequently with 
a delay of 0. Whenever the container thread wakes, it checks the queue to send 
events then calls schedule again. The access to the queue is protected by locks.

The downside is that the container thread abuses a full CPU but we can limit 
this by using a delay of higher than 0 on schedule.

Regards,
Adel


From: Alan Conway 
Sent: Wednesday, March 15, 2017 10:51:24 PM
To: users@qpid.apache.org
Subject: Re: [qpid-proton-cpp] default_container does not implement thread 
safety at all?

On Tue, 2017-03-14 at 01:23 +0200, Fj wrote:
> Hello, I'm mightily confused.
>
> There's
> https://qpid.apache.org/releases/qpid-proton-0.17.0/proton/cpp/api/md
> _mt.html
> that says in no uncertain terms that I can use event_loop.inject() to
> execute a callback on the thread that runs the event loop. There's an
> examples/cpp/mt/broker.cpp linked from the above that's supposed to
> be a
> thread safe implementation of a thread pool running a bunch of
> containers.
>
> But after "grep inject" and carefully sifting through the results, it
> seems
> that after some indirection it all ends up calling
>
> // FIXME aconway 2016-06-07: this is not thread safe. It is
> sufficient for
> using
> // default_container::schedule() inside a handler but not for
> inject() from
> // another thread.
> bool event_loop::impl::inject(void_function0& f) {
> try { f(); } catch(...) {}
> return true;
> }
>
> What the hell? Blank exception suppression is just the icing on the
> cake,
> nothing here even resembles doing the actual hard thing: telling the
> reactor to inject a new custom event in a threadsafe manner.

Guilty as charged mlud. This was work in progress when we started to
redo the guts in a more profound way. The Real Thing is coming - it is
available in C now as pn_proactor and the C++ binding is being
refactored on top of it.

> Am I missing something obvious, or is the documentation there, and in
> other
> places, and the example, chemically pure wishful thinking, like, it
> would
> be pretty nice if we supported multithreading, and it would work in
> such
> and such ways then, but unfortunately we don't, as a matter of fact?

The state of the release is probably not clearly documented: the C++ MT
interfaces *allow* you to build an MT app that replaces the
proton::container (as demoed in the mt_broker) BUT the
proton::container itself is still not multithreaded. It has a
compatible API because it will be in future.

> If so, maybe you gals and guys should fix the documentation, and not
> just
> with "experimental" but with "DOESN'T WORK AT ALL" prominent on the
> page?

I agree the doc is not clear, next release it should work as expected
an not as obscurely caveatted.

> On more constructive notes:
>
> 1) do people maybe use some custom containers, similar to the
> epoll_container in the examples (which doesn't support schedule()
> though, I
> have to point out)? If so, I much desire to see one.

Yes, but the plan is to fix the non-custom container to be fully
thread-safe so you don't have to unless you have special needs. You can
also implement directly in C if you have very special needs.

> 2) why do you attempt to bolt on your event_loop thing to Connection
> and
> below when the only thing that has the run() method is Container,
> therefore
> that's the scope that any worker thread would have? It's the
> Container that
> should have the inject() method. Underlying C API notwithstanding.

Nope: the threading model is seralized-per-connection, so functions
that operate only on connection state and are triggered from an event
handler don't need to be locked. Only interactions that cross
connections (e.g. one connection queues something a subscriber on
another connection needs to wake up) need sync. This is demonstrated
with the mt_broker stuff. That's why injecting is per-connection.

> 3) What's the best way forward if I really have to have a threadsafe
> container that I can inject some event into threadsafely:

The example demonstrates how you can do it, but is incomplete as you
point out. Soon it will be built in.

>   3a) does the C API support thread safety? Like, the whole problem
> is
> touching the reactor's job queue or whatever it has with taking an
> appropriate lock, and it must take that same lock itself for it to
> work.

It does now, see the pn_proactor, there are examples. The C reactor is
fundamentally and forever thread-unsafe and horribly broken in all ways
with respect to concurrency. We started to introduce MT at the C++
layer and work around the reactor - proton::container lagged because it
is so tied to the reactor.

Finally we decided to replace the pn_reactor entirely with the
pn_proactor in C - this is 

Re: [qpid-proton-cpp] default_container does not implement thread safety at all?

[Alan Conway]

On Tue, 2017-03-14 at 01:23 +0200, Fj wrote:
> Hello, I'm mightily confused.
> 
> There's
> https://qpid.apache.org/releases/qpid-proton-0.17.0/proton/cpp/api/md
> _mt.html
> that says in no uncertain terms that I can use event_loop.inject() to
> execute a callback on the thread that runs the event loop. There's an
> examples/cpp/mt/broker.cpp linked from the above that's supposed to
> be a
> thread safe implementation of a thread pool running a bunch of
> containers.
> 
> But after "grep inject" and carefully sifting through the results, it
> seems
> that after some indirection it all ends up calling
> 
> // FIXME aconway 2016-06-07: this is not thread safe. It is
> sufficient for
> using
> // default_container::schedule() inside a handler but not for
> inject() from
> // another thread.
> bool event_loop::impl::inject(void_function0& f) {
> try { f(); } catch(...) {}
> return true;
> }
> 
> What the hell? Blank exception suppression is just the icing on the
> cake,
> nothing here even resembles doing the actual hard thing: telling the
> reactor to inject a new custom event in a threadsafe manner.

Guilty as charged mlud. This was work in progress when we started to
redo the guts in a more profound way. The Real Thing is coming - it is
available in C now as pn_proactor and the C++ binding is being
refactored on top of it.

> Am I missing something obvious, or is the documentation there, and in
> other
> places, and the example, chemically pure wishful thinking, like, it
> would
> be pretty nice if we supported multithreading, and it would work in
> such
> and such ways then, but unfortunately we don't, as a matter of fact?

The state of the release is probably not clearly documented: the C++ MT
interfaces *allow* you to build an MT app that replaces the
proton::container (as demoed in the mt_broker) BUT the
proton::container itself is still not multithreaded. It has a
compatible API because it will be in future.

> If so, maybe you gals and guys should fix the documentation, and not
> just
> with "experimental" but with "DOESN'T WORK AT ALL" prominent on the
> page?

I agree the doc is not clear, next release it should work as expected
an not as obscurely caveatted.

> On more constructive notes:
> 
> 1) do people maybe use some custom containers, similar to the
> epoll_container in the examples (which doesn't support schedule()
> though, I
> have to point out)? If so, I much desire to see one.

Yes, but the plan is to fix the non-custom container to be fully
thread-safe so you don't have to unless you have special needs. You can
also implement directly in C if you have very special needs.

> 2) why do you attempt to bolt on your event_loop thing to Connection
> and
> below when the only thing that has the run() method is Container,
> therefore
> that's the scope that any worker thread would have? It's the
> Container that
> should have the inject() method. Underlying C API notwithstanding.

Nope: the threading model is seralized-per-connection, so functions
that operate only on connection state and are triggered from an event
handler don't need to be locked. Only interactions that cross
connections (e.g. one connection queues something a subscriber on
another connection needs to wake up) need sync. This is demonstrated
with the mt_broker stuff. That's why injecting is per-connection.

> 3) What's the best way forward if I really have to have a threadsafe
> container that I can inject some event into threadsafely:

The example demonstrates how you can do it, but is incomplete as you
point out. Soon it will be built in.

>   3a) does the C API support thread safety? Like, the whole problem
> is
> touching the reactor's job queue or whatever it has with taking an
> appropriate lock, and it must take that same lock itself for it to
> work.

It does now, see the pn_proactor, there are examples. The C reactor is
fundamentally and forever thread-unsafe and horribly broken in all ways
with respect to concurrency. We started to introduce MT at the C++
layer and work around the reactor - proton::container lagged because it
is so tied to the reactor. 

Finally we decided to replace the pn_reactor entirely with the
pn_proactor in C - this is designed to be concurrent and provide for
replaceable IO. At this point the proactor exists and has initial
implementations (libuv done, native iocp + epoll nearly so) but we are
still working on replacing the reactor. It's been a big job.

> 
>   3b) I checked out the Python API, they use a mock EventInjector
> pollable
> thingie instead of reaching inside the reactor and telling it add an
> event.

Yep, the python API is due for an overhaul also but works for now as
far as python threads are concerned. Ruby likewise. 

>   3c) epoll example does yet another thing apparently (though I'm not
> sure
> it works because it's not covered by any tests): just tell the
> reactor to
> wake up and process the queued job list in your handler.

The reactor is a dead-end threading 

Re: [VOTE] Release Qpid for Java 6.1.2 (RC1)

[Oleksandr Rudyy]

+1

I performed the following testing of Qpid for Java 6.1.2:
* started the broker
* using Web Management Console created test queues, ACL provider, etc
* ran successfully Hello and Spout/Drain examples using Legacy JMS
Client for AMQP 0.x of version 6.1.2 against the broker
* created test JMS application using Qpid JMS Client of version 0.21
and successfully published and consumed messages from the broker

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

[VOTE] Release Qpid for Java 6.1.2 (RC1)

[Oleksandr Rudyy]

Hi everyone,

The release candidate version 6.1.2 of Qpid for Java is built and
available from dev staging repos.
Please, test it and vote accordingly.

The list of changes can be found in Jira:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20QPID%20AND%20fixVersion%20%3D%20qpid-java-6.1.2

The source and binary bundles can be downloaded from here:
https://dist.apache.org/repos/dist/dev/qpid/java/6.1.2-rc1

The maven release artifacts are staged at:
https://repository.apache.org/content/repositories/orgapacheqpid-1103

For testing of release artifacts using maven please add the staging
repo into maven project pom.xml:



  staging
  
https://repository.apache.org/content/repositories/orgapacheqpid-1103



Kind regards,
Alex

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

Re: [Java Broker] Port 0 range

[Rob Godfrey]

On 14 March 2017 at 17:47, Adel Boutros  wrote:

> Hello Rob,
>
>
> I think I wasn't clear enough. Sorry for that.
>
>
> As referenced here[1], there are registered ports which are dynamic ports
> however they identify a know service (5672 is one of them).
>
> What I am talking about are private dynamic ports (ephemeral ports) which
> are not registered and to be used internally.
>
>
> As this is not a requirement useful for all users of the Broker, I was
> wondering if there was a way to specify a certain port range for the broker
> to get an available port from it and which is a lot more restrictive than
> the full dynamic range.
>


I understood your original question I think :-)  You want to restrict which
ports are allocated from when you pass in "0" as the service port number.
As per my original answer, Qpid (or rather the JVM) simply uses the
operating system to choose the port.  The operating system is configured
with a particular port range to pick the ephemeral port from... so I think
this is something you would want to configure in your OS rather than in the
broker.  If the broker on your operating system is allowing ports which you
believe should be restricted to well known services you should double check
the operating system configuration.  If the OS configuration looks correct,
but the broker is allocating outside of that range then that would be
interesting.

-- Rob


>
> [1]: https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers
>
>
> 
> From: Rob Godfrey 
> Sent: Tuesday, March 14, 2017 5:25:56 PM
> To: users@qpid.apache.org
> Subject: Re: [Java Broker] Port 0 range
>
> So, the Broker is simply using the Java mechanism... and the Java mechanism
> is (I presume) just obeying the settings in your operating system.  Which
> operating system are you seeing the broker pick "low" ports on, and how is
> that operating system configured with respect to the "dynamic" port
> range[1]?  What sort of "low" numbers are you getting... which operating
> system are you seeing this on... and does the port number you are seeing
> lay outside the OS settings for dynamic port assignment?
>
> -- Rob
>
> [1] According to this (
> http://stackoverflow.com/questions/913501/how-to-let-
> kernel-choose-a-port-number-in-the-range-1024-5000-in-tcp-socket-pr)
> StackOverflow question, the following commands can be used to get the
> operating system settings:
>
> Linux:
>   cat /proc/sys/net/ipv4/ip_local_port_range
> Windows:
>   netsh int ipv4 show dynamicport tcp
> OS X:
>   sysctl net.inet.ip.portrange.first net.inet.ip.portrange.last
> Solaris:
>   /usr/sbin/ndd /dev/tcp tcp_smallest_anon_port tcp_largest_anon_port
>
> On 14 March 2017 at 16:56, Adel Boutros  wrote:
>
> > Hello,
> >
> >
> > We are asked to deploy broker on random ports. So we thought about using
> > Port 0 and let the Broker find available ports.
> >
> > This works as expected however we have a concern with the port range.
> >
> >
> > It seems by default Java will take any port outside the well known ports
> > and assign it. However, in large environments, services are requested to
> > use private/dynamic ports (range 49152 to 65535 as specified by the
> > Internet Assigned Numbers Authority).
> >
> >
> > So I was wondering if there was a way to make the broker respect this
> port
> > range when it is passed a port value of 0?
> >
> >
> > Maybe allow the user to pass a property defining the range of ports
> > available.
> >
> >
> > What do you think?
> >
> >
> > Regards,
> >
> > Adel
> >
>

[ANNOUNCE] Apache Qpid JMS 0.21.0 released

[Robbie Gemmell]

The Apache Qpid (http://qpid.apache.org) community is pleased to
announce the immediate availability of Apache Qpid JMS 0.21.0.

This is the latest release of our newer JMS client supporting the
Advanced Message Queuing Protocol 1.0 (AMQP 1.0, ISO/IEC 19464,
http://www.amqp.org), based around the Apache Qpid Proton protocol
engine and implementing the AMQP JMS Mapping as it evolves at OASIS.

The release is available now from our website:
http://qpid.apache.org/download.html

Binaries are also available via Maven Central:
http://qpid.apache.org/maven.html

Release notes can be found at:
http://qpid.apache.org/releases/qpid-jms-0.21.0/release-notes.html

Thanks to all involved,
Robbie

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

Re: [Java Broker 6.1.1, qpid-jms-client 0.20.0] Best match for SASL auth was: null

[Rob Godfrey]

On 15 March 2017 at 03:30, Dan Langford  wrote:

> Thanks for the heads up. On our other Qpid install we have played with this
> .Net library https://github.com/Azure/amqpnetlite/blob/master/README.md
> which only supports PLAIN, EXTERNAL, and ANONYMOUS. I also know we did a
> NodeJS POC with the noodledrenzy library which looks like it also only
> supports PLAIN and ANONYMOUS
> https://github.com/noodlefrenzy/node-amqp10/blob/master/lib/sasl.js
>
> Couple questions: what libraries are people using for .Net and nodejs
> connections?

Also since I am now doing everything over SSL, even local Dev,
> will the broker allow the PLAIN sasl mechanism against the SCRAM-SHA-256
> Auth Provider?


Yes - when using SSL the SCRAM-SHA-256 auth provider will offer the PLAIN
mechanism, so pretty much every client should work.

-- Rob


> Or am I misunderstanding the relationship between a SASL
> Mechanism and an Auth Provider?
>
> As always thanks for your time
>
> On Sat, Mar 11, 2017 at 4:07 PM Rob Godfrey 
> wrote:
>
> On 11 March 2017 at 22:35, Dan Langford  wrote:
>
> > thanks for explaining this all to me. i could swear that SCRAM-SHA-256
> was
> > giving me the error, but like you i tried to reproduce it again and could
> > not. i must have tested poorly, not waited for some settings to take
> effect
> > or was looking at prior results. sorry to take up your time. It does seem
> > to be working as i would expect it.
> >
> > i did notice that many of the methods where deprecated which is why i was
> > leaning towards the SCRAM-SHA-256. which Auth Provider would you say is
> the
> > most secure and permits me to manage users and store passwords LOCALLY,
> > within qpid?
> >
> >
> Of the available methods in the Java Broker, SCRAM-SHA-256 is the one I
> would recommend if you want the broker to manage the users/passwords
> yourself and store them through the broker.  One consideration is that some
> of the non-Java clients don't support SCRAM-SHA-256 because they use the
> Cyrus SASL libraries, which only support SCRAM-SHA-1.  If you plan to use
> any of those clients then I'd suggest SCRAM-SHA-1.
>
>
> > I also am seeing so many things that behave differently or just don't
> work
> > if there is not SSL involved.
>
>
> The broker deliberately doesn't allow plain text passwords over non-TLS
> connections (unless you explicitly disable these protections).
>
>
> > I think this is great. for local DEV and POC
> > work self signed certs can be annoying. So i dug around a little and
> > realized i can use a self signed cert that QPID made for me and just
> > include "transport.trustAll=true" in my connection string. this will give
> > me a little more confidence that i am working towards a desired set up
> full
> > of SSL even though im stuck using self-signed this early in our dev.
> >
>
> I'd certainly encourage using SSL/TLS in all environments.  We included the
> auto-generating self-signed key store for precisely this purpose, to allow
> TLS to be configured in dev environments without having to procure a
> certificate authority.
>
> -- Rob
>
>
> >
> > thanks
> >
> > On Sat, Mar 11, 2017 at 6:44 AM Robbie Gemmell  >
> > wrote:
> >
> > > Hi Dan,
> > >
> > > The client will emit the below if it either fails to find a matching
> > > SASL mechanism that both it and the server support, or if it isn't
> > > able to use any of the offered mechanisms because the avaialble
> > > credentials don't allow (e.g FOO etc mechs are offered and need a
> > > user/pass, but none was given).
> > >
> > > By default the Java broker doesnt offer the PLAIN mechanism, even if
> > > the given authentication provider supports it, unless the port is
> > > using SSL. You can change this (more below), but in this case you
> > > probably shouldnt, and so another mechanism must be used instead.
> > >
> > > For the Base64MD5PasswordFile AuthenticationProvider, without SSL or
> > > the config to override the related behaviour then the broker only
> > > offers some custom CRAM-MD5-HASHED and CRAM-MD5-HEX mechanisms. None
> > > of the AMQP 1.0 clients support these old custom mechs, so the
> > > connection attempt failed because the client couldn't find an
> > > agreeable mechanism to use. This is the first reason it wont work with
> > > this auth provider currently, another coming later. Use of this auth
> > > provider isn't really advised however, and per the docs is considered
> > > deprecated:
> > > http://qpid.apache.org/releases/qpid-java-6.1.1/java-
> > broker/book/Java-Broker-Security.html
> > > .
> > >
> > > For the SCRAM-SHA-256 provider, it only offers SCRAM-SHA-256 by
> > > default unless you use SSL or override the related behaviour to allow
> > > PLAIN. I was able to get this provider working without issue, since
> > > the client does support that mech. If I defined a user for the
> > > provider and used it, the connection succeeded, if I