Re: [Proton 0.16.0] [Solaris] Unit tests hanging when destroying connection_driver

[Adel Boutros]

Hello Andrew,


Issue reported and patch provided at head of master here: 
https://issues.apache.org/jira/browse/PROTON-1382

2 problems fixed:

* Remove bit fields initialization to fix hanging tests on Solaris

* Add missing include to fix incomplete type error on Solaris (message.cpp, 
Error: Function "proton::link::error() const" with incomplete return type 
"proton::error_condition", compiler cannot generate virtual table in this 
situation..)


Could this be considered as a regression because Proton was compiling on 
Solaris at 0.14.0?

Would it be possible to consider a 0.16.1 release in that case if 0.17.0 is a 
bit far from being released?


Regards,

Adel


From: Andrew Stitcher 
Sent: Wednesday, January 4, 2017 4:39:27 PM
To: users@qpid.apache.org
Subject: Re: [Proton 0.16.0] [Solaris] Unit tests hanging when destroying 
connection_driver

On Wed, 2017-01-04 at 14:47 +, Adel Boutros wrote:
> I found the issue!!
>
>
> It is a Solaris compiler bug:
>
> Actually Solaris doesn't handle correctly bit fields in C. This is
> the case of the struct pn_collector_t (bool head_returned:1).

We probably should just never be using bifields in this case - it is
pretty unusual in my experience (even if it seems like it would save
space in the struct).

So I, for one, would definitely accept a patch to remove all uses of
bool bitfields.

Andrew


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

Re: [Proton 0.16.0] Is libuv mandatory to compile Proton?

[Adel Boutros]

Thank you Andrew,


two last questions:

* is the proactor implementation based on libuv ready? (We rely on the C++ 
bindings of Proton)

* When do you expect to release it?


Regards,

Adel


From: Andrew Stitcher 
Sent: Wednesday, January 4, 2017 4:35:14 PM
To: users@qpid.apache.org
Subject: Re: [Proton 0.16.0] Is libuv mandatory to compile Proton?

On Wed, 2017-01-04 at 09:36 +, Adel Boutros wrote:
> Thank you Andrew for this clear explanation.
>
>
> Epoll is not supported on Solaris. So we will have to think of an
> alternative for this OS (poll which you suggested should work).
>
>
> As for libuv, we are currently compiling Proton 0.16.0 without it
> because we don't have bandwidth to check if libuv is working on
> Solaris. I will have to discuss internally to see if we can allocate
> some bandwidth to dealing with libuv on Solaris. If you have any
> input at this level, we will highly appreciate it.

