[jira] [Commented] (QPID-6933) Factor out a JMS client neutral messaging test suite from system tests

2018-01-04 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/QPID-6933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16312342#comment-16312342
 ] 

ASF subversion and git services commented on QPID-6933:
---

Commit 7624590186189c6d4a801178c4f74636fa72aa39 in qpid-broker-j's branch 
refs/heads/master from [~alex.rufous]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=7624590 ]

QPID-6933: [System Tests] Refactor temporary queue prefix tests as JMS 1.1 
system test


> Factor out a JMS client neutral messaging test suite from system tests
> --
>
> Key: QPID-6933
> URL: https://issues.apache.org/jira/browse/QPID-6933
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Tests
>Reporter: Keith Wall
>Assignee: Alex Rudyy
>
> The existing system testsuite is in a poor state.
> * It is poorly structured
> * Mixes different types of test.  i.e. messaging behaviour with those that 
> test features of the Java Broker (e.g. REST).
> * Many of the tests refer directly to the implementation classes of the Qpid 
> Client 0-8..0-10 client meaning the tests cannot be run using the new client.
> As a first step, we want to factor out a separate messaging system test suite:
> * The tests in this suite will be JMS client neutral.
> * Written in terms of JNDI/JMS client
> * Configurations/Broker observations will be performed via a clean 
> Broker-neutral facade. For instance
> **  a mechanism to cause the queue to be created of a particular type.
> ** a mechanism to observe a queue depth.
> * The tests will be classified by feature (to be defined)
> * The classification system will be used to drive an exclusion feature (to be 
> defined).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (QPID-6933) Factor out a JMS client neutral messaging test suite from system tests

2018-01-04 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/QPID-6933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16312297#comment-16312297
 ] 

ASF subversion and git services commented on QPID-6933:
---

Commit a2e57db7cc45ca4f0b8bb12c83f60ba2a6c6c25d in qpid-broker-j's branch 
refs/heads/master from [~alex.rufous]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=a2e57db ]

QPID-6933: [System Tests] Refactor queue message durability tests as JMS 1.1 
system test


> Factor out a JMS client neutral messaging test suite from system tests
> --
>
> Key: QPID-6933
> URL: https://issues.apache.org/jira/browse/QPID-6933
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Tests
>Reporter: Keith Wall
>Assignee: Alex Rudyy
>
> The existing system testsuite is in a poor state.
> * It is poorly structured
> * Mixes different types of test.  i.e. messaging behaviour with those that 
> test features of the Java Broker (e.g. REST).
> * Many of the tests refer directly to the implementation classes of the Qpid 
> Client 0-8..0-10 client meaning the tests cannot be run using the new client.
> As a first step, we want to factor out a separate messaging system test suite:
> * The tests in this suite will be JMS client neutral.
> * Written in terms of JNDI/JMS client
> * Configurations/Broker observations will be performed via a clean 
> Broker-neutral facade. For instance
> **  a mechanism to cause the queue to be created of a particular type.
> ** a mechanism to observe a queue depth.
> * The tests will be classified by feature (to be defined)
> * The classification system will be used to drive an exclusion feature (to be 
> defined).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (QPID-6933) Factor out a JMS client neutral messaging test suite from system tests

2018-01-04 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/QPID-6933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16312296#comment-16312296
 ] 

ASF subversion and git services commented on QPID-6933:
---

Commit 61389ed54cf1dca3548d4ad2c9450b6232db248a in qpid-broker-j's branch 
refs/heads/master from [~alex.rufous]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=61389ed ]

QPID-6933: [System Tests] Refactor AMQP 1-0 JMS routing tests as JMS 1.1 system 
test


> Factor out a JMS client neutral messaging test suite from system tests
> --
>
> Key: QPID-6933
> URL: https://issues.apache.org/jira/browse/QPID-6933
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Tests
>Reporter: Keith Wall
>Assignee: Alex Rudyy
>
> The existing system testsuite is in a poor state.
> * It is poorly structured
> * Mixes different types of test.  i.e. messaging behaviour with those that 
> test features of the Java Broker (e.g. REST).
> * Many of the tests refer directly to the implementation classes of the Qpid 
> Client 0-8..0-10 client meaning the tests cannot be run using the new client.
> As a first step, we want to factor out a separate messaging system test suite:
> * The tests in this suite will be JMS client neutral.
> * Written in terms of JNDI/JMS client
> * Configurations/Broker observations will be performed via a clean 
> Broker-neutral facade. For instance
> **  a mechanism to cause the queue to be created of a particular type.
> ** a mechanism to observe a queue depth.
> * The tests will be classified by feature (to be defined)
> * The classification system will be used to drive an exclusion feature (to be 
> defined).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (QPID-6933) Factor out a JMS client neutral messaging test suite from system tests

2018-01-04 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/QPID-6933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16312215#comment-16312215
 ] 

ASF subversion and git services commented on QPID-6933:
---

Commit 4542234d5c7cddfd739f5cb5ea97e9fd2ff3ee05 in qpid-broker-j's branch 
refs/heads/master from [~alex.rufous]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=4542234 ]

QPID-6933: [System Tests] Refactor node auto-creation policy tests as JMS 1.1 
system test


> Factor out a JMS client neutral messaging test suite from system tests
> --
>
> Key: QPID-6933
> URL: https://issues.apache.org/jira/browse/QPID-6933
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Tests
>Reporter: Keith Wall
>Assignee: Alex Rudyy
>
> The existing system testsuite is in a poor state.
> * It is poorly structured
> * Mixes different types of test.  i.e. messaging behaviour with those that 
> test features of the Java Broker (e.g. REST).
> * Many of the tests refer directly to the implementation classes of the Qpid 
> Client 0-8..0-10 client meaning the tests cannot be run using the new client.
> As a first step, we want to factor out a separate messaging system test suite:
> * The tests in this suite will be JMS client neutral.
> * Written in terms of JNDI/JMS client
> * Configurations/Broker observations will be performed via a clean 
> Broker-neutral facade. For instance
> **  a mechanism to cause the queue to be created of a particular type.
> ** a mechanism to observe a queue depth.
> * The tests will be classified by feature (to be defined)
> * The classification system will be used to drive an exclusion feature (to be 
> defined).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (QPID-6933) Factor out a JMS client neutral messaging test suite from system tests

