Re: Meaning of http: yes in qdrouterd.conf

[Gordon Sim]

On 29/05/17 19:12, Alan Conway wrote:

On Mon, 2017-05-29 at 16:03 +0200, Jiri Danek wrote:

Hello, I've added http: yes to the listener in the default broker
config.
So my only listener on the router looks like this

listener {
   host: 0.0.0.0
   port: amqp
   authenticatePeer: no
   saslMechanisms: ANONYMOUS
   http: yes
}

I am now unable to connect with qdstat to the broker


http:yes means listen for HTTP/AMQP-over-websockets connections, not
normal AMQP. You can connect to the port with a web browser to see the
dispatch router management console.

We don't (yet) support automatic detection of AMQP vs. HTTP protcols so
if you use http:yes, that port will only act as a HTTP server port, it
won't accept normal AMQP connections.


Perhaps it would be clearer to set the 'role' of the listener to 'http' 
(instead of 'normal')? That way you realise that you need a separate 
listener.


(If and when there is some detection of protocols, then a 'protocols' 
option listing those enabled could be added).



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

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

[Alan Conway]

On Fri, 2017-05-26 at 03:06 +0300, Fj wrote:
> By the way, if anyone is interested, as a stop-gap solution I ended
> up just
> implementing a timer-based callback reenqueuing itself every 50ms and
> pulling callbacks from a properly synchronized queue and executing
> them on
> the worker thread. It's not even that bad performance-wise, it just
> adds
> those 50/2 ms of latency on average.

That's the right workaround. The new C++ API has thread-safe work-
queues that will allow you to have a function executed in the proper
context which will be more efficient and more flexible than using the
timer callbacks. Behind the scenes it uses whatever is efficient on the
underlying IO platform (linux eventfds, libuv async_send etc.) to do
the wakeup.
 
> 
> A better solution would be to do the same thing the Python binding
> does,
> expose a Selectable interface and use it to wake up the reactor
> thread.
> 
> And by the way there's a thing that you might want to consider:
> there's a
> bunch of use cases that don't need inter-thread synchronization, for
> example, single-threaded workers, or multi-threaded workers that only
> need
> to know when to stop and they know it from the socket being closed.
> In
> those cases exposing a thread-safe Container.inject(callback) is a
> total
> waste, because it means that everything else must constantly take
> locks for
> no reason.

+1, those are all good observations. Look at the C proactors to see how
we are implementing this. Suggestions welcome. At the C level all you
can do is trigger a wakeup, to keep the C layer easy to re-implement.
The C++ binding will use the basic wakeup provided by C, and add
programmer convenience in the form of work queues so you can not only
trigger a wakeup but provide a function to be executed.

> 
> Maybe in the spirit of "you don't pay for what you don't use" the way
> Python binding does it is actually fundamentally better, with an
> EventInjector thingie that you can add to your Container if you want
> and
> then call injector.inject(callback) instead of container.inject?

That's roughly how it works: there are a set of "contexts", the
container is just one of them. Like selectables but simpler, providing
only "wakeup" not read/write. Each connection, listener and the
container have a context, we're thinking about how to expose the
concept so the user can create contexts of their own for syncing
application data structures.

> 
> On Fri, Mar 24, 2017 at 3:30 PM, Alan Conway 
> wrote:
> 
> > On Fri, 2017-03-24 at 14:06 +0530, Venkat B wrote:
> > > Good day,
> > > 
> > > -- Forwarded message --
> > > > From: Alan Conway 
> > > > To: users@qpid.apache.org
> > > > Cc:
> > > > Bcc:
> > > > Date: Wed, 22 Mar 2017 14:09:00 -0400
> > > > Subject: Re: [qpid-proton-cpp] default_container does not
> > > > implement
> > > > thread
> > > > safety at all?
> > > > 
> > > 
> > > [snip]
> > > > 
> > > > And to be clear this is abuse to hack out of a short-term hole
> > > > - we
> > > > will have a properly behaved solution soon.
> > > > 
> > > > 
> > > 
> > > Do you have something that I could test?
> > > The code in examples/cpp/mt does not compile out of the box on
> > > 0.17.0
> > > and
> > > in case it is being redesigned anyway then I would prefer to work
> > > with the
> > > new API.
> > > 
> > 
> > I defer to astitcher on the current state of the examples. The API
> > isn't changing significantly, the code in mt/broker.cpp will still
> > be
> > correct with only minor changes if any.
> > 
> > The code in epoll_container.cpp will also still be basically
> > unchanged
> > but writing a custom container will no longer be necessary for most
> > cases: the default_container will be thread-safe and we will have
> > epoll-native, iocp-native and libuv flavours to cover most needs.
> > 
> > 
> > 
> > -
> > 
> > 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: Meaning of http: yes in qdrouterd.conf