I think it is highly likely that libuv will work on Solaris (although I
haven't tried it myself).

My reason for thinking this is that libuv is an outcome of the Node.js
project. The major sponsor for this project was (is?) Joyent whose
business was based around a Solaris derivative (Illumos I think).

This in turn is because the principals of Joyent were kernel engineers
at Sun (responsible amongst other things for DTrace).

Put another way - anywhere Node.js runs you;d expect libuv to run as
Node.js depends on libuv.

> Alan Conway stated in another discussion that libuv should fix the
> slowness we detected in the event injection API. I don't know if
> poll/epoll would also address this issue which is a bit critical for
> us.
>

I think he said that the proactor based interface would be the
important aspect of the speed up rather than libuv per se. So you
should get that speed up (eventually).

Andrew


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

Qpid C++ 1.36 issues an invalid AMQP 1.0 frame after successful DIGEST-MD5 authentication

[drasil]

Hello,

I believe that I found a bug in the Qpid C++ broker (I tried versions 1.35
and 1.36 and both are affected). When the broker is configured to use the
DIGEST-MD5 SASL mechanism, the authentication passes successfully, but just
after that the broker issues a completely invalid AMQP 1.0 frame. As a
result, the client complains about a framing error and disconnects. I am
using a client based on python-qpid-proton 0.16.0 but that should not be
important I guess. When I change the SASL mechanism to CRAM-MD5, PLAIN or
ANONYMOUS, everything works well.

Attached is a tcpdump file with four subsequent connection attempts, showing
the described behavior:  amqp.dmp
  

Regards, Pavel



--
View this message in context: 
http://qpid.2158936.n2.nabble.com/Qpid-C-1-36-issues-an-invalid-AMQP-1-0-frame-after-successful-DIGEST-MD5-authentication-tp7657354.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: Qpid C++ 1.36 issues an invalid AMQP 1.0 frame after successful DIGEST-MD5 authentication

[Gordon Sim]

On 05/01/17 08:39, drasil wrote:

Hello,

I believe that I found a bug in the Qpid C++ broker (I tried versions 1.35
and 1.36 and both are affected). When the broker is configured to use the
DIGEST-MD5 SASL mechanism, the authentication passes successfully, but just
after that the broker issues a completely invalid AMQP 1.0 frame.


By default, DIGEST-MD5 installs an encryption layer after successful 
authentication. So from wireshark's perspective, subsequent frames will 
not be decodable.



As a
result, the client complains about a framing error and disconnects.


That shouldn't happen if the client and server are aligned on the 
establishment of the encryption layer.



I am
using a client based on python-qpid-proton 0.16.0 but that should not be
important I guess.


The client (and version) is I think relevant here. Were you using one of 
the standard examples in testing?


I've tried connecting using DIGEST-MD5 and the 0.16 proton python client 
and it works for me (viewing with wireshark, all the frames after the 
sasl layer is established are reported as invalid due to the encryption):



$ PN_TRACE_FRM=1 python ./share/proton-0.16.0/examples/python/simple_send.py -a 
guest:guest@localhost/amq.fanout -m 1
[0x5634d72a2c50]:  -> SASL
[0x5634d72a2c50]:  <- SASL
[0x5634d72a2c50]:0 <- @sasl-mechanisms(64) 
[sasl-server-mechanisms=@PN_SYMBOL[:"DIGEST-MD5", :PLAIN]]
[0x5634d72a2c50]:0 -> @sasl-init(65) [mechanism=:"DIGEST-MD5"]
[0x5634d72a2c50]:0 <- @sasl-challenge(66) 
[challenge=b"nonce="XiDROFG5dWVBVyih71+KSuBvSNawZr3g9SrnjRj3LLY=",realm="QPID",qop="auth,auth-int,auth-conf",cipher="rc4-40,rc4-56,rc4,des,3des",maxbuf=65535,charset=utf-8,algorithm=md5-sess"]
[0x5634d72a2c50]:0 -> @sasl-response(67) 
[response=b"username="guest",realm="QPID",nonce="XiDROFG5dWVBVyih71+KSuBvSNawZr3g9SrnjRj3LLY=",cnonce="LwH1PutrtfaR5kzmXy3MnO6VDAsApszmkvcbCQek9vk=",nc=0001,qop=auth-conf,cipher=rc4,maxbuf=32768,digest-uri="amqp/localhost",response=3488392792124469fa3e1acfdb2cbc85"]
[0x5634d72a2c50]:0 <- @sasl-challenge(66) 
[challenge=b"rspauth=e79db70777debb33d3b179272f13e462"]
[0x5634d72a2c50]:0 -> @sasl-response(67) [response=b""]
[0x5634d72a2c50]:0 <- @sasl-outcome(68) [code=0]
[0x5634d72a2c50]:  -> AMQP
[0x5634d72a2c50]:0 -> @open(16) [container-id="8bb0482d-2eb2-4f97-a749-22e8ea2dec4f", 
hostname="localhost", channel-max=32767]
[0x5634d72a2c50]:0 -> @begin(17) [next-outgoing-id=0, 
incoming-window=2147483647, outgoing-window=2147483647]
[0x5634d72a2c50]:0 -> @attach(18) 
[name="8bb0482d-2eb2-4f97-a749-22e8ea2dec4f-amq.fanout", handle=0, role=false, 
snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0, timeout=0, dynamic=false], 
target=@target(41) [address="amq.fanout", durable=0, timeout=0, dynamic=false], 
initial-delivery-count=0, max-message-size=0]
[0x5634d72a2c50]:  <- AMQP
[0x5634d72a2c50]:0 <- @open(16) [container-id="a6022696-2483-49f5-8ea6-a6f50db0e7ae", channel-max=32767, 
offered-capabilities=@PN_SYMBOL[:"ANONYMOUS-RELAY"], properties={:product="qpid-cpp", :version="1.36.0", 
:platform="Linux", :host="localhost.localdomain"}]
[0x5634d72a2c50]:0 <- @begin(17) [remote-channel=0, next-outgoing-id=0, 
incoming-window=2147483647, outgoing-window=2147483647]
[0x5634d72a2c50]:0 <- @attach(18) 
[name="8bb0482d-2eb2-4f97-a749-22e8ea2dec4f-amq.fanout", handle=0, role=true, 
snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0, timeout=0, dynamic=false], 
target=@target(41) [address="amq.fanout", durable=0, timeout=0, dynamic=false], 
initial-delivery-count=0]
[0x5634d72a2c50]:0 <- @flow(19) [next-incoming-id=0, 
incoming-window=2147483647, next-outgoing-id=0, outgoing-window=2147483647, 
handle=0, delivery-count=0, link-credit=500, drain=false]
[0x5634d72a2c50]:0 -> @transfer(20) [handle=0, delivery-id=0, delivery-tag=b"1", 
message-format=0, settled=false, more=false] (86) 
"\x00Sp\xd0\x00\x00\x00\x0b\x00\x00\x00\x05BP\x04@BR\x00\x00Ss\xd0\x00\x00\x00#\x00\x00\x00\x0dS\x01@@@\x83\x00\x00\x00\x00\x00\x00\x00\x00\x83\x00\x00\x00\x00\x00\x00\x00\x00@R\x00@\x00Sw\xd1\x00\x00\x00\x10\x00\x00\x00\x02\xa1\x08sequenceT\x01"
[0x5634d72a2c50]:0 <- @flow(19) [next-incoming-id=1, 
incoming-window=2147483647, next-outgoing-id=0, outgoing-window=2147483647, 
handle=0, delivery-count=1, link-credit=500, drain=false]
[0x5634d72a2c50]:0 <- @disposition(21) [role=true, first=0, last=0, 
settled=true, state=@accepted(36) []]
all messages confirmed
[0x5634d72a2c50]:0 -> @close(24) []
[0x5634d72a2c50]:  -> EOS
[0x5634d72a2c50]:0 <- @close(24) []
[0x5634d72a2c50]:  <- EOS



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