2018-01-04 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/QPID-6933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16312213#comment-16312213
 ] 

ASF subversion and git services commented on QPID-6933:
---

Commit 0904d6691a0599de0f2f679439bfc4ccadb5d8a5 in qpid-broker-j's branch 
refs/heads/master from [~alex.rufous]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=0904d66 ]

QPID-6933: [System Tests] Refactor TLS tests as JMS 1.1 system test


> Factor out a JMS client neutral messaging test suite from system tests
> --
>
> Key: QPID-6933
> URL: https://issues.apache.org/jira/browse/QPID-6933
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Tests
>Reporter: Keith Wall
>Assignee: Alex Rudyy
>
> The existing system testsuite is in a poor state.
> * It is poorly structured
> * Mixes different types of test.  i.e. messaging behaviour with those that 
> test features of the Java Broker (e.g. REST).
> * Many of the tests refer directly to the implementation classes of the Qpid 
> Client 0-8..0-10 client meaning the tests cannot be run using the new client.
> As a first step, we want to factor out a separate messaging system test suite:
> * The tests in this suite will be JMS client neutral.
> * Written in terms of JNDI/JMS client
> * Configurations/Broker observations will be performed via a clean 
> Broker-neutral facade. For instance
> **  a mechanism to cause the queue to be created of a particular type.
> ** a mechanism to observe a queue depth.
> * The tests will be classified by feature (to be defined)
> * The classification system will be used to drive an exclusion feature (to be 
> defined).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (QPID-6933) Factor out a JMS client neutral messaging test suite from system tests

2018-01-04 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/QPID-6933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16312214#comment-16312214
 ] 

ASF subversion and git services commented on QPID-6933:
---

Commit 8d028eff837c91aaff411ddea0059833395c0e9b in qpid-broker-j's branch 
refs/heads/master from [~alex.rufous]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=8d028ef ]

QPID-6933: [System Tests] Refactor routing tests as JMS 1.1 system test


> Factor out a JMS client neutral messaging test suite from system tests
> --
>
> Key: QPID-6933
> URL: https://issues.apache.org/jira/browse/QPID-6933
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Tests
>Reporter: Keith Wall
>Assignee: Alex Rudyy
>
> The existing system testsuite is in a poor state.
> * It is poorly structured
> * Mixes different types of test.  i.e. messaging behaviour with those that 
> test features of the Java Broker (e.g. REST).
> * Many of the tests refer directly to the implementation classes of the Qpid 
> Client 0-8..0-10 client meaning the tests cannot be run using the new client.
> As a first step, we want to factor out a separate messaging system test suite:
> * The tests in this suite will be JMS client neutral.
> * Written in terms of JNDI/JMS client
> * Configurations/Broker observations will be performed via a clean 
> Broker-neutral facade. For instance
> **  a mechanism to cause the queue to be created of a particular type.
> ** a mechanism to observe a queue depth.
> * The tests will be classified by feature (to be defined)
> * The classification system will be used to drive an exclusion feature (to be 
> defined).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (QPID-8069) [Qpid JMS AMQP 0-x] An establishment of connection blocks for 30 seconds when TLS handshake failure

2018-01-04 Thread Alex Rudyy (JIRA) 
Alex Rudyy created QPID-8069:


 Summary: [Qpid JMS AMQP 0-x] An establishment of connection blocks 
for 30 seconds when TLS handshake failure
 Key: QPID-8069
 URL: https://issues.apache.org/jira/browse/QPID-8069
 Project: Qpid
  Issue Type: Bug
  Components: JMS AMQP 0-x
Affects Versions: qpid-java-client-0-x-6.3.0
Reporter: Alex Rudyy


AMQTimeoutException is reported after waiting for "maximum state wait time", 
when TLS hand shake fails.

