date:20180329

[GitHub] qpid-proton pull request #137: [cpp] Fix update method missing 'name' variab...

2018-03-29 Thread asfgit

Github user asfgit closed the pull request at:

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


---

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

[jira] [Created] (PROTON-1821) link name is not correctly set from sender or receiver options

2018-03-29 Thread Andrew Stitcher (JIRA)

Andrew Stitcher created PROTON-1821:
---

 Summary: link name is not correctly set from sender or receiver 
options
 Key: PROTON-1821
 URL: https://issues.apache.org/jira/browse/PROTON-1821
 Project: Qpid Proton
  Issue Type: Bug
  Components: cpp-binding
Reporter: Andrew Stitcher
Assignee: Andrew Stitcher
 Fix For: proton-c-0.23.0


Bug found and fixed by Andre Oliveira.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (PROTON-1695) [OSX] Cyrus SASL plugins do not load leading to missing mechanisms

2018-03-29 Thread ASF subversion and git services (JIRA)


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

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

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

PROTON-1695: Enable SASL for MacOS CI build


> [OSX] Cyrus SASL plugins do not load leading to missing mechanisms
> --
>
> Key: PROTON-1695
> URL: https://issues.apache.org/jira/browse/PROTON-1695
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: proton-c-0.18.0
> Environment: OS X 10.11.6
> Cyrus SASL 2.1.26
>Reporter: Roddie Kieley
>Priority: Major
>
> Found this issue while working on PROTON-522 as per this 
> [comment|https://issues.apache.org/jira/browse/PROTON-522?focusedCommentId=16218540=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16218540]
>  the short version of which is:
> {quote}
> Ran into some trouble with cyrus-sasl after seeing that the go TestAuthPlain 
> failed for both "Unix Makefiles" and "Xcode", in this case 7.3.1. Found that 
> the plugins do not get loaded on OSX due to sasl_client_init(NULL) but 
> rectified with sasl_client_init(pni_user_password_callbacks).
> {quote}
> The issue with the go-test TestAuthPlain was addressed via PROTON-1655, 
> however the work for PROTON-522 does not include the above update as testing 
> the update was not complete.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (QPID-8140) [Broker-J][BDB HA] Removal of non existing group member can end up in broker crash due to uncaught MemberNotFoundException

2018-03-29 Thread Keith Wall (JIRA)


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

Keith Wall commented on QPID-8140:
--

Changes look reasonable to me.

> [Broker-J][BDB HA] Removal of non existing group member can end up in broker 
> crash due to uncaught MemberNotFoundException
> --
>
> Key: QPID-8140
> URL: https://issues.apache.org/jira/browse/QPID-8140
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.2, qpid-java-broker-7.0.0, 
> qpid-java-broker-7.0.1
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Minor
> Fix For: qpid-java-broker-7.1.0
>
> Attachments: 
> TEST-org.apache.qpid.server.store.berkeleydb.replication.BDBHAVirtualHostNodeRestTest.testDeleteMasterNode.txt
>
>
> When two concurrent requests are made to delete a group member using REST API 
> for remote replication node, one can successfully remove the node, whilst 
> other can end-up in un-handled  {{MemberNotFoundException}} which crashes the 
> broker.
> An example of remote node delete request
> {code}
>  curl -v -k -u admin -X DELETE  
> http://localhost:8080/api/latest/remotereplicationnode/node2/node1
> {code}
> For failed requests an exception like the one below is reported
> {noformat}
>  ERROR [VirtualHostNode-node2-Config] o.a.q.s.u.ServerScopedRuntimeException 
> Exception on node removal from group
> com.sleepycat.je.rep.MemberNotFoundException: (JE 7.4.5) Node: node1 is not 
> currently a member of the group: 
> BDBHAVirtualHostNodeRestTest.testDeleteMasterNode, it has been removed.
>   at 
> com.sleepycat.je.rep.util.ReplicationGroupAdmin.checkMember(ReplicationGroupAdmin.java:576)
>   at 
> com.sleepycat.je.rep.util.ReplicationGroupAdmin.removeMember(ReplicationGroupAdmin.java:314)
>   at 
> org.apache.qpid.server.store.berkeleydb.replication.ReplicatedEnvironmentFacade.removeNodeFromGroup(ReplicatedEnvironmentFacade.java:1210)
>   at 
> org.apache.qpid.server.virtualhostnode.berkeleydb.BDBHARemoteReplicationNodeImpl.onDelete(BDBHARemoteReplicationNodeImpl.java:139)
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject$21.onSuccess(AbstractConfiguredObject.java:2759)
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject$24$1.run(AbstractConfiguredObject.java:2894)
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject$24$1.run(AbstractConfiguredObject.java:2890)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at javax.security.auth.Subject.doAs(Subject.java:360)
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject$24.onSuccess(AbstractConfiguredObject.java:2889)
>   at 
> com.google.common.util.concurrent.Futures$CallbackListener.run(Futures.java:1237)
>   at 
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$ImmediateIfSameThreadExecutor.execute(TaskExecutorImpl.java:400)
>   at 
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.execute(TaskExecutorImpl.java:183)
>   at 
> com.google.common.util.concurrent.AbstractFuture.executeListener(AbstractFuture.java:911)
>   at 
> com.google.common.util.concurrent.AbstractFuture.complete(AbstractFuture.java:822)
>   at 
> com.google.common.util.concurrent.AbstractFuture.set(AbstractFuture.java:664)
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject$ChainedSettableFuture.set(AbstractConfiguredObject.java:2710)
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject$21$1.onSuccess(AbstractConfiguredObject.java:2765)
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject$24$1.run(AbstractConfiguredObject.java:2894)
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject$24$1.run(AbstractConfiguredObject.java:2890)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at javax.security.auth.Subject.doAs(Subject.java:360)
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject$24.onSuccess(AbstractConfiguredObject.java:2889)
>   at 
> com.google.common.util.concurrent.Futures$CallbackListener.run(Futures.java:1237)
>   at 
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$ImmediateIfSameThreadExecutor.execute(TaskExecutorImpl.java:400)
>   at 
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.execute(TaskExecutorImpl.java:183)
>   at 
> com.google.common.util.concurrent.AbstractFuture.executeListener(AbstractFuture.java:911)
>   at 
> com.google.common.util.concurrent.AbstractFuture.addListener(AbstractFuture.java:645)
>   at 
>

[jira] [Resolved] (QPID-8140) [Broker-J][BDB HA] Removal of non existing group member can end up in broker crash due to uncaught MemberNotFoundException

2018-03-29 Thread Keith Wall (JIRA)


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

Keith Wall resolved QPID-8140.
--
Resolution: Fixed

> [Broker-J][BDB HA] Removal of non existing group member can end up in broker 
> crash due to uncaught MemberNotFoundException
> --
>
> Key: QPID-8140
> URL: https://issues.apache.org/jira/browse/QPID-8140
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.2, qpid-java-broker-7.0.0, 
> qpid-java-broker-7.0.1
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-7.1.0
>
> Attachments: 
> TEST-org.apache.qpid.server.store.berkeleydb.replication.BDBHAVirtualHostNodeRestTest.testDeleteMasterNode.txt
>
>
> When two concurrent requests are made to delete a group member using REST API 
> for remote replication node, one can successfully remove the node, whilst 
> other can end-up in un-handled  {{MemberNotFoundException}} which crashes the 
> broker.
> An example of remote node delete request
> {code}
>  curl -v -k -u admin -X DELETE  
> http://localhost:8080/api/latest/remotereplicationnode/node2/node1
> {code}
> For failed requests an exception like the one below is reported
> {noformat}
>  ERROR [VirtualHostNode-node2-Config] o.a.q.s.u.ServerScopedRuntimeException 
> Exception on node removal from group
> com.sleepycat.je.rep.MemberNotFoundException: (JE 7.4.5) Node: node1 is not 
> currently a member of the group: 
> BDBHAVirtualHostNodeRestTest.testDeleteMasterNode, it has been removed.
>   at 
> com.sleepycat.je.rep.util.ReplicationGroupAdmin.checkMember(ReplicationGroupAdmin.java:576)
>   at 
> com.sleepycat.je.rep.util.ReplicationGroupAdmin.removeMember(ReplicationGroupAdmin.java:314)
>   at 
> org.apache.qpid.server.store.berkeleydb.replication.ReplicatedEnvironmentFacade.removeNodeFromGroup(ReplicatedEnvironmentFacade.java:1210)
>   at 
> org.apache.qpid.server.virtualhostnode.berkeleydb.BDBHARemoteReplicationNodeImpl.onDelete(BDBHARemoteReplicationNodeImpl.java:139)
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject$21.onSuccess(AbstractConfiguredObject.java:2759)
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject$24$1.run(AbstractConfiguredObject.java:2894)
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject$24$1.run(AbstractConfiguredObject.java:2890)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at javax.security.auth.Subject.doAs(Subject.java:360)
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject$24.onSuccess(AbstractConfiguredObject.java:2889)
>   at 
> com.google.common.util.concurrent.Futures$CallbackListener.run(Futures.java:1237)
>   at 
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$ImmediateIfSameThreadExecutor.execute(TaskExecutorImpl.java:400)
>   at 
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.execute(TaskExecutorImpl.java:183)
>   at 
> com.google.common.util.concurrent.AbstractFuture.executeListener(AbstractFuture.java:911)
>   at 
> com.google.common.util.concurrent.AbstractFuture.complete(AbstractFuture.java:822)
>   at 
> com.google.common.util.concurrent.AbstractFuture.set(AbstractFuture.java:664)
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject$ChainedSettableFuture.set(AbstractConfiguredObject.java:2710)
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject$21$1.onSuccess(AbstractConfiguredObject.java:2765)
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject$24$1.run(AbstractConfiguredObject.java:2894)
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject$24$1.run(AbstractConfiguredObject.java:2890)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at javax.security.auth.Subject.doAs(Subject.java:360)
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject$24.onSuccess(AbstractConfiguredObject.java:2889)
>   at 
> com.google.common.util.concurrent.Futures$CallbackListener.run(Futures.java:1237)
>   at 
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$ImmediateIfSameThreadExecutor.execute(TaskExecutorImpl.java:400)
>   at 
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.execute(TaskExecutorImpl.java:183)
>   at 
> com.google.common.util.concurrent.AbstractFuture.executeListener(AbstractFuture.java:911)
>   at 
> com.google.common.util.concurrent.AbstractFuture.addListener(AbstractFuture.java:645)
>   at 
> com.google.common.util.concurrent.AbstractFuture$TrustedFuture.addListener(AbstractFuture.java:101)
>   at 
>

[jira] [Updated] (QPID-8140) [Broker-J][BDB HA] Removal of non existing group member can end up in broker crash due to uncaught MemberNotFoundException

2018-03-29 Thread Keith Wall (JIRA)


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

Keith Wall updated QPID-8140:
-
Priority: Minor  (was: Major)

> [Broker-J][BDB HA] Removal of non existing group member can end up in broker 
> crash due to uncaught MemberNotFoundException
> --
>
> Key: QPID-8140
> URL: https://issues.apache.org/jira/browse/QPID-8140
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.2, qpid-java-broker-7.0.0, 
> qpid-java-broker-7.0.1
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Minor
> Fix For: qpid-java-broker-7.1.0
>
> Attachments: 
> TEST-org.apache.qpid.server.store.berkeleydb.replication.BDBHAVirtualHostNodeRestTest.testDeleteMasterNode.txt
>
>
> When two concurrent requests are made to delete a group member using REST API 
> for remote replication node, one can successfully remove the node, whilst 
> other can end-up in un-handled  {{MemberNotFoundException}} which crashes the 
> broker.
> An example of remote node delete request
> {code}
>  curl -v -k -u admin -X DELETE  
> http://localhost:8080/api/latest/remotereplicationnode/node2/node1
> {code}
> For failed requests an exception like the one below is reported
> {noformat}
>  ERROR [VirtualHostNode-node2-Config] o.a.q.s.u.ServerScopedRuntimeException 
> Exception on node removal from group
> com.sleepycat.je.rep.MemberNotFoundException: (JE 7.4.5) Node: node1 is not 
> currently a member of the group: 
> BDBHAVirtualHostNodeRestTest.testDeleteMasterNode, it has been removed.
>   at 
> com.sleepycat.je.rep.util.ReplicationGroupAdmin.checkMember(ReplicationGroupAdmin.java:576)
>   at 
> com.sleepycat.je.rep.util.ReplicationGroupAdmin.removeMember(ReplicationGroupAdmin.java:314)
>   at 
> org.apache.qpid.server.store.berkeleydb.replication.ReplicatedEnvironmentFacade.removeNodeFromGroup(ReplicatedEnvironmentFacade.java:1210)
>   at 
> org.apache.qpid.server.virtualhostnode.berkeleydb.BDBHARemoteReplicationNodeImpl.onDelete(BDBHARemoteReplicationNodeImpl.java:139)
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject$21.onSuccess(AbstractConfiguredObject.java:2759)
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject$24$1.run(AbstractConfiguredObject.java:2894)
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject$24$1.run(AbstractConfiguredObject.java:2890)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at javax.security.auth.Subject.doAs(Subject.java:360)
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject$24.onSuccess(AbstractConfiguredObject.java:2889)
>   at 
> com.google.common.util.concurrent.Futures$CallbackListener.run(Futures.java:1237)
>   at 
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$ImmediateIfSameThreadExecutor.execute(TaskExecutorImpl.java:400)
>   at 
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.execute(TaskExecutorImpl.java:183)
>   at 
> com.google.common.util.concurrent.AbstractFuture.executeListener(AbstractFuture.java:911)
>   at 
> com.google.common.util.concurrent.AbstractFuture.complete(AbstractFuture.java:822)
>   at 
> com.google.common.util.concurrent.AbstractFuture.set(AbstractFuture.java:664)
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject$ChainedSettableFuture.set(AbstractConfiguredObject.java:2710)
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject$21$1.onSuccess(AbstractConfiguredObject.java:2765)
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject$24$1.run(AbstractConfiguredObject.java:2894)
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject$24$1.run(AbstractConfiguredObject.java:2890)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at javax.security.auth.Subject.doAs(Subject.java:360)
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject$24.onSuccess(AbstractConfiguredObject.java:2889)
>   at 
> com.google.common.util.concurrent.Futures$CallbackListener.run(Futures.java:1237)
>   at 
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$ImmediateIfSameThreadExecutor.execute(TaskExecutorImpl.java:400)
>   at 
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.execute(TaskExecutorImpl.java:183)
>   at 
> com.google.common.util.concurrent.AbstractFuture.executeListener(AbstractFuture.java:911)
>   at 
> com.google.common.util.concurrent.AbstractFuture.addListener(AbstractFuture.java:645)
>   at 
> com.google.common.util.concurrent.AbstractFuture$TrustedFuture.addListener(AbstractFuture.java:101)
>   at

[jira] [Updated] (QPID-8140) [Broker-J][BDB HA] Removal of non existing group member can end up in broker crash due to uncaught MemberNotFoundException

2018-03-29 Thread Keith Wall (JIRA)


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

Keith Wall updated QPID-8140:
-
Fix Version/s: qpid-java-broker-7.1.0

> [Broker-J][BDB HA] Removal of non existing group member can end up in broker 
> crash due to uncaught MemberNotFoundException
> --
>
> Key: QPID-8140
> URL: https://issues.apache.org/jira/browse/QPID-8140
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.2, qpid-java-broker-7.0.0, 
> qpid-java-broker-7.0.1
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-7.1.0
>
> Attachments: 
> TEST-org.apache.qpid.server.store.berkeleydb.replication.BDBHAVirtualHostNodeRestTest.testDeleteMasterNode.txt
>
>
> When two concurrent requests are made to delete a group member using REST API 
> for remote replication node, one can successfully remove the node, whilst 
> other can end-up in un-handled  {{MemberNotFoundException}} which crashes the 
> broker.
> An example of remote node delete request
> {code}
>  curl -v -k -u admin -X DELETE  
> http://localhost:8080/api/latest/remotereplicationnode/node2/node1
> {code}
> For failed requests an exception like the one below is reported
> {noformat}
>  ERROR [VirtualHostNode-node2-Config] o.a.q.s.u.ServerScopedRuntimeException 
> Exception on node removal from group
> com.sleepycat.je.rep.MemberNotFoundException: (JE 7.4.5) Node: node1 is not 
> currently a member of the group: 
> BDBHAVirtualHostNodeRestTest.testDeleteMasterNode, it has been removed.
>   at 
> com.sleepycat.je.rep.util.ReplicationGroupAdmin.checkMember(ReplicationGroupAdmin.java:576)
>   at 
> com.sleepycat.je.rep.util.ReplicationGroupAdmin.removeMember(ReplicationGroupAdmin.java:314)
>   at 
> org.apache.qpid.server.store.berkeleydb.replication.ReplicatedEnvironmentFacade.removeNodeFromGroup(ReplicatedEnvironmentFacade.java:1210)
>   at 
> org.apache.qpid.server.virtualhostnode.berkeleydb.BDBHARemoteReplicationNodeImpl.onDelete(BDBHARemoteReplicationNodeImpl.java:139)
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject$21.onSuccess(AbstractConfiguredObject.java:2759)
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject$24$1.run(AbstractConfiguredObject.java:2894)
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject$24$1.run(AbstractConfiguredObject.java:2890)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at javax.security.auth.Subject.doAs(Subject.java:360)
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject$24.onSuccess(AbstractConfiguredObject.java:2889)
>   at 
> com.google.common.util.concurrent.Futures$CallbackListener.run(Futures.java:1237)
>   at 
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$ImmediateIfSameThreadExecutor.execute(TaskExecutorImpl.java:400)
>   at 
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.execute(TaskExecutorImpl.java:183)
>   at 
> com.google.common.util.concurrent.AbstractFuture.executeListener(AbstractFuture.java:911)
>   at 
> com.google.common.util.concurrent.AbstractFuture.complete(AbstractFuture.java:822)
>   at 
> com.google.common.util.concurrent.AbstractFuture.set(AbstractFuture.java:664)
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject$ChainedSettableFuture.set(AbstractConfiguredObject.java:2710)
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject$21$1.onSuccess(AbstractConfiguredObject.java:2765)
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject$24$1.run(AbstractConfiguredObject.java:2894)
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject$24$1.run(AbstractConfiguredObject.java:2890)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at javax.security.auth.Subject.doAs(Subject.java:360)
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject$24.onSuccess(AbstractConfiguredObject.java:2889)
>   at 
> com.google.common.util.concurrent.Futures$CallbackListener.run(Futures.java:1237)
>   at 
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$ImmediateIfSameThreadExecutor.execute(TaskExecutorImpl.java:400)
>   at 
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.execute(TaskExecutorImpl.java:183)
>   at 
> com.google.common.util.concurrent.AbstractFuture.executeListener(AbstractFuture.java:911)
>   at 
> com.google.common.util.concurrent.AbstractFuture.addListener(AbstractFuture.java:645)
>   at 
> com.google.common.util.concurrent.AbstractFuture$TrustedFuture.addListener(AbstractFuture.java:101)
>

[jira] [Updated] (QPID-8146) [AMQP 1.0] Test TransferTest#transfersWithDuplicateUnsettledDeliveryTag and TransferTest#exceedMaxMessageSizeLimit reveals QBB leaks

2018-03-29 Thread Keith Wall (JIRA)


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

Keith Wall updated QPID-8146:
-
Attachment: qbb_leak_detection.diff

> [AMQP 1.0] Test TransferTest#transfersWithDuplicateUnsettledDeliveryTag and 
> TransferTest#exceedMaxMessageSizeLimit reveals QBB leaks
> 
>
> Key: QPID-8146
> URL: https://issues.apache.org/jira/browse/QPID-8146
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Reporter: Keith Wall
>Priority: Minor
> Attachments: 
> org.apache.qpid.tests.protocol.v1_0.messaging.TransferTest.txt, 
> org.apache.qpid.tests.protocol.v1_0.transaction.DischargeTest.txt, 
> qbb_leak_detection.diff
>
>
> AMQP 1.0 tests TransferTest#transfersWithDuplicateUnsettledDeliveryTag and 
> TransferTest#exceedMaxMessageSizeLimit reveal QBB leaks. These test exercises 
> an error path and so would not threaten the stability of a production system.
> DischargeTest also shows leaks, but these are from the test itself rather 
> than the production code.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (QPID-8146) [AMQP 1.0] Tests TransferTest#transfersWithDuplicateUnsettledDeliveryTag and TransferTest#exceedMaxMessageSizeLimit reveals QBB leaks

2018-03-29 Thread Keith Wall (JIRA)


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

Keith Wall updated QPID-8146:
-
Summary: [AMQP 1.0] Tests 
TransferTest#transfersWithDuplicateUnsettledDeliveryTag and 
TransferTest#exceedMaxMessageSizeLimit reveals QBB leaks  (was: [AMQP 1.0] Test 
TransferTest#transfersWithDuplicateUnsettledDeliveryTag and 
TransferTest#exceedMaxMessageSizeLimit reveals QBB leaks)

> [AMQP 1.0] Tests TransferTest#transfersWithDuplicateUnsettledDeliveryTag and 
> TransferTest#exceedMaxMessageSizeLimit reveals QBB leaks
> -
>
> Key: QPID-8146
> URL: https://issues.apache.org/jira/browse/QPID-8146
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Reporter: Keith Wall
>Priority: Minor
> Attachments: 
> org.apache.qpid.tests.protocol.v1_0.messaging.TransferTest.txt, 
> org.apache.qpid.tests.protocol.v1_0.transaction.DischargeTest.txt, 
> qbb_leak_detection.diff
>
>
> AMQP 1.0 tests TransferTest#transfersWithDuplicateUnsettledDeliveryTag and 
> TransferTest#exceedMaxMessageSizeLimit reveal QBB leaks. These test exercises 
> an error path and so would not threaten the stability of a production system.
> DischargeTest also shows leaks, but these are from the test itself rather 
> than the production code.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (QPID-8146) [AMQP 1.0] Test TransferTest#transfersWithDuplicateUnsettledDeliveryTag and TransferTest#exceedMaxMessageSizeLimit reveals QBB leaks

2018-03-29 Thread Keith Wall (JIRA)


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

Keith Wall updated QPID-8146:
-
Description: 
AMQP 1.0 tests TransferTest#transfersWithDuplicateUnsettledDeliveryTag and 
TransferTest#exceedMaxMessageSizeLimit reveal QBB leaks. These test exercises 
an error path and so would not threaten the stability of a production system.


DischargeTest also shows leaks, but these are from the test itself rather than 
the production code.

  was:AMQP 1.0 tests TransferTest#transfersWithDuplicateUnsettledDeliveryTag 
and TransferTest#exceedMaxMessageSizeLimit reveal QBB leaks. These test 
exercises an error path and so would not threaten the stability of a production 
system.


> [AMQP 1.0] Test TransferTest#transfersWithDuplicateUnsettledDeliveryTag and 
> TransferTest#exceedMaxMessageSizeLimit reveals QBB leaks
> 
>
> Key: QPID-8146
> URL: https://issues.apache.org/jira/browse/QPID-8146
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Reporter: Keith Wall
>Priority: Minor
> Attachments: 
> org.apache.qpid.tests.protocol.v1_0.messaging.TransferTest.txt, 
> org.apache.qpid.tests.protocol.v1_0.transaction.DischargeTest.txt
>
>
> AMQP 1.0 tests TransferTest#transfersWithDuplicateUnsettledDeliveryTag and 
> TransferTest#exceedMaxMessageSizeLimit reveal QBB leaks. These test exercises 
> an error path and so would not threaten the stability of a production system.
> DischargeTest also shows leaks, but these are from the test itself rather 
> than the production code.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (QPID-8146) [AMQP 1.0] Test TransferTest#transfersWithDuplicateUnsettledDeliveryTag and TransferTest#exceedMaxMessageSizeLimit reveals QBB leaks

2018-03-29 Thread Keith Wall (JIRA)


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

Keith Wall updated QPID-8146:
-
Attachment: 
org.apache.qpid.tests.protocol.v1_0.transaction.DischargeTest.txt

> [AMQP 1.0] Test TransferTest#transfersWithDuplicateUnsettledDeliveryTag and 
> TransferTest#exceedMaxMessageSizeLimit reveals QBB leaks
> 
>
> Key: QPID-8146
> URL: https://issues.apache.org/jira/browse/QPID-8146
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Reporter: Keith Wall
>Priority: Minor
> Attachments: 
> org.apache.qpid.tests.protocol.v1_0.messaging.TransferTest.txt, 
> org.apache.qpid.tests.protocol.v1_0.transaction.DischargeTest.txt
>
>
> AMQP 1.0 tests TransferTest#transfersWithDuplicateUnsettledDeliveryTag and 
> TransferTest#exceedMaxMessageSizeLimit reveal QBB leaks. These test exercises 
> an error path and so would not threaten the stability of a production system.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Created] (QPIDIT-120) ProtonCpp LargeContentTest Sender closes connection too soon