Re: Qpid C++ 1.36 issues an invalid AMQP 1.0 frame after successful DIGEST-MD5 authentication

[drasil]

Oh, I see. I thought that SASL mechanisms influence just the authentication
phase. Thank you very much for clarification. So there is probably something
wrong with my proton client because the problem occurs with the standard
example as well:

$ PN_TRACE_FRM=1 python
/usr/local/share/proton-0.16.0/examples/python/simple_send.py -a
myUser:myPassword@localhost/amq.fanout -m 1
[0x9839880]:  -> SASL
[0x9839880]:  <- SASL
[0x9839880]:0 <- @sasl-mechanisms(64) [sasl-server-mechanisms=:"DIGEST-MD5"]
[0x9839880]:0 -> @sasl-init(65) [mechanism=:"DIGEST-MD5"]
[0x9839880]:0 <- @sasl-challenge(66)
[challenge=b"nonce="Cq5chKnatfwEV28lxxdQw5bD3vxywxUSRnTJ2tLD5ro=",realm="QPID",qop="auth,auth-int,auth-conf",cipher="rc4-40,rc4-56,rc4,des,3des",maxbuf=65535,charset=utf-8,algorithm=md5-sess"]
[0x9839880]:0 -> @sasl-response(67)
[response=b"username="myUser",realm="QPID",nonce="Cq5chKnatfwEV28lxxdQw5bD3vxywxUSRnTJ2tLD5ro=",cnonce="MZV40TRDnt4gzIFENyrdc40fgSNpWXY5jv3v4bOC2vE=",nc=0001,qop=auth-conf,cipher=rc4,maxbuf=32768,digest-uri="amqp/localhost",response=2dfde3790620d0aede423b17f8edb4a1"]
[0x9839880]:0 <- @sasl-challenge(66)
[challenge=b"rspauth=cf464b4a887edbb1392fc95e5f9f972c"]
[0x9839880]:0 -> @sasl-response(67) [response=b""]
[0x9839880]:0 <- @sasl-outcome(68) [code=0]
[0x9839880]:  <- EOS
[0x9839880]:  -> EOS
ERROR:root:amqp:connection:framing-error: AMQP header mismatch: Unknown
protocol
['\x00\x00\x00\x18S\xd8\xf6\xd6q\xde\xbd\xd3\x06\xb8X\xb53g\xd0\xba\xe4\x8b\x00\x01\x00\x00\x00\x00']