The stack traces like below are reported
{noformat}
2018-01-04 21:59:33,960 DEBUG [main] o.a.q.c.AMQConnection 
Connection(27):amqp://guest:@clientid/?brokerlist='tcp://localhost:46879?trust_store='/tmp/test-profiles/test_resources/ssl/java_client_truststore.jks'_store_password=''='true''
2018-01-04 21:59:33,960 DEBUG [main] o.a.q.c.AMQConnection AMQP version 0-9-1
2018-01-04 21:59:33,960 DEBUG [main] o.a.q.c.p.AMQProtocolSession Using 
ProtocolVersion for Session:0-91
2018-01-04 21:59:33,960 DEBUG [main] o.a.q.c.h.ClientMethodDispatcherImpl New 
Method Dispatcher:AMQProtocolSession[null]
2018-01-04 21:59:33,960 DEBUG [main] o.a.q.c.AMQConnection Connecting with 
ProtocolHandler Version:0-91
2018-01-04 21:59:33,960 DEBUG [main] o.a.q.c.AMQConnectionDelegate_8_0 
Connecting to 
broker:tcp://localhost:46879?trust_store='/tmp/test-profiles/test_resources/ssl/java_client_truststore.jks'_store_password=''='true'
2018-01-04 21:59:33,961 DEBUG [main] o.a.q.t.n.i.IoNetworkTransport Socket 
options SO_RCVBUF : 65535, SO_SNDBUF : 65535, TCP_NODELAY : true
2018-01-04 21:59:33,961 DEBUG [main] o.a.q.t.n.i.IoNetworkTransport Socket 
connection from /127.0.0.1:48680 to localhost/127.0.0.1:46879 established
2018-01-04 21:59:33,961 DEBUG 
[IO-pool-Port-testClientCertificateMissingWhilstNeedingTlsPort-5] 
o.a.q.s.t.NonBlockingConnection Identified transport encryption as TLS
2018-01-04 21:59:33,962 DEBUG [main] o.a.q.c.s.StateWaiter New StateWaiter 
:CONNECTION_NOT_STARTED:[CONNECTION_OPEN, CONNECTION_CLOSED]
2018-01-04 21:59:33,964 DEBUG [IO-/127.0.0.1:48680] 
o.a.q.s.t.NonBlockingConnection Read 172 byte(s)
2018-01-04 21:59:33,973 DEBUG [IO-/127.0.0.1:48680] 
o.a.q.s.t.NonBlockingConnection Written 1825 bytes
2018-01-04 21:59:33,974 DEBUG [IO-/127.0.0.1:48680] 
o.a.q.s.t.NonBlockingConnection Read 0 byte(s)
2018-01-04 21:59:33,982 DEBUG [IO-/127.0.0.1:48680] 
o.a.q.s.t.NonBlockingConnection Read 173 byte(s)
2018-01-04 21:59:33,984 DEBUG [IO-/127.0.0.1:48680] 
o.a.q.s.t.NonBlockingConnection Exception performing I/O for connection 
'/127.0.0.1:48680'
javax.net.ssl.SSLHandshakeException: null cert chain
at sun.security.ssl.Handshaker.checkThrown(Handshaker.java:1478)
at 
sun.security.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:535)
at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:813)
at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:781)
at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:624)
at 
org.apache.qpid.server.bytebuffer.QpidByteBufferFactory.decryptSSL(QpidByteBufferFactory.java:197)
at 
org.apache.qpid.server.bytebuffer.QpidByteBuffer.decryptSSL(QpidByteBuffer.java:68)
at 
org.apache.qpid.server.transport.NonBlockingConnectionTLSDelegate.processData(NonBlockingConnectionTLSDelegate.java:125)
at 
org.apache.qpid.server.transport.NonBlockingConnection.doRead(NonBlockingConnection.java:496)
at 
org.apache.qpid.server.transport.NonBlockingConnection.doWork(NonBlockingConnection.java:270)
at 
org.apache.qpid.server.transport.NetworkConnectionScheduler.processConnection(NetworkConnectionScheduler.java:134)
at 
org.apache.qpid.server.transport.SelectorThread$ConnectionProcessor.processConnection(SelectorThread.java:580)
at 
org.apache.qpid.server.transport.SelectorThread$SelectionTask.performSelect(SelectorThread.java:371)
at 
org.apache.qpid.server.transport.SelectorThread$SelectionTask.run(SelectorThread.java:97)
at 
org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:538)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at 
org.apache.qpid.server.bytebuffer.QpidByteBufferFactory.lambda$null$0(QpidByteBufferFactory.java:464)
at java.lang.Thread.run(Thread.java:745)
Caused by: javax.net.ssl.SSLHandshakeException: null cert chain
at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1666)
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:304)
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:292)
at 
sun.security.ssl.ServerHandshaker.clientCertificate(ServerHandshaker.java:1862)
at

[jira] [Created] (PROTON-1734) [cpp] container.stop() doesn't work when called from non-proactor thread.

2018-01-04 Thread Alan Conway (JIRA) 
Alan Conway created PROTON-1734:
---

 Summary: [cpp] container.stop() doesn't work when called from 
non-proactor thread.
 Key: PROTON-1734
 URL: https://issues.apache.org/jira/browse/PROTON-1734
 Project: Qpid Proton
  Issue Type: Bug
  Components: cpp-binding
Affects Versions: proton-c-0.19.0
Reporter: Alan Conway
Assignee: Alan Conway
 Fix For: proton-c-0.20.0


Using the below code

{code}
#include 
#include 
#include 

int main( int, char** )
{
  try
  {
proton::container c;
c.auto_stop( false );
auto containerThread = std::thread([&]() { std::cout << "CONTAINER IS 
RUNNING" << std::endl; 

  c.run(); std::cout << "CONTAINER IS DONE" << std::endl; });
std::this_thread::sleep_for( std::chrono::seconds( 2 ));
std::cout << "STOPPING CONTAINER" << std::endl;
c.stop();
std::cout << "WAITING FOR CONTAINER" << std::endl;
containerThread.join();
return 0;
  }
  catch( std::exception& e )
  {
std::cerr << e.what() << std::endl;
  }
  return 1;
}
{code}

via
{code}
[rkieley@i7t450s build]$ g++ -g -Wall -Wextra -Wpointer-arith -Wconversion 
-Wformat -Wformat-security -Wformat-y2k -Wsign-promo -Wcast-qual -g3 -ggdb3 
-Wunused-variable -fno-eliminate-unused-debug-types -O3 -DNDEBUG -fPIC 
-DPN_CPP_HAS_LAMBDAS=0  -std=gnu++11  ../attachments/test.cpp -lqpid-proton-cpp 
-lqpid-proton-core -lqpid-proton-proactor -lrt -lpthread -o test
{code}

With both PROACTOR epoll and libuv I see the following when run:

{quote}
[New Thread 0x73c95700 (LWP 20312)]
CONTAINER IS RUNNING
STOPPING CONTAINER
WAITING FOR CONTAINER
^C
Thread 1 "test" received signal SIGINT, Interrupt.
{quote}

When I use CTRL-C to stop waiting after running via gdb and waiting 2 minutes.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (DISPATCH-878) qdrouterd should log real port if port 0 was specified for the listener port property in qdrouterd.conf

2018-01-04 Thread Alan Conway (JIRA) 

[ 
https://issues.apache.org/jira/browse/DISPATCH-878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16312049#comment-16312049
 ] 

Alan Conway commented on DISPATCH-878:
--

Fixed PROTON-1706. You can now get the list of real addresses used by a 
listener once it is open (at the PN_LISTENER_OPEN event)

To print all the listening addresses do something like:

{code}
pn_netaddr_t *na = pn_netaddr_listening(my_listener);
while (na) {
  char str[PN_MAX_ADDR] = "";
  pn_netaddr_str(na, str, sizeof(str));
  log_this_somewhere(str); // Contains bare "host:port"
  na = pn_netaddr_next(na);
}
{code}