2018-03-29 Thread Chuck Rolke (JIRA)

Chuck Rolke created QPIDIT-120:
--

 Summary: ProtonCpp LargeContentTest Sender closes connection too 
soon
 Key: QPIDIT-120
 URL: https://issues.apache.org/jira/browse/QPIDIT-120
 Project: Apache QPID Interoperability Test Suite
  Issue Type: Bug
  Components: Proton C++ Shim
Reporter: Chuck Rolke


In researching the bug reported in DISPATCH-939 (router closes connection with 
error) a problem in the test has emerged.

The Cpp shim uses on_tracker_accept and then closes the connection when when 
the number of confirmed messages equals the number of total messages. In 
theory, then, the test should never close the connection before the router has 
confirmed and accepted all the messages. From the trace in DISPATCH-939 the 
connection is closed about 2 mS after the fourth Sender message has gone over 
the wire to Dispatch. Not enough dispositions have been received to cover the 
number of messages sent so why has the connection been closed?

Adding some print debugging reveals the issue. In the test as it is today the 
_totalMessages_ is 2. However, in the send loop the actual number of messages 
sent is 2 times the number of elements in the incoming list of test values. In 
today's case the values list has four elements so a total of 8 messages should 
go over the wire.

A hack '* 4' is added to the on_tracker_accept to make the test work:

{{if (_msgsConfirmed >= _totalMsgs * 4) {}}

print debugging session shows:

{{InteropTestError: Send shim 'ProtonCpp':}}
{{on_container_start: _totalMsgs: 2}}
{{on_sendable: msgsSent: 1}}
{{on_sendable: msgsSent: 2}}
{{on_sendable: msgsSent: 3}}
{{on_sendable: msgsSent: 4}}
{{on_sendable: msgsSent: 5}}
{{on_sendable: msgsSent: 6}}
{{on_sendable: msgsSent: 7}}
{{on_sendable: msgsSent: 8}}
{{on_tracker_accept: msgsConfirmed: 1}}
{{on_tracker_accept: msgsConfirmed: 2}}
{{on_tracker_accept: msgsConfirmed: 3}}
{{on_tracker_accept: msgsConfirmed: 4}}
{{on_tracker_accept: msgsConfirmed: 5}}
{{on_tracker_accept: msgsConfirmed: 6}}
{{on_tracker_accept: msgsConfirmed: 7}}
{{on_tracker_accept: msgsConfirmed: 8}}

 The test needs to get the test elementsList factor back into the tracker to 
decide correctly when to close the connection.

This test has still been valuable pointing out an issue in Dispatch that needs 
some attention.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (QPID-8146) [AMQP 1.0] Test TransferTest#transfersWithDuplicateUnsettledDeliveryTag and TransferTest#exceedMaxMessageSizeLimit reveals QBB leaks

2018-03-29 Thread Keith Wall (JIRA)


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

Keith Wall updated QPID-8146:
-
Attachment: org.apache.qpid.tests.protocol.v1_0.messaging.TransferTest.txt

> [AMQP 1.0] Test TransferTest#transfersWithDuplicateUnsettledDeliveryTag and 
> TransferTest#exceedMaxMessageSizeLimit reveals QBB leaks
> 
>
> Key: QPID-8146
> URL: https://issues.apache.org/jira/browse/QPID-8146
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Reporter: Keith Wall
>Priority: Minor
> Attachments: 
> org.apache.qpid.tests.protocol.v1_0.messaging.TransferTest.txt
>
>
> AMQP 1.0 tests TransferTest#transfersWithDuplicateUnsettledDeliveryTag and 
> TransferTest#exceedMaxMessageSizeLimit reveal QBB leaks. These test exercises 
> an error path and so would not threaten the stability of a production system.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Created] (QPID-8146) [AMQP 1.0] Test TransferTest#transfersWithDuplicateUnsettledDeliveryTag and TransferTest#exceedMaxMessageSizeLimit reveals QBB leaks

2018-03-29 Thread Keith Wall (JIRA)

Keith Wall created QPID-8146:


 Summary: [AMQP 1.0] Test 
TransferTest#transfersWithDuplicateUnsettledDeliveryTag and 
TransferTest#exceedMaxMessageSizeLimit reveals QBB leaks
 Key: QPID-8146
 URL: https://issues.apache.org/jira/browse/QPID-8146
 Project: Qpid
  Issue Type: Bug
  Components: Broker-J
Reporter: Keith Wall


AMQP 1.0 tests TransferTest#transfersWithDuplicateUnsettledDeliveryTag and 
TransferTest#exceedMaxMessageSizeLimit reveal QBB leaks. These test exercises 
an error path and so would not threaten the stability of a production system.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Created] (QPID-8145) [AMQP 0-10] ConnectionTest#tooSmallFrameSize reveals QBB leak

2018-03-29 Thread Keith Wall (JIRA)

Keith Wall created QPID-8145:


 Summary: [AMQP 0-10] ConnectionTest#tooSmallFrameSize reveals QBB 
leak
 Key: QPID-8145
 URL: https://issues.apache.org/jira/browse/QPID-8145
 Project: Qpid
  Issue Type: Bug
  Components: Broker-J
Reporter: Keith Wall
 Attachments: 
TEST-org.apache.qpid.tests.protocol.v0_10.ConnectionTest.txt