Is it possible that I inadvertently compiled my proton binaries without
support for DIGEST-MD5? Just to explain what I did - I first compiled and
installed the proton 0.16 binaries and then used pip to download and install
the python-qpid-proton 0.16 package.



--
View this message in context: 
http://qpid.2158936.n2.nabble.com/Qpid-C-1-36-issues-an-invalid-AMQP-1-0-frame-after-successful-DIGEST-MD5-authentication-tp7657354p7657361.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: Qpid C++ 1.36 issues an invalid AMQP 1.0 frame after successful DIGEST-MD5 authentication

[Gordon Sim]

On 05/01/17 11:15, drasil wrote:

Oh, I see. I thought that SASL mechanisms influence just the authentication
phase. Thank you very much for clarification. So there is probably something
wrong with my proton client because the problem occurs with the standard
example as well:

$ PN_TRACE_FRM=1 python
/usr/local/share/proton-0.16.0/examples/python/simple_send.py -a
myUser:myPassword@localhost/amq.fanout -m 1
[0x9839880]:  -> SASL
[0x9839880]:  <- SASL
[0x9839880]:0 <- @sasl-mechanisms(64) [sasl-server-mechanisms=:"DIGEST-MD5"]
[0x9839880]:0 -> @sasl-init(65) [mechanism=:"DIGEST-MD5"]
[0x9839880]:0 <- @sasl-challenge(66)
[challenge=b"nonce="Cq5chKnatfwEV28lxxdQw5bD3vxywxUSRnTJ2tLD5ro=",realm="QPID",qop="auth,auth-int,auth-conf",cipher="rc4-40,rc4-56,rc4,des,3des",maxbuf=65535,charset=utf-8,algorithm=md5-sess"]
[0x9839880]:0 -> @sasl-response(67)
[response=b"username="myUser",realm="QPID",nonce="Cq5chKnatfwEV28lxxdQw5bD3vxywxUSRnTJ2tLD5ro=",cnonce="MZV40TRDnt4gzIFENyrdc40fgSNpWXY5jv3v4bOC2vE=",nc=0001,qop=auth-conf,cipher=rc4,maxbuf=32768,digest-uri="amqp/localhost",response=2dfde3790620d0aede423b17f8edb4a1"]
[0x9839880]:0 <- @sasl-challenge(66)
[challenge=b"rspauth=cf464b4a887edbb1392fc95e5f9f972c"]
[0x9839880]:0 -> @sasl-response(67) [response=b""]
[0x9839880]:0 <- @sasl-outcome(68) [code=0]
[0x9839880]:  <- EOS
[0x9839880]:  -> EOS
ERROR:root:amqp:connection:framing-error: AMQP header mismatch: Unknown
protocol
['\x00\x00\x00\x18S\xd8\xf6\xd6q\xde\xbd\xd3\x06\xb8X\xb53g\xd0\xba\xe4\x8b\x00\x01\x00\x00\x00\x00']

Is it possible that I inadvertently compiled my proton binaries without
support for DIGEST-MD5?


No, I don't think so, because then the client would fail before trying 
the DIGEST-MD5 authentication.



Just to explain what I did - I first compiled and
installed the proton 0.16 binaries and then used pip to download and install
the python-qpid-proton 0.16 package.


I did a pip install (without having proton-c installed in standard 
location) in a virtual env and with that, that same example works for me 
(against a 1.36 broker).



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

Qpid java broker 6.0.4 - JDBC message store performance issues

[Antoine Chevin]

Hello,

I ran a benchmark using Qpid java broker 6.0.4 and the JDBC message store
with an Oracle database.
I tried to send and read 1,000,000 messages to the broker but was not able
to finish the benchmark as there was a StoreException caused by a
java.net.ConnectException (full stack is attached).

