[GitHub] qpid-dispatch pull request #222: Add missing delivery decref when presettled...

2017-11-17 Thread kgiusti 
GitHub user kgiusti opened a pull request:

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

Add missing delivery decref when presettled.  Related to #213



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

$ git pull https://github.com/kgiusti/dispatch decref-fix

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

https://github.com/apache/qpid-dispatch/pull/222.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 #222


commit ae00e82d2dfac203a71ac2dd8d565539fe444c3d
Author: Kenneth Giusti 
Date:   2017-11-18T02:27:59Z

Add missing delivery decref when presettled.  Related to #213




---

-
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

2017-11-17 Thread ASF subversion and git services (JIRA) 

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

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

Commit 06e53d7a5f6cb942a2706dffe340018b659aa077 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=06e53d7 ]

QPID-8038: [Broker-J][System Tests] Introduce new module 'protocol-tests-core' 
and move test common functionality into it


> [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] [Resolved] (PROTON-1064) ruby: native IO based on connection_driver.c

2017-11-17 Thread Alan Conway (JIRA) 

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

Alan Conway resolved PROTON-1064.
-
Resolution: Fixed

> ruby: native IO based on connection_driver.c 
> -
>
> Key: PROTON-1064
> URL: https://issues.apache.org/jira/browse/PROTON-1064
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: ruby-binding
>Affects Versions: 0.11.0
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: proton-c-0.19.0
>
>
> Refactor ruby binding to use a native Ruby IO driver with the C 
> pn_connection_driver for AMQP protocol support. 
> Ruby ConnectionDriver - drive a single connection, single threaded
> - Use any ruby IO subclass
> - Works with native Ruby polling primitives
> - Avoids Ruby threading issue with GVL (all IO is done in Ruby) 
> - Thread safe function injection for MT use.
> Client/server examples using native ruby connect,  multi-threaded broker 
> example using ruby listen. 



--
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-1689) [cpp] exception thrown in handler can result in garbage exception from run()

2017-11-17 Thread ASF subversion and git services (JIRA) 

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

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

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

PROTON-1689: [cpp] exception in handler results in garbage exception from run()

Was using a pointer to an out-of-scope exception message to construct a new 
exception.


> [cpp] exception thrown in handler can result in garbage exception from run()
> 
>
> Key: PROTON-1689
> URL: https://issues.apache.org/jira/browse/PROTON-1689
> Project: Qpid Proton
>  Issue Type: Bug
>Affects Versions: proton-c-0.18.1
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: proton-c-0.19.0
>
>
> Container is using a pointer to an out-of-scope exception message to 
> construct a new exception, resulting in garbage message or possible core dump.



--
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-1689) [cpp] exception thrown in handler can result in garbage exception from run()

2017-11-17 Thread Alan Conway (JIRA) 
Alan Conway created PROTON-1689:
---

 Summary: [cpp] exception thrown in handler can result in garbage 
exception from run()
 Key: PROTON-1689
 URL: https://issues.apache.org/jira/browse/PROTON-1689
 Project: Qpid Proton
  Issue Type: Bug
Affects Versions: proton-c-0.18.1
Reporter: Alan Conway
Assignee: Alan Conway
 Fix For: proton-c-0.19.0


Container is using a pointer to an out-of-scope exception message to construct 
a new exception, resulting in garbage message or possible core dump.



--
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 #221: DISPATCH-880 - Document initialHandshakeTim...

2017-11-17 Thread bhardesty 
GitHub user bhardesty opened a pull request:

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

DISPATCH-880 - Document initialHandshakeTimeoutSeconds (WIP)

**Note:** This doc update is under review. Please do not merge yet.

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

I added the "initialHandshakeTimeoutSeconds" attribute to the configuration 
reference.