AMQP 0-10 test {{ConnectionTest#tooSmallFrameSize}} reveals a QBB leak.  The 
test exercises an error path and so would not threaten the stability of a 
production system.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Created] (PROTON-1820) [ruby] Container#schedule does not work if called from handler

2018-03-29 Thread Alan Conway (JIRA)

Alan Conway created PROTON-1820:
---

 Summary: [ruby] Container#schedule does not work if called from 
handler
 Key: PROTON-1820
 URL: https://issues.apache.org/jira/browse/PROTON-1820
 Project: Qpid Proton
  Issue Type: Bug
  Components: ruby-binding
Affects Versions: proton-c-0.22.0
Reporter: Alan Conway
Assignee: Alan Conway
 Fix For: proton-c-0.23.0


The Container#schedule method does not work if called from a handler function.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[GitHub] qpid-dispatch pull request #275: NO JIRA: Fix minor doc issue with heading l...

2018-03-29 Thread bhardesty

GitHub user bhardesty opened a pull request:

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

NO JIRA: Fix minor doc issue with heading level



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

$ git pull https://github.com/bhardesty/qpid-dispatch fix-heading-level

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

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


commit c0996627f4a8deafea0c1bf062a52345cd9f80be
Author: Ben Hardesty 
Date:   2018-03-29T19:46:54Z

Fix minor doc issue with heading level




---

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

[jira] [Commented] (DISPATCH-952) qdrouterd seg fault after reporting "too many sessions"

2018-03-29 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on DISPATCH-952:
-

GitHub user ganeshmurthy opened a pull request:

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

DISPATCH-952 - Limit number of sessions to one on a route-container c…

…onnection. All links created will be created in this one session

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

$ git pull https://github.com/ganeshmurthy/qpid-dispatch DISPATCH-952

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

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


commit e8a17fef999ffe21733bb834cb4349cb835289ba
Author: Ganesh Murthy 
Date:   2018-03-29T19:12:00Z

DISPATCH-952 - Limit number of sessions to one on a route-container 
connection. All links created will be created in this one session




> qdrouterd seg fault after reporting "too many sessions"
> ---
>
> Key: DISPATCH-952
> URL: https://issues.apache.org/jira/browse/DISPATCH-952
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Container
>Reporter: Alan Conway
>Priority: Major
>
> Reported at [https://bugzilla.redhat.com/show_bug.cgi?id=1561876]
>  
> {code:java}
> Currently running Satellite 6.3 with 5K clients. The clients are managed by 2 
> capsules:
> Capsule 1: 3K clients
> Capsule 2: 2K clients
> Logs from Capsule 1:
> [root@c02-h10-r620-vm1 ~]# journalctl | grep qdrouterd
> Mar 26 03:00:47 c02-h10-r620-vm1.rdu.openstack.engineering.redhat.com 
> groupadd[19140]: group added to /etc/group: name=qdrouterd, GID=993
> Mar 26 03:00:47 c02-h10-r620-vm1.rdu.openstack.engineering.redhat.com 
> groupadd[19140]: group added to /etc/gshadow: name=qdrouterd
> Mar 26 03:00:47 c02-h10-r620-vm1.rdu.openstack.engineering.redhat.com 
> groupadd[19140]: new group: name=qdrouterd, GID=993
> Mar 26 03:00:47 c02-h10-r620-vm1.rdu.openstack.engineering.redhat.com 
> useradd[19145]: new user: name=qdrouterd, UID=996, GID=993, 
> home=/var/lib/qdrouterd, shell=/sbin/nologin
> Mar 28 10:39:06 c02-h10-r620-vm1.rdu.openstack.engineering.redhat.com 
> qdrouterd[16084]: [0x7fe3f0016aa0]:pn_session: too many sessions: 32768  
> channel_max is 32767
> Mar 28 10:39:06 c02-h10-r620-vm1.rdu.openstack.engineering.redhat.com kernel: 
> qdrouterd[16087]: segfault at 88 ip 7fe40b79d820 sp 7fe3fd5f9298 
> error 6 in libqpid-proton.so.10.0.0[7fe40b77f000+4b000]
> Mar 28 10:39:07 c02-h10-r620-vm1.rdu.openstack.engineering.redhat.com 
> systemd[1]: qdrouterd.service: main process exited, code=killed, 
> status=11/SEGV
> Mar 28 10:39:07 c02-h10-r620-vm1.rdu.openstack.engineering.redhat.com 
> systemd[1]: Unit qdrouterd.service entered failed state.
> Mar 28 10:39:07 c02-h10-r620-vm1.rdu.openstack.engineering.redhat.com 
> systemd[1]: qdrouterd.service failed.
> Mar 29 01:02:09 c02-h10-r620-vm1.rdu.openstack.engineering.redhat.com 
> /usr/sbin/katello-service[1740]: *** status failed: qdrouterd ***
> Logs from Capsule 2:
> [root@c02-h10-r620-vm2 ~]# systemctl status qdrouterd
> ● qdrouterd.service - Qpid Dispatch router daemon
>Loaded: loaded (/usr/lib/systemd/system/qdrouterd.service; enabled; vendor 
> preset: disabled)
>   Drop-In: /etc/systemd/system/qdrouterd.service.d
>└─limits.conf
>Active: failed (Result: signal) since Wed 2018-03-28 10:58:02 EDT; 14h ago
>   Process: 1158 ExecStart=/usr/sbin/qdrouterd -c 
> /etc/qpid-dispatch/qdrouterd.conf (code=killed, signal=SEGV)
>  Main PID: 1158 (code=killed, signal=SEGV)
> Mar 28 07:38:46 c02-h10-r620-vm2.rdu.openstack.engineering.redhat.com 
> systemd[1]: Started Qpid Dispatch router daemon.
> Mar 28 07:38:46 c02-h10-r620-vm2.rdu.openstack.engineering.redhat.com 
> systemd[1]: Starting Qpid Dispatch router daemon...
> Mar 28 10:58:02 c02-h10-r620-vm2.rdu.openstack.engineering.redhat.com 
> qdrouterd[1158]: [0x7f36a000a170]:unable to find an open available channel 
> within limit of 32767
> Mar 28 10:58:02 c02-h10-r620-vm2.rdu.openstack.engineering.redhat.com 
> qdrouterd[1158]: [0x7f36a000a170]:process error -2
> Mar 28 10:58:02 c02-h10-r620-vm2.rdu.openstack.engineering.redhat.com 
> qdrouterd[1158]: [0x7f36a000a170]:pn_session: too many sessions: 32768  
> channel_max is 32767
> Mar 28 10:58:02 c02-h10-r620-vm2.rdu.openstack.engineering.redhat.com 
> systemd[1]: qdrouterd.service: main process exited, code=killed, 
> status=11/SEGV
> Mar 28 10:58:02 c02-h10-r620-vm2.rdu.openstack.engineering.redhat.com 
> systemd[1]: Unit qdrouterd.service entered failed state.
> Mar 28 10:58:02

[GitHub] qpid-dispatch pull request #274: DISPATCH-952 - Limit number of sessions to ...

2018-03-29 Thread ganeshmurthy

GitHub user ganeshmurthy opened a pull request:

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

DISPATCH-952 - Limit number of sessions to one on a route-container câ¦

â¦onnection. All links created will be created in this one session

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

$ git pull https://github.com/ganeshmurthy/qpid-dispatch DISPATCH-952

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

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


commit e8a17fef999ffe21733bb834cb4349cb835289ba
Author: Ganesh Murthy 
Date:   2018-03-29T19:12:00Z

DISPATCH-952 - Limit number of sessions to one on a route-container 
connection. All links created will be created in this one session




---

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

[jira] [Commented] (QPIDIT-119) Add AMQP complex type test

2018-03-29 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/QPIDIT-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16419490#comment-16419490
 ] 

ASF subversion and git services commented on QPIDIT-119:


Commit c1fb41599b6046ca8fddb5a754d57191240b313c in qpid-interop-test's branch 
refs/heads/master from [~kpvdr]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-interop-test.git;h=c1fb415 ]

QPIDIT-119: Generator for amqp_complex_types_test, which can generate Python 
and C++ data files from JSON at this point. RheaJs and AmqpNetLite remain 
stubbed, and will be completed later. A first version of the JSON test data 
files are also included, one each for arrays, lists and maps.


> Add AMQP complex type test
> --
>
> Key: QPIDIT-119
> URL: https://issues.apache.org/jira/browse/QPIDIT-119
> Project: Apache QPID Interoperability Test Suite
>  Issue Type: Task
>Affects Versions: 0.1.0
>Reporter: Kim van der Riet
>Assignee: Kim van der Riet
>Priority: Major
> Fix For: 0.2.0
>
>
> The AMQP types test cover the simple tests well, but do not do a good job of 
> the complex types. This is because the ability to represent the test data for 
> the complex types is itself a complex issue, as each complex type may contain 
> an arbitrary number of other complex types. For example, a list may contain 
> other lists or maps, and maps may contain other lists and maps as both keys 
> and values.
> Solving this problem requires that a mechanism exist to create and represent 
> an arbitrarily large and complex set of data for testing, and allow the sent 
> and received data to be compared to determine success or failure.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Resolved] (DISPATCH-953) Relative path name self test fails unless dispatch is installed

2018-03-29 Thread Chuck Rolke (JIRA)


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

Chuck Rolke resolved DISPATCH-953.
--
   Resolution: Fixed
Fix Version/s: 1.1.0

Fixed at commit 03c000

> Relative path name self test fails unless dispatch is installed
> ---
>
> Key: DISPATCH-953
> URL: https://issues.apache.org/jira/browse/DISPATCH-953
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Chuck Rolke
>Priority: Major
> Fix For: 1.1.0
>
>
> See 
> https://issues.apache.org/jira/browse/DISPATCH-940?focusedCommentId=16419005=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16419005



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (DISPATCH-952) qdrouterd seg fault after reporting "too many sessions"

2018-03-29 Thread Alan Conway (JIRA)


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

Alan Conway commented on DISPATCH-952:
--

It looks like every link established by the router via qd_link() in container.c 
creates its own session. This seems like a serious scalability problem on 
inter-router connections and connections to brokers, which could have > 32k 
links. I think the fix is to use a single shared session on such connections. 
Since traffic on a single connection gets serialized in any case, there's no 
real benefit to multiple sessions on a connection.

> qdrouterd seg fault after reporting "too many sessions"
> ---
>
> Key: DISPATCH-952
> URL: https://issues.apache.org/jira/browse/DISPATCH-952
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Container
>Reporter: Alan Conway
>Priority: Major
>
> Reported at [https://bugzilla.redhat.com/show_bug.cgi?id=1561876]
>  
> {code:java}
> Currently running Satellite 6.3 with 5K clients. The clients are managed by 2 
> capsules:
> Capsule 1: 3K clients
> Capsule 2: 2K clients
> Logs from Capsule 1:
> [root@c02-h10-r620-vm1 ~]# journalctl | grep qdrouterd
> Mar 26 03:00:47 c02-h10-r620-vm1.rdu.openstack.engineering.redhat.com 
> groupadd[19140]: group added to /etc/group: name=qdrouterd, GID=993
> Mar 26 03:00:47 c02-h10-r620-vm1.rdu.openstack.engineering.redhat.com 
> groupadd[19140]: group added to /etc/gshadow: name=qdrouterd
> Mar 26 03:00:47 c02-h10-r620-vm1.rdu.openstack.engineering.redhat.com 
> groupadd[19140]: new group: name=qdrouterd, GID=993
> Mar 26 03:00:47 c02-h10-r620-vm1.rdu.openstack.engineering.redhat.com 
> useradd[19145]: new user: name=qdrouterd, UID=996, GID=993, 
> home=/var/lib/qdrouterd, shell=/sbin/nologin
> Mar 28 10:39:06 c02-h10-r620-vm1.rdu.openstack.engineering.redhat.com 
> qdrouterd[16084]: [0x7fe3f0016aa0]:pn_session: too many sessions: 32768  
> channel_max is 32767
> Mar 28 10:39:06 c02-h10-r620-vm1.rdu.openstack.engineering.redhat.com kernel: 
> qdrouterd[16087]: segfault at 88 ip 7fe40b79d820 sp 7fe3fd5f9298 
> error 6 in libqpid-proton.so.10.0.0[7fe40b77f000+4b000]
> Mar 28 10:39:07 c02-h10-r620-vm1.rdu.openstack.engineering.redhat.com 
> systemd[1]: qdrouterd.service: main process exited, code=killed, 
> status=11/SEGV
> Mar 28 10:39:07 c02-h10-r620-vm1.rdu.openstack.engineering.redhat.com 
> systemd[1]: Unit qdrouterd.service entered failed state.
> Mar 28 10:39:07 c02-h10-r620-vm1.rdu.openstack.engineering.redhat.com 
> systemd[1]: qdrouterd.service failed.
> Mar 29 01:02:09 c02-h10-r620-vm1.rdu.openstack.engineering.redhat.com 
> /usr/sbin/katello-service[1740]: *** status failed: qdrouterd ***
> Logs from Capsule 2:
> [root@c02-h10-r620-vm2 ~]# systemctl status qdrouterd
> ● qdrouterd.service - Qpid Dispatch router daemon
>Loaded: loaded (/usr/lib/systemd/system/qdrouterd.service; enabled; vendor 
> preset: disabled)
>   Drop-In: /etc/systemd/system/qdrouterd.service.d
>└─limits.conf
>Active: failed (Result: signal) since Wed 2018-03-28 10:58:02 EDT; 14h ago
>   Process: 1158 ExecStart=/usr/sbin/qdrouterd -c 
> /etc/qpid-dispatch/qdrouterd.conf (code=killed, signal=SEGV)
>  Main PID: 1158 (code=killed, signal=SEGV)
> Mar 28 07:38:46 c02-h10-r620-vm2.rdu.openstack.engineering.redhat.com 
> systemd[1]: Started Qpid Dispatch router daemon.
> Mar 28 07:38:46 c02-h10-r620-vm2.rdu.openstack.engineering.redhat.com 
> systemd[1]: Starting Qpid Dispatch router daemon...
> Mar 28 10:58:02 c02-h10-r620-vm2.rdu.openstack.engineering.redhat.com 
> qdrouterd[1158]: [0x7f36a000a170]:unable to find an open available channel 
> within limit of 32767
> Mar 28 10:58:02 c02-h10-r620-vm2.rdu.openstack.engineering.redhat.com 
> qdrouterd[1158]: [0x7f36a000a170]:process error -2
> Mar 28 10:58:02 c02-h10-r620-vm2.rdu.openstack.engineering.redhat.com 
> qdrouterd[1158]: [0x7f36a000a170]:pn_session: too many sessions: 32768  
> channel_max is 32767
> Mar 28 10:58:02 c02-h10-r620-vm2.rdu.openstack.engineering.redhat.com 
> systemd[1]: qdrouterd.service: main process exited, code=killed, 
> status=11/SEGV
> Mar 28 10:58:02 c02-h10-r620-vm2.rdu.openstack.engineering.redhat.com 
> systemd[1]: Unit qdrouterd.service entered failed state.
> Mar 28 10:58:02 c02-h10-r620-vm2.rdu.openstack.engineering.redhat.com 
> systemd[1]: qdrouterd.service failed.
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (DISPATCH-940) When running qdrouterd with -c and -d combined, configuration file is reporting as not found

2018-03-29 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on DISPATCH-940:
--

Commit 03c000eb6062cf830e777362d399a4de900f7412 in qpid-dispatch's branch 
refs/heads/master from [~chug]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=03c000e ]

DISPATCH-953: Restore cmdline self test; fix to work out of source

Self test system_tests_cmdline_parsing was disabled under
DISPATCH-940 when the test failed unless dispatch was installed.


> When running qdrouterd with -c and -d combined, configuration file is 
> reporting as not found
> 
>
> Key: DISPATCH-940
> URL: https://issues.apache.org/jira/browse/DISPATCH-940
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 1.1.0
>Reporter: Fernando Giorgetti
>Priority: Minor
>  Labels: pull-request-available
> Fix For: 1.1.0
>
>
> If you run qdrouterd as shown below, everything works just fine:
>  
> {code:java}
> [fgiorget@fgiorget qpid-dispatch]$ qdrouterd -c qdrouterd.conf 
> 2018-03-08 14:49:02.797039 -0300 SERVER (info) Container Name: Router.A
> 2018-03-08 14:49:02.797142 -0300 ROUTER (info) Router started in Standalone 
> mode 
> {code}
> But if you try to add -d (daemon) flag, then it does not find the 
> configuration file.
> {code:java}
> [fgiorget@fgiorget qpid-dispatch]$ qdrouterd -d -c qdrouterd.conf 
> qdrouterd: Not found: Configuration file could not be opened{code}
> It only works with fully qualified file name.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (DISPATCH-953) Relative path name self test fails unless dispatch is installed

2018-03-29 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on DISPATCH-953:
--

Commit 03c000eb6062cf830e777362d399a4de900f7412 in qpid-dispatch's branch 
refs/heads/master from [~chug]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=03c000e ]

DISPATCH-953: Restore cmdline self test; fix to work out of source

Self test system_tests_cmdline_parsing was disabled under
DISPATCH-940 when the test failed unless dispatch was installed.


> Relative path name self test fails unless dispatch is installed
> ---
>
> Key: DISPATCH-953
> URL: https://issues.apache.org/jira/browse/DISPATCH-953
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Chuck Rolke
>Priority: Major
>
> See 
> https://issues.apache.org/jira/browse/DISPATCH-940?focusedCommentId=16419005=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16419005



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (QPID-8144) [Broker-J] Memory compaction does not run when used direct memory exceeds 2GB

2018-03-29 Thread ASF subversion and git services (JIRA)


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

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

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

QPID-8144: [Broker-J] Correct arithmetic type used when computing utilised 
direct memory (from int to long).

Cherry picked from master 8e6d2c1f2cb47df31d7d2ccb8e00dfed6b713a70


> [Broker-J] Memory compaction does not run when used direct memory exceeds 2GB
> -
>
> Key: QPID-8144
> URL: https://issues.apache.org/jira/browse/QPID-8144
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.2, qpid-java-6.0.7, 
> qpid-java-6.1.3, qpid-java-6.0.8, qpid-java-broker-7.0.0, qpid-java-6.1.5, 
> qpid-java-broker-7.0.1
>Reporter: Keith Wall
>Priority: Blocker
> Fix For: qpid-java-6.1.6, qpid-java-broker-7.0.3
>
>
> The Broker-J uses direct memory for the caching of message content and IO 
> buffers used for AMQP messaging. If direct memory utilisation exceeds 2GB, 
> owing to a defect the memory compaction mechanism does not get triggered.  
> This problem may lead to an {{OutOfMemoryError: direct}} condition. Whether 
> this condition manifests will depend on the message consumption patten - if 
> the consumption pattern leads to sparsely occupied buffers the problem will 
> occur. 
> A Broker restart will be required to restore service.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (PROTON-1806) Release qpid_proton gem with heartbeating implemented

2018-03-29 Thread Justin Ross (JIRA)


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

Justin Ross commented on PROTON-1806:
-

The 0.22.0 RC1 just went out.  I expect the vote will close in the next 1-2 
weeks.  After that we'll post the new gem.  I figure that will take only a 
couple extra days after the release.