[Alan Conway]

On Mon, 2017-05-29 at 16:03 +0200, Jiri Danek wrote:
> Hello, I've added http: yes to the listener in the default broker
> config.
> So my only listener on the router looks like this
> 
> listener {
>    host: 0.0.0.0
>    port: amqp
>    authenticatePeer: no
>    saslMechanisms: ANONYMOUS
>    http: yes
> }
> 
> I am now unable to connect with qdstat to the broker

http:yes means listen for HTTP/AMQP-over-websockets connections, not
normal AMQP. You can connect to the port with a web browser to see the
dispatch router management console.

We don't (yet) support automatic detection of AMQP vs. HTTP protcols so
if you use http:yes, that port will only act as a HTTP server port, it
won't accept normal AMQP connections.

> 
> [root@5c1091d699f0 /]# qdrouterd -c qdrouterd.conf &
> [1] 92
> [root@5c1091d699f0 /]# Mon May 29 13:41:39 2017 HTTP (info) Initial
> logging
> level 7
> Mon May 29 13:41:39 2017 HTTP (info) Libwebsockets version: 2.1.0
> unknown-build-hash
> Mon May 29 13:41:39 2017 HTTP (info) IPV6 not compiled in
> Mon May 29 13:41:39 2017 HTTP (info) libev support not compiled in
> Mon May 29 13:41:39 2017 HTTP (info) libuv support not compiled in
> Mon May 29 13:41:39 2017 HTTP (info)  Threads: 1 each 1048576 fds
> Mon May 29 13:41:39 2017 HTTP (info)  mem: platform fd map: 8388608
> bytes
> Mon May 29 13:41:39 2017 HTTP (info)  Compiled with OpenSSL support
> Mon May 29 13:41:39 2017 HTTP (info)  mem: per-conn:  512
> bytes +
> protocol rx buf
> Mon May 29 13:41:39 2017 SERVER (info) Container Name: Router.A
> Mon May 29 13:41:39 2017 ROUTER (info) Router started in Standalone
> mode
> Mon May 29 13:41:39 2017 ROUTER_CORE (info) Allow Unsettled
> Multicast: no
> Mon May 29 13:41:39 2017 ROUTER_CORE (info) Router Core thread
> running.
> 0/Router.A
> Mon May 29 13:41:39 2017 ROUTER_CORE (info) In-process subscription
> M/$management
> Mon May 29 13:41:39 2017 AGENT (info) Activating management agent on
> $_management_internal
> Mon May 29 13:41:39 2017 ROUTER_CORE (info) In-process subscription
> L/$management
> Mon May 29 13:41:39 2017 ROUTER_CORE (info) In-process subscription
> L/$_management_internal
> Mon May 29 13:41:39 2017 CONN_MGR (info) Configured Listener:
> 0.0.0.0:amqp
> proto=any, role=normal, http
> Mon May 29 13:41:39 2017 HTTP (info) Creating Vhost 'vhost0' port -2,
> 3
> protocols, IPv6 off
> Mon May 29 13:41:39 2017 HTTP (info)mounting
> file:///usr/share/qpid-dispatch/console/stand-alone to /
> Mon May 29 13:41:39 2017 POLICY (info) Policy configured
> maxConnections:
> 65535, policyDir: '', access rules enabled: 'false'
> Mon May 29 13:41:39 2017 POLICY (info) Policy fallback defaultVhost
> is
> defined: '$default'
> Mon May 29 13:41:39 2017 SERVER (info) Operational, 4 Threads Running
> 
> [root@5c1091d699f0 /]# qdstat -a -b amqp://127.0.0.1
> Mon May 29 13:44:44 2017 HTTP (info)  forbidding on uri sanitation
> Mon May 29 13:44:44 2017 HTTP (info) lws_server_socket_service: wsi
> 0x7fcc8c017610 read 0
> ConnectionException: Connection amqp://127.0.0.1:amqp/$management
> disconnected: Condition('amqp:connection:framing-error', "SASL header
> mismatch: Unknown protocol ['HTTP/1.0 403
> Forbidden\\x0d\\x0aserver: qpid-dispatch-router\\x0d\\x0acontent-
> type:
> text/html\\x0d\\x0acontent-length:
> 38\\x0d\\x0a\\x0d\\x0a403']")
> 
> Apparently, setting http: yes means that only websocket connections
> are now
> accepted, and not regular amqp. Is that intended?
> 
> I addition, qpid clients generally print unhelpful messages when
> connecting
> with regular amqp to such listener. Output of proton binding is shown
> in
> qdstat output. Qpid-jms prints
> 
> 13:59:11,726 ERROR Failed to connect to remote at:
> amqp://127.0.0.1:5672
> 13:59:11,729 ERROR org.apache.qpid.proton.engine.TransportException:
> AMQP
> SASL header mismatch value 48, expecting 41. In state: HEADER0
> javax.jms.JMSException:
> org.apache.qpid.proton.engine.TransportException:
> AMQP SASL header mismatch value 48, expecting 41. In state: HEADER0
> at
> org.apache.qpid.jms.exceptions.JmsExceptionSupport.create(JmsExceptio
> nSupport.java:86)
> at
> org.apache.qpid.jms.exceptions.JmsExceptionSupport.create(JmsExceptio
> nSupport.java:108)
> at org.apache.qpid.jms.JmsConnection.connect(JmsConnection.java:168)
> at
> org.apache.qpid.jms.JmsConnectionFactory.createConnection(JmsConnecti
> onFactory.java:204)
> at
> org.apache.qpid.jms.JmsConnectionFactory.createConnection(JmsConnecti
> onFactory.java:191)
> at
> com.redhat.mqe.jms.ConnectionManager.(ConnectionManager.java:85
> )
> at
> com.redhat.mqe.jms.CoreClient.createConnection(CoreClient.java:135)
> at
> com.redhat.mqe.jms.ReceiverClient.consumeMessage(ReceiverClient.java:
> 134)
> at
> com.redhat.mqe.jms.ReceiverClient.startClient(ReceiverClient.java:110
> )
> at com.redhat.mqe.jms.aac1_receiver.main(aac1_receiver.java:17)
> at com.redhat.mqe.jms.Main.main(Main.java:28)
> at
> com.redhat.mqe.jms.MainTest.sendAndReceiveSingleMessage(MainTest.kt:3
> 2)

Meaning of http: yes in qdrouterd.conf

[Jiri Danek]

Hello, I've added http: yes to the listener in the default broker config.
So my only listener on the router looks like this

listener {
   host: 0.0.0.0
   port: amqp
   authenticatePeer: no
   saslMechanisms: ANONYMOUS
   http: yes
}

I am now unable to connect with qdstat to the broker

[root@5c1091d699f0 /]# qdrouterd -c qdrouterd.conf &
[1] 92
[root@5c1091d699f0 /]# Mon May 29 13:41:39 2017 HTTP (info) Initial logging
level 7
Mon May 29 13:41:39 2017 HTTP (info) Libwebsockets version: 2.1.0
unknown-build-hash
Mon May 29 13:41:39 2017 HTTP (info) IPV6 not compiled in
Mon May 29 13:41:39 2017 HTTP (info) libev support not compiled in
Mon May 29 13:41:39 2017 HTTP (info) libuv support not compiled in
Mon May 29 13:41:39 2017 HTTP (info)  Threads: 1 each 1048576 fds
Mon May 29 13:41:39 2017 HTTP (info)  mem: platform fd map: 8388608 bytes
Mon May 29 13:41:39 2017 HTTP (info)  Compiled with OpenSSL support
Mon May 29 13:41:39 2017 HTTP (info)  mem: per-conn:  512 bytes +
protocol rx buf
Mon May 29 13:41:39 2017 SERVER (info) Container Name: Router.A
Mon May 29 13:41:39 2017 ROUTER (info) Router started in Standalone mode
Mon May 29 13:41:39 2017 ROUTER_CORE (info) Allow Unsettled Multicast: no
Mon May 29 13:41:39 2017 ROUTER_CORE (info) Router Core thread running.
0/Router.A
Mon May 29 13:41:39 2017 ROUTER_CORE (info) In-process subscription
M/$management
Mon May 29 13:41:39 2017 AGENT (info) Activating management agent on
$_management_internal
Mon May 29 13:41:39 2017 ROUTER_CORE (info) In-process subscription
L/$management
Mon May 29 13:41:39 2017 ROUTER_CORE (info) In-process subscription
L/$_management_internal
Mon May 29 13:41:39 2017 CONN_MGR (info) Configured Listener: 0.0.0.0:amqp
proto=any, role=normal, http
Mon May 29 13:41:39 2017 HTTP (info) Creating Vhost 'vhost0' port -2, 3
protocols, IPv6 off
Mon May 29 13:41:39 2017 HTTP (info)mounting
file:///usr/share/qpid-dispatch/console/stand-alone to /
Mon May 29 13:41:39 2017 POLICY (info) Policy configured maxConnections:
65535, policyDir: '', access rules enabled: 'false'
Mon May 29 13:41:39 2017 POLICY (info) Policy fallback defaultVhost is
defined: '$default'
Mon May 29 13:41:39 2017 SERVER (info) Operational, 4 Threads Running

[root@5c1091d699f0 /]# qdstat -a -b amqp://127.0.0.1
Mon May 29 13:44:44 2017 HTTP (info)  forbidding on uri sanitation
Mon May 29 13:44:44 2017 HTTP (info) lws_server_socket_service: wsi
0x7fcc8c017610 read 0
ConnectionException: Connection amqp://127.0.0.1:amqp/$management
disconnected: Condition('amqp:connection:framing-error', "SASL header
mismatch: Unknown protocol ['HTTP/1.0 403
Forbidden\\x0d\\x0aserver: qpid-dispatch-router\\x0d\\x0acontent-type:
text/html\\x0d\\x0acontent-length:
38\\x0d\\x0a\\x0d\\x0a403']")

Apparently, setting http: yes means that only websocket connections are now
accepted, and not regular amqp. Is that intended?

I addition, qpid clients generally print unhelpful messages when connecting
with regular amqp to such listener. Output of proton binding is shown in
qdstat output. Qpid-jms prints

13:59:11,726 ERROR Failed to connect to remote at: amqp://127.0.0.1:5672
13:59:11,729 ERROR org.apache.qpid.proton.engine.TransportException: AMQP
SASL header mismatch value 48, expecting 41. In state: HEADER0
javax.jms.JMSException: org.apache.qpid.proton.engine.TransportException:
AMQP SASL header mismatch value 48, expecting 41. In state: HEADER0
at
org.apache.qpid.jms.exceptions.JmsExceptionSupport.create(JmsExceptionSupport.java:86)
at
org.apache.qpid.jms.exceptions.JmsExceptionSupport.create(JmsExceptionSupport.java:108)
at org.apache.qpid.jms.JmsConnection.connect(JmsConnection.java:168)
at
org.apache.qpid.jms.JmsConnectionFactory.createConnection(JmsConnectionFactory.java:204)
at
org.apache.qpid.jms.JmsConnectionFactory.createConnection(JmsConnectionFactory.java:191)
at com.redhat.mqe.jms.ConnectionManager.(ConnectionManager.java:85)
at com.redhat.mqe.jms.CoreClient.createConnection(CoreClient.java:135)
at com.redhat.mqe.jms.ReceiverClient.consumeMessage(ReceiverClient.java:134)
at com.redhat.mqe.jms.ReceiverClient.startClient(ReceiverClient.java:110)
at com.redhat.mqe.jms.aac1_receiver.main(aac1_receiver.java:17)
at com.redhat.mqe.jms.Main.main(Main.java:28)
at com.redhat.mqe.jms.MainTest.sendAndReceiveSingleMessage(MainTest.kt:32)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:316)
at
org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:114)
at
org.junit.jupiter.engine.descriptor.MethodTestDescriptor.lambda$invokeTestMethod$6(MethodTestDescriptor.java:171)
at

Re: [VOTE] Release Qpid Java 6.0.7 (RC1)

[Oleksandr Rudyy]

+1

I performed the following tests:

1) Build broker and client from source distribution
2) Run 'hello world' example against broker built from source distribution
3) Verified the md5/sha checksums on all distribution artefacts
4) Verified signatures on all all distribution artefacts
5) Run amqp-0-x jms client 'hello world' example against broker from binary
distribution
6) Run amqp-1-0 jms client 'hello world' example against broker from binary
distribution