(As an aside, the "configuration reference" is an artifact in the new 
Dispatch Router book. It needs to be replaced, likely with the management 
schema reference that's automatically generated from qdrouter.json. As a 
temporary measure, I just added the new attribute to the config ref so that 
it's complete.)

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

$ git pull https://github.com/bhardesty/qpid-dispatch 
dispatch-880-disconnect-connections

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

https://github.com/apache/qpid-dispatch/pull/221.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 #221


commit a084630258e02a02cb159186a5b145ca60d1d80e
Author: Ben Hardesty 
Date:   2017-11-17T20:46:14Z

Add initialHandshakeTimeoutSeconds to config ref




---

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

[jira] [Commented] (DISPATCH-880) Document how Dispatch Router disconnects connections

2017-11-17 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on DISPATCH-880:
-

GitHub user bhardesty opened a pull request:

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

DISPATCH-880 - Document initialHandshakeTimeoutSeconds (WIP)

**Note:** This doc update is under review. Please do not merge yet.

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

I added the "initialHandshakeTimeoutSeconds" attribute to the configuration 
reference.

(As an aside, the "configuration reference" is an artifact in the new 
Dispatch Router book. It needs to be replaced, likely with the management 
schema reference that's automatically generated from qdrouter.json. As a 
temporary measure, I just added the new attribute to the config ref so that 
it's complete.)

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

$ git pull https://github.com/bhardesty/qpid-dispatch 
dispatch-880-disconnect-connections

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

https://github.com/apache/qpid-dispatch/pull/221.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 #221


commit a084630258e02a02cb159186a5b145ca60d1d80e
Author: Ben Hardesty 
Date:   2017-11-17T20:46:14Z

Add initialHandshakeTimeoutSeconds to config ref




> Document how Dispatch Router disconnects connections
> 
>
> Key: DISPATCH-880
> URL: https://issues.apache.org/jira/browse/DISPATCH-880
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Documentation
>Reporter: Ben Hardesty
>Assignee: Ben Hardesty
>




--
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 #130: Add coverage reporting for the Ruby binding

2017-11-17 Thread codecov-io 
Github user codecov-io commented on the issue:

https://github.com/apache/qpid-proton/pull/130
  
# [Codecov](https://codecov.io/gh/apache/qpid-proton/pull/130?src=pr=h1) 
Report
> Merging 
[#130](https://codecov.io/gh/apache/qpid-proton/pull/130?src=pr=desc) into 
[master](https://codecov.io/gh/apache/qpid-proton/commit/9de60a86f5bdb3a47bfc0015a1e5ff9c595fa5de?src=pr=desc)
 will **decrease** coverage by `0.38%`.
> The diff coverage is `n/a`.

[![Impacted file tree 
graph](https://codecov.io/gh/apache/qpid-proton/pull/130/graphs/tree.svg?token=UKKzV9XnFF=650=150=pr)](https://codecov.io/gh/apache/qpid-proton/pull/130?src=pr=tree)

```diff
@@Coverage Diff @@
##   master #130  +/-   ##
==
- Coverage   78.65%   78.27%   -0.39% 
==
  Files 231  300  +69 
  Lines   3055233493+2941 
  Branches 2905 2903   -2 
==
+ Hits2403226216+2184 
- Misses   4878 5640 +762 
+ Partials 1642 1637   -5
```


| [Impacted 
Files](https://codecov.io/gh/apache/qpid-proton/pull/130?src=pr=tree) | 
Coverage Δ | |
|---|---|---|
| 
[examples/cpp/scheduled\_send\_03.cpp](https://codecov.io/gh/apache/qpid-proton/pull/130?src=pr=tree#diff-ZXhhbXBsZXMvY3BwL3NjaGVkdWxlZF9zZW5kXzAzLmNwcA==)
 | `84.44% <0%> (-2.23%)` | :arrow_down: |
| 
[proton-c/bindings/ruby/lib/util/condition.rb](https://codecov.io/gh/apache/qpid-proton/pull/130?src=pr=tree#diff-cHJvdG9uLWMvYmluZGluZ3MvcnVieS9saWIvdXRpbC9jb25kaXRpb24ucmI=)
 | `68.18% <0%> (ø)` | |
| 
[...dings/ruby/lib/handler/incoming\_message\_handler.rb](https://codecov.io/gh/apache/qpid-proton/pull/130?src=pr=tree#diff-cHJvdG9uLWMvYmluZGluZ3MvcnVieS9saWIvaGFuZGxlci9pbmNvbWluZ19tZXNzYWdlX2hhbmRsZXIucmI=)
 | `64.51% <0%> (ø)` | |
| 
[proton-c/bindings/ruby/lib/core/transport.rb](https://codecov.io/gh/apache/qpid-proton/pull/130?src=pr=tree#diff-cHJvdG9uLWMvYmluZGluZ3MvcnVieS9saWIvY29yZS90cmFuc3BvcnQucmI=)
 | `75.64% <0%> (ø)` | |
| 
[proton-c/bindings/ruby/lib/reactor/ssl\_config.rb](https://codecov.io/gh/apache/qpid-proton/pull/130?src=pr=tree#diff-cHJvdG9uLWMvYmluZGluZ3MvcnVieS9saWIvcmVhY3Rvci9zc2xfY29uZmlnLnJi)
 | `45.45% <0%> (ø)` | |
| 
[proton-c/bindings/ruby/lib/codec/data.rb](https://codecov.io/gh/apache/qpid-proton/pull/130?src=pr=tree#diff-cHJvdG9uLWMvYmluZGluZ3MvcnVieS9saWIvY29kZWMvZGF0YS5yYg==)
 | `93.2% <0%> (ø)` | |
| 
[proton-c/bindings/ruby/lib/util/wrapper.rb](https://codecov.io/gh/apache/qpid-proton/pull/130?src=pr=tree#diff-cHJvdG9uLWMvYmluZGluZ3MvcnVieS9saWIvdXRpbC93cmFwcGVyLnJi)
 | `92.68% <0%> (ø)` | |
| 
[proton-c/bindings/ruby/lib/reactor/reactor.rb](https://codecov.io/gh/apache/qpid-proton/pull/130?src=pr=tree#diff-cHJvdG9uLWMvYmluZGluZ3MvcnVieS9saWIvcmVhY3Rvci9yZWFjdG9yLnJi)
 | `31.31% <0%> (ø)` | |
| 
[proton-c/bindings/ruby/lib/core/ssl.rb](https://codecov.io/gh/apache/qpid-proton/pull/130?src=pr=tree#diff-cHJvdG9uLWMvYmluZGluZ3MvcnVieS9saWIvY29yZS9zc2wucmI=)
 | `41.86% <0%> (ø)` | |
| 
[proton-c/bindings/ruby/tests/test\_tools.rb](https://codecov.io/gh/apache/qpid-proton/pull/130?src=pr=tree#diff-cHJvdG9uLWMvYmluZGluZ3MvcnVieS90ZXN0cy90ZXN0X3Rvb2xzLnJi)
 | `74.54% <0%> (ø)` | |
| ... and [67 
more](https://codecov.io/gh/apache/qpid-proton/pull/130?src=pr=tree-more) | |

--

[Continue to review full report at 
Codecov](https://codecov.io/gh/apache/qpid-proton/pull/130?src=pr=continue).
> **Legend** - [Click here to learn 
more](https://docs.codecov.io/docs/codecov-delta)
> `Δ = absolute  (impact)`, `ø = not affected`, `? = missing 
data`
> Powered by 
[Codecov](https://codecov.io/gh/apache/qpid-proton/pull/130?src=pr=footer). 
Last update 
[9de60a8...698cb38](https://codecov.io/gh/apache/qpid-proton/pull/130?src=pr=lastupdated).
 Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments).



---

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

[jira] [Commented] (DISPATCH-879) Document how Dispatch Router uses alternate failover URLs

2017-11-17 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on DISPATCH-879:
-

Github user ganeshmurthy commented on a diff in the pull request:

https://github.com/apache/qpid-dispatch/pull/220#discussion_r151789336
  
--- Diff: doc/new-book/configuration-connections.adoc ---
@@ -56,7 +56,10 @@ If you have set up SSL/TLS or SASL in your environment, 
you can configure the ro
 [[adding_outgoing_connections]]
 == Adding Outgoing Connections
 
-Configuring outgoing connections involves setting the host and port on 
which the router should connect to other routers and brokers.
+Configuring outgoing connections involves setting the host and port on 
which the router connects to other routers and brokers.
+
+// Adding this here for now; in the future it might be better to have 
separate procedures for creating inter-router and route-container connections.
+When a router connects to a broker, the broker may provide backup 
connection data that the router can use if the primary connection fails. If the 
primary connection fails, the router attempts to reconnect by using a 
combination of the primary and -- if provided -- backup connections. For more 
information about viewing the backup connection data provided by the broker, 
see xref:managing_connectors[].
 
--- End diff --

Can we please add the following - 

If the router is unable to successfully connect using the primary or the 
backup connection information, it round robins around the list until it is able 
to make a successful connection. 


> Document how Dispatch Router uses alternate failover URLs
> -
>
> Key: DISPATCH-879
> URL: https://issues.apache.org/jira/browse/DISPATCH-879
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Documentation
>Reporter: Ben Hardesty
>Assignee: Ben Hardesty
>




--
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 #220: DISPATCH-879 - Document how routers use alt...

2017-11-17 Thread ganeshmurthy 
Github user ganeshmurthy commented on a diff in the pull request:

https://github.com/apache/qpid-dispatch/pull/220#discussion_r151789336
  
--- Diff: doc/new-book/configuration-connections.adoc ---
@@ -56,7 +56,10 @@ If you have set up SSL/TLS or SASL in your environment, 
you can configure the ro
 [[adding_outgoing_connections]]
 == Adding Outgoing Connections
 
-Configuring outgoing connections involves setting the host and port on 
which the router should connect to other routers and brokers.
+Configuring outgoing connections involves setting the host and port on 
which the router connects to other routers and brokers.
+
+// Adding this here for now; in the future it might be better to have 
separate procedures for creating inter-router and route-container connections.
+When a router connects to a broker, the broker may provide backup 
connection data that the router can use if the primary connection fails. If the 
primary connection fails, the router attempts to reconnect by using a 
combination of the primary and -- if provided -- backup connections. For more 
information about viewing the backup connection data provided by the broker, 
see xref:managing_connectors[].
 
--- End diff --

Can we please add the following - 

If the router is unable to successfully connect using the primary or the 
backup connection information, it round robins around the list until it is able 
to make a successful connection. 


---

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

[GitHub] qpid-proton pull request #130: Add coverage reporting for the Ruby binding

2017-11-17 Thread jdanekrh 
GitHub user jdanekrh opened a pull request:

https://github.com/apache/qpid-proton/pull/130

Add coverage reporting for the Ruby binding



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

$ git pull https://github.com/jdanekrh/qpid-proton jd_cov_ruby

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

https://github.com/apache/qpid-proton/pull/130.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 #130


commit 0633111631fc9e3b43ff19960f7b2bfc1282
Author: Jiri Danek 
Date:   2017-11-17T11:38:34Z

Add coverage reporting for the Ruby binding




---

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

[jira] [Created] (DISPATCH-880) Document how Dispatch Router disconnects connections

2017-11-17 Thread Ben Hardesty (JIRA) 
Ben Hardesty created DISPATCH-880:
-

 Summary: Document how Dispatch Router disconnects connections
 Key: DISPATCH-880
 URL: https://issues.apache.org/jira/browse/DISPATCH-880
 Project: Qpid Dispatch
  Issue Type: Bug
  Components: Documentation
Reporter: Ben Hardesty
Assignee: Ben Hardesty






--
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-879) Document how Dispatch Router uses alternate failover URLs

2017-11-17 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on DISPATCH-879:
-

GitHub user bhardesty opened a pull request:

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

DISPATCH-879 - Document how routers use alternate failover URLs (WIP)

**Note:** This PR is under review. Please don't merge yet.

@ganeshmurthy, can you please review for technical accuracy?

In the part where we talk about outgoing connections, I described a bit 
about how routers use the failover list. Also, in the part about managing 
outgoing connections, I added a command that can be used to view the failover 
list.

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

$ git pull https://github.com/bhardesty/qpid-dispatch 
dispatch-879-failover-url

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

https://github.com/apache/qpid-dispatch/pull/220.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 #220


commit 9df847158619d0c77449fadc3b5bea907949d4f1
Author: Ben Hardesty 
Date:   2017-11-16T22:47:54Z

Doc how routers use alternate connection url




> Document how Dispatch Router uses alternate failover URLs
> -
>
> Key: DISPATCH-879
> URL: https://issues.apache.org/jira/browse/DISPATCH-879
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Documentation
>Reporter: Ben Hardesty
>Assignee: Ben Hardesty
>




--
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 #220: DISPATCH-879 - Document how routers use alt...

2017-11-17 Thread bhardesty 
GitHub user bhardesty opened a pull request:

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

DISPATCH-879 - Document how routers use alternate failover URLs (WIP)

**Note:** This PR is under review. Please don't merge yet.

@ganeshmurthy, can you please review for technical accuracy?

In the part where we talk about outgoing connections, I described a bit 
about how routers use the failover list. Also, in the part about managing 
outgoing connections, I added a command that can be used to view the failover 
list.

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

$ git pull https://github.com/bhardesty/qpid-dispatch 
dispatch-879-failover-url

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

https://github.com/apache/qpid-dispatch/pull/220.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 #220


commit 9df847158619d0c77449fadc3b5bea907949d4f1
Author: Ben Hardesty 
Date:   2017-11-16T22:47:54Z

Doc how routers use alternate connection url




---

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

[jira] [Commented] (PROTON-855) Add axTLS (embedded SSL) support to proton-c

2017-11-17 Thread Alan Conway (JIRA) 

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

Alan Conway commented on PROTON-855:


The pn_connection_driver API has been added to proton and makes this type of 
integration easier. I will try to put together a demo using the connection 
driver to show how this would work.

> Add axTLS (embedded SSL) support to proton-c
> 
>
> Key: PROTON-855
> URL: https://issues.apache.org/jira/browse/PROTON-855
> Project: Qpid Proton
>  Issue Type: New Feature
>  Components: proton-c
>Affects Versions: 0.9, 0.9.1, 0.10
> Environment: Platform independent
>Reporter: Tomasz Nowicki
>Assignee: Alan Conway
>  Labels: features, patch
> Fix For: proton-c-0.19.0
>
> Attachments: axtls.c, axtls_proton_example.c, qpidproton-AXTLS.patch, 
> ssl_io.h
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> The axTLS embedded SSL project is a highly configurable client/server 
> TLSv1 SSL library designed for platforms with small memory requirements. 
> It comes with a small HTTP/HTTPS server and additional test tools. 
> axTLS It's free! (BSD style licensing)
> http://axtls.sourceforge.net/
> axTLS integration with proton is done on socket layer(posix layer). On the 
> other hand OpenSSL integration with proton is done on the transport layer. To 
> use both solutions we had to add two methods pn_ssl_recv i pn_ssl_send 
> (daclared in include/ssl_io.h) which in openssl mode, without crypting, 
> invoke native proton "pn_send" and "pn_receive (io.c)". In axTLS mode, those 
> methods are replaced with proper axtls comunication methods. Those are 
> defined in openssl.c, ssl_stub.c, axtls.c and located in src/ssl.
> Methods pn_ssl_recv and pn_ssl_send replace original pn_send and pn_recv used 
> in pni_connection_writable(pn_selectable_t *sel), 
> pni_connection_readable(pn_selectable_t *sel) (connection.c).
> Moreover we introduced new file axtls.c located in src/ssl. The file is an 
> equivalent of openssl.c, implementing base ssl methods:  PN_EXTERN 
> pn_ssl_domain_t *pn_ssl_domain( pn_ssl_mode_t mode);
> PN_EXTERN void pn_ssl_domain_free( pn_ssl_domain_t *domain ); etc
> Example of axTLS integration with ex ActiveMQ 
> atatched(axtls_proton_example.c):
> It's based on
> http://mail-archives.us.apache.org/mod_mbox/qpid-proton/201501.mbox/%3ccacl1bnc5jerbnikd_4fgkjqh13h5nl_2z-sszp3jg2t+ywa...@mail.gmail.com%3E



--
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 #218: DISPATCH-875 - Doc new "pattern" attribute ...

2017-11-17 Thread kgiusti 
Github user kgiusti commented on a diff in the pull request:

https://github.com/apache/qpid-dispatch/pull/218#discussion_r151715642
  
--- Diff: doc/new-book/routing.adoc ---
@@ -213,15 +213,17 @@ address {
 }
 
 
-`prefix` | `pattern`:: The address or group of addresses to which the 
address settings should be applied. You can specify a prefix to match an exact 
address or segment of an address. Alternatively, you can specify a pattern to 
match an address using wildcards.
+`prefix` | `pattern`:: The address or group of addresses to which the 
address settings should be applied. You can specify a prefix to match an exact 
address or beginning segment of an address. Alternatively, you can specify a 
pattern to match an address using wildcards.
 +
 //tag::prefix-matching[]
-A _prefix_ matches either an exact address or a segment within an address 
that is delimited by either a `.` or `/` character. For example, the prefix 
`my_address` would match the address `my_address` as well as `my_address.1` and 
`my_address/1`. However, it would not match `my_address1`.
+A _prefix_ matches either an exact address or the beginning segment within 
an address that is delimited by either a `.` or `/` character. For example, the 
prefix `my_address` would match the address `my_address` as well as 
`my_address.1` and `my_address/1`. However, it would not match `my_address1`.
 //end::prefix-matching[]
 +
 //tag::pattern-matching[]
 A _pattern_ matches an address that corresponds to a pattern. A pattern is 
a sequence of words delimited by either a `.` or `/` character. You can use 
wildcard characters to represent a word. The  `*` character matches exactly one 
word, and the `#` character matches any sequence of zero or more words.
 +
+The pattern configuration and the address(es) that match the pattern 
should use the same delimiter character. For example, if you configure the 
pattern to be `my.+`, then the addresses that match the pattern should also use 
a `.` as a delimiter (instead of a `/`).
--- End diff --

Yes I agree on that change - but there's a typo in that last paragraph:  / 
is not a wildcard, # is.




---

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

[jira] [Commented] (DISPATCH-875) Document address and link route wildcards

2017-11-17 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on DISPATCH-875:
-

Github user kgiusti commented on a diff in the pull request:

https://github.com/apache/qpid-dispatch/pull/218#discussion_r151715642
  
--- Diff: doc/new-book/routing.adoc ---
@@ -213,15 +213,17 @@ address {
 }
 
 
-`prefix` | `pattern`:: The address or group of addresses to which the 
address settings should be applied. You can specify a prefix to match an exact 
address or segment of an address. Alternatively, you can specify a pattern to 
match an address using wildcards.
+`prefix` | `pattern`:: The address or group of addresses to which the 
address settings should be applied. You can specify a prefix to match an exact 
address or beginning segment of an address. Alternatively, you can specify a 
pattern to match an address using wildcards.
 +
 //tag::prefix-matching[]
-A _prefix_ matches either an exact address or a segment within an address 
that is delimited by either a `.` or `/` character. For example, the prefix 
`my_address` would match the address `my_address` as well as `my_address.1` and 
`my_address/1`. However, it would not match `my_address1`.
+A _prefix_ matches either an exact address or the beginning segment within 
an address that is delimited by either a `.` or `/` character. For example, the 
prefix `my_address` would match the address `my_address` as well as 
`my_address.1` and `my_address/1`. However, it would not match `my_address1`.
 //end::prefix-matching[]
 +
 //tag::pattern-matching[]
 A _pattern_ matches an address that corresponds to a pattern. A pattern is 
a sequence of words delimited by either a `.` or `/` character. You can use 
wildcard characters to represent a word. The  `*` character matches exactly one 
word, and the `#` character matches any sequence of zero or more words.
 +
+The pattern configuration and the address(es) that match the pattern 
should use the same delimiter character. For example, if you configure the 
pattern to be `my.+`, then the addresses that match the pattern should also use 
a `.` as a delimiter (instead of a `/`).
--- End diff --

Yes I agree on that change - but there's a typo in that last paragraph:  / 
is not a wildcard, # is.




> Document address and link route wildcards
> -
>
> Key: DISPATCH-875
> URL: https://issues.apache.org/jira/browse/DISPATCH-875
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Documentation
>Affects Versions: 1.1.0
>Reporter: Ben Hardesty
>Assignee: Ben Hardesty
>
> Update Dispatch Router doc to describe how to define groups of addresses 
> using the new "pattern" address attribute.



--
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-7991) Segfault in broker while processing active bridges

2017-11-17 Thread Alan Conway (JIRA) 

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

Alan Conway commented on QPID-7991:
---

The bug would not be triggered if all the detached bridges were already at the 
end of the vector; then std::remove_if wouldn't bother moving them, it would 
simply return an iterator to the dead zone and everything would work fine. 
Possibly your tool does things in a slightly different order or with different 
timing - so your tool causes mixed batches detached/active bridges to be 
processed, where python tool did not. E.g. (speculating) the  python tool might 
be more synchronous than necessary while your tool issues management commands 
in batches or something like that.

> Segfault in broker while processing active bridges
> --
>
> Key: QPID-7991
> URL: https://issues.apache.org/jira/browse/QPID-7991
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker
>Affects Versions: qpid-cpp-1.36.0, qpid-cpp-1.37.0
> Environment: Ubuntu 17.10 x86_64, gcc 7.
>Reporter: Chris Richardson
>Assignee: Alan Conway
>Priority: Critical
> Fix For: qpid-cpp-1.37.0
>
> Attachments: segfault stack trace, segfault-fix.patch, 
> segfault-repoduce.tar.gz, std_remove_if_with_smart_ptr.cpp
>
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> Segfault occurs on a brackground thread within about 5-10 seconds of broker 
> startup at src/qpid/broker/Link.cpp:465. [^segfault stack trace] attached, 
> frames #3 and #5 are of particular relevance.
> The unchecked Bridge::shared_ptr derived from the iterator is null and the 
> invocation of bridge->closed() triggers the segfault. Adding a simple null 
> check (as per attached [^segfault-fix.patch]) fixes the segfault but not the 
> underlying reason for the null pointer. 
> The segfault appears to be related to how a second broker (henceforth 
> "broker1") is configured; this is the one to which the links are established. 
> Without broker1, the "segfaulting broker" (aka "broker2") does not do its 
> thing. It may be that broker1 returns invalid data to broker2 but this is not 
> in the scope of this bug report, which focuses on the segfault. 
> h2. Reproduce
> Unfortunately the steps to  arrive at this situation are not clear so the 
> reproduce is a bit hacky - the data directory, config file and some certs for 
> the two brokers are attached as a tarball in the hope that they can be 
> arranged in such a way as to provide a reproduce in lieu of a purely 
> step-based procedure.
> Steps to reproduce:
> * Temporarily add a DNS alias to the local machine of "octopussy" (necessary 
> due to cert config and durable link config in broker2's data store)
> * Extract the attached [^segfault-repoduce.tar.gz] to an empty directory 
> (assumed to be cwd)
> * Start broker1 with "qpidd --config broker1/qpidd.conf"
> * In another shell with the same cwd, start broker2 with "qpidd --config 
> broker2/qpidd.conf"
> * Observe segfault in broker2 after 5-10 seconds.



--
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] [Assigned] (QPID-8041) [Messaging] Allow virtualhost to be specified when form an AMQP 0-10 connection

2017-11-17 Thread Keith Wall (JIRA) 

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

Keith Wall reassigned QPID-8041:


Assignee: Keith Wall

> [Messaging] Allow virtualhost to be specified when form an AMQP 0-10 
> connection
> ---
>
> Key: QPID-8041
> URL: https://issues.apache.org/jira/browse/QPID-8041
> Project: Qpid
>  Issue Type: Improvement
>  Components: C++ Client
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Minor
>
> When connecting to a peer that supports multiple virtual hosts (such as 
> Broker-J), the ability to specify the {{virtual-host}} field in the 
> {{connection.open}} control is required when establishing a connection to a 
> virtualhost that is not marked as the default.  



--
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-8041) [Messaging] Allow virtualhost to be specified when form an AMQP 0-10 connection

2017-11-17 Thread ASF subversion and git services (JIRA) 

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

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

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

QPID-8041: Allow virtualhost field to be specified when forming an AMQP 0-10 
connection.


> [Messaging] Allow virtualhost to be specified when form an AMQP 0-10 
> connection
> ---
>
> Key: QPID-8041
> URL: https://issues.apache.org/jira/browse/QPID-8041
> Project: Qpid
>  Issue Type: Improvement
>  Components: C++ Client
>Reporter: Keith Wall
>Priority: Minor
>
> When connecting to a peer that supports multiple virtual hosts (such as 
> Broker-J), the ability to specify the {{virtual-host}} field in the 
> {{connection.open}} control is required when establishing a connection to a 
> virtualhost that is not marked as the default.  



--
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] (QPID-8041) [Messaging] Allow virtualhost to be specified when form an AMQP 0-10 connection

2017-11-17 Thread Keith Wall (JIRA) 

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

Keith Wall updated QPID-8041:
-
Status: Reviewable  (was: In Progress)

> [Messaging] Allow virtualhost to be specified when form an AMQP 0-10 
> connection
> ---
>
> Key: QPID-8041
> URL: https://issues.apache.org/jira/browse/QPID-8041
> Project: Qpid
>  Issue Type: Improvement
>  Components: C++ Client
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Minor
>
> When connecting to a peer that supports multiple virtual hosts (such as 
> Broker-J), the ability to specify the {{virtual-host}} field in the 
> {{connection.open}} control is required when establishing a connection to a 
> virtualhost that is not marked as the default.  



--
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-8041) [Messaging] Allow virtualhost to be specified when form an AMQP 0-10 connection

2017-11-17 Thread Keith Wall (JIRA) 
Keith Wall created QPID-8041:


 Summary: [Messaging] Allow virtualhost to be specified when form 
an AMQP 0-10 connection
 Key: QPID-8041
 URL: https://issues.apache.org/jira/browse/QPID-8041
 Project: Qpid
  Issue Type: Improvement
  Components: C++ Client
Reporter: Keith Wall
Priority: Minor


When connecting to a peer that supports multiple virtual hosts (such as 
Broker-J), the ability to specify the {{virtual-host}} field in the 
{{connection.open}} control is required when establishing a connection to a 
virtualhost that is not marked as the default.  



--
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] (QPID-8040) [Broker-J] Uncaught java.nio.channels.CancelledKeyException seen during Broker shutdown

2017-11-17 Thread Keith Wall (JIRA) 

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

Keith Wall updated QPID-8040:
-
Attachment: 
TEST-org.apache.qpid.systest.management.amqp.AmqpManagementTest.testInvokeOperationReturningMap

> [Broker-J] Uncaught java.nio.channels.CancelledKeyException seen during 
> Broker shutdown
> ---
>
> Key: QPID-8040
> URL: https://issues.apache.org/jira/browse/QPID-8040
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.1.0
>Reporter: Keith Wall
>Priority: Minor
> Attachments: 
> TEST-org.apache.qpid.systest.management.amqp.AmqpManagementTest.testInvokeOperationReturningMap
>
>
> The following exception was trapped by the UncaughtExceptionHandler during a 
> shutdown of the Broker.  The would have caused a abnormal termination.   I 
> expect it could also happen during a HA virtualhost mastership change too.
> This code hasn't changed, so I think the problem is probably longstanding.
> {noformat}
> 2017-11-10 20:30:04,540  DEBUG [QpidJMS Connection Executor: 
> ID:51dec5e7-faf9-4b92-89ec-16396a27a101:1] o.a.q.j.u.ThreadPoolUtils Shutdown 
> of ExecutorService: 
> java.util.concurrent.ScheduledThreadPoolExecutor@6fbbe33[Terminated, pool 
> size = 0, active threads = 0, queued tasks = 0, completed tasks = 24] is 
> shutdown: true and terminated: true took: 0.000 seconds.
> 2017-11-10 20:30:04,540  DEBUG [VirtualHostNode-test-Config] 
> o.a.q.s.c.u.TaskExecutorImpl Stopping task executor 
> virtualhost-test-preferences
> 2017-11-10 20:30:04,544  DEBUG [VirtualHostNode-test-Config] 
> o.a.q.s.c.u.TaskExecutorImpl Task executor is stopped
> 2017-11-10 20:30:04,543  ERROR [Selector-Port-amqp] 
> o.a.q.t.u.InternalBrokerHolder Uncaught exception from thread 
> Selector-Port-amqp
> java.nio.channels.CancelledKeyException: null
>   at sun.nio.ch.SelectionKeyImpl.ensureValid(SelectionKeyImpl.java:73)
>   at sun.nio.ch.SelectionKeyImpl.interestOps(SelectionKeyImpl.java:82)
>   at 
> java.nio.channels.spi.AbstractSelectableChannel.register(AbstractSelectableChannel.java:204)
>   at 
> org.apache.qpid.server.transport.SelectorThread$SelectionTask.processSelectionKeys(SelectorThread.java:240)
>   at 
> org.apache.qpid.server.transport.SelectorThread$SelectionTask.performSelect(SelectorThread.java:326)
>   at 
> org.apache.qpid.server.transport.SelectorThread$SelectionTask.run(SelectorThread.java:97)
>   at 
> org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:528)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>   at 
> org.apache.qpid.server.bytebuffer.QpidByteBufferFactory.lambda$null$0(QpidByteBufferFactory.java:464)
>   at java.lang.Thread.run(Thread.java:748)
> {noformat}



--
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] (QPID-8040) [Broker-J] Uncaught java.nio.channels.CancelledKeyException seen during Broker shutdown

2017-11-17 Thread Keith Wall (JIRA) 

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

Keith Wall updated QPID-8040:
-
Description: 
The following exception was trapped by the UncaughtExceptionHandler during a 
shutdown of the Broker.  The would have caused a abnormal termination.   I 
expect it could also happen during a HA virtualhost mastership change too.

This code hasn't changed, so I think the problem is probably longstanding.


{noformat}
2017-11-10 20:30:04,540  DEBUG [QpidJMS Connection Executor: 
ID:51dec5e7-faf9-4b92-89ec-16396a27a101:1] o.a.q.j.u.ThreadPoolUtils Shutdown 
of ExecutorService: 
java.util.concurrent.ScheduledThreadPoolExecutor@6fbbe33[Terminated, pool size 
= 0, active threads = 0, queued tasks = 0, completed tasks = 24] is shutdown: 
true and terminated: true took: 0.000 seconds.
2017-11-10 20:30:04,540  DEBUG [VirtualHostNode-test-Config] 
o.a.q.s.c.u.TaskExecutorImpl Stopping task executor virtualhost-test-preferences
2017-11-10 20:30:04,544  DEBUG [VirtualHostNode-test-Config] 
o.a.q.s.c.u.TaskExecutorImpl Task executor is stopped
2017-11-10 20:30:04,543  ERROR [Selector-Port-amqp] 
o.a.q.t.u.InternalBrokerHolder Uncaught exception from thread Selector-Port-amqp
java.nio.channels.CancelledKeyException: null
at sun.nio.ch.SelectionKeyImpl.ensureValid(SelectionKeyImpl.java:73)
at sun.nio.ch.SelectionKeyImpl.interestOps(SelectionKeyImpl.java:82)
at 
java.nio.channels.spi.AbstractSelectableChannel.register(AbstractSelectableChannel.java:204)
at 
org.apache.qpid.server.transport.SelectorThread$SelectionTask.processSelectionKeys(SelectorThread.java:240)
at 
org.apache.qpid.server.transport.SelectorThread$SelectionTask.performSelect(SelectorThread.java:326)
at 
org.apache.qpid.server.transport.SelectorThread$SelectionTask.run(SelectorThread.java:97)
at 
org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:528)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at 
org.apache.qpid.server.bytebuffer.QpidByteBufferFactory.lambda$null$0(QpidByteBufferFactory.java:464)
at java.lang.Thread.run(Thread.java:748)
{noformat}


  was:
The following exception was trapped by the UncaughtExceptionHandler during a 
shutdown of the Broker.  The would have caused a abnormal termination.   I 
expect it could also happen during a HA virtualhost mastership change too.

This code hasn't changed, so I think the problem is probably longstanding.



2017-11-10 20:30:04,540  DEBUG [QpidJMS Connection Executor: 
ID:51dec5e7-faf9-4b92-89ec-16396a27a101:1] o.a.q.j.u.ThreadPoolUtils Shutdown 
of ExecutorService: 
java.util.concurrent.ScheduledThreadPoolExecutor@6fbbe33[Terminated, pool size 
= 0, active threads = 0, queued tasks = 0, completed tasks = 24] is shutdown: 
true and terminated: true took: 0.000 seconds.
2017-11-10 20:30:04,540  DEBUG [VirtualHostNode-test-Config] 
o.a.q.s.c.u.TaskExecutorImpl Stopping task executor virtualhost-test-preferences
2017-11-10 20:30:04,544  DEBUG [VirtualHostNode-test-Config] 
o.a.q.s.c.u.TaskExecutorImpl Task executor is stopped
2017-11-10 20:30:04,543  ERROR [Selector-Port-amqp] 
o.a.q.t.u.InternalBrokerHolder Uncaught exception from thread Selector-Port-amqp
java.nio.channels.CancelledKeyException: null
at sun.nio.ch.SelectionKeyImpl.ensureValid(SelectionKeyImpl.java:73)
at sun.nio.ch.SelectionKeyImpl.interestOps(SelectionKeyImpl.java:82)
at 
java.nio.channels.spi.AbstractSelectableChannel.register(AbstractSelectableChannel.java:204)
at 
org.apache.qpid.server.transport.SelectorThread$SelectionTask.processSelectionKeys(SelectorThread.java:240)
at 
org.apache.qpid.server.transport.SelectorThread$SelectionTask.performSelect(SelectorThread.java:326)
at 
org.apache.qpid.server.transport.SelectorThread$SelectionTask.run(SelectorThread.java:97)
at 
org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:528)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at 
org.apache.qpid.server.bytebuffer.QpidByteBufferFactory.lambda$null$0(QpidByteBufferFactory.java:464)
at java.lang.Thread.run(Thread.java:748)


> [Broker-J] Uncaught java.nio.channels.CancelledKeyException seen during 
> Broker shutdown
> ---
>
> Key: QPID-8040
> URL: https://issues.apache.org/jira/browse/QPID-8040
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions:

[jira] [Created] (QPID-8040) [Broker-J] Uncaught java.nio.channels.CancelledKeyException seen during Broker shutdown

2017-11-17 Thread Keith Wall (JIRA) 
Keith Wall created QPID-8040:


 Summary: [Broker-J] Uncaught 
java.nio.channels.CancelledKeyException seen during Broker shutdown
 Key: QPID-8040
 URL: https://issues.apache.org/jira/browse/QPID-8040
 Project: Qpid
  Issue Type: Bug
  Components: Broker-J
Affects Versions: qpid-java-broker-7.1.0
Reporter: Keith Wall
Priority: Minor


The following exception was trapped by the UncaughtExceptionHandler during a 
shutdown of the Broker.  The would have caused a abnormal termination.   I 
expect it could also happen during a HA virtualhost mastership change too.

This code hasn't changed, so I think the problem is probably longstanding.



2017-11-10 20:30:04,540  DEBUG [QpidJMS Connection Executor: 
ID:51dec5e7-faf9-4b92-89ec-16396a27a101:1] o.a.q.j.u.ThreadPoolUtils Shutdown 
of ExecutorService: 
java.util.concurrent.ScheduledThreadPoolExecutor@6fbbe33[Terminated, pool size 
= 0, active threads = 0, queued tasks = 0, completed tasks = 24] is shutdown: 
true and terminated: true took: 0.000 seconds.
2017-11-10 20:30:04,540  DEBUG [VirtualHostNode-test-Config] 
o.a.q.s.c.u.TaskExecutorImpl Stopping task executor virtualhost-test-preferences
2017-11-10 20:30:04,544  DEBUG [VirtualHostNode-test-Config] 
o.a.q.s.c.u.TaskExecutorImpl Task executor is stopped
2017-11-10 20:30:04,543  ERROR [Selector-Port-amqp] 
o.a.q.t.u.InternalBrokerHolder Uncaught exception from thread Selector-Port-amqp
java.nio.channels.CancelledKeyException: null
at sun.nio.ch.SelectionKeyImpl.ensureValid(SelectionKeyImpl.java:73)
at sun.nio.ch.SelectionKeyImpl.interestOps(SelectionKeyImpl.java:82)
at 
java.nio.channels.spi.AbstractSelectableChannel.register(AbstractSelectableChannel.java:204)
at 
org.apache.qpid.server.transport.SelectorThread$SelectionTask.processSelectionKeys(SelectorThread.java:240)
at 
org.apache.qpid.server.transport.SelectorThread$SelectionTask.performSelect(SelectorThread.java:326)
at 
org.apache.qpid.server.transport.SelectorThread$SelectionTask.run(SelectorThread.java:97)
at 
org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:528)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at 
org.apache.qpid.server.bytebuffer.QpidByteBufferFactory.lambda$null$0(QpidByteBufferFactory.java:464)
at java.lang.Thread.run(Thread.java:748)



--
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