> Release qpid_proton gem with heartbeating implemented
> -
>
> Key: PROTON-1806
> URL: https://issues.apache.org/jira/browse/PROTON-1806
> Project: Qpid Proton
>  Issue Type: Wish
>  Components: ruby-binding
>Reporter: Miha Plesko
>Assignee: Justin Ross
>Priority: Major
>
> We use qpid_proton gem in RedHat CloudForms to capture events from ActiveMQ 
> queue. Recently we discovered a blocking bug in this gem which results in 
> client connection being disconnected every 2-3 minutes accompanied with file 
> descriptor leakage bug as described here:
> https://issues.apache.org/jira/browse/PROTON-1782 and
> https://issues.apache.org/jira/browse/PROTON-1791
> Both issues are fixed by now and merged qpid_proton master branch, many 
> thanks to [~aconway], [~astitcher], [~jdanek] for amazing response time.
>  
> I'm opening this ticket to discuss release plans for the qpid_proton gem. 
> CloudForms is about to be released first week in April and our initial plan 
> was to monkey-patch the gem to include those fixes. It turns our, however, 
> that changes modify gem's core to much to do the monkey-patching, hence we 
> decided to wait for you guys to perform the next release.
>  
> Q: Do you happen to know specific date when releasing new gem version is 
> supposed to happen? I remember we mentioned "within a couple of weeks" here 
> https://issues.apache.org/jira/browse/PROTON-1782?focusedCommentId=16401841=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16401841
>  , but we would need as good estimate as possible since we need to 
> communicate to customers how long they need to wait
>  
> Thanks for your great work, looking forward to be hearing from you!



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Created] (DISPATCH-953) Relative path name self test fails unless dispatch is installed

2018-03-29 Thread Chuck Rolke (JIRA)

Chuck Rolke created DISPATCH-953:


 Summary: Relative path name self test fails unless dispatch is 
installed
 Key: DISPATCH-953
 URL: https://issues.apache.org/jira/browse/DISPATCH-953
 Project: Qpid Dispatch
  Issue Type: Bug
Affects Versions: 1.1.0
Reporter: Chuck Rolke


See 
https://issues.apache.org/jira/browse/DISPATCH-940?focusedCommentId=16419005=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16419005



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (QPID-8140) [Broker-J][BDB HA] Removal of non existing group member can end up in broker crash due to uncaught MemberNotFoundException

2018-03-29 Thread ASF subversion and git services (JIRA)


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

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

Commit 1d832c616859ed5a5648315da4eba696207c9f15 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=1d832c6 ]

QPID-8140: [Broker-J][BDB HA] Handle MemberNotFoundException on removal of 
non-existing node


> [Broker-J][BDB HA] Removal of non existing group member can end up in broker 
> crash due to uncaught MemberNotFoundException
> --
>
> Key: QPID-8140
> URL: https://issues.apache.org/jira/browse/QPID-8140
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.2, qpid-java-broker-7.0.0, 
> qpid-java-broker-7.0.1
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Attachments: 
> TEST-org.apache.qpid.server.store.berkeleydb.replication.BDBHAVirtualHostNodeRestTest.testDeleteMasterNode.txt
>
>
> When two concurrent requests are made to delete a group member using REST API 
> for remote replication node, one can successfully remove the node, whilst 
> other can end-up in un-handled  {{MemberNotFoundException}} which crashes the 
> broker.
> An example of remote node delete request
> {code}
>  curl -v -k -u admin -X DELETE  
> http://localhost:8080/api/latest/remotereplicationnode/node2/node1
> {code}
> For failed requests an exception like the one below is reported
> {noformat}
>  ERROR [VirtualHostNode-node2-Config] o.a.q.s.u.ServerScopedRuntimeException 
> Exception on node removal from group
> com.sleepycat.je.rep.MemberNotFoundException: (JE 7.4.5) Node: node1 is not 
> currently a member of the group: 
> BDBHAVirtualHostNodeRestTest.testDeleteMasterNode, it has been removed.
>   at 
> com.sleepycat.je.rep.util.ReplicationGroupAdmin.checkMember(ReplicationGroupAdmin.java:576)
>   at 
> com.sleepycat.je.rep.util.ReplicationGroupAdmin.removeMember(ReplicationGroupAdmin.java:314)
>   at 
> org.apache.qpid.server.store.berkeleydb.replication.ReplicatedEnvironmentFacade.removeNodeFromGroup(ReplicatedEnvironmentFacade.java:1210)
>   at 
> org.apache.qpid.server.virtualhostnode.berkeleydb.BDBHARemoteReplicationNodeImpl.onDelete(BDBHARemoteReplicationNodeImpl.java:139)
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject$21.onSuccess(AbstractConfiguredObject.java:2759)
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject$24$1.run(AbstractConfiguredObject.java:2894)
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject$24$1.run(AbstractConfiguredObject.java:2890)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at javax.security.auth.Subject.doAs(Subject.java:360)
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject$24.onSuccess(AbstractConfiguredObject.java:2889)
>   at 
> com.google.common.util.concurrent.Futures$CallbackListener.run(Futures.java:1237)
>   at 
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$ImmediateIfSameThreadExecutor.execute(TaskExecutorImpl.java:400)
>   at 
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.execute(TaskExecutorImpl.java:183)
>   at 
> com.google.common.util.concurrent.AbstractFuture.executeListener(AbstractFuture.java:911)
>   at 
> com.google.common.util.concurrent.AbstractFuture.complete(AbstractFuture.java:822)
>   at 
> com.google.common.util.concurrent.AbstractFuture.set(AbstractFuture.java:664)
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject$ChainedSettableFuture.set(AbstractConfiguredObject.java:2710)
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject$21$1.onSuccess(AbstractConfiguredObject.java:2765)
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject$24$1.run(AbstractConfiguredObject.java:2894)
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject$24$1.run(AbstractConfiguredObject.java:2890)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at javax.security.auth.Subject.doAs(Subject.java:360)
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject$24.onSuccess(AbstractConfiguredObject.java:2889)
>   at 
> com.google.common.util.concurrent.Futures$CallbackListener.run(Futures.java:1237)
>   at 
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$ImmediateIfSameThreadExecutor.execute(TaskExecutorImpl.java:400)
>   at 
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.execute(TaskExecutorImpl.java:183)
>   at 
>

[jira] [Commented] (QPIDJMS-374) Double encoded query parameters

2018-03-29 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/QPIDJMS-374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16419224#comment-16419224
 ] 

ASF GitHub Bot commented on QPIDJMS-374:


Github user tabish121 commented on the issue:

https://github.com/apache/qpid-jms/pull/17
  
I believe the correct fix is to call PropertyUtil.parseQuery(remoteURI) 
instead and it will do the right thing, although we can't know until you 
provide some tests to validate it.  


> Double encoded query parameters
> ---
>
> Key: QPIDJMS-374
> URL: https://issues.apache.org/jira/browse/QPIDJMS-374
> Project: Qpid JMS
>  Issue Type: Bug
>  Components: qpid-jms-client
>Affects Versions: 0.31.0
>Reporter: Michael Bolz
>Priority: Major
>
> When query parameters are parsed in 
> [TransportFactory|https://github.com/apache/qpid-jms/blob/70fe1b882e1381b1016a10b0707f6e112d4e0598/qpid-jms-client/src/main/java/org/apache/qpid/jms/transports/TransportFactory.java#L51]
>  and 
> [AmqpProviderFactory|https://github.com/apache/qpid-jms/blob/70fe1b882e1381b1016a10b0707f6e112d4e0598/qpid-jms-client/src/main/java/org/apache/qpid/jms/provider/amqp/AmqpProviderFactory.java#L41]
>  and than further processed via 
> [PropertyUtil#replaceQuery|https://github.com/apache/qpid-jms/blob/70fe1b882e1381b1016a10b0707f6e112d4e0598/qpid-jms-client/src/main/java/org/apache/qpid/jms/util/PropertyUtil.java#L64]
>  the values gets double encoded.
> See also Javadoc of 
> [PropertyUtil#replaceQuery|https://github.com/apache/qpid-jms/blob/70fe1b882e1381b1016a10b0707f6e112d4e0598/qpid-jms-client/src/main/java/org/apache/qpid/jms/util/PropertyUtil.java#L64]:
> {quote}
> The string values in the Map will be URL Encoded by this method which means 
> that if an
> already encoded value is passed it will be double encoded resulting in 
> corrupt values
> in the newly created URI.
> {quote}
> For a fix I created a [pull 
> request|https://github.com/apache/qpid-jms/pull/17].



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[GitHub] qpid-jms issue #17: QPIDJMS-374: Use getRawQuery to avoid double encoding

2018-03-29 Thread tabish121

Github user tabish121 commented on the issue:

https://github.com/apache/qpid-jms/pull/17
  
I believe the correct fix is to call PropertyUtil.parseQuery(remoteURI) 
instead and it will do the right thing, although we can't know until you 
provide some tests to validate it.  


---

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

[jira] [Commented] (DISPATCH-947) system tests on master branch failing when run against latest master proton

2018-03-29 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on DISPATCH-947:
--

Commit cbbefa77fb6ae5da6dd881eb201b3501180e69d8 in qpid-dispatch's branch 
refs/heads/master from [~mgoulish]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=cbbefa7 ]

DISPATCH-947 : fix tests broken by de-Messengerization of other tests


> system tests on master branch failing when run against latest master proton
> ---
>
> Key: DISPATCH-947
> URL: https://issues.apache.org/jira/browse/DISPATCH-947
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Tests
>Affects Versions: 1.1.0
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>Priority: Major
>
> The system_tests_*.py are failing when run against the latest code from 
> proton master branch with the following error
>  
> {noformat}
> 42: Test command: /usr/bin/python 
> "/home/gmurthy/opensource/qpid-dispatch/build/tests/run.py" "-x" "unit2" "-v" 
> "system_tests_http"
> 42: Test timeout computed to be: 1500
> 42: Traceback (most recent call last):
> 42:   File "/usr/bin/unit2", line 11, in 
> 42: load_entry_point('unittest2==1.1.0', 'console_scripts', 'unit2')()
> 42:   File "/usr/lib/python2.7/site-packages/unittest2/__main__.py", line 18, 
> in main_
> 42: main(module=None)
> 42:   File "/usr/lib/python2.7/site-packages/unittest2/main.py", line 89, in 
> __init__
> 42: self.parseArgs(argv)
> 42:   File "/usr/lib/python2.7/site-packages/unittest2/main.py", line 135, in 
> parseArgs
> 42: self.createTests()
> 42:   File "/usr/lib/python2.7/site-packages/unittest2/main.py", line 142, in 
> createTests
> 42: self.module)
> 42:   File "/usr/lib/python2.7/site-packages/unittest2/loader.py", line 245, 
> in loadTestsFromNames
> 42: suites = [self.loadTestsFromName(name, module) for name in names]
> 42:   File "/usr/lib/python2.7/site-packages/unittest2/loader.py", line 172, 
> in loadTestsFromName
> 42: module = __import__(module_name)
> 42:   File 
> "/home/gmurthy/opensource/qpid-dispatch/tests/system_tests_http.py", line 23, 
> in 
> 42: from system_test import TestCase, Qdrouterd, main_module, DIR
> 42:   File "/home/gmurthy/opensource/qpid-dispatch/tests/system_test.py", 
> line 478, in 
> 42: class Messenger(proton.Messenger):
> 42: AttributeError: 'module' object has no attribute 'Messenger'
> 42/42 Test #42: system_tests_http .***Failed    0.18 
> sec
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (QPID-8144) [Broker-J] Memory compaction does not run when used direct memory exceeds 2GB

2018-03-29 Thread Keith Wall (JIRA)


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

Keith Wall updated QPID-8144:
-
Description: 
The Broker-J uses direct memory for the caching of message content and IO 
buffers used for AMQP messaging. If direct memory utilisation exceeds 2GB, 
owing to a defect the memory compaction mechanism does not get triggered.  This 
problem may lead to an {{OutOfMemoryError: direct}} condition. Whether this 
condition manifests will depend on the message consumption patten - if the 
consumption pattern leads to sparsely occupied buffers the problem will occur. 

A Broker restart will be required to restore service.




  was:
The Broker-J uses direct memory for the caching of message content and IO 
buffers used for AMQP messaging. If direct memory utilisation exceeds 2GB, 
owing to a defect the memory compaction mechanism does not get triggered.  This 
problem may lead to an {{OutOfMemoryError: direct}} condition. Whether this 
condition manifests will depend on the message consumption patten - if the 
consumption pattern leads to sparsely occupied buffers the problem will occur. 






> [Broker-J] Memory compaction does not run when used direct memory exceeds 2GB
> -
>
> Key: QPID-8144
> URL: https://issues.apache.org/jira/browse/QPID-8144
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.2, qpid-java-6.0.7, 
> qpid-java-6.1.3, qpid-java-6.0.8, qpid-java-broker-7.0.0, qpid-java-6.1.5, 
> qpid-java-broker-7.0.1
>Reporter: Keith Wall
>Priority: Blocker
> Fix For: qpid-java-6.1.6, qpid-java-broker-7.0.3
>
>
> The Broker-J uses direct memory for the caching of message content and IO 
> buffers used for AMQP messaging. If direct memory utilisation exceeds 2GB, 
> owing to a defect the memory compaction mechanism does not get triggered.  
> This problem may lead to an {{OutOfMemoryError: direct}} condition. Whether 
> this condition manifests will depend on the message consumption patten - if 
> the consumption pattern leads to sparsely occupied buffers the problem will 
> occur. 
> A Broker restart will be required to restore service.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (QPID-8144) [Broker-J] Memory compaction not running when allocated direct memory exceeds 2GB

2018-03-29 Thread Keith Wall (JIRA)


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

Keith Wall updated QPID-8144:
-
Affects Version/s: qpid-java-broker-7.0.2
   qpid-java-6.0.7
   qpid-java-6.1.3
   qpid-java-6.0.8
   qpid-java-broker-7.0.0
   qpid-java-6.1.5
   qpid-java-broker-7.0.1

> [Broker-J] Memory compaction not running when allocated direct memory exceeds 
> 2GB
> -
>
> Key: QPID-8144
> URL: https://issues.apache.org/jira/browse/QPID-8144
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.2, qpid-java-6.0.7, 
> qpid-java-6.1.3, qpid-java-6.0.8, qpid-java-broker-7.0.0, qpid-java-6.1.5, 
> qpid-java-broker-7.0.1
>Reporter: Keith Wall
>Priority: Blocker
> Fix For: qpid-java-6.1.6, qpid-java-broker-7.0.3
>
>
> The Broker-J uses direct memory for the caching of message content and IO 
> buffers used for AMQP messaging. If direct memory utilisation exceeds 2GB, 
> owing to a defect the memory compaction mechanism does not get triggered.  
> This problem may lead to an {{OutOfMemoryError: direct}} condition. Whether 
> this condition manifests will depend on the message consumption patten - if 
> the consumption pattern leads to sparsely occupied buffers the problem will 
> occur. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (QPID-8144) [Broker-J] Memory compaction does not run when used direct memory exceeds 2GB

2018-03-29 Thread Keith Wall (JIRA)


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

Keith Wall updated QPID-8144:
-
Summary: [Broker-J] Memory compaction does not run when used direct memory 
exceeds 2GB  (was: [Broker-J] Memory compaction not running when allocated 
direct memory exceeds 2GB)

> [Broker-J] Memory compaction does not run when used direct memory exceeds 2GB
> -
>
> Key: QPID-8144
> URL: https://issues.apache.org/jira/browse/QPID-8144
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.2, qpid-java-6.0.7, 
> qpid-java-6.1.3, qpid-java-6.0.8, qpid-java-broker-7.0.0, qpid-java-6.1.5, 
> qpid-java-broker-7.0.1
>Reporter: Keith Wall
>Priority: Blocker
> Fix For: qpid-java-6.1.6, qpid-java-broker-7.0.3
>
>
> The Broker-J uses direct memory for the caching of message content and IO 
> buffers used for AMQP messaging. If direct memory utilisation exceeds 2GB, 
> owing to a defect the memory compaction mechanism does not get triggered.  
> This problem may lead to an {{OutOfMemoryError: direct}} condition. Whether 
> this condition manifests will depend on the message consumption patten - if 
> the consumption pattern leads to sparsely occupied buffers the problem will 
> occur. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (QPID-8144) [Broker-J] Memory compaction not running when allocated direct memory exceeds 2GB

2018-03-29 Thread Keith Wall (JIRA)


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

Keith Wall updated QPID-8144:
-
Fix Version/s: (was: qpid-java-6.1.3)
   (was: qpid-java-6.0.7)
   (was: qpid-java-broker-7.1.0)

> [Broker-J] Memory compaction not running when allocated direct memory exceeds 
> 2GB
> -
>
> Key: QPID-8144
> URL: https://issues.apache.org/jira/browse/QPID-8144
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.2, qpid-java-6.0.7, 
> qpid-java-6.1.3, qpid-java-6.0.8, qpid-java-broker-7.0.0, qpid-java-6.1.5, 
> qpid-java-broker-7.0.1
>Reporter: Keith Wall
>Priority: Blocker
> Fix For: qpid-java-6.1.6, qpid-java-broker-7.0.3
>
>
> The Broker-J uses direct memory for the caching of message content and IO 
> buffers used for AMQP messaging. If direct memory utilisation exceeds 2GB, 
> owing to a defect the memory compaction mechanism does not get triggered.  
> This problem may lead to an {{OutOfMemoryError: direct}} condition. Whether 
> this condition manifests will depend on the message consumption patten - if 
> the consumption pattern leads to sparsely occupied buffers the problem will 
> occur. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Created] (QPID-8144) [Broker-J] Memory compaction not running when allocated direct memory exceeds 2GB

2018-03-29 Thread Keith Wall (JIRA)

Keith Wall created QPID-8144:


 Summary: [Broker-J] Memory compaction not running when allocated 
direct memory exceeds 2GB
 Key: QPID-8144
 URL: https://issues.apache.org/jira/browse/QPID-8144
 Project: Qpid
  Issue Type: Bug
  Components: Broker-J
Reporter: Keith Wall
 Fix For: qpid-java-broker-7.1.0, qpid-java-6.1.6, 
qpid-java-broker-7.0.3, qpid-java-6.1.3, qpid-java-6.0.7


The Broker-J uses direct memory for the caching of message content and IO 
buffers used for AMQP messaging. If direct memory utilisation exceeds 2GB, 
owing to a defect the memory compaction mechanism does not get triggered.  This 
problem may lead to an {{OutOfMemoryError: direct}} condition. Whether this 
condition manifests will depend on the message consumption patten - if the 
consumption pattern leads to sparsely occupied buffers the problem will occur. 







--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Created] (DISPATCH-952) qdrouterd seg fault after reporting "too many sessions"

2018-03-29 Thread Alan Conway (JIRA)

Alan Conway created DISPATCH-952:


 Summary: qdrouterd seg fault after reporting "too many sessions"
 Key: DISPATCH-952
 URL: https://issues.apache.org/jira/browse/DISPATCH-952
 Project: Qpid Dispatch
  Issue Type: Bug
  Components: Container
Reporter: Alan Conway


Reported at [https://bugzilla.redhat.com/show_bug.cgi?id=1561876]

 
{code:java}
Currently running Satellite 6.3 with 5K clients. The clients are managed by 2 
capsules:
Capsule 1: 3K clients
Capsule 2: 2K clients

Logs from Capsule 1:

[root@c02-h10-r620-vm1 ~]# journalctl | grep qdrouterd
Mar 26 03:00:47 c02-h10-r620-vm1.rdu.openstack.engineering.redhat.com 
groupadd[19140]: group added to /etc/group: name=qdrouterd, GID=993
Mar 26 03:00:47 c02-h10-r620-vm1.rdu.openstack.engineering.redhat.com 
groupadd[19140]: group added to /etc/gshadow: name=qdrouterd
Mar 26 03:00:47 c02-h10-r620-vm1.rdu.openstack.engineering.redhat.com 
groupadd[19140]: new group: name=qdrouterd, GID=993
Mar 26 03:00:47 c02-h10-r620-vm1.rdu.openstack.engineering.redhat.com 
useradd[19145]: new user: name=qdrouterd, UID=996, GID=993, 
home=/var/lib/qdrouterd, shell=/sbin/nologin
Mar 28 10:39:06 c02-h10-r620-vm1.rdu.openstack.engineering.redhat.com 
qdrouterd[16084]: [0x7fe3f0016aa0]:pn_session: too many sessions: 32768  
channel_max is 32767
Mar 28 10:39:06 c02-h10-r620-vm1.rdu.openstack.engineering.redhat.com kernel: 
qdrouterd[16087]: segfault at 88 ip 7fe40b79d820 sp 7fe3fd5f9298 error 
6 in libqpid-proton.so.10.0.0[7fe40b77f000+4b000]
Mar 28 10:39:07 c02-h10-r620-vm1.rdu.openstack.engineering.redhat.com 
systemd[1]: qdrouterd.service: main process exited, code=killed, status=11/SEGV
Mar 28 10:39:07 c02-h10-r620-vm1.rdu.openstack.engineering.redhat.com 
systemd[1]: Unit qdrouterd.service entered failed state.
Mar 28 10:39:07 c02-h10-r620-vm1.rdu.openstack.engineering.redhat.com 
systemd[1]: qdrouterd.service failed.
Mar 29 01:02:09 c02-h10-r620-vm1.rdu.openstack.engineering.redhat.com 
/usr/sbin/katello-service[1740]: *** status failed: qdrouterd ***

Logs from Capsule 2:
[root@c02-h10-r620-vm2 ~]# systemctl status qdrouterd
● qdrouterd.service - Qpid Dispatch router daemon
   Loaded: loaded (/usr/lib/systemd/system/qdrouterd.service; enabled; vendor 
preset: disabled)
  Drop-In: /etc/systemd/system/qdrouterd.service.d
   └─limits.conf
   Active: failed (Result: signal) since Wed 2018-03-28 10:58:02 EDT; 14h ago
  Process: 1158 ExecStart=/usr/sbin/qdrouterd -c 
/etc/qpid-dispatch/qdrouterd.conf (code=killed, signal=SEGV)
 Main PID: 1158 (code=killed, signal=SEGV)

Mar 28 07:38:46 c02-h10-r620-vm2.rdu.openstack.engineering.redhat.com 
systemd[1]: Started Qpid Dispatch router daemon.
Mar 28 07:38:46 c02-h10-r620-vm2.rdu.openstack.engineering.redhat.com 
systemd[1]: Starting Qpid Dispatch router daemon...
Mar 28 10:58:02 c02-h10-r620-vm2.rdu.openstack.engineering.redhat.com 
qdrouterd[1158]: [0x7f36a000a170]:unable to find an open available channel 
within limit of 32767
Mar 28 10:58:02 c02-h10-r620-vm2.rdu.openstack.engineering.redhat.com 
qdrouterd[1158]: [0x7f36a000a170]:process error -2
Mar 28 10:58:02 c02-h10-r620-vm2.rdu.openstack.engineering.redhat.com 
qdrouterd[1158]: [0x7f36a000a170]:pn_session: too many sessions: 32768  
channel_max is 32767
Mar 28 10:58:02 c02-h10-r620-vm2.rdu.openstack.engineering.redhat.com 
systemd[1]: qdrouterd.service: main process exited, code=killed, status=11/SEGV
Mar 28 10:58:02 c02-h10-r620-vm2.rdu.openstack.engineering.redhat.com 
systemd[1]: Unit qdrouterd.service entered failed state.
Mar 28 10:58:02 c02-h10-r620-vm2.rdu.openstack.engineering.redhat.com 
systemd[1]: qdrouterd.service failed.

{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Resolved] (DISPATCH-940) When running qdrouterd with -c and -d combined, configuration file is reporting as not found

2018-03-29 Thread Chuck Rolke (JIRA)


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

Chuck Rolke resolved DISPATCH-940.
--
Resolution: Fixed

The problematic self test was disabled in commit 9b07c2d.

The test will be fixed under another jira.

> When running qdrouterd with -c and -d combined, configuration file is 
> reporting as not found
> 
>
> Key: DISPATCH-940
> URL: https://issues.apache.org/jira/browse/DISPATCH-940
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 1.1.0
>Reporter: Fernando Giorgetti
>Priority: Minor
>  Labels: pull-request-available
> Fix For: 1.1.0
>
>
> If you run qdrouterd as shown below, everything works just fine:
>  
> {code:java}
> [fgiorget@fgiorget qpid-dispatch]$ qdrouterd -c qdrouterd.conf 
> 2018-03-08 14:49:02.797039 -0300 SERVER (info) Container Name: Router.A
> 2018-03-08 14:49:02.797142 -0300 ROUTER (info) Router started in Standalone 
> mode 
> {code}
> But if you try to add -d (daemon) flag, then it does not find the 
> configuration file.
> {code:java}
> [fgiorget@fgiorget qpid-dispatch]$ qdrouterd -d -c qdrouterd.conf 
> qdrouterd: Not found: Configuration file could not be opened{code}
> It only works with fully qualified file name.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (DISPATCH-940) When running qdrouterd with -c and -d combined, configuration file is reporting as not found

2018-03-29 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on DISPATCH-940:
--

Commit 9b07c2d69bcd38fb0be0e5fc0d0cf44a84eb3c65 in qpid-dispatch's branch 
refs/heads/master from [~chug]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=9b07c2d ]

DISPATCH-940: Disable test that fails unless router is installed

The underlying feature works in practice so this issue will be
closed. Fixing the test will be addressed in a new jira.


> When running qdrouterd with -c and -d combined, configuration file is 
> reporting as not found
> 
>
> Key: DISPATCH-940
> URL: https://issues.apache.org/jira/browse/DISPATCH-940
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 1.1.0
>Reporter: Fernando Giorgetti
>Priority: Minor
>  Labels: pull-request-available
> Fix For: 1.1.0
>
>
> If you run qdrouterd as shown below, everything works just fine:
>  
> {code:java}
> [fgiorget@fgiorget qpid-dispatch]$ qdrouterd -c qdrouterd.conf 
> 2018-03-08 14:49:02.797039 -0300 SERVER (info) Container Name: Router.A
> 2018-03-08 14:49:02.797142 -0300 ROUTER (info) Router started in Standalone 
> mode 
> {code}
> But if you try to add -d (daemon) flag, then it does not find the 
> configuration file.
> {code:java}
> [fgiorget@fgiorget qpid-dispatch]$ qdrouterd -d -c qdrouterd.conf 
> qdrouterd: Not found: Configuration file could not be opened{code}
> It only works with fully qualified file name.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Created] (PROTON-1819) [cpp] handle running out of sessions properly