I suspected a very high number of connections.

I tried using JDBC with BoneCP and the benchmark finished. I could get the
BoneCP statistics and for 1,000,000 messages, there were 3,000,000 DB
connections requested.

It looks like the broker requests a connection when enqueuing and dequeuing
the message with the JDBC store. Is it a normal behavior?

Also, the benchmark showed that the JDBC store with Oracle was slower than
the BDB store. (an average throughput of 2.8K msg/s vs 5.4K msg/s).
I suspected a degradation as the Oracle store is located on a separate
machine and the broker goes over the network to persist the messages. But
not that much.
Do you know if there is a possible improvement in the JDBC message store
code to narrow the gap?

Thank you in advance,
Best regards,
Antoine

#
# Unhandled Exception org.apache.qpid.server.store.StoreException: 
java.sql.SQLException: The Network Adapter could not establish the connection 
in Thread virtualhost-default-pool-1
#
# Exiting
#

org.apache.qpid.server.store.StoreException: java.sql.SQLException: The Network 
Adapter could not establish the connection
at 
org.apache.qpid.server.store.AbstractJDBCMessageStore$JDBCTransaction.(AbstractJDBCMessageStore.java:1120)
at 
org.apache.qpid.server.store.jdbc.GenericAbstractJDBCMessageStore$RecordedJDBCTransaction.(GenericAbstractJDBCMessageStore.java:118)
at 
org.apache.qpid.server.store.jdbc.GenericAbstractJDBCMessageStore$RecordedJDBCTransaction.(GenericAbstractJDBCMessageStore.java:114)
at 
org.apache.qpid.server.store.jdbc.GenericAbstractJDBCMessageStore.newTransaction(GenericAbstractJDBCMessageStore.java:110)
at 
org.apache.qpid.server.txn.AutoCommitTransaction.dequeue(AutoCommitTransaction.java:85)
at 
org.apache.qpid.server.queue.AbstractQueue.dequeueEntry(AbstractQueue.java:1926)
at 
org.apache.qpid.server.queue.AbstractQueue.dequeueEntry(AbstractQueue.java:1921)
at 
org.apache.qpid.server.queue.AbstractQueue.checkMessageStatus(AbstractQueue.java:2521)
at 
org.apache.qpid.server.virtualhost.AbstractVirtualHost$VirtualHostHouseKeepingTask.execute(AbstractVirtualHost.java:1284)
at 
org.apache.qpid.server.virtualhost.HouseKeepingTask$1.run(HouseKeepingTask.java:65)
at java.security.AccessController.doPrivileged(Native Method)
at 
org.apache.qpid.server.virtualhost.HouseKeepingTask.run(HouseKeepingTask.java:60)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.sql.SQLException: The Network Adapter could not establish the 
connection
at oracle.jdbc.driver.T4CConnection.logon(T4CConnection.java:412)
at 
oracle.jdbc.driver.PhysicalConnection.(PhysicalConnection.java:531)
at oracle.jdbc.driver.T4CConnection.(T4CConnection.java:221)
at 
oracle.jdbc.driver.T4CDriverExtension.getConnection(T4CDriverExtension.java:32)
at oracle.jdbc.driver.OracleDriver.connect(OracleDriver.java:503)
at java.sql.DriverManager.getConnection(DriverManager.java:664)
at java.sql.DriverManager.getConnection(DriverManager.java:247)
at 
org.apache.qpid.server.store.jdbc.DefaultConnectionProvider.getConnection(DefaultConnectionProvider.java:49)
at 
org.apache.qpid.server.store.jdbc.GenericJDBCMessageStore.getConnection(GenericJDBCMessageStore.java:121)
at 
org.apache.qpid.server.store.AbstractJDBCMessageStore.newConnection(AbstractJDBCMessageStore.java:544)
at 
org.apache.qpid.server.store.AbstractJDBCMessageStore$JDBCTransaction.(AbstractJDBCMessageStore.java:1116)
... 18 more
Caused by: oracle.net.ns.NetException: The Network Adapter could not establish 
the connection
at oracle.net.nt.ConnStrategy.execute(ConnStrategy.java:359)
at 
oracle.net.resolver.AddrResolution.resolveAndExecute(AddrResolution.java:422)
at oracle.net.ns.NSProtocol.establishConnection(NSProtocol.java:672)
at orac