> qdrouterd should log real port if port 0 was specified for the listener port 
> property in qdrouterd.conf
> ---
>
> Key: DISPATCH-878
> URL: https://issues.apache.org/jira/browse/DISPATCH-878
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Container
> Environment: OS: Red Hat Linux Server release 6.4
> Dispatch version: 0.7.0
>Reporter: Jeremy
>
> For such a qdrouterd.conf configuration:
> {noformat}
> router {
> mode: standalone
> id: Router.A
> }
> listener {
> host: 0.0.0.0
> *port: 5673*
> authenticatePeer: no
> saslMechanisms: ANONYMOUS
> }
> {noformat}
> qdrouterd logs the port as such:
> {noformat}
> CONN_MGR (info) Configured Listener: 0.0.0.0:5673 proto=any, role=normal
> {noformat}
> When specifying port 0, so that the dispatch router runs on a random 
> available port, the log is as such:
> {noformat}
> CONN_MGR (info) Configured Listener: 0.0.0.0:0 proto=any, role=normal
> {noformat}
> qdrouterd process can log instead the real port that was randomly chosen.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (PROTON-1705) [go] binding puts build artifacts in the source tree

2018-01-04 Thread Alan Conway (JIRA) 

 [ 
https://issues.apache.org/jira/browse/PROTON-1705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alan Conway updated PROTON-1705:

Fix Version/s: proton-c-0.20.0

> [go] binding puts build artifacts in the source tree
> 
>
> Key: PROTON-1705
> URL: https://issues.apache.org/jira/browse/PROTON-1705
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: go-binding
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: proton-c-0.20.0
>
>
> The Go build puts object files in the source tree which is bad practice and 
> causes confusion if artifacts are left behind. Make it do all its work in the 
> build tree.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (DISPATCH-227) Independent filtering of logging to consoles and log files.

2018-01-04 Thread Alan Conway (JIRA) 

 [ 
https://issues.apache.org/jira/browse/DISPATCH-227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alan Conway updated DISPATCH-227:
-
Priority: Minor  (was: Major)

> Independent filtering of logging to consoles and log files.
> ---
>
> Key: DISPATCH-227
> URL: https://issues.apache.org/jira/browse/DISPATCH-227
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Management Agent
>Affects Versions: 0.5
>Reporter: Alan Conway
>Assignee: Alan Conway
>Priority: Minor
>
> Currently the log filter settings are global, the same settings apply to 
> every log destination (files, consoles etc.) We need to be able to configure 
> different log filters on a per-console or per-file basis. We also need a new 
> log output type which sends log messges to an address that a console can 
> subscribe to.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (PROTON-1705) [go] binding puts build artifacts in the source tree

2018-01-04 Thread Alan Conway (JIRA) 

 [ 
https://issues.apache.org/jira/browse/PROTON-1705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alan Conway resolved PROTON-1705.
-
Resolution: Fixed

> [go] binding puts build artifacts in the source tree
> 
>
> Key: PROTON-1705
> URL: https://issues.apache.org/jira/browse/PROTON-1705
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: go-binding
>Reporter: Alan Conway
>Assignee: Alan Conway
>
> The Go build puts object files in the source tree which is bad practice and 
> causes confusion if artifacts are left behind. Make it do all its work in the 
> build tree.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (PROTON-1644) [FreeBSD] Scheme for reusing ports in testing does not work for FreeBSD

2018-01-04 Thread Alan Conway (JIRA) 

 [ 
https://issues.apache.org/jira/browse/PROTON-1644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alan Conway resolved PROTON-1644.
-
Resolution: Fixed

> [FreeBSD] Scheme for reusing ports in testing does not work for FreeBSD
> ---
>
> Key: PROTON-1644
> URL: https://issues.apache.org/jira/browse/PROTON-1644
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: proton-c-0.18.0
> Environment: FreeBSD 10.3-RELEASE-p20
>Reporter: Andrew Stitcher
>Assignee: Alan Conway
>  Labels: freebsd
> Fix For: proton-c-0.20.0
>
>
> The scheme for picking ports using SO_REUSEPORT does not seem to work on 
> FreeBSD producing a bunch of errors like
> {noformat}
> listen error: proton:io: address already in use - listening on localhost:51439
> broker shutdown: proton:io: address already in use - listening on 
> localhost:51439
> {noformat}
> This happens in the tests:
> - 12:ruby-test-container
> - 31:c-proactor-tests
> - 34:cpp-example-container
> - 35:cpp-example-container-ssl



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (PROTON-1644) [FreeBSD] Scheme for reusing ports in testing does not work for FreeBSD

2018-01-04 Thread Alan Conway (JIRA) 

[ 
https://issues.apache.org/jira/browse/PROTON-1644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16312036#comment-16312036
 ] 

Alan Conway commented on PROTON-1644:
-

C++ fixed by PROTON-1733

PROTON-1646 is still valid, although no longer required to address this issue.


> [FreeBSD] Scheme for reusing ports in testing does not work for FreeBSD
> ---
>
> Key: PROTON-1644
> URL: https://issues.apache.org/jira/browse/PROTON-1644
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: proton-c-0.18.0
> Environment: FreeBSD 10.3-RELEASE-p20
>Reporter: Andrew Stitcher
>Assignee: Alan Conway
>  Labels: freebsd
> Fix For: proton-c-0.20.0
>
>
> The scheme for picking ports using SO_REUSEPORT does not seem to work on 
> FreeBSD producing a bunch of errors like
> {noformat}
> listen error: proton:io: address already in use - listening on localhost:51439
> broker shutdown: proton:io: address already in use - listening on 
> localhost:51439
> {noformat}
> This happens in the tests:
> - 12:ruby-test-container
> - 31:c-proactor-tests
> - 34:cpp-example-container
> - 35:cpp-example-container-ssl



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (PROTON-1733) [cpp] Provide access to actual listening port for listen(":0")

2018-01-04 Thread Alan Conway (JIRA) 

 [ 
https://issues.apache.org/jira/browse/PROTON-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alan Conway resolved PROTON-1733.
-
Resolution: Fixed

> [cpp] Provide access to actual listening port for listen(":0")
> --
>
> Key: PROTON-1733
> URL: https://issues.apache.org/jira/browse/PROTON-1733
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: cpp-binding
>Affects Versions: proton-c-0.19.0
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: proton-c-0.20.0
>
>
> Add
> int proton::listener::port() 
> to get the actual listening port used by an open listener, for the case where 
> the listener was started with port=0.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (PROTON-1733) [cpp] Provide access to actual listening port for listen(":0")

2018-01-04 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/PROTON-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16312031#comment-16312031
 ] 

ASF subversion and git services commented on PROTON-1733:
-

Commit c7fcec16cf0f46a327828d80e81b6eb29d421a6b in qpid-proton's branch 
refs/heads/master from [~aconway]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=c7fcec1 ]

PROTON-1733: [cpp] fix proton::url to handle //... URLs

Previous implementation failed to parse URLs starting with "//" correctly.


> [cpp] Provide access to actual listening port for listen(":0")
> --
>
> Key: PROTON-1733
> URL: https://issues.apache.org/jira/browse/PROTON-1733
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: cpp-binding
>Affects Versions: proton-c-0.19.0
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: proton-c-0.20.0
>
>
> Add
> int proton::listener::port() 
> to get the actual listening port used by an open listener, for the case where 
> the listener was started with port=0.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (PROTON-1733) [cpp] Provide access to actual listening port for listen(":0")

2018-01-04 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/PROTON-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16312032#comment-16312032
 ] 

ASF subversion and git services commented on PROTON-1733:
-

Commit 59cedf3a5a7aa9478ec30ce6ccf448f04fbbd2e1 in qpid-proton's branch 
refs/heads/master from [~aconway]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=59cedf3 ]

PROTON-1733: [cpp] remove helloworld_direct example

A program that talks to itself is strange and confusing.
Peer-to-peer AMQP is better illustrated by the direct_send/direct_recv examples.


> [cpp] Provide access to actual listening port for listen(":0")
> --
>
> Key: PROTON-1733
> URL: https://issues.apache.org/jira/browse/PROTON-1733
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: cpp-binding
>Affects Versions: proton-c-0.19.0
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: proton-c-0.20.0
>
>
> Add
> int proton::listener::port() 
> to get the actual listening port used by an open listener, for the case where 
> the listener was started with port=0.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (PROTON-1733) [cpp] Provide access to actual listening port for listen(":0")

2018-01-04 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/PROTON-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16312033#comment-16312033
 ] 