2018-03-29 Thread Alan Conway (JIRA)

Alan Conway created PROTON-1819:
---

 Summary: [cpp] handle running out of sessions properly
 Key: PROTON-1819
 URL: https://issues.apache.org/jira/browse/PROTON-1819
 Project: Qpid Proton
  Issue Type: Bug
  Components: cpp-binding
Affects Versions: proton-c-0.22.0
Reporter: Alan Conway
 Fix For: proton-c-0.23.0


C++ binding does not handle running out of sessions correctly, see:

[https://github.com/apache/qpid-proton/blob/master/proton-c/bindings/cpp/src/connection.cpp#L113]

 

The binding should throw an exception rather than returning a null session, 
which will almost certainly cause a core dump when the application tries to use 
it.

This issue was pointed out by the reporter of

https://bugzilla.redhat.com/show_bug.cgi?id=1561876



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (PROTON-1818) [C++ binding] Complex types: list of nulls causes SIGABRT

2018-03-29 Thread Kim van der Riet (JIRA)


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

Kim van der Riet updated PROTON-1818:
-
Description: 
The following snippet of code
{noformat}
std::vector array_2 = {nullptr, nullptr, };
{noformat}
compiles, but when run throws the following core:
{noformat}
terminate called after throwing an instance of 'std::logic_error'
what(): basic_string::_M_construct null not valid

Program received signal SIGABRT, Aborted.
0x76f18660 in raise () from /lib64/libc.so.6
(gdb) bt
#0 0x76f18660 in raise () from /lib64/libc.so.6
#1 0x76f19c41 in abort () from /lib64/libc.so.6
#2 0x7788e025 in __gnu_cxx::__verbose_terminate_handler() () from 
/lib64/libstdc++.so.6
#3 0x7788bc16 in __cxxabiv1::__terminate(void (*)()) () from 
/lib64/libstdc++.so.6
#4 0x7788bc61 in std::terminate() () from /lib64/libstdc++.so.6
#5 0x7788bea4 in __cxa_throw () from /lib64/libstdc++.so.6
#6 0x778b580f in std::__throw_logic_error(char const*) () from 
/lib64/libstdc++.so.6
#7 0x779242c1 in void std::__cxx11::basic_string::_M_construct(char 
const*, char const*, std::forward_iterator_tag) ()
from /lib64/libstdc++.so.6
#8 0x7792443f in std::__cxx11::basic_string::basic_string(char const*, 
std::allocator const&) () from /lib64/libstdc++.so.6
#9 0x004174d7 in proton::codec::operator<< (e=..., s=0x0) at 
../install/include/proton/././codec/encoder.hpp:168
#10 0x004189f7 in 
proton::value::operator=(decltype(nullptr) const&) 
(this=0x7fff9eb0, x=) at 
../install/include/proton/./value.hpp:84
#11 0x004179e4 in 
proton::value::value(decltype(nullptr) const&, 
proton::value::assignable::type*) 
(this=0x7fff9eb0, 
x=) at ../install/include/proton/./value.hpp:79
#12 0x0040233b in qpidit::amqp_complex_types_test::TestData::initialize 
() at amqp_complex_types_test.data.cpp:61
#13 0x00417109 in __static_initialization_and_destruction_0 
(__initialize_p=1, __priority=65535) at amqp_complex_types_test.data.cpp:613
#14 0x00417125 in 
_GLOBAL__sub_I__ZN6qpidit23amqp_complex_types_test8TestData10initializeEv () at 
amqp_complex_types_test.data.cpp:638
#15 0x0041b74d in __libc_csu_init ()
#16 0x76f04ebb in __libc_start_main () from /lib64/libc.so.6
#17 0x00401fca in _start ()
{noformat}
and where the referenced line {{amqp_complex_types_test.data.cpp:61}} is the 
snippet shown above.

  was:
The following snippet of code
{noformat}
std::vector array_2 = {nullptr, nullptr, };
{noformat}
compiles, but when run throws the following core:
{noformat}
terminate called after throwing an instance of 'std::logic_error'
what(): basic_string::_M_construct null not valid

Program received signal SIGABRT, Aborted.
0x76f18660 in raise () from /lib64/libc.so.6
Missing separate debuginfos, use: dnf debuginfo-install 
cyrus-sasl-lib-2.1.26-34.fc27.x86_64 keyutils-libs-1.5.10-3.fc27.x86_64 
krb5-libs-1.15.2-7.fc27.x86_64 libcom_err-1.43.5-2.fc27.x86_64 
libcrypt-nss-2.26-27.fc27.x86_64 libgcc-7.3.1-5.fc27.x86_64 
libselinux-2.7-3.fc27.x86_64 libstdc++-7.3.1-5.fc27.x86_64 
nss-softokn-freebl-3.35.0-1.0.fc27.x86_64 openssl-libs-1.1.0g-1.fc27.x86_64 
pcre2-10.31-1.fc27.x86_64 zlib-1.2.11-4.fc27.x86_64
(gdb) bt
#0 0x76f18660 in raise () from /lib64/libc.so.6
#1 0x76f19c41 in abort () from /lib64/libc.so.6
#2 0x7788e025 in __gnu_cxx::__verbose_terminate_handler() () from 
/lib64/libstdc++.so.6
#3 0x7788bc16 in __cxxabiv1::__terminate(void (*)()) () from 
/lib64/libstdc++.so.6
#4 0x7788bc61 in std::terminate() () from /lib64/libstdc++.so.6
#5 0x7788bea4 in __cxa_throw () from /lib64/libstdc++.so.6
#6 0x778b580f in std::__throw_logic_error(char const*) () from 
/lib64/libstdc++.so.6
#7 0x779242c1 in void std::__cxx11::basic_string::_M_construct(char 
const*, char const*, std::forward_iterator_tag) ()
from /lib64/libstdc++.so.6
#8 0x7792443f in std::__cxx11::basic_string::basic_string(char const*, 
std::allocator const&) () from /lib64/libstdc++.so.6
#9 0x004174d7 in proton::codec::operator<< (e=..., s=0x0) at 
../install/include/proton/././codec/encoder.hpp:168
#10 0x004189f7 in 
proton::value::operator=(decltype(nullptr) const&) 
(this=0x7fff9eb0, x=) at 
../install/include/proton/./value.hpp:84
#11 0x004179e4 in 
proton::value::value(decltype(nullptr) const&, 
proton::value::assignable::type*) 
(this=0x7fff9eb0, 
x=) at ../install/include/proton/./value.hpp:79
#12 0x0040233b in

[jira] [Created] (DISPATCH-951) log details for the proton found during build

2018-03-29 Thread Robbie Gemmell (JIRA)

Robbie Gemmell created DISPATCH-951:
---

 Summary: log details for the proton found during build
 Key: DISPATCH-951
 URL: https://issues.apache.org/jira/browse/DISPATCH-951
 Project: Qpid Dispatch
  Issue Type: Improvement
Affects Versions: 1.0.1, 1.1.0
Reporter: Robbie Gemmell


The router build logs info about various things it finds when running cmake, 
e.g Python and libwebsockets, but it does not emit the details for proton, e.g 
the way qpid-cpp does. It would be useful if it did.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (PROTON-1818) [C++ binding] Complex types: list of nulls causes SIGABRT

2018-03-29 Thread Kim van der Riet (JIRA)


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

Kim van der Riet updated PROTON-1818:
-
Component/s: cpp-binding