Re: One SSL + SASL EXTERNAL queue creation works with qpidd 1.36.0 but not 1.35.0

[Gordon Sim]

On 04/01/17 23:08, Jeff Donner wrote:

# The queue creation is run at this point (reminder)
qpid-config --broker amqps://dev-qpidclient@localhost:5672 \
--ssl-certificate=pki/client/certs/client-cert.pem \
--ssl-key=pki/client/private/client-keys.pem \
--sasl-mechanism=EXTERNAL \
add queue examples


2017-01-04 13:24:55 [Network] trace 
/builddir/build/BUILD/qpid-cpp-1.35.0/src/qpid/sys/ssl/SslSocket.cpp:340:qpid::sys::ssl::SslMuxSocket::accept:
 Accepting connection with optional SSL wrapper.
2017-01-04 13:24:55 [Network] trace 
/builddir/build/BUILD/qpid-cpp-1.35.0/src/qpid/sys/ssl/SslSocket.cpp:345:qpid::sys::ssl::SslMuxSocket::accept:
 Accepted Plaintext connection.


The first thing that seems odd is that the log above suggests SSL is not 
actually used whereas the later 1.36 trace shows an SSL connection being 
accepted. The SslSocket.cpp code is identical between 1.35 and 1,36 
however so not sure how the same client and command would result in 
different behaviours (I'm assuming both are running on the same machine, 
with the same nss cert dbs etc).



2017-01-04 13:24:55 [Network] debug 
/builddir/build/BUILD/qpid-cpp-1.35.0/src/qpid/sys/SocketTransport.cpp:51:qpid::sys::{anonymous}::establishedCommon:
 Set TCP_NODELAY on connection to [::1]:51976
2017-01-04 13:24:57 [System] debug 
/builddir/build/BUILD/qpid-cpp-1.35.0/src/qpid/sys/AsynchIOHandler.cpp:150:qpid::sys::AsynchIOHandler::readbuff:
 RECV [qpid.[::1]:5672-[::1]:51976]: INIT(1-0)
2017-01-04 13:24:57 [System] debug 
/builddir/build/BUILD/qpid-cpp-1.35.0/src/qpid/Exception.cpp:43:qpid::Exception::Exception:
 Exception constructed: SASL layer required!
2017-01-04 13:24:57 [System] error 
/builddir/build/BUILD/qpid-cpp-1.35.0/src/qpid/sys/AsynchIOHandler.cpp:164:qpid::sys::AsynchIOHandler::readbuff:
 SASL layer required!


This error suggests that the broker did not get the AMQP-SASL protocol 
header frame that it expected. Again, not clear to me why that would be.


Are both brokers built against the same version of proton?

[...]

I don't see any release notes or JIRA issues for 1.36.0 that point out problems 
or quirks in 1.35.0 for this - any ideas?

This is Fedora 23 Linux.


Have you tried with the rpms?


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

RE: SSL + SASL EXTERNAL queue creation works with qpidd 1.36.0 but not 1.35.0

[Jeff Donner]

> Are both brokers built against the same version of proton?

No - qpidd 1.35.0 is Fedora's packaged version and would have been built 
against proton 0.14.0, 1.36.0 was hand-built against proton 16. 

But this is prior to any interaction with test clients, it's just creating a 
queue. The two tests use the same proton 14(?) or qpidd 1.35(?) version of 
qpid-config. 

> Have you tried with the rpms?

I used Fedora's, unless there are separate qpid ones. 

I see that EXTERNAL is supposed to work in 1.35 - I thought, per table 1.10.1.1 
of 
http://qpid.apache.org/releases/qpid-cpp-1.36.0/cpp-broker/cpp-broker-book.pdf 
that it might not be supported, but I see elsewhere in that document that it is 
(the same in both 1.35 and 1.36 versions). 

Well, thanks for the thoughts! 

Jeff

From: Gordon Sim [g...@redhat.com]
Sent: Thursday, January 05, 2017 6:04 AM
To: users@qpid.apache.org
Subject: Re: One SSL + SASL EXTERNAL queue creation works with qpidd 1.36.0 but 
not 1.35.0