ASF subversion and git services commented on PROTON-1733:
-

Commit d6cef7b8ca32c470cbae57e6f7a6b7e4c508a06d in qpid-proton's branch 
refs/heads/master from [~aconway]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=d6cef7b ]

PROTON-1733: [cpp] access actual listening port for listen on port 0

Added proton::listener::port() to provide access to the port.
Updated tests to listen on port 0 as a safe, portable way to allocate ports.


> [cpp] Provide access to actual listening port for listen(":0")
> --
>
> Key: PROTON-1733
> URL: https://issues.apache.org/jira/browse/PROTON-1733
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: cpp-binding
>Affects Versions: proton-c-0.19.0
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: proton-c-0.20.0
>
>
> Add
> int proton::listener::port() 
> to get the actual listening port used by an open listener, for the case where 
> the listener was started with port=0.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (PROTON-1732) [OSX] Enable swig for the Travis CI build

2018-01-04 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/PROTON-1732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16311969#comment-16311969
 ] 

ASF GitHub Bot commented on PROTON-1732:


Github user RoddieKieley commented on the issue:

https://github.com/apache/qpid-proton/pull/135
  
@astitcher Thanks for the quick feedback. Will address the 2nd and 3rd 
points and push changes for review as well as take a look at the BUILD_PERL 
configuration.


> [OSX] Enable swig for the Travis CI build
> -
>
> Key: PROTON-1732
> URL: https://issues.apache.org/jira/browse/PROTON-1732
> Project: Qpid Proton
>  Issue Type: Sub-task
>  Components: proton-c
>Affects Versions: proton-c-0.19.0
> Environment: Travis CI
> Xcode 7.3, 9
>Reporter: Roddie Kieley
>Priority: Minor
> Fix For: proton-c-future
>
>
> Comparing the current travis builds for linux and osx we see that the linux 
> builds cover ruby whereas the osx builds do not. Swig is required for this to 
> occur.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[GitHub] qpid-proton issue #135: PROTON-1732: [OSX] Enable swig for the Travis CI bui...

2018-01-04 Thread RoddieKieley 
Github user RoddieKieley commented on the issue:

https://github.com/apache/qpid-proton/pull/135
  
@astitcher Thanks for the quick feedback. Will address the 2nd and 3rd 
points and push changes for review as well as take a look at the BUILD_PERL 
configuration.


---

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

[jira] [Commented] (QPID-8038) [Broker-J][System Tests] Add protocol system test suites for AMQP 0-x

2018-01-04 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/QPID-8038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16311868#comment-16311868
 ] 

ASF subversion and git services commented on QPID-8038:
---

Commit a9e61c16b742d266a9b75d54c18c76fcd9341c8a in qpid-broker-j's branch 
refs/heads/master from [~k-wall]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=a9e61c1 ]

QPID-8038: [Broker-J] [AMQP 0-x] Add tests related to protocol negotiation and 
oevrsized frames.