> [C++ binding] Complex types: list of nulls causes SIGABRT
> -
>
> Key: PROTON-1818
> URL: https://issues.apache.org/jira/browse/PROTON-1818
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
>Reporter: Kim van der Riet
>Priority: Major
>
> The following snippet of code
> {noformat}
> std::vector array_2 = {nullptr, nullptr, };
> {noformat}
> compiles, but when run throws the following core:
> {noformat}
> terminate called after throwing an instance of 'std::logic_error'
> what(): basic_string::_M_construct null not valid
> Program received signal SIGABRT, Aborted.
> 0x76f18660 in raise () from /lib64/libc.so.6
> Missing separate debuginfos, use: dnf debuginfo-install 
> cyrus-sasl-lib-2.1.26-34.fc27.x86_64 keyutils-libs-1.5.10-3.fc27.x86_64 
> krb5-libs-1.15.2-7.fc27.x86_64 libcom_err-1.43.5-2.fc27.x86_64 
> libcrypt-nss-2.26-27.fc27.x86_64 libgcc-7.3.1-5.fc27.x86_64 
> libselinux-2.7-3.fc27.x86_64 libstdc++-7.3.1-5.fc27.x86_64 
> nss-softokn-freebl-3.35.0-1.0.fc27.x86_64 openssl-libs-1.1.0g-1.fc27.x86_64 
> pcre2-10.31-1.fc27.x86_64 zlib-1.2.11-4.fc27.x86_64
> (gdb) bt
> #0 0x76f18660 in raise () from /lib64/libc.so.6
> #1 0x76f19c41 in abort () from /lib64/libc.so.6
> #2 0x7788e025 in __gnu_cxx::__verbose_terminate_handler() () from 
> /lib64/libstdc++.so.6
> #3 0x7788bc16 in __cxxabiv1::__terminate(void (*)()) () from 
> /lib64/libstdc++.so.6
> #4 0x7788bc61 in std::terminate() () from /lib64/libstdc++.so.6
> #5 0x7788bea4 in __cxa_throw () from /lib64/libstdc++.so.6
> #6 0x778b580f in std::__throw_logic_error(char const*) () from 
> /lib64/libstdc++.so.6
> #7 0x779242c1 in void std::__cxx11::basic_string std::char_traits, std::allocator >::_M_construct const*>(char const*, char const*, std::forward_iterator_tag) ()
> from /lib64/libstdc++.so.6
> #8 0x7792443f in std::__cxx11::basic_string std::char_traits, std::allocator >::basic_string(char const*, 
> std::allocator const&) () from /lib64/libstdc++.so.6
> #9 0x004174d7 in proton::codec::operator<< (e=..., s=0x0) at 
> ../install/include/proton/././codec/encoder.hpp:168
> #10 0x004189f7 in 
> proton::value::operator=(decltype(nullptr) const&) 
> (this=0x7fff9eb0, x=) at 
> ../install/include/proton/./value.hpp:84
> #11 0x004179e4 in 
> proton::value::value(decltype(nullptr) const&, 
> proton::value::assignable::type*) 
> (this=0x7fff9eb0, 
> x=) at ../install/include/proton/./value.hpp:79
> #12 0x0040233b in 
> qpidit::amqp_complex_types_test::TestData::initialize () at 
> amqp_complex_types_test.data.cpp:61
> #13 0x00417109 in __static_initialization_and_destruction_0 
> (__initialize_p=1, __priority=65535) at amqp_complex_types_test.data.cpp:613
> #14 0x00417125 in 
> _GLOBAL__sub_I__ZN6qpidit23amqp_complex_types_test8TestData10initializeEv () 
> at amqp_complex_types_test.data.cpp:638
> #15 0x0041b74d in __libc_csu_init ()
> #16 0x76f04ebb in __libc_start_main () from /lib64/libc.so.6
> #17 0x00401fca in _start ()
> {noformat}
> and where the referenced line {{amqp_complex_types_test.data.cpp:61}} is the 
> snippet shown above.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (PROTON-1815) [C++ binding] Complex types: List containing array of std::nullptr_t fails compilation

2018-03-29 Thread Kim van der Riet (JIRA)


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

Kim van der Riet updated PROTON-1815:
-
Issue Type: Bug  (was: Task)

> [C++ binding]  Complex types: List containing array of std::nullptr_t fails 
> compilation
> ---
>
> Key: PROTON-1815
> URL: https://issues.apache.org/jira/browse/PROTON-1815
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
>Reporter: Kim van der Riet
>Priority: Major
>
> If an array of AMQP nulls is contained in a list, the compiler fails with:
> {noformat}
> include/proton/./codec/vector.hpp:39:31: error: incomplete type 
> ‘proton::internal::type_id_of’ used in nested name specifier
> {noformat}
> Code snippet that produces this error:
> {noformat}
> std::vector _arr_27 = {nullptr, nullptr, };
> std::vector _arr_28 = {int8_t(1), int8_t(2), };
> std::vector _lst_7 = {_arr_27, _arr_28, };
> {noformat}
> which fails on the third line.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Created] (PROTON-1818) [C++ binding] Complex types: list of nulls causes SIGABRT

2018-03-29 Thread Kim van der Riet (JIRA)

Kim van der Riet created PROTON-1818:


 Summary: [C++ binding] Complex types: list of nulls causes SIGABRT
 Key: PROTON-1818
 URL: https://issues.apache.org/jira/browse/PROTON-1818
 Project: Qpid Proton
  Issue Type: Bug
Reporter: Kim van der Riet


The following snippet of code
{noformat}
std::vector array_2 = {nullptr, nullptr, };
{noformat}
compiles, but when run throws the following core:
{noformat}
terminate called after throwing an instance of 'std::logic_error'
what(): basic_string::_M_construct null not valid

Program received signal SIGABRT, Aborted.
0x76f18660 in raise () from /lib64/libc.so.6
Missing separate debuginfos, use: dnf debuginfo-install 
cyrus-sasl-lib-2.1.26-34.fc27.x86_64 keyutils-libs-1.5.10-3.fc27.x86_64 
krb5-libs-1.15.2-7.fc27.x86_64 libcom_err-1.43.5-2.fc27.x86_64 
libcrypt-nss-2.26-27.fc27.x86_64 libgcc-7.3.1-5.fc27.x86_64 
libselinux-2.7-3.fc27.x86_64 libstdc++-7.3.1-5.fc27.x86_64 
nss-softokn-freebl-3.35.0-1.0.fc27.x86_64 openssl-libs-1.1.0g-1.fc27.x86_64 
pcre2-10.31-1.fc27.x86_64 zlib-1.2.11-4.fc27.x86_64
(gdb) bt
#0 0x76f18660 in raise () from /lib64/libc.so.6
#1 0x76f19c41 in abort () from /lib64/libc.so.6
#2 0x7788e025 in __gnu_cxx::__verbose_terminate_handler() () from 
/lib64/libstdc++.so.6
#3 0x7788bc16 in __cxxabiv1::__terminate(void (*)()) () from 
/lib64/libstdc++.so.6
#4 0x7788bc61 in std::terminate() () from /lib64/libstdc++.so.6
#5 0x7788bea4 in __cxa_throw () from /lib64/libstdc++.so.6
#6 0x778b580f in std::__throw_logic_error(char const*) () from 
/lib64/libstdc++.so.6
#7 0x779242c1 in void std::__cxx11::basic_string::_M_construct(char 
const*, char const*, std::forward_iterator_tag) ()
from /lib64/libstdc++.so.6
#8 0x7792443f in std::__cxx11::basic_string::basic_string(char const*, 
std::allocator const&) () from /lib64/libstdc++.so.6
#9 0x004174d7 in proton::codec::operator<< (e=..., s=0x0) at 
../install/include/proton/././codec/encoder.hpp:168
#10 0x004189f7 in 
proton::value::operator=(decltype(nullptr) const&) 
(this=0x7fff9eb0, x=) at 
../install/include/proton/./value.hpp:84
#11 0x004179e4 in 
proton::value::value(decltype(nullptr) const&, 
proton::value::assignable::type*) 
(this=0x7fff9eb0, 
x=) at ../install/include/proton/./value.hpp:79
#12 0x0040233b in qpidit::amqp_complex_types_test::TestData::initialize 
() at amqp_complex_types_test.data.cpp:61
#13 0x00417109 in __static_initialization_and_destruction_0 
(__initialize_p=1, __priority=65535) at amqp_complex_types_test.data.cpp:613
#14 0x00417125 in 
_GLOBAL__sub_I__ZN6qpidit23amqp_complex_types_test8TestData10initializeEv () at 
amqp_complex_types_test.data.cpp:638
#15 0x0041b74d in __libc_csu_init ()
#16 0x76f04ebb in __libc_start_main () from /lib64/libc.so.6
#17 0x00401fca in _start ()
{noformat}
and where the referenced line {{amqp_complex_types_test.data.cpp:61}} is the 
snippet shown above.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (DISPATCH-940) When running qdrouterd with -c and -d combined, configuration file is reporting as not found

2018-03-29 Thread Robbie Gemmell (JIRA)


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

Robbie Gemmell commented on DISPATCH-940:
-

I reopened this because the test has issues.

I was seeing a failure while running it, where the test timed out, seemingly 
due to a router not coming up. There was no test or router logging to allow 
determining why.

In the end, the reason is that I didn't have dispatch installed. I was running 
the tests as part of the build verification, prior to installing it. As a 
result, the test failed to start a router. This also means its likely the test 
could start the wrong router, if another happened to be on the path.

> When running qdrouterd with -c and -d combined, configuration file is 
> reporting as not found
> 
>
> Key: DISPATCH-940
> URL: https://issues.apache.org/jira/browse/DISPATCH-940
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 1.1.0
>Reporter: Fernando Giorgetti
>Priority: Minor
>  Labels: pull-request-available
> Fix For: 1.1.0
>
>
> If you run qdrouterd as shown below, everything works just fine:
>  
> {code:java}
> [fgiorget@fgiorget qpid-dispatch]$ qdrouterd -c qdrouterd.conf 
> 2018-03-08 14:49:02.797039 -0300 SERVER (info) Container Name: Router.A
> 2018-03-08 14:49:02.797142 -0300 ROUTER (info) Router started in Standalone 
> mode 
> {code}
> But if you try to add -d (daemon) flag, then it does not find the 
> configuration file.
> {code:java}
> [fgiorget@fgiorget qpid-dispatch]$ qdrouterd -d -c qdrouterd.conf 
> qdrouterd: Not found: Configuration file could not be opened{code}
> It only works with fully qualified file name.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Reopened] (DISPATCH-940) When running qdrouterd with -c and -d combined, configuration file is reporting as not found

2018-03-29 Thread Robbie Gemmell (JIRA)


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

Robbie Gemmell reopened DISPATCH-940:
-

> When running qdrouterd with -c and -d combined, configuration file is 
> reporting as not found
> 
>
> Key: DISPATCH-940
> URL: https://issues.apache.org/jira/browse/DISPATCH-940
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 1.1.0
>Reporter: Fernando Giorgetti
>Priority: Minor
>  Labels: pull-request-available
> Fix For: 1.1.0
>
>
> If you run qdrouterd as shown below, everything works just fine:
>  
> {code:java}
> [fgiorget@fgiorget qpid-dispatch]$ qdrouterd -c qdrouterd.conf 
> 2018-03-08 14:49:02.797039 -0300 SERVER (info) Container Name: Router.A
> 2018-03-08 14:49:02.797142 -0300 ROUTER (info) Router started in Standalone 
> mode 
> {code}
> But if you try to add -d (daemon) flag, then it does not find the 
> configuration file.
> {code:java}
> [fgiorget@fgiorget qpid-dispatch]$ qdrouterd -d -c qdrouterd.conf 
> qdrouterd: Not found: Configuration file could not be opened{code}
> It only works with fully qualified file name.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Assigned] (QPID-8140) [Broker-J][BDB HA] Removal of non existing group member can end up in broker crash due to uncaught MemberNotFoundException

2018-03-29 Thread Alex Rudyy (JIRA)


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

Alex Rudyy reassigned QPID-8140:


Assignee: Alex Rudyy

> [Broker-J][BDB HA] Removal of non existing group member can end up in broker 
> crash due to uncaught MemberNotFoundException
> --
>
> Key: QPID-8140
> URL: https://issues.apache.org/jira/browse/QPID-8140
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.2, qpid-java-broker-7.0.0, 
> qpid-java-broker-7.0.1
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Attachments: 
> TEST-org.apache.qpid.server.store.berkeleydb.replication.BDBHAVirtualHostNodeRestTest.testDeleteMasterNode.txt
>
>
> When two concurrent requests are made to delete a group member using REST API 
> for remote replication node, one can successfully remove the node, whilst 
> other can end-up in un-handled  {{MemberNotFoundException}} which crashes the 
> broker.
> An example of remote node delete request
> {code}
>  curl -v -k -u admin -X DELETE  
> http://localhost:8080/api/latest/remotereplicationnode/node2/node1
> {code}
> For failed requests an exception like the one below is reported
> {noformat}
>  ERROR [VirtualHostNode-node2-Config] o.a.q.s.u.ServerScopedRuntimeException 
> Exception on node removal from group
> com.sleepycat.je.rep.MemberNotFoundException: (JE 7.4.5) Node: node1 is not 
> currently a member of the group: 
> BDBHAVirtualHostNodeRestTest.testDeleteMasterNode, it has been removed.
>   at 
> com.sleepycat.je.rep.util.ReplicationGroupAdmin.checkMember(ReplicationGroupAdmin.java:576)
>   at 
> com.sleepycat.je.rep.util.ReplicationGroupAdmin.removeMember(ReplicationGroupAdmin.java:314)
>   at 
> org.apache.qpid.server.store.berkeleydb.replication.ReplicatedEnvironmentFacade.removeNodeFromGroup(ReplicatedEnvironmentFacade.java:1210)
>   at 
> org.apache.qpid.server.virtualhostnode.berkeleydb.BDBHARemoteReplicationNodeImpl.onDelete(BDBHARemoteReplicationNodeImpl.java:139)
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject$21.onSuccess(AbstractConfiguredObject.java:2759)
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject$24$1.run(AbstractConfiguredObject.java:2894)
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject$24$1.run(AbstractConfiguredObject.java:2890)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at javax.security.auth.Subject.doAs(Subject.java:360)
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject$24.onSuccess(AbstractConfiguredObject.java:2889)
>   at 
> com.google.common.util.concurrent.Futures$CallbackListener.run(Futures.java:1237)
>   at 
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$ImmediateIfSameThreadExecutor.execute(TaskExecutorImpl.java:400)
>   at 
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.execute(TaskExecutorImpl.java:183)
>   at 
> com.google.common.util.concurrent.AbstractFuture.executeListener(AbstractFuture.java:911)
>   at 
> com.google.common.util.concurrent.AbstractFuture.complete(AbstractFuture.java:822)
>   at 
> com.google.common.util.concurrent.AbstractFuture.set(AbstractFuture.java:664)
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject$ChainedSettableFuture.set(AbstractConfiguredObject.java:2710)
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject$21$1.onSuccess(AbstractConfiguredObject.java:2765)
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject$24$1.run(AbstractConfiguredObject.java:2894)
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject$24$1.run(AbstractConfiguredObject.java:2890)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at javax.security.auth.Subject.doAs(Subject.java:360)
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject$24.onSuccess(AbstractConfiguredObject.java:2889)
>   at 
> com.google.common.util.concurrent.Futures$CallbackListener.run(Futures.java:1237)
>   at 
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$ImmediateIfSameThreadExecutor.execute(TaskExecutorImpl.java:400)
>   at 
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.execute(TaskExecutorImpl.java:183)
>   at 
> com.google.common.util.concurrent.AbstractFuture.executeListener(AbstractFuture.java:911)
>   at 
> com.google.common.util.concurrent.AbstractFuture.addListener(AbstractFuture.java:645)
>   at 
> com.google.common.util.concurrent.AbstractFuture$TrustedFuture.addListener(AbstractFuture.java:101)
>   at 
>

[jira] [Updated] (QPID-8064) [Broker-J] FileKeyStore should validate java keystore content to make sure that private key is present

2018-03-29 Thread Alex Rudyy (JIRA)


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

Alex Rudyy updated QPID-8064:
-
Status: Reviewable  (was: In Progress)