On 04/01/17 23:08, Jeff Donner wrote:
> # The queue creation is run at this point (reminder)
> qpid-config --broker amqps://dev-qpidclient@localhost:5672 \
> --ssl-certificate=pki/client/certs/client-cert.pem \
> --ssl-key=pki/client/private/client-keys.pem \
> --sasl-mechanism=EXTERNAL \
> add queue examples
>
>
> 2017-01-04 13:24:55 [Network] trace 
> /builddir/build/BUILD/qpid-cpp-1.35.0/src/qpid/sys/ssl/SslSocket.cpp:340:qpid::sys::ssl::SslMuxSocket::accept:
>  Accepting connection with optional SSL wrapper.
> 2017-01-04 13:24:55 [Network] trace 
> /builddir/build/BUILD/qpid-cpp-1.35.0/src/qpid/sys/ssl/SslSocket.cpp:345:qpid::sys::ssl::SslMuxSocket::accept:
>  Accepted Plaintext connection.

The first thing that seems odd is that the log above suggests SSL is not
actually used whereas the later 1.36 trace shows an SSL connection being
accepted. The SslSocket.cpp code is identical between 1.35 and 1,36
however so not sure how the same client and command would result in
different behaviours (I'm assuming both are running on the same machine,
with the same nss cert dbs etc).

> 2017-01-04 13:24:55 [Network] debug 
> /builddir/build/BUILD/qpid-cpp-1.35.0/src/qpid/sys/SocketTransport.cpp:51:qpid::sys::{anonymous}::establishedCommon:
>  Set TCP_NODELAY on connection to [::1]:51976
> 2017-01-04 13:24:57 [System] debug 
> /builddir/build/BUILD/qpid-cpp-1.35.0/src/qpid/sys/AsynchIOHandler.cpp:150:qpid::sys::AsynchIOHandler::readbuff:
>  RECV [qpid.[::1]:5672-[::1]:51976]: INIT(1-0)
> 2017-01-04 13:24:57 [System] debug 
> /builddir/build/BUILD/qpid-cpp-1.35.0/src/qpid/Exception.cpp:43:qpid::Exception::Exception:
>  Exception constructed: SASL layer required!
> 2017-01-04 13:24:57 [System] error 
> /builddir/build/BUILD/qpid-cpp-1.35.0/src/qpid/sys/AsynchIOHandler.cpp:164:qpid::sys::AsynchIOHandler::readbuff:
>  SASL layer required!

This error suggests that the broker did not get the AMQP-SASL protocol
header frame that it expected. Again, not clear to me why that would be.

Are both brokers built against the same version of proton?

[...]
> I don't see any release notes or JIRA issues for 1.36.0 that point out 
> problems or quirks in 1.35.0 for this - any ideas?
>
> This is Fedora 23 Linux.

Have you tried with the rpms?


-
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: One SSL + SASL EXTERNAL queue creation works with qpidd 1.36.0 but not 1.35.0

[Gordon Sim]

On 04/01/17 23:08, Jeff Donner wrote:

# The queue creation is run at this point (reminder)
qpid-config --broker amqps://dev-qpidclient@localhost:5672 \
--ssl-certificate=pki/client/certs/client-cert.pem \
--ssl-key=pki/client/private/client-keys.pem \
--sasl-mechanism=EXTERNAL \
add queue examples


2017-01-04 13:24:55 [Network] trace 
/builddir/build/BUILD/qpid-cpp-1.35.0/src/qpid/sys/ssl/SslSocket.cpp:340:qpid::sys::ssl::SslMuxSocket::accept:
 Accepting connection with optional SSL wrapper.
2017-01-04 13:24:55 [Network] trace 
/builddir/build/BUILD/qpid-cpp-1.35.0/src/qpid/sys/ssl/SslSocket.cpp:345:qpid::sys::ssl::SslMuxSocket::accept:
 Accepted Plaintext connection.
2017-01-04 13:24:55 [Network] debug 
/builddir/build/BUILD/qpid-cpp-1.35.0/src/qpid/sys/SocketTransport.cpp:51:qpid::sys::{anonymous}::establishedCommon:
 Set TCP_NODELAY on connection to [::1]:51976