> [Broker-J][System Tests] Add protocol system test suites for AMQP 0-x
> -
>
> Key: QPID-8038
> URL: https://issues.apache.org/jira/browse/QPID-8038
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J, Java Tests
>Reporter: Alex Rudyy
>
> We need a test frameworks which would allow creation of tests which would be 
> sending the AMQP 0-x performatives over TCP and receiving and asserting 
> broker responses.
> The framework should satisfy the following requirements:
> * It should allow running tests against other AMQP brokers
> * The framework should encapsulate starting/stopping of broker and queue 
> creation/deletion under special interface(s) which can be implemented by the 
> Broker developers in order to run tests against different Broker 
> implementations
> * Tests should be able to start and stop broker if required or configured
> * Tests should be able to generate AMQP performatives and assert received 
> peer's AMQP performatives
> * The framework should allow using other transport than TCP if required
> * The framework should be based on AMQP 0-x  implementations of Broker-J



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (QPID-8038) [Broker-J][System Tests] Add protocol system test suites for AMQP 0-x

2018-01-04 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/QPID-8038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16311869#comment-16311869
 ] 

ASF subversion and git services commented on QPID-8038:
---

Commit 99fa51f01cbd03e5712821bcdd782e59584c175f in qpid-broker-j's branch 
refs/heads/master from [~k-wall]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=99fa51f ]

QPID-8038: [Broker-J] [AMQP 0-x/1.0]  Add heartbeating/idle tests to protocol 
suites


> [Broker-J][System Tests] Add protocol system test suites for AMQP 0-x
> -
>
> Key: QPID-8038
> URL: https://issues.apache.org/jira/browse/QPID-8038
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J, Java Tests
>Reporter: Alex Rudyy
>
> We need a test frameworks which would allow creation of tests which would be 
> sending the AMQP 0-x performatives over TCP and receiving and asserting 
> broker responses.
> The framework should satisfy the following requirements:
> * It should allow running tests against other AMQP brokers
> * The framework should encapsulate starting/stopping of broker and queue 
> creation/deletion under special interface(s) which can be implemented by the 
> Broker developers in order to run tests against different Broker 
> implementations
> * Tests should be able to start and stop broker if required or configured
> * Tests should be able to generate AMQP performatives and assert received 
> peer's AMQP performatives
> * The framework should allow using other transport than TCP if required
> * The framework should be based on AMQP 0-x  implementations of Broker-J



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (PROTON-1718) (Proton-J) Custom Sasl

2018-01-04 Thread Tim Taylor (JIRA) 

[ 
https://issues.apache.org/jira/browse/PROTON-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16311814#comment-16311814
 ] 

Tim Taylor commented on PROTON-1718:


And if the only time the reactor does IO processing is when it receives an 
event, when is the appropriate event to send the response? I've tried sending 
the response at onReactorQuiesced(), onSelectableWritable(), etc. and none of 
them seem to be the right time. Because the responses never make it to the 
service. 

So far, the only event that I can send upon and have it successfully sent to 
the service is the handleChallenge() event within the SaslImpl, but you don't 
want that to be accessible, so I'm stuck. 

> (Proton-J) Custom Sasl
> --
>
> Key: PROTON-1718
> URL: https://issues.apache.org/jira/browse/PROTON-1718
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-j
>Affects Versions: proton-j-0.24.0
>Reporter: Tim Taylor
>  Labels: features
>
> I would like to be able to provide a custom SASL implementation for Proton-j 
> to use instead of being forced to use the default SaslImpl.java 
> implementation.
> Ideally, code like below would be possible
> private class CustomSasl implements org.apache.qpid.proton.engine.Sasl
> {
> ...
> }
> ...
> ...
> //transport.sasl(...) saves the provided sasl implementation and uses it 
> internally
> Sasl sasl = transport.sasl(new CustomSasl());
> Do you currently have a workaround that would allow me to use Proton-J this 
> way?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (PROTON-1733) [cpp] Provide access to actual listening port for listen(":0")

2018-01-04 Thread Alan Conway (JIRA) 
Alan Conway created PROTON-1733:
---

 Summary: [cpp] Provide access to actual listening port for 
listen(":0")
 Key: PROTON-1733
 URL: https://issues.apache.org/jira/browse/PROTON-1733
 Project: Qpid Proton
  Issue Type: Improvement
  Components: cpp-binding
Affects Versions: proton-c-0.19.0
Reporter: Alan Conway
Assignee: Alan Conway
 Fix For: proton-c-0.20.0


Add

int proton::listener::port() 

to get the actual listening port used by an open listener, for the case where 
the listener was started with port=0.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (PROTON-1706) pn_listener_t provide access to actual listening port

2018-01-04 Thread Andrew Stitcher (JIRA) 

[ 
https://issues.apache.org/jira/browse/PROTON-1706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16311781#comment-16311781
 ] 

Andrew Stitcher commented on PROTON-1706:
-

Did I say I really hate this whole concept!

In the past we've introduced the idea of listening to port 0 and then being 
able to find out later what the actual port was. However I don't think it 
turned out to have been a good idea.

* It essentially only useful for testing - and adding an API just for testing 
isn't a wonderful idea IMO.
* We already have a better more generally useful scheme to cover the same 
testing case - passing in a socket to the proactor.

So I really can't see the point in doing this then doing the pass in a socket 
API - just do the latter.

> pn_listener_t provide access to actual listening port
> -
>
> Key: PROTON-1706
> URL: https://issues.apache.org/jira/browse/PROTON-1706
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: proton-c-0.18.1
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: proton-c-0.20.0
>
>
> Allow access to the actual listening port of a pn_listener_t so that the 
> actual address is available when listening on port 0. 
> Proposed API:
> {code}
> /**
>  * Get the listening addresses of a listener.
>  * A listener can have more than one address for several reasons:
>  * - DNS host records may indicate more than one address
>  * - On a multi-homed host, listening on the default host "" will listen on 
> all local addresses.
>  * - Some IPv4/IPV6 configurations may expand a single address into a v4/v6 
> pair.
>  *
>  * @param l points to the listener
>  * @param addrs an array of `pn_netaddr_t*` to be filled with pointers the 
> listening addresses
>  *  Pointers are invalid after the listener closes (PN_LISTENER_CLOSE event 
> is handled)
>  * @param len is the length of the array @p addrs
>  * @return The actual number of addresses used for listening. This may be:
>  *  - 0: addresses are unavailable.
>  *  - <= @p len:  all addresses were copied to @p addrs, remaining entries 
> were set to NULL.
>  *  - > @p len: the first @p len addresses were copied to @p addr.
>  *  `pn_netaddr_listen(l, NULL, 0)` returns the number of listening addresses.
>  */
> PNP_EXTERN const size_t pn_netaddr_listen(pn_listener_t *l, pn_netaddr_t** 
> addrs, size_t len);
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (PROTON-1644) [FreeBSD] Scheme for reusing ports in testing does not work for FreeBSD