> [Broker-J] FileKeyStore should validate java keystore content to make sure 
> that private key is present
> --
>
> Key: QPID-8064
> URL: https://issues.apache.org/jira/browse/QPID-8064
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Affects Versions: qpid-java-6.0.8, qpid-java-broker-7.0.0, qpid-java-6.1.5
>Reporter: Alex Rudyy
>Assignee: Keith Wall
>Priority: Minor
> Fix For: qpid-java-broker-7.1.0, qpid-java-broker-7.0.3
>
>
> Currently Broker-J does not issue any error or warning when private key is 
> missed in java keystore (i.e., truststore is provided instead of keystore). 
> We should add a validation for the private key and deny keystore creation (or 
> recovery) if private key is not present. 
> When keystore without private key is configured, an attempt to make TLS 
> fails, but the root cause of the failure is difficult to debug. Even when 
> java debug logging is enabled (-Djavax.net.debug=all) the logs for the 
> handshake failure are confusing: "fatal error: 40: no cipher suites in 
> common", for example
> {noformat}
> HttpManagement-HTTP-392, READ: TLSv1 Handshake, length = 224
> *** ClientHello, TLSv1.2
> RandomCookie:  GMT: -1512757423 bytes = { 141, 10, 192, 6, 218, 230, 103, 
> 203, 46, 231, 80, 160, 40, 21, 47, 125, 0, 149, 138, 74, 65, 251, 5, 165, 
> 194, 45, 196, 236 }
> Session ID:  {}
> Cipher Suites: [Unknown 0xaa:0xaa, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, 
> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, 
> TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, 
> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, Unknown 0xcc:0xa9, Unknown 0xcc:0xa8, 
> Unknown 0xcc:0x14, Unknown 0xcc:0x13, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, 
> TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, 
> TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_GCM_SHA256, 
> TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_128_CBC_SHA, 
> TLS_RSA_WITH_AES_256_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA]
> Compression Methods:  { 0 }
> Unsupported extension type_10794, data:
> Extension renegotiation_info, renegotiated_connection: 
> Extension server_name, server_name: [type=host_name (0), 
> value=abcd24p9390.abc.ef.g1234567.net]
> Unsupported extension type_23, data:
> Unsupported extension type_35, data:
> Extension signature_algorithms, signature_algorithms: SHA256withECDSA, 
> Unknown (hash:0x8, signature:0x4), SHA256withRSA, SHA384withECDSA, Unknown 
> (hash:0x8, signature:0x5), SHA384withRSA, Unknown (hash:0x8, signature:0x6), 
> SHA512withRSA, SHA1withRSA
> Unsupported extension status_request, data: 01:00:00:00:00
> Unsupported extension type_18, data:
> Unsupported extension type_16, data: 00:0c:02:68:32:08:68:74:74:70:2f:31:2e:31
> Unsupported extension type_30032, data:
> Extension ec_point_formats, formats: [uncompressed]
> Extension elliptic_curves, curve names: {unknown curve 56026, unknown curve 
> 29, secp256r1, secp384r1}
> Unsupported extension type_23130, data: 00
> ***
> [read] MD5 and SHA1 hashes:  len = 224
> : 01 00 00 DC 03 03 A6 D5   27 51 8D 0A C0 06 DA E6  'Q..
> 0010: 67 CB 2E E7 50 A0 28 15   2F 7D 00 95 8A 4A 41 FB  g...P.(./JA.
> 0020: 05 A5 C2 2D C4 EC 00 00   26 AA AA C0 2B C0 2F 00  ...-&...+./.
> 0030: 9E C0 2C C0 30 CC A9 CC   A8 CC 14 CC 13 C0 13 00  ..,.0...
> 0040: 33 C0 14 00 39 00 9C 00   9D 00 2F 00 35 00 0A 01  3...9./.5...
> 0050: 00 00 8D 2A 2A 00 00 FF   01 00 01 00 00 00 00 24  ...**..$
> 0060: 00 22 00 00 1F 76 73 69   6E 32 34 70 39 33 39 30  ."...abcd24p9390
> 0070: 2E 73 76 72 2E 75 73 2E   6A 70 6D 63 68 61 73 65  .abc.ef.g1234567
> 0080: 2E 6E 65 74 00 17 00 00   00 23 00 00 00 0D 00 14  .net.#..
> 0090: 00 12 04 03 08 04 04 01   05 03 08 05 05 01 08 06  
> 00A0: 06 01 02 01 00 05 00 05   01 00 00 00 00 00 12 00  
> 00B0: 00 00 10 00 0E 00 0C 02   68 32 08 68 74 74 70 2F  h2.http/
> 00C0: 31 2E 31 75 50 00 00 00   0B 00 02 01 00 00 0A 00  1.1uP...
> 00D0: 0A 00 08 DA DA 00 1D 00   17 00 18 5A 5A 00 01 00  ...ZZ...
> %% Initialized:  [Session-37, SSL_NULL_WITH_NULL_NULL]
> HttpManagement-HTTP-392, fatal error: 40: no cipher suites in common
> javax.net.ssl.SSLHandshakeException: no cipher suites in common
> %% Invalidated:  [Session-37, SSL_NULL_WITH_NULL_NULL]
> HttpManagement-HTTP-392, SEND TLSv1.2 ALERT:  fatal, description = 
> handshake_failure
> HttpManagement-HTTP-392, WRITE: TLSv1.2 Alert, length = 2
> HttpManagement-HTTP-392, fatal: engine already closed.

[jira] [Commented] (PROTON-1777) 0.22.0 release tasks

2018-03-29 Thread ASF subversion and git services (JIRA)


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

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

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

PROTON-1777: update versions for 0.22.0-rc1


> 0.22.0 release tasks
> 
>
> Key: PROTON-1777
> URL: https://issues.apache.org/jira/browse/PROTON-1777
> Project: Qpid Proton
>  Issue Type: Task
>  Components: proton-c, release
>Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
>Priority: Major
> Fix For: proton-c-0.22.0
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (PROTON-1777) 0.22.0 release tasks

2018-03-29 Thread ASF subversion and git services (JIRA)


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

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

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

PROTON-1812, PROTON-1777: update versions for 0.23.0-SNAPSHOT


> 0.22.0 release tasks
> 
>
> Key: PROTON-1777
> URL: https://issues.apache.org/jira/browse/PROTON-1777
> Project: Qpid Proton
>  Issue Type: Task
>  Components: proton-c, release
>Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
>Priority: Major
> Fix For: proton-c-0.22.0
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (PROTON-1812) 0.23.0 release tasks

2018-03-29 Thread ASF subversion and git services (JIRA)


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

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

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

PROTON-1812, PROTON-1777: update versions for 0.23.0-SNAPSHOT


> 0.23.0 release tasks
> 
>
> Key: PROTON-1812
> URL: https://issues.apache.org/jira/browse/PROTON-1812
> Project: Qpid Proton
>  Issue Type: Task
>  Components: proton-c, release
>Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
>Priority: Major
> Fix For: proton-c-0.23.0
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (PROTON-1809) [python, ruby] Unable to receive messages when max-frame-size is set to more than 2^20

2018-03-29 Thread Robbie Gemmell (JIRA)


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

Robbie Gemmell commented on PROTON-1809:


I have reverted the change to remove it from 0.22.0. This is very long-standing 
issue with relatively minor chance anyone new will hit it, it can wait for 
0.23.0.

I don't think the approach taken of silently adjusting and exceeding the 
requested session capacity is correct. In some ways it would be worse than the 
automagic effect that changing frame size had on the session window handling 
previously. Doing so would hide a fundamental issue in the usage, and result in 
likely undesired single-frame session window that will give poor performance in 
all but the simplest cases. People setting the session capacity and frame size 
explicitly really need to understand what that means, and that the former cant 
be smaller than the latter if they want to receive anything and actually govern 
session capacity. We can actively prevent them configuring it that way if 
desired, though some doc text would suffice for me.

Definitely needs some tests adding.

PROTON-636 needs updated as well, linked it for now.

> [python, ruby] Unable to receive messages when max-frame-size is set to more 
> than 2^20
> --
>
> Key: PROTON-1809
> URL: https://issues.apache.org/jira/browse/PROTON-1809
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: python-binding, ruby-binding
>Affects Versions: proton-c-0.22.0
> Environment: RHEL 7 x86_64
>Reporter: Radim Kubis
>Assignee: Alan Conway
>Priority: Minor
> Fix For: proton-c-0.23.0
>
>
> *Python:*
> {code:java}
>   def on_session_init(self, event):
>  event.transport._set_max_frame_size(VALUE)
> {code}
> I noticed that the receiver is not able to receive messages when the value 
> for max-frame-size is larger than 2^20 (1048576) bytes (remote_max_frame_size 
> is 4294967295). I'm not really sure if that is expected. This may be 
> reproduced when adding the code above ie.: to simple_recv.py.
> Note: This is not a good use case as setting the max-frame-size in 
> on_session_init is really too late. But given that it is too late to set the 
> max-frame-size, I would expect it won't have any effect on the client.
>  
> *Ruby:*
> From [https://github.com/rh-messaging/cli-proton-ruby] 
> [cli-proton-ruby|https://github.com/rh-messaging/cli-proton-ruby]
> {{cli-proton-ruby-receiver -b  -c  --log-msgs dict 
> --conn-max-frame-size 1048577}}
> Receiver is stuck.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (PROTON-1809) [python, ruby] Unable to receive messages when max-frame-size is set to more than 2^20

2018-03-29 Thread Robbie Gemmell (JIRA)


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

Robbie Gemmell updated PROTON-1809:
---
Fix Version/s: (was: proton-c-0.22.0)
   proton-c-0.23.0

> [python, ruby] Unable to receive messages when max-frame-size is set to more 
> than 2^20
> --
>
> Key: PROTON-1809
> URL: https://issues.apache.org/jira/browse/PROTON-1809
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: python-binding, ruby-binding
>Affects Versions: proton-c-0.22.0
> Environment: RHEL 7 x86_64
>Reporter: Radim Kubis
>Assignee: Alan Conway
>Priority: Minor
> Fix For: proton-c-0.23.0
>
>
> *Python:*
> {code:java}
>   def on_session_init(self, event):
>  event.transport._set_max_frame_size(VALUE)
> {code}
> I noticed that the receiver is not able to receive messages when the value 
> for max-frame-size is larger than 2^20 (1048576) bytes (remote_max_frame_size 
> is 4294967295). I'm not really sure if that is expected. This may be 
> reproduced when adding the code above ie.: to simple_recv.py.
> Note: This is not a good use case as setting the max-frame-size in 
> on_session_init is really too late. But given that it is too late to set the 
> max-frame-size, I would expect it won't have any effect on the client.
>  
> *Ruby:*
> From [https://github.com/rh-messaging/cli-proton-ruby] 
> [cli-proton-ruby|https://github.com/rh-messaging/cli-proton-ruby]
> {{cli-proton-ruby-receiver -b  -c  --log-msgs dict 
> --conn-max-frame-size 1048577}}
> Receiver is stuck.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Reopened] (PROTON-1809) [python, ruby] Unable to receive messages when max-frame-size is set to more than 2^20

2018-03-29 Thread Robbie Gemmell (JIRA)


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

Robbie Gemmell reopened PROTON-1809:


> [python, ruby] Unable to receive messages when max-frame-size is set to more 
> than 2^20
> --
>
> Key: PROTON-1809
> URL: https://issues.apache.org/jira/browse/PROTON-1809
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: python-binding, ruby-binding
>Affects Versions: proton-c-0.22.0
> Environment: RHEL 7 x86_64
>Reporter: Radim Kubis
>Assignee: Alan Conway
>Priority: Minor
> Fix For: proton-c-0.23.0
>
>
> *Python:*
> {code:java}
>   def on_session_init(self, event):
>  event.transport._set_max_frame_size(VALUE)
> {code}
> I noticed that the receiver is not able to receive messages when the value 
> for max-frame-size is larger than 2^20 (1048576) bytes (remote_max_frame_size 
> is 4294967295). I'm not really sure if that is expected. This may be 
> reproduced when adding the code above ie.: to simple_recv.py.
> Note: This is not a good use case as setting the max-frame-size in 
> on_session_init is really too late. But given that it is too late to set the 
> max-frame-size, I would expect it won't have any effect on the client.
>  
> *Ruby:*
> From [https://github.com/rh-messaging/cli-proton-ruby] 
> [cli-proton-ruby|https://github.com/rh-messaging/cli-proton-ruby]
> {{cli-proton-ruby-receiver -b  -c  --log-msgs dict 
> --conn-max-frame-size 1048577}}
> Receiver is stuck.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (PROTON-1809) [python, ruby] Unable to receive messages when max-frame-size is set to more than 2^20

2018-03-29 Thread ASF subversion and git services (JIRA)


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

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

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

Revert "PROTON-1809: Unable to receive messages when max-frame-size > 2^20"

This reverts commit e8de49d33b1c750327e6c9a090332953a7669a4d.


> [python, ruby] Unable to receive messages when max-frame-size is set to more 
> than 2^20
> --
>
> Key: PROTON-1809
> URL: https://issues.apache.org/jira/browse/PROTON-1809
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: python-binding, ruby-binding
>Affects Versions: proton-c-0.22.0
> Environment: RHEL 7 x86_64
>Reporter: Radim Kubis
>Assignee: Alan Conway
>Priority: Minor
> Fix For: proton-c-0.22.0
>
>
> *Python:*
> {code:java}
>   def on_session_init(self, event):
>  event.transport._set_max_frame_size(VALUE)
> {code}
> I noticed that the receiver is not able to receive messages when the value 
> for max-frame-size is larger than 2^20 (1048576) bytes (remote_max_frame_size 
> is 4294967295). I'm not really sure if that is expected. This may be 
> reproduced when adding the code above ie.: to simple_recv.py.
> Note: This is not a good use case as setting the max-frame-size in 
> on_session_init is really too late. But given that it is too late to set the 
> max-frame-size, I would expect it won't have any effect on the client.
>  
> *Ruby:*
> From [https://github.com/rh-messaging/cli-proton-ruby] 
> [cli-proton-ruby|https://github.com/rh-messaging/cli-proton-ruby]
> {{cli-proton-ruby-receiver -b  -c  --log-msgs dict 
> --conn-max-frame-size 1048577}}
> Receiver is stuck.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (QPID-8143) [Broker-J] Properly validate @ManagedAttributeValueTypes, and allow for factory methods

2018-03-29 Thread Rob Godfrey (JIRA)


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

Rob Godfrey updated QPID-8143:
--
Status: Reviewable  (was: In Progress)

> [Broker-J] Properly validate @ManagedAttributeValueTypes, and allow for 
> factory methods
> ---
>
> Key: QPID-8143
> URL: https://issues.apache.org/jira/browse/QPID-8143
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Reporter: Rob Godfrey
>Assignee: Rob Godfrey
>Priority: Major
>
> Currently types annotated with the {{@ManagedAttributeValueType}} annotation 
> are not correctly validated (the validator is not being run).
> Such types should be interfaces with only accessor methods unless they are 
> marked as "abstract" which means they cannot be instantiated from input.  For 
> abstract types, allow the use of classes as well as interfaces.  For 
> non-abstract types allow the use of a factory method rather than forcing the 
> use of proxy classes.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Assigned] (QPID-8143) [Broker-J] Properly validate @ManagedAttributeValueTypes, and allow for factory methods

2018-03-29 Thread Rob Godfrey (JIRA)


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

Rob Godfrey reassigned QPID-8143:
-

Assignee: Keith Wall  (was: Rob Godfrey)

> [Broker-J] Properly validate @ManagedAttributeValueTypes, and allow for 
> factory methods
> ---
>
> Key: QPID-8143
> URL: https://issues.apache.org/jira/browse/QPID-8143
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Reporter: Rob Godfrey
>Assignee: Keith Wall
>Priority: Major
>
> Currently types annotated with the {{@ManagedAttributeValueType}} annotation 
> are not correctly validated (the validator is not being run).
> Such types should be interfaces with only accessor methods unless they are 
> marked as "abstract" which means they cannot be instantiated from input.  For 
> abstract types, allow the use of classes as well as interfaces.  For 
> non-abstract types allow the use of a factory method rather than forcing the 
> use of proxy classes.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Assigned] (QPID-8143) [Broker-J] Properly validate @ManagedAttributeValueTypes, and allow for factory methods

2018-03-29 Thread Rob Godfrey (JIRA)


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

Rob Godfrey reassigned QPID-8143:
-

Assignee: Rob Godfrey

> [Broker-J] Properly validate @ManagedAttributeValueTypes, and allow for 
> factory methods
> ---
>
> Key: QPID-8143
> URL: https://issues.apache.org/jira/browse/QPID-8143
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Reporter: Rob Godfrey
>Assignee: Rob Godfrey
>Priority: Major
>
> Currently types annotated with the {{@ManagedAttributeValueType}} annotation 
> are not correctly validated (the validator is not being run).
> Such types should be interfaces with only accessor methods unless they are 
> marked as "abstract" which means they cannot be instantiated from input.  For 
> abstract types, allow the use of classes as well as interfaces.  For 
> non-abstract types allow the use of a factory method rather than forcing the 
> use of proxy classes.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (QPID-8143) [Broker-J] Properly validate @ManagedAttributeValueTypes, and allow for factory methods

2018-03-29 Thread ASF subversion and git services (JIRA)


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

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

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

QPID-8143 : Properly validate @ManagedAttributeValueTypes, and allow for 
factory methods


> [Broker-J] Properly validate @ManagedAttributeValueTypes, and allow for 
> factory methods
> ---
>
> Key: QPID-8143
> URL: https://issues.apache.org/jira/browse/QPID-8143
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Reporter: Rob Godfrey
>Priority: Major
>
> Currently types annotated with the {{@ManagedAttributeValueType}} annotation 
> are not correctly validated (the validator is not being run).
> Such types should be interfaces with only accessor methods unless they are 
> marked as "abstract" which means they cannot be instantiated from input.  For 
> abstract types, allow the use of classes as well as interfaces.  For 
> non-abstract types allow the use of a factory method rather than forcing the 
> use of proxy classes.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Created] (QPID-8143) [Broker-J] Properly validate @ManagedAttributeValueTypes, and allow for factory methods

2018-03-29 Thread Rob Godfrey (JIRA)

Rob Godfrey created QPID-8143:
-

 Summary: [Broker-J] Properly validate @ManagedAttributeValueTypes, 
and allow for factory methods
 Key: QPID-8143
 URL: https://issues.apache.org/jira/browse/QPID-8143
 Project: Qpid
  Issue Type: Improvement
  Components: Broker-J
Reporter: Rob Godfrey


Currently types annotated with the {{@ManagedAttributeValueType}} annotation 
are not correctly validated (the validator is not being run).

Such types should be interfaces with only accessor methods unless they are 
marked as "abstract" which means they cannot be instantiated from input.  For 
abstract types, allow the use of classes as well as interfaces.  For 
non-abstract types allow the use of a factory method rather than forcing the 
use of proxy classes.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (QPID-8064) [Broker-J] FileKeyStore should validate java keystore content to make sure that private key is present

2018-03-29 Thread ASF subversion and git services (JIRA)


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

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

Commit 9f82a4d338c5103cce9f64dbe07f9886334e7112 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=9f82a4d ]

QPID-8064: [Broker-J] Fix tests failing with IBM JDK


> [Broker-J] FileKeyStore should validate java keystore content to make sure 
> that private key is present
> --
>
> Key: QPID-8064
> URL: https://issues.apache.org/jira/browse/QPID-8064
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Affects Versions: qpid-java-6.0.8, qpid-java-broker-7.0.0, qpid-java-6.1.5
>Reporter: Alex Rudyy
>Assignee: Keith Wall
>Priority: Minor
> Fix For: qpid-java-broker-7.1.0, qpid-java-broker-7.0.3
>
>
> Currently Broker-J does not issue any error or warning when private key is 
> missed in java keystore (i.e., truststore is provided instead of keystore). 
> We should add a validation for the private key and deny keystore creation (or 
> recovery) if private key is not present. 
> When keystore without private key is configured, an attempt to make TLS 
> fails, but the root cause of the failure is difficult to debug. Even when 
> java debug logging is enabled (-Djavax.net.debug=all) the logs for the 
> handshake failure are confusing: "fatal error: 40: no cipher suites in 
> common", for example
> {noformat}
> HttpManagement-HTTP-392, READ: TLSv1 Handshake, length = 224
> *** ClientHello, TLSv1.2
> RandomCookie:  GMT: -1512757423 bytes = { 141, 10, 192, 6, 218, 230, 103, 
> 203, 46, 231, 80, 160, 40, 21, 47, 125, 0, 149, 138, 74, 65, 251, 5, 165, 
> 194, 45, 196, 236 }
> Session ID:  {}
> Cipher Suites: [Unknown 0xaa:0xaa, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, 
> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, 
> TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, 
> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, Unknown 0xcc:0xa9, Unknown 0xcc:0xa8, 
> Unknown 0xcc:0x14, Unknown 0xcc:0x13, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, 
> TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, 
> TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_GCM_SHA256, 
> TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_128_CBC_SHA, 
> TLS_RSA_WITH_AES_256_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA]
> Compression Methods:  { 0 }
> Unsupported extension type_10794, data:
> Extension renegotiation_info, renegotiated_connection: 
> Extension server_name, server_name: [type=host_name (0), 
> value=abcd24p9390.abc.ef.g1234567.net]
> Unsupported extension type_23, data:
> Unsupported extension type_35, data:
> Extension signature_algorithms, signature_algorithms: SHA256withECDSA, 
> Unknown (hash:0x8, signature:0x4), SHA256withRSA, SHA384withECDSA, Unknown 
> (hash:0x8, signature:0x5), SHA384withRSA, Unknown (hash:0x8, signature:0x6), 
> SHA512withRSA, SHA1withRSA
> Unsupported extension status_request, data: 01:00:00:00:00
> Unsupported extension type_18, data:
> Unsupported extension type_16, data: 00:0c:02:68:32:08:68:74:74:70:2f:31:2e:31
> Unsupported extension type_30032, data:
> Extension ec_point_formats, formats: [uncompressed]
> Extension elliptic_curves, curve names: {unknown curve 56026, unknown curve 
> 29, secp256r1, secp384r1}
> Unsupported extension type_23130, data: 00
> ***
> [read] MD5 and SHA1 hashes:  len = 224
> : 01 00 00 DC 03 03 A6 D5   27 51 8D 0A C0 06 DA E6  'Q..
> 0010: 67 CB 2E E7 50 A0 28 15   2F 7D 00 95 8A 4A 41 FB  g...P.(./JA.
> 0020: 05 A5 C2 2D C4 EC 00 00   26 AA AA C0 2B C0 2F 00  ...-&...+./.
> 0030: 9E C0 2C C0 30 CC A9 CC   A8 CC 14 CC 13 C0 13 00  ..,.0...
> 0040: 33 C0 14 00 39 00 9C 00   9D 00 2F 00 35 00 0A 01  3...9./.5...
> 0050: 00 00 8D 2A 2A 00 00 FF   01 00 01 00 00 00 00 24  ...**..$
> 0060: 00 22 00 00 1F 76 73 69   6E 32 34 70 39 33 39 30  ."...abcd24p9390
> 0070: 2E 73 76 72 2E 75 73 2E   6A 70 6D 63 68 61 73 65  .abc.ef.g1234567
> 0080: 2E 6E 65 74 00 17 00 00   00 23 00 00 00 0D 00 14  .net.#..
> 0090: 00 12 04 03 08 04 04 01   05 03 08 05 05 01 08 06  
> 00A0: 06 01 02 01 00 05 00 05   01 00 00 00 00 00 12 00  
> 00B0: 00 00 10 00 0E 00 0C 02   68 32 08 68 74 74 70 2F  h2.http/
> 00C0: 31 2E 31 75 50 00 00 00   0B 00 02 01 00 00 0A 00  1.1uP...
> 00D0: 0A 00 08 DA DA 00 1D 00   17 00 18 5A 5A 00 01 00  ...ZZ...
> %% Initialized:  [Session-37, SSL_NULL_WITH_NULL_NULL]
> HttpManagement-HTTP-392, fatal error: 40: no cipher suites in common
> javax.net.ssl.SSLHandshakeException: no cipher

[jira] [Updated] (QPIDJMS-374) Double encoded query parameters

2018-03-29 Thread Michael Bolz (JIRA)


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

Michael Bolz updated QPIDJMS-374:
-
Description: 
When query parameters are parsed in 
[TransportFactory|https://github.com/apache/qpid-jms/blob/70fe1b882e1381b1016a10b0707f6e112d4e0598/qpid-jms-client/src/main/java/org/apache/qpid/jms/transports/TransportFactory.java#L51]
 and 
[AmqpProviderFactory|https://github.com/apache/qpid-jms/blob/70fe1b882e1381b1016a10b0707f6e112d4e0598/qpid-jms-client/src/main/java/org/apache/qpid/jms/provider/amqp/AmqpProviderFactory.java#L41]
 and than further processed via 
[PropertyUtil#replaceQuery|https://github.com/apache/qpid-jms/blob/70fe1b882e1381b1016a10b0707f6e112d4e0598/qpid-jms-client/src/main/java/org/apache/qpid/jms/util/PropertyUtil.java#L64]
 the values gets double encoded.
See also Javadoc of 
[PropertyUtil#replaceQuery|https://github.com/apache/qpid-jms/blob/70fe1b882e1381b1016a10b0707f6e112d4e0598/qpid-jms-client/src/main/java/org/apache/qpid/jms/util/PropertyUtil.java#L64]:

{quote}
The string values in the Map will be URL Encoded by this method which means 
that if an
already encoded value is passed it will be double encoded resulting in corrupt 
values
in the newly created URI.
{quote}

For a fix I created a [pull request|https://github.com/apache/qpid-jms/pull/17].

  was:
When query parameters are parsed in 
[TransportFactory|https://github.com/apache/qpid-jms/blob/70fe1b882e1381b1016a10b0707f6e112d4e0598/qpid-jms-client/src/main/java/org/apache/qpid/jms/transports/TransportFactory.java#L51]
 and 
[AmqpProviderFactory|https://github.com/apache/qpid-jms/blob/70fe1b882e1381b1016a10b0707f6e112d4e0598/qpid-jms-client/src/main/java/org/apache/qpid/jms/provider/amqp/AmqpProviderFactory.java#L41]
 and than further processed via 
[PropertyUtil#replaceQuery|https://github.com/apache/qpid-jms/blob/70fe1b882e1381b1016a10b0707f6e112d4e0598/qpid-jms-client/src/main/java/org/apache/qpid/jms/util/PropertyUtil.java#L64]
 the values gets double encoded.
See also Javadoc of 
[PropertyUtil#replaceQuery|https://github.com/apache/qpid-jms/blob/70fe1b882e1381b1016a10b0707f6e112d4e0598/qpid-jms-client/src/main/java/org/apache/qpid/jms/util/PropertyUtil.java#L64]:

{quote}
The string values in the Map will be URL Encoded by this method which means 
that if an
already encoded value is passed it will be double encoded resulting in corrupt 
values
in the newly created URI.
{quote}

For a fix I created a [pull request|…].


> Double encoded query parameters
> ---
>
> Key: QPIDJMS-374
> URL: https://issues.apache.org/jira/browse/QPIDJMS-374
> Project: Qpid JMS
>  Issue Type: Bug
>  Components: qpid-jms-client
>Affects Versions: 0.31.0
>Reporter: Michael Bolz
>Priority: Major
>
> When query parameters are parsed in 
> [TransportFactory|https://github.com/apache/qpid-jms/blob/70fe1b882e1381b1016a10b0707f6e112d4e0598/qpid-jms-client/src/main/java/org/apache/qpid/jms/transports/TransportFactory.java#L51]
>  and 
> [AmqpProviderFactory|https://github.com/apache/qpid-jms/blob/70fe1b882e1381b1016a10b0707f6e112d4e0598/qpid-jms-client/src/main/java/org/apache/qpid/jms/provider/amqp/AmqpProviderFactory.java#L41]
>  and than further processed via 
> [PropertyUtil#replaceQuery|https://github.com/apache/qpid-jms/blob/70fe1b882e1381b1016a10b0707f6e112d4e0598/qpid-jms-client/src/main/java/org/apache/qpid/jms/util/PropertyUtil.java#L64]
>  the values gets double encoded.
> See also Javadoc of 
> [PropertyUtil#replaceQuery|https://github.com/apache/qpid-jms/blob/70fe1b882e1381b1016a10b0707f6e112d4e0598/qpid-jms-client/src/main/java/org/apache/qpid/jms/util/PropertyUtil.java#L64]:
> {quote}
> The string values in the Map will be URL Encoded by this method which means 
> that if an
> already encoded value is passed it will be double encoded resulting in 
> corrupt values
> in the newly created URI.
> {quote}
> For a fix I created a [pull 
> request|https://github.com/apache/qpid-jms/pull/17].



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (QPIDJMS-374) Double encoded query parameters

2018-03-29 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/QPIDJMS-374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16418516#comment-16418516
 ] 

ASF GitHub Bot commented on QPIDJMS-374:


GitHub user mibo opened a pull request:

https://github.com/apache/qpid-jms/pull/17

QPIDJMS-374: Use getRawQuery to avoid double encoding



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

$ git pull https://github.com/mibo/qpid-jms master

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

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


commit b89a1e8cebcde65575aee1bd0dbe3c2cce01ccee
Author: mibo 
Date:   2018-03-29T06:52:29Z

QPIDJMS-374: Use getRawQuery to avoid double encoding




> Double encoded query parameters
> ---
>
> Key: QPIDJMS-374
> URL: https://issues.apache.org/jira/browse/QPIDJMS-374
> Project: Qpid JMS
>  Issue Type: Bug
>  Components: qpid-jms-client
>Affects Versions: 0.31.0
>Reporter: Michael Bolz
>Priority: Major
>
> When query parameters are parsed in 
> [TransportFactory|https://github.com/apache/qpid-jms/blob/70fe1b882e1381b1016a10b0707f6e112d4e0598/qpid-jms-client/src/main/java/org/apache/qpid/jms/transports/TransportFactory.java#L51]
>  and 
> [AmqpProviderFactory|https://github.com/apache/qpid-jms/blob/70fe1b882e1381b1016a10b0707f6e112d4e0598/qpid-jms-client/src/main/java/org/apache/qpid/jms/provider/amqp/AmqpProviderFactory.java#L41]
>  and than further processed via 
> [PropertyUtil#replaceQuery|https://github.com/apache/qpid-jms/blob/70fe1b882e1381b1016a10b0707f6e112d4e0598/qpid-jms-client/src/main/java/org/apache/qpid/jms/util/PropertyUtil.java#L64]
>  the values gets double encoded.
> See also Javadoc of 
> [PropertyUtil#replaceQuery|https://github.com/apache/qpid-jms/blob/70fe1b882e1381b1016a10b0707f6e112d4e0598/qpid-jms-client/src/main/java/org/apache/qpid/jms/util/PropertyUtil.java#L64]:
> {quote}
> The string values in the Map will be URL Encoded by this method which means 
> that if an
> already encoded value is passed it will be double encoded resulting in 
> corrupt values
> in the newly created URI.
> {quote}
> For a fix I created a [pull request|…].



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[GitHub] qpid-jms pull request #17: QPIDJMS-374: Use getRawQuery to avoid double enco...

2018-03-29 Thread mibo

GitHub user mibo opened a pull request:

https://github.com/apache/qpid-jms/pull/17

QPIDJMS-374: Use getRawQuery to avoid double encoding



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

$ git pull https://github.com/mibo/qpid-jms master

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

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


commit b89a1e8cebcde65575aee1bd0dbe3c2cce01ccee
Author: mibo 
Date:   2018-03-29T06:52:29Z

QPIDJMS-374: Use getRawQuery to avoid double encoding




---

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

[jira] [Created] (QPIDJMS-374) Double encoded query parameters

2018-03-29 Thread Michael Bolz (JIRA)

Michael Bolz created QPIDJMS-374:


 Summary: Double encoded query parameters
 Key: QPIDJMS-374
 URL: https://issues.apache.org/jira/browse/QPIDJMS-374
 Project: Qpid JMS
  Issue Type: Bug
  Components: qpid-jms-client
Affects Versions: 0.31.0
Reporter: Michael Bolz


When query parameters are parsed in 
[TransportFactory|https://github.com/apache/qpid-jms/blob/70fe1b882e1381b1016a10b0707f6e112d4e0598/qpid-jms-client/src/main/java/org/apache/qpid/jms/transports/TransportFactory.java#L51]
 and 
[AmqpProviderFactory|https://github.com/apache/qpid-jms/blob/70fe1b882e1381b1016a10b0707f6e112d4e0598/qpid-jms-client/src/main/java/org/apache/qpid/jms/provider/amqp/AmqpProviderFactory.java#L41]
 and than further processed via 
[PropertyUtil#replaceQuery|https://github.com/apache/qpid-jms/blob/70fe1b882e1381b1016a10b0707f6e112d4e0598/qpid-jms-client/src/main/java/org/apache/qpid/jms/util/PropertyUtil.java#L64]
 the values gets double encoded.
See also Javadoc of 
[PropertyUtil#replaceQuery|https://github.com/apache/qpid-jms/blob/70fe1b882e1381b1016a10b0707f6e112d4e0598/qpid-jms-client/src/main/java/org/apache/qpid/jms/util/PropertyUtil.java#L64]:

{quote}
The string values in the Map will be URL Encoded by this method which means 
that if an
already encoded value is passed it will be double encoded resulting in corrupt 
values
in the newly created URI.
{quote}

For a fix I created a [pull request|…].



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

66 matches

Mail list logo