2017-01-04 13:24:57 [System] debug 
/builddir/build/BUILD/qpid-cpp-1.35.0/src/qpid/sys/AsynchIOHandler.cpp:150:qpid::sys::AsynchIOHandler::readbuff:
 RECV [qpid.[::1]:5672-[::1]:51976]: INIT(1-0)
2017-01-04 13:24:57 [System] debug 
/builddir/build/BUILD/qpid-cpp-1.35.0/src/qpid/Exception.cpp:43:qpid::Exception::Exception:
 Exception constructed: SASL layer required!
2017-01-04 13:24:57 [System] error 
/builddir/build/BUILD/qpid-cpp-1.35.0/src/qpid/sys/AsynchIOHandler.cpp:164:qpid::sys::AsynchIOHandler::readbuff:
 SASL layer required!


Another odd thing..., the protocol header in the trace is for 1.0 (not 
0-10 like in the 1.36 trace) and indeed I believe the error thrown would 
only be thrown on the 1.0 codepath.


I don't think this trace can correspond to the qpid-config connection, 
since the client that tool is based on speaks 0-10 only.




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

RE: One SSL + SASL EXTERNAL queue creation works with qpidd 1.36.0 but not 1.35.0

[Jeff Donner]

Yeah I noticed that 1.35 was doing plaintext. I'll look into why it does that 
and why it's going to 1.0, as you point out.

Thanks!
Jeff

From: Gordon Sim [g...@redhat.com]
Sent: Thursday, January 05, 2017 12:17 PM
To: users@qpid.apache.org
Subject: Re: One SSL + SASL EXTERNAL queue creation works with qpidd 1.36.0 but 
not 1.35.0

On 04/01/17 23:08, Jeff Donner wrote:
> # The queue creation is run at this point (reminder)
> qpid-config --broker amqps://dev-qpidclient@localhost:5672 \
> --ssl-certificate=pki/client/certs/client-cert.pem \
> --ssl-key=pki/client/private/client-keys.pem \
> --sasl-mechanism=EXTERNAL \
> add queue examples
>
>
> 2017-01-04 13:24:55 [Network] trace 
> /builddir/build/BUILD/qpid-cpp-1.35.0/src/qpid/sys/ssl/SslSocket.cpp:340:qpid::sys::ssl::SslMuxSocket::accept:
>  Accepting connection with optional SSL wrapper.
> 2017-01-04 13:24:55 [Network] trace 
> /builddir/build/BUILD/qpid-cpp-1.35.0/src/qpid/sys/ssl/SslSocket.cpp:345:qpid::sys::ssl::SslMuxSocket::accept:
>  Accepted Plaintext connection.
> 2017-01-04 13:24:55 [Network] debug 
> /builddir/build/BUILD/qpid-cpp-1.35.0/src/qpid/sys/SocketTransport.cpp:51:qpid::sys::{anonymous}::establishedCommon:
>  Set TCP_NODELAY on connection to [::1]:51976
> 2017-01-04 13:24:57 [System] debug 
> /builddir/build/BUILD/qpid-cpp-1.35.0/src/qpid/sys/AsynchIOHandler.cpp:150:qpid::sys::AsynchIOHandler::readbuff:
>  RECV [qpid.[::1]:5672-[::1]:51976]: INIT(1-0)
> 2017-01-04 13:24:57 [System] debug 
> /builddir/build/BUILD/qpid-cpp-1.35.0/src/qpid/Exception.cpp:43:qpid::Exception::Exception:
>  Exception constructed: SASL layer required!
> 2017-01-04 13:24:57 [System] error 
> /builddir/build/BUILD/qpid-cpp-1.35.0/src/qpid/sys/AsynchIOHandler.cpp:164:qpid::sys::AsynchIOHandler::readbuff:
>  SASL layer required!

Another odd thing..., the protocol header in the trace is for 1.0 (not
0-10 like in the 1.36 trace) and indeed I believe the error thrown would
only be thrown on the 1.0 codepath.

I don't think this trace can correspond to the qpid-config connection,
since the client that tool is based on speaks 0-10 only.



-
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