2018-01-04 Thread Alan Conway (JIRA) 

[ 
https://issues.apache.org/jira/browse/PROTON-1644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16311774#comment-16311774
 ] 

Alan Conway commented on PROTON-1644:
-

C tests and examples fixed by PROTON-1706, using listen ":0" to safely choose a 
port.
Ruby examples fixed by PROTON-1064, use listening socket created externally.
C++ remains to be addressed

> [FreeBSD] Scheme for reusing ports in testing does not work for FreeBSD
> ---
>
> Key: PROTON-1644
> URL: https://issues.apache.org/jira/browse/PROTON-1644
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: proton-c-0.18.0
> Environment: FreeBSD 10.3-RELEASE-p20
>Reporter: Andrew Stitcher
>Assignee: Alan Conway
>  Labels: freebsd
> Fix For: proton-c-0.20.0
>
>
> The scheme for picking ports using SO_REUSEPORT does not seem to work on 
> FreeBSD producing a bunch of errors like
> {noformat}
> listen error: proton:io: address already in use - listening on localhost:51439
> broker shutdown: proton:io: address already in use - listening on 
> localhost:51439
> {noformat}
> This happens in the tests:
> - 12:ruby-test-container
> - 31:c-proactor-tests
> - 34:cpp-example-container
> - 35:cpp-example-container-ssl



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (PROTON-1706) pn_listener_t provide access to actual listening port

2018-01-04 Thread Alan Conway (JIRA) 

 [ 
https://issues.apache.org/jira/browse/PROTON-1706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alan Conway resolved PROTON-1706.
-
Resolution: Fixed

> pn_listener_t provide access to actual listening port
> -
>
> Key: PROTON-1706
> URL: https://issues.apache.org/jira/browse/PROTON-1706
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: proton-c-0.18.1
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: proton-c-0.20.0
>
>
> Allow access to the actual listening port of a pn_listener_t so that the 
> actual address is available when listening on port 0. 
> Proposed API:
> {code}
> /**
>  * Get the listening addresses of a listener.
>  * A listener can have more than one address for several reasons:
>  * - DNS host records may indicate more than one address
>  * - On a multi-homed host, listening on the default host "" will listen on 
> all local addresses.
>  * - Some IPv4/IPV6 configurations may expand a single address into a v4/v6 
> pair.
>  *
>  * @param l points to the listener
>  * @param addrs an array of `pn_netaddr_t*` to be filled with pointers the 
> listening addresses
>  *  Pointers are invalid after the listener closes (PN_LISTENER_CLOSE event 
> is handled)
>  * @param len is the length of the array @p addrs
>  * @return The actual number of addresses used for listening. This may be:
>  *  - 0: addresses are unavailable.
>  *  - <= @p len:  all addresses were copied to @p addrs, remaining entries 
> were set to NULL.
>  *  - > @p len: the first @p len addresses were copied to @p addr.
>  *  `pn_netaddr_listen(l, NULL, 0)` returns the number of listening addresses.
>  */
> PNP_EXTERN const size_t pn_netaddr_listen(pn_listener_t *l, pn_netaddr_t** 
> addrs, size_t len);
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (PROTON-1706) pn_listener_t provide access to actual listening port

2018-01-04 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/PROTON-1706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16311758#comment-16311758
 ] 

ASF subversion and git services commented on PROTON-1706:
-

Commit 7bc25c6117350f55572c0b628c9f9fd29d68c7d9 in qpid-proton's branch 
refs/heads/master from [~aconway]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=7bc25c6 ]

PROTON-1706: pn_listener_t provide access to actual listening port

pn_netaddr_listening() provides list of pn_netaddr_t addresses for a listener.

Implemented in all proactors: epoll, libuv, iocp
Updated C tests to listen on port 0 for safe, portable dynamic port allocation.


> pn_listener_t provide access to actual listening port
> -
>
> Key: PROTON-1706
> URL: https://issues.apache.org/jira/browse/PROTON-1706
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: proton-c-0.18.1
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: proton-c-0.20.0
>
>
> Allow access to the actual listening port of a pn_listener_t so that the 
> actual address is available when listening on port 0. 
> Proposed API:
> {code}
> /**
>  * Get the listening addresses of a listener.
>  * A listener can have more than one address for several reasons:
>  * - DNS host records may indicate more than one address
>  * - On a multi-homed host, listening on the default host "" will listen on 
> all local addresses.
>  * - Some IPv4/IPV6 configurations may expand a single address into a v4/v6 
> pair.
>  *
>  * @param l points to the listener
>  * @param addrs an array of `pn_netaddr_t*` to be filled with pointers the 
> listening addresses
>  *  Pointers are invalid after the listener closes (PN_LISTENER_CLOSE event 
> is handled)
>  * @param len is the length of the array @p addrs
>  * @return The actual number of addresses used for listening. This may be:
>  *  - 0: addresses are unavailable.
>  *  - <= @p len:  all addresses were copied to @p addrs, remaining entries 
> were set to NULL.
>  *  - > @p len: the first @p len addresses were copied to @p addr.
>  *  `pn_netaddr_listen(l, NULL, 0)` returns the number of listening addresses.
>  */
> PNP_EXTERN const size_t pn_netaddr_listen(pn_listener_t *l, pn_netaddr_t** 
> addrs, size_t len);
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (PROTON-1706) pn_listener_t provide access to actual listening port