Kind Regards,
Alex

On 25 May 2017 at 18:44, Keith W  wrote:

> Making my +1 explicit.
>
> My testing was:
>
> 1) Ran apache rat
> 2) Verified the md5/sha checksums on all distribution artefacts
> 3) Verified signatures on all all distribution artefacts
> 4) Built/ran test profiles mms for 0-9 and 0-10 from source bundle
> 5) Ran hello world against staged maven artefacts against broker from
> binary distribution artefact
>
> On 25 May 2017 at 17:39, Keith W  wrote:
> > Hi all,
> >
> > A release candidate for the next release (6.0.7) of the Qpid Java
> > Components has been created.
> >
> > The list of defect fixes can be found in Jira:
> >
> > https://issues.apache.org/jira/issues/?jql=project%20%
> 3D%20QPID%20AND%20fixVersion%20%3D%20qpid-java-6.0.7
> >
> > Please test and vote accordingly.
> >
> > The source and binary archives can be grabbed from here:
> > https://dist.apache.org/repos/dist/dev/qpid/java/6.0.7-rc1
> >
> > Those files and the other maven artifacts are also staged for now at:
> > https://repository.apache.org/content/repositories/orgapacheqpid-1107
> >
> > Kind regards
> >
> > P.S. If you want to test it out using maven (e.g with the examples src,
> > or your own things), you can temporarily add this to your poms to access
> > the staging repo:
> >
> >   
> > 
> >   staging
> >   https://repository.apache.org/content/
> repositories/orgapacheqpid-1107
> > 
> >   
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>

Re: [VOTE] Release Qpid Java 6.1.3 (RC1)

[Oleksandr Rudyy]

+1

I performed the following tests:

1) Build broker and client from source distribution
2) Run 'hello world' example against broker built from source distribution
3) Verified the md5/sha checksums on all distribution artefacts
4) Verified signatures on all all distribution artefacts
5) Run 'hello world' example against broker binary distribution

Please, note, there is a redundant sha1 signature
qpid-java-6.1.3.tar.gz.sha1 for source distribution.

Kind Regards,
Alex


On 26 May 2017 at 16:39, Lorenz Quack  wrote:

> Hi all,
>
> As Rob pointed out my previous mail contained an error.
> This email thread is (as the subject suggests) a voting thread for
> the release candidate for the 6.1.3 release and not for 6.0.7 as
> my previous email erroneously stated.
> Currently, there is also a voting thread started by Keith for
> 6.0.7 RC1 going on but it is separate from this vote.
> The corrected voting announcement is as follows:
>
>
> A release candidate for the next release (6.1.3) of the Qpid Java
> Components has been created.
>
> The list of defect fixes can be found in Jira:
>
> https://issues.apache.org/jira/issues/?jql=project%20%
> 3D%20QPID%20AND%20fixVersion%20%3D%20qpid-java-6.1.3
>
> Please test and vote accordingly.
>
> The source and binary archives can be grabbed from here:
> https://dist.apache.org/repos/dist/dev/qpid/java/6.1.3-rc1/
>
> Those files and the other maven artifacts are also staged for now at:
> https://repository.apache.org/content/repositories/orgapacheqpid-1108/
>
> Kind regards
>
> P.S. If you want to test it out using maven (e.g with the examples src,
> or your own things), you can temporarily add this to your poms to access
> the staging repo:
>
>   
> 
>   staging
>   https://repository.apache.org/content/
> repositories/orgapacheqpid-1108
> 
>   
>
>
>
>
> On Fri, 2017-05-26 at 13:49 +0100, Rob Godfrey wrote:
> > The title and links say 6.1.3 but the body of the e-mail says 6.0.7 ...
> You
> > might want to resend and make clear :-)
> >
> > -- Rob
> >
> > On 26 May 2017 1:44 pm, "Lorenz Quack"  wrote:
> >
> > Hi all,
> >
> > A release candidate for the next release (6.0.7) of the Qpid Java
> > Components has been created.
> >
> > The list of defect fixes can be found in Jira:
> >
> > https://issues.apache.org/jira/issues/?jql=project%20%
> > 3D%20QPID%20AND%20fixVersion%20%3D%20qpid-java-6.1.3
> >
> > Please test and vote accordingly.
> >
> > The source and binary archives can be grabbed from here:
> > https://dist.apache.org/repos/dist/dev/qpid/java/6.1.3-rc1/
> >
> > Those files and the other maven artifacts are also staged for now at:
> > https://repository.apache.org/content/repositories/orgapacheqpid-1108/
> >
> > Kind regards
> >
> > P.S. If you want to test it out using maven (e.g with the examples src,
> > or your own things), you can temporarily add this to your poms to access
> > the staging repo:
> >
> >   
> > 
> >   staging
> >   https://repository.apache.org/content/
> repositories/orgapacheqpid-
> > 1108
> > 
> >   
> >
> >
> > -
> > 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
>
>