2018-01-04 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/PROTON-1706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16311759#comment-16311759
 ] 

ASF subversion and git services commented on PROTON-1706:
-

Commit 4dfe296920c9345dfbe8c9c535cbeb27055c01c2 in qpid-proton's branch 
refs/heads/master from [~aconway]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=4dfe296 ]

PROTON-1706: fix compiler warnings in windows c examples


> pn_listener_t provide access to actual listening port
> -
>
> Key: PROTON-1706
> URL: https://issues.apache.org/jira/browse/PROTON-1706
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: proton-c-0.18.1
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: proton-c-0.20.0
>
>
> Allow access to the actual listening port of a pn_listener_t so that the 
> actual address is available when listening on port 0. 
> Proposed API:
> {code}
> /**
>  * Get the listening addresses of a listener.
>  * A listener can have more than one address for several reasons:
>  * - DNS host records may indicate more than one address
>  * - On a multi-homed host, listening on the default host "" will listen on 
> all local addresses.
>  * - Some IPv4/IPV6 configurations may expand a single address into a v4/v6 
> pair.
>  *
>  * @param l points to the listener
>  * @param addrs an array of `pn_netaddr_t*` to be filled with pointers the 
> listening addresses
>  *  Pointers are invalid after the listener closes (PN_LISTENER_CLOSE event 
> is handled)
>  * @param len is the length of the array @p addrs
>  * @return The actual number of addresses used for listening. This may be:
>  *  - 0: addresses are unavailable.
>  *  - <= @p len:  all addresses were copied to @p addrs, remaining entries 
> were set to NULL.
>  *  - > @p len: the first @p len addresses were copied to @p addr.
>  *  `pn_netaddr_listen(l, NULL, 0)` returns the number of listening addresses.
>  */
> PNP_EXTERN const size_t pn_netaddr_listen(pn_listener_t *l, pn_netaddr_t** 
> addrs, size_t len);
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (PROTON-1732) [OSX] Enable swig for the Travis CI build

2018-01-04 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/PROTON-1732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16311587#comment-16311587
 ] 

ASF GitHub Bot commented on PROTON-1732:


Github user astitcher commented on the issue:

https://github.com/apache/qpid-proton/pull/135
  
Hmm, not quite sure about this:
* The actual change seems fine, although ISTR putting in an explicit 
turning off for PERL for apple builds some years ago, so I'm surprised you 
needed to do this (but not an actual problem).
* All of the ruby tests are crashing, so maybe turning ruby off until we 
investigate and fix might be good, we can't have merging this change make the 
Travis master CI fail.
* Even though cmake does find and use swig, the most important thing - the 
python tests - still don't build/run because cmake finds a mismatched libpython 
with a different version from the python interpreter it finds.

So this is a useful step, but not a real advance over where are already are.


> [OSX] Enable swig for the Travis CI build
> -
>
> Key: PROTON-1732
> URL: https://issues.apache.org/jira/browse/PROTON-1732
> Project: Qpid Proton
>  Issue Type: Sub-task
>  Components: proton-c
>Affects Versions: proton-c-0.19.0
> Environment: Travis CI
> Xcode 7.3, 9
>Reporter: Roddie Kieley
>Priority: Minor
> Fix For: proton-c-future
>
>
> Comparing the current travis builds for linux and osx we see that the linux 
> builds cover ruby whereas the osx builds do not. Swig is required for this to 
> occur.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[GitHub] qpid-proton issue #135: PROTON-1732: [OSX] Enable swig for the Travis CI bui...

2018-01-04 Thread astitcher 
Github user astitcher commented on the issue:

https://github.com/apache/qpid-proton/pull/135
  
Hmm, not quite sure about this:
* The actual change seems fine, although ISTR putting in an explicit 
turning off for PERL for apple builds some years ago, so I'm surprised you 
needed to do this (but not an actual problem).
* All of the ruby tests are crashing, so maybe turning ruby off until we 
investigate and fix might be good, we can't have merging this change make the 
Travis master CI fail.
* Even though cmake does find and use swig, the most important thing - the 
python tests - still don't build/run because cmake finds a mismatched libpython 
with a different version from the python interpreter it finds.

So this is a useful step, but not a real advance over where are already are.


---

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

[jira] [Commented] (DISPATCH-906) Document Kerberos integration

2018-01-04 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/DISPATCH-906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16311464#comment-16311464
 ] 

ASF GitHub Bot commented on DISPATCH-906:
-

GitHub user bhardesty opened a pull request:

https://github.com/apache/qpid-dispatch/pull/241

DISPATCH-906 Create procedure for integrating dispatch router with kerberos

@ted-ross can you please review for technical accuracy?

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/bhardesty/qpid-dispatch 
DISPATCH-906-kerberos-integration

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/qpid-dispatch/pull/241.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #241


commit 2723ccbd0b8e8a75846668808756bcfceb57c0d5
Author: Ben Hardesty 
Date:   2018-01-03T22:28:36Z

Create procedure for integrating dispatch router with kerberos




> Document Kerberos integration
> -
>
> Key: DISPATCH-906
> URL: https://issues.apache.org/jira/browse/DISPATCH-906
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Documentation
>Reporter: Ben Hardesty
>Assignee: Ben Hardesty
>
> Document requirements and for accepting Kerberos authenticated connections.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[GitHub] qpid-dispatch pull request #241: DISPATCH-906 Create procedure for integrati...

2018-01-04 Thread bhardesty 
GitHub user bhardesty opened a pull request:

https://github.com/apache/qpid-dispatch/pull/241

DISPATCH-906 Create procedure for integrating dispatch router with kerberos

@ted-ross can you please review for technical accuracy?

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/bhardesty/qpid-dispatch 
DISPATCH-906-kerberos-integration

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/qpid-dispatch/pull/241.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #241


commit 2723ccbd0b8e8a75846668808756bcfceb57c0d5
Author: Ben Hardesty 
Date:   2018-01-03T22:28:36Z

Create procedure for integrating dispatch router with kerberos




---

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