[jira] [Comment Edited] (DISPATCH-782) [unit-tests] SIGSEGV in qd_python_finalize

[Jiri Danek (JIRA)]

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

Jiri Danek edited comment on DISPATCH-782 at 8/10/17 1:57 PM:
--

[~ganeshmurthy] I tried reproducing on Fedora 25 in a VM (not docker) and I 
could not reproduce this. I then tried VM with Debian Stretch and I could 
reproduce it there with the usual

{noformat}
ret=0
while [[ $ret == 0 ]]; do rm -rf ~/.local/share/rr || true; /usr/bin/python 
"/main/qpid-dispatch/build/tests/run.py" "-x" "unit_tests" 
"/main/qpid-dispatch/tests/threads4.conf"; ret=$?; done;
{noformat}

edit: so it seems this is OS-dependent. I can reproduce it in a Debian VM or 
Docker, but not in Fedora VM or Docker.


was (Author: jdanek):
[~ganeshmurthy] I tried reproducing on Fedora 25 in a VM (not docker) and I 
could not reproduce this. I then tried VM with Debian Stretch and I could 
reproduce it there with the usual

{noformat}
ret=0
while [[ $ret == 0 ]]; do rm -rf ~/.local/share/rr || true; /usr/bin/python 
"/main/qpid-dispatch/build/tests/run.py" "-x" "unit_tests" 
"/main/qpid-dispatch/tests/threads4.conf"; ret=$?; done;
{noformat}

> [unit-tests] SIGSEGV in qd_python_finalize
> --
>
> Key: DISPATCH-782
> URL: https://issues.apache.org/jira/browse/DISPATCH-782
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Tests
>Affects Versions: 1.0.0
>Reporter: Jiri Danek
> Attachments: 9.core
>
>
> {noformat}
> commit 8d862beabd32bd22d4b315ff3a35bd937aa4b2a1
> Author: Andrew Stitcher 
> Date:   Fri May 26 16:16:18 2017 -0400
> No-JIRA: really fix tox tests without breaking anything else!
> {noformat}
> {noformat}
> commit b1f09d5ea8101f40f3df4db5b4c5d2ee00e6ef7e
> Author: Alan Conway 
> Date:   Mon May 29 15:16:26 2017 -0400
> DISPATCH-777: async-signal-safe shutdown of the reactor.
> {noformat}
> If repeatedly running the unit tests, eventually a SIGSEGV is raised.
> Reproducibility: the command below likely needs to be executed multiple times 
> for the error to appear.
> {noformat}
> ctest -VV -R unit_tests --repeat-until-fail 1000
> {noformat}
> {noformat}
> 9: Test command: /usr/bin/python "/main/qpid-dispatch/build/tests/run.py" 
> "-x" "unit_tests" "/main/qpid-dispatch/tests/threads4.conf"
> 9: Test timeout computed to be: 1500
> 9: 2017-05-30 13:23:52.630778 + AGENT (debug) Add entity: 
> LogEntity(enable=debug+, identity=log/DEFAULT, module=DEFAULT, 
> name=log/DEFAULT, output=stderr, source=False, timestamp=True, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.631948 + AGENT (debug) Add entity: 
> LogEntity(identity=log/HTTP, module=HTTP, name=log/HTTP, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.632602 + AGENT (debug) Add entity: 
> LogEntity(identity=log/ROUTER_LS, module=ROUTER_LS, name=log/ROUTER_LS, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.633137 + AGENT (debug) Add entity: 
> LogEntity(identity=log/PYTHON, module=PYTHON, name=log/PYTHON, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.633712 + AGENT (debug) Add entity: 
> LogEntity(identity=log/ROUTER_MA, module=ROUTER_MA, name=log/ROUTER_MA, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.634201 + AGENT (debug) Add entity: 
> LogEntity(identity=log/CONN_MGR, module=CONN_MGR, name=log/CONN_MGR, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.634756 + AGENT (debug) Add entity: 
> LogEntity(identity=log/ROUTER_HELLO, module=ROUTER_HELLO, 
> name=log/ROUTER_HELLO, type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.635661 + AGENT (debug) Add entity: 
> LogEntity(identity=log/SERVER, module=SERVER, name=log/SERVER, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.636837 + AGENT (debug) Add entity: 
> LogEntity(identity=log/POLICY, module=POLICY, name=log/POLICY, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.637421 + AGENT (debug) Add entity: 
> LogEntity(identity=log/CONTAINER, module=CONTAINER, name=log/CONTAINER, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.637968 + AGENT (debug) Add entity: 
> LogEntity(identity=log/AGENT, module=AGENT, name=log/AGENT, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.638828 + AGENT (debug) Add entity: 
> LogEntity(identity=log/ERROR, module=ERROR, name=log/ERROR, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.640134 + AGENT (debug) Add entity: 
> LogEntity(identity=log/ROUTER_CORE, module=ROUTER_CORE, name=log/ROUTER_CORE, 
> type=org.apache.qpid.dispatch.log)
> 9: 2017-05-30 13:23:52.640886 + AGENT (debug) Add entity: 
> LogEntity(identity=log/ROUTER, module=ROUTER, name=log/ROUTER, 
> 

[jira] [Commented] (DISPATCH-803) refuse attach to undefined addresses

[ASF subversion and git services (JIRA)]

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

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

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

DISPATCH-803 - The following changes were made to support unavailable 
distribution
1. Added a new attribute to the router entity called called defaultDistribution 
which defaults to balanced
but can be set to unavailable
2. Attaches to addresses with distribution unavailable are rejected and the 
link is detached
3. Anonymous senders sending to unavailable addresses will be sent back a 
disposition of PN_REJECTED but link will not be closed
4. Added system test system_tests_default_distribution.py to test the above 
cases

(cherry picked from commit 49f643e9fabfe381934b26b679b4f2bda39f2e4a)


> refuse attach to undefined addresses
> 
>
> Key: DISPATCH-803
> URL: https://issues.apache.org/jira/browse/DISPATCH-803
> Project: Qpid Dispatch
>  Issue Type: Improvement
>Reporter: Gordon Sim
>Assignee: Ganesh Murthy
> Fix For: 1.0.0
>
>
> At present, if you attach to an address in the router whose semantics have 
> not been specifically defined, you get balanced message routing semantics.
> It would be useful to be able to configure the router such that it would 
> refuse links whose source/target was not explicitly defined. E.g. by being 
> able to configure the default semantics to be of type 'invalid' (or anything 
> similar). (Being able to explicitly blacklist certain addresses might also be 
> nice, but is a more exotic use case I think).
> Messages sent through an anonymous link to these 'invalid' addresses would be 
> rejected.
>  



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

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

[jira] [Commented] (PROTON-1517) SyncRequestResponse(BlockingConnection).call() fails with timeout

[Ted Ross (JIRA)]

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

Ted Ross commented on PROTON-1517:
--

This is correct.  The message implementation within qpidd treats the 
correlationId as a string.  The QMF agent in the broker uses this 
implementation.


> SyncRequestResponse(BlockingConnection).call() fails with timeout
> -
>
> Key: PROTON-1517
> URL: https://issues.apache.org/jira/browse/PROTON-1517
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: python-binding
>Affects Versions: 0.17.0
> Environment: macOS Sierra 10.12.5
> Python 3.6.1
>Reporter: aikchar
>Assignee: Justin Ross
>  Labels: easyfix, patch
> Fix For: proton-c-0.18.0
>
>
> Send a QMFv2 message using SyncRequestResponse.call(). The response times out.
> h2. Repro
> This repro uses the example from 
> https://qpid.apache.org/releases/qpid-proton-0.17.0/proton/python/examples/sync_client.py.html.
> {noformat}
> $ python
> Python 3.6.1 (default, Apr 24 2017, 09:59:45)
> [GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.42.1)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
> >>> address = 
> >>> 'amqps://REDACTED_USERNAME:REDACTED_PASSWORD@REDACTED_IP_ADDR:5672/qmf.default.direct'
> >>> from proton import Url
> >>> url = Url(address)
> >>>
> >>> from proton.utils import SyncRequestResponse, BlockingConnection
> >>> client = SyncRequestResponse(BlockingConnection(url, timeout=15, 
> >>> target='qmf.default.direct', sasl_enabled=True, allowed_mechs='PLAIN'), 
> >>> 'qmf.default.direct')
> >>>
> >>> content = {'_what': 'OBJECT', '_schema_id': {'_class_name': 'queue'}}
> >>> properties = {'x-amqp-0-10.app-id': 'qmf2', 'qmf.opcode': 
> >>> '_query_request', 'method': 'request'}
> >>>
> >>> from proton import Message
> >>> m = Message(reply_to=client.receiver.remote_source.address, 
> >>> address=address, body=content, properties=properties, subject='broker')
> >>> r = client.call(m)
> Traceback (most recent call last):
>   File "", line 1, in 
>   File 
> "/Users/hamza.sheikh/virtualenvs/flight-test-py36/lib/python3.6/site-packages/proton/utils.py",
>  line 400, in call
> self.connection.wait(wakeup, msg="Waiting for response")
>   File 
> "/Users/hamza.sheikh/virtualenvs/flight-test-py36/lib/python3.6/site-packages/proton/utils.py",
>  line 288, in wait
> raise Timeout(txt)
> proton.Timeout: Connection 
> amqps://REDACTED_USERNAME:REDACTED_PASSWORD@REDACTED_IP_ADDR:5672/qmf.default.direct
>  timed out: Waiting for response
> >>>
> {noformat}
> h2. Patch
> Patch is to make sure correlation_id is a string.
> {noformat}
> $ git diff
> diff --git a/proton-c/bindings/python/proton/utils.py 
> b/proton-c/bindings/python/proton/utils.py
> index 05ef80df..528ce338 100644
> --- a/proton-c/bindings/python/proton/utils.py
> +++ b/proton-c/bindings/python/proton/utils.py
> @@ -349,7 +349,7 @@ class SyncRequestResponse(IncomingMessageHandler):
>  if not self.address and not request.address:
>  raise ValueError("Request message has no address: %s" % request)
>  request.reply_to = self.reply_to
> -request.correlation_id = correlation_id = self.correlation_id.next()
> +request.correlation_id = correlation_id = 
> str(self.correlation_id.next())
>  self.sender.send(request)
>  def wakeup():
>  return self.response and (self.response.correlation_id == 
> correlation_id)
> {noformat}
> After applying the patch, the response does not time out.
> {noformat}
> $ python
> Python 3.6.1 (default, Apr 24 2017, 09:59:45)
> [GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.42.1)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
> >>> address = 
> >>> 'amqps://REDACTED_USERNAME:REDACTED_PASSWORD@REDACTED_IP_ADDR:5672/qmf.default.direct'
> >>> from proton import Url
> >>> url = Url(address)
> >>>
> >>> from proton.utils import SyncRequestResponse, BlockingConnection
> >>> client = SyncRequestResponse(BlockingConnection(url, timeout=15, 
> >>> target='qmf.default.direct', sasl_enabled=True, allowed_mechs='PLAIN'), 
> >>> 'qmf.default.direct')
> >>>
> >>> content = {'_what': 'OBJECT', '_schema_id': {'_class_name': 'queue'}}
> >>> properties = {'x-amqp-0-10.app-id': 'qmf2', 'qmf.opcode': 
> >>> '_query_request', 'method': 'request'}
> >>>
> >>> from proton import Message
> >>> m = Message(reply_to=client.receiver.remote_source.address, 
> >>> address=address, body=content, properties=properties, subject='broker')
> >>> r = client.call(m)
> >>> r.body
> [{'_create_ts': ulong(1500315523092865467), '_delete_ts': ulong(0), 
> '_object_id': {'_agent_epoch': ulong(3), '_object_name': 
> 

[GitHub] qpid-dispatch pull request #185: DISPATCH-803 - The following changes were m...

[ganeshmurthy]

Github user ganeshmurthy closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[jira] [Commented] (DISPATCH-803) refuse attach to undefined addresses

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on DISPATCH-803:
-

Github user ganeshmurthy closed the pull request at:

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


> refuse attach to undefined addresses
> 
>
> Key: DISPATCH-803
> URL: https://issues.apache.org/jira/browse/DISPATCH-803
> Project: Qpid Dispatch
>  Issue Type: Improvement
>Reporter: Gordon Sim
>Assignee: Ganesh Murthy
> Fix For: 1.0.0
>
>
> At present, if you attach to an address in the router whose semantics have 
> not been specifically defined, you get balanced message routing semantics.
> It would be useful to be able to configure the router such that it would 
> refuse links whose source/target was not explicitly defined. E.g. by being 
> able to configure the default semantics to be of type 'invalid' (or anything 
> similar). (Being able to explicitly blacklist certain addresses might also be 
> nice, but is a more exotic use case I think).
> Messages sent through an anonymous link to these 'invalid' addresses would be 
> rejected.
>  



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

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

[jira] [Created] (PROTON-1535) Can't set hostname on SASL-INIT

[Gordon Sim (JIRA)]

Gordon Sim created PROTON-1535:
--

 Summary: Can't set hostname on SASL-INIT
 Key: PROTON-1535
 URL: https://issues.apache.org/jira/browse/PROTON-1535
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-c
Reporter: Gordon Sim
Assignee: Andrew Stitcher
 Fix For: proton-c-0.18.0


There is no way to set the hostname in the SASL-INIT frame that is sent out by 
proton. This is needed if the server will use that hostname to determine the 
realm/domain against which to authenticate in a multi-tenant environment.



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

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

[jira] [Commented] (QPID-7434) Mature the AMQP message conversion layer (headers and content)

[ASF subversion and git services (JIRA)]

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

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

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

QPID-7434: [Java Broker] Improve Internal to AMQP 1.0 content conversion and 
add unit tests


> Mature the AMQP message conversion layer (headers and content)
> --
>
> Key: QPID-7434
> URL: https://issues.apache.org/jira/browse/QPID-7434
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
>Assignee: Lorenz Quack
> Fix For: qpid-java-broker-7.0.0
>
>
> There are a number of gaps in our message converters that mean some message 
> are not converted with complete fidelity (particularly in the treatment of 
> application headers), and where complete fidelity cannot be acheived we need 
> sensible rules, uniformly implemented to decide how aspects degrade.
> For instance, for AMQP 0-8..0-10 allow application headers whose values were 
> complex types (e.g. map).  AMQP 1.0 disallows this.  What should the 
> behaviour be?  Should the header be dropped?
> Another instance is the length and constituency of the keys of application 
> headers.  AMQP 0-8..0-10 have a protocol restriction of 255 UTF8 bytes.  AMQP 
> has supports longer strings.  Also AMQP 0-9 says further restricts the key to 
> be formed like a Java identifier.



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

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

[jira] [Created] (QPID-7885) [Java Broker] Support Java 9

[Lorenz Quack (JIRA)]

Lorenz Quack created QPID-7885:
--

 Summary: [Java Broker] Support Java 9
 Key: QPID-7885
 URL: https://issues.apache.org/jira/browse/QPID-7885
 Project: Qpid
  Issue Type: Improvement
  Components: Java Broker, Java Client
Reporter: Lorenz Quack


With the Java 9 on the horizon it is time to get Qpid's Java components ready.
* make sure component compile with JDK9
* make sure components run with JRE9
* take advantage of the new Java Module System




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

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

[jira] [Created] (PROTON-1536) THere is no way using the C++ binding connection_driver API to either send heartbeat frames, or recognise heartbeat timeouts

[Andrew Stitcher (JIRA)]

Andrew Stitcher created PROTON-1536:
---

 Summary: THere is no way using the C++ binding connection_driver 
API to either send heartbeat frames, or recognise heartbeat timeouts
 Key: PROTON-1536
 URL: https://issues.apache.org/jira/browse/PROTON-1536
 Project: Qpid Proton
  Issue Type: Improvement
  Components: cpp-binding
Reporter: Andrew Stitcher
Assignee: Andrew Stitcher


The C++ connection_driver API does not expose any way to get to the 
pn_transport_tick() function to tell the engine what time it is. So the engine 
has no way to know whether it needs to send empty heartbeat frames, and equally 
it can't tell when a heartbeat timeout has occurred due to lack of traffic from 
the peer.



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

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

[jira] [Updated] (PROTON-1517) SyncRequestResponse(BlockingConnection).call() fails with timeout

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-1517:

Fix Version/s: (was: proton-c-0.18.0)
   proton-c-0.19.0

> SyncRequestResponse(BlockingConnection).call() fails with timeout
> -
>
> Key: PROTON-1517
> URL: https://issues.apache.org/jira/browse/PROTON-1517
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: python-binding
>Affects Versions: 0.17.0
> Environment: macOS Sierra 10.12.5
> Python 3.6.1
>Reporter: aikchar
>Assignee: Justin Ross
>  Labels: easyfix, patch
> Fix For: proton-c-0.19.0
>
>
> Send a QMFv2 message using SyncRequestResponse.call(). The response times out.
> h2. Repro
> This repro uses the example from 
> https://qpid.apache.org/releases/qpid-proton-0.17.0/proton/python/examples/sync_client.py.html.
> {noformat}
> $ python
> Python 3.6.1 (default, Apr 24 2017, 09:59:45)
> [GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.42.1)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
> >>> address = 
> >>> 'amqps://REDACTED_USERNAME:REDACTED_PASSWORD@REDACTED_IP_ADDR:5672/qmf.default.direct'
> >>> from proton import Url
> >>> url = Url(address)
> >>>
> >>> from proton.utils import SyncRequestResponse, BlockingConnection
> >>> client = SyncRequestResponse(BlockingConnection(url, timeout=15, 
> >>> target='qmf.default.direct', sasl_enabled=True, allowed_mechs='PLAIN'), 
> >>> 'qmf.default.direct')
> >>>
> >>> content = {'_what': 'OBJECT', '_schema_id': {'_class_name': 'queue'}}
> >>> properties = {'x-amqp-0-10.app-id': 'qmf2', 'qmf.opcode': 
> >>> '_query_request', 'method': 'request'}
> >>>
> >>> from proton import Message
> >>> m = Message(reply_to=client.receiver.remote_source.address, 
> >>> address=address, body=content, properties=properties, subject='broker')
> >>> r = client.call(m)
> Traceback (most recent call last):
>   File "", line 1, in 
>   File 
> "/Users/hamza.sheikh/virtualenvs/flight-test-py36/lib/python3.6/site-packages/proton/utils.py",
>  line 400, in call
> self.connection.wait(wakeup, msg="Waiting for response")
>   File 
> "/Users/hamza.sheikh/virtualenvs/flight-test-py36/lib/python3.6/site-packages/proton/utils.py",
>  line 288, in wait
> raise Timeout(txt)
> proton.Timeout: Connection 
> amqps://REDACTED_USERNAME:REDACTED_PASSWORD@REDACTED_IP_ADDR:5672/qmf.default.direct
>  timed out: Waiting for response
> >>>
> {noformat}
> h2. Patch
> Patch is to make sure correlation_id is a string.
> {noformat}
> $ git diff
> diff --git a/proton-c/bindings/python/proton/utils.py 
> b/proton-c/bindings/python/proton/utils.py
> index 05ef80df..528ce338 100644
> --- a/proton-c/bindings/python/proton/utils.py
> +++ b/proton-c/bindings/python/proton/utils.py
> @@ -349,7 +349,7 @@ class SyncRequestResponse(IncomingMessageHandler):
>  if not self.address and not request.address:
>  raise ValueError("Request message has no address: %s" % request)
>  request.reply_to = self.reply_to
> -request.correlation_id = correlation_id = self.correlation_id.next()
> +request.correlation_id = correlation_id = 
> str(self.correlation_id.next())
>  self.sender.send(request)
>  def wakeup():
>  return self.response and (self.response.correlation_id == 
> correlation_id)
> {noformat}
> After applying the patch, the response does not time out.
> {noformat}
> $ python
> Python 3.6.1 (default, Apr 24 2017, 09:59:45)
> [GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.42.1)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
> >>> address = 
> >>> 'amqps://REDACTED_USERNAME:REDACTED_PASSWORD@REDACTED_IP_ADDR:5672/qmf.default.direct'
> >>> from proton import Url
> >>> url = Url(address)
> >>>
> >>> from proton.utils import SyncRequestResponse, BlockingConnection
> >>> client = SyncRequestResponse(BlockingConnection(url, timeout=15, 
> >>> target='qmf.default.direct', sasl_enabled=True, allowed_mechs='PLAIN'), 
> >>> 'qmf.default.direct')
> >>>
> >>> content = {'_what': 'OBJECT', '_schema_id': {'_class_name': 'queue'}}
> >>> properties = {'x-amqp-0-10.app-id': 'qmf2', 'qmf.opcode': 
> >>> '_query_request', 'method': 'request'}
> >>>
> >>> from proton import Message
> >>> m = Message(reply_to=client.receiver.remote_source.address, 
> >>> address=address, body=content, properties=properties, subject='broker')
> >>> r = client.call(m)
> >>> r.body
> [{'_create_ts': ulong(1500315523092865467), '_delete_ts': ulong(0), 
> '_object_id': {'_agent_epoch': ulong(3), '_object_name': 
> b'org.apache.qpid.broker:queue:420cb745-f3c7-4a47-ac09-0a4711f10058:1.0'}, 
> '_schema_id': {'_class_name': b'queue', '_hash': 
> 

[jira] [Resolved] (DISPATCH-803) refuse attach to undefined addresses

[Ganesh Murthy (JIRA)]

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

Ganesh Murthy resolved DISPATCH-803.

Resolution: Fixed

> refuse attach to undefined addresses
> 
>
> Key: DISPATCH-803
> URL: https://issues.apache.org/jira/browse/DISPATCH-803
> Project: Qpid Dispatch
>  Issue Type: Improvement
>Reporter: Gordon Sim
>Assignee: Ganesh Murthy
> Fix For: 1.0.0
>
>
> At present, if you attach to an address in the router whose semantics have 
> not been specifically defined, you get balanced message routing semantics.
> It would be useful to be able to configure the router such that it would 
> refuse links whose source/target was not explicitly defined. E.g. by being 
> able to configure the default semantics to be of type 'invalid' (or anything 
> similar). (Being able to explicitly blacklist certain addresses might also be 
> nice, but is a more exotic use case I think).
> Messages sent through an anonymous link to these 'invalid' addresses would be 
> rejected.
>  



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

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

[jira] [Assigned] (QPID-7781) [Java Broker] 500 error whilst deleting a virtualhost.

[Alex Rudyy (JIRA)]

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

Alex Rudyy reassigned QPID-7781:


Assignee: Alex Rudyy  (was: Keith Wall)

> [Java Broker] 500 error whilst deleting a virtualhost.
> --
>
> Key: QPID-7781
> URL: https://issues.apache.org/jira/browse/QPID-7781
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Lorenz Quack
>Assignee: Alex Rudyy
> Fix For: qpid-java-broker-7.0.0
>
>
> The following 500 was encountered whilst deleting a JSON/Derby store backed 
> virtualhostnode/virtualhost.  The virtualhost had three messages on two 
> queues.  Clients were connected to the queues at the time (stopped on a 
> breakpoint).  The Broker did not crash.
> This will probably be just a trunk issue.
> {noformat}
> 2017-05-12 15:28:34,596 ERROR [HttpManagement-HTTP-89] 
> (o.a.q.s.m.p.f.ExceptionHandlingFilter) - Unexpected exception in servlet 
> '/api/latest/virtualhostnode':
> java.lang.IllegalStateException: Message store is not open
> at 
> org.apache.qpid.server.store.derby.AbstractDerbyMessageStore.checkMessageStoreOpen(AbstractDerbyMessageStore.java:117)
> at 
> org.apache.qpid.server.store.derby.DerbyMessageStore.getConnection(DerbyMessageStore.java:57)
> at 
> org.apache.qpid.server.virtualhost.derby.DerbyVirtualHostImpl.getConnection(DerbyVirtualHostImpl.java:111)
> at 
> org.apache.qpid.server.protocol.v1_0.store.jdbc.JDBCLinkStore.getConnection(JDBCLinkStore.java:224)
> at 
> org.apache.qpid.server.protocol.v1_0.store.jdbc.JDBCLinkStore.doDelete(JDBCLinkStore.java:189)
> at 
> org.apache.qpid.server.protocol.v1_0.store.AbstractLinkStore.delete(AbstractLinkStore.java:122)
> at 
> org.apache.qpid.server.protocol.v1_0.LinkRegistryImpl.delete(LinkRegistryImpl.java:136)
> at 
> org.apache.qpid.server.virtualhost.AbstractVirtualHost$13.run(AbstractVirtualHost.java:2233)
> at 
> org.apache.qpid.server.model.AbstractConfiguredObject$21.onSuccess(AbstractConfiguredObject.java:2587)
> at 
> org.apache.qpid.server.model.AbstractConfiguredObject$22$1.run(AbstractConfiguredObject.java:2628)
> at 
> org.apache.qpid.server.model.AbstractConfiguredObject$22$1.run(AbstractConfiguredObject.java:2624)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at 
> org.apache.qpid.server.model.AbstractConfiguredObject$22.onSuccess(AbstractConfiguredObject.java:2623)
> at com.google.common.util.concurrent.Futures$6.run(Futures.java:1319)
> at 
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$ImmediateIfSameThreadExecutor.execute(TaskExecutorImpl.java:392)
> at 
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.execute(TaskExecutorImpl.java:175)
> at 
> com.google.common.util.concurrent.ExecutionList.executeListener(ExecutionList.java:156)
> at 
> com.google.common.util.concurrent.ExecutionList.execute(ExecutionList.java:145)
> at 
> com.google.common.util.concurrent.AbstractFuture.set(AbstractFuture.java:185)
> at 
> com.google.common.util.concurrent.SettableFuture.set(SettableFuture.java:53)
> at 
> org.apache.qpid.server.model.AbstractConfiguredObject$2$1.onSuccess(AbstractConfiguredObject.java:641)
> at 
> org.apache.qpid.server.model.AbstractConfiguredObject$22$1.run(AbstractConfiguredObject.java:2628)
> at 
> org.apache.qpid.server.model.AbstractConfiguredObject$22$1.run(AbstractConfiguredObject.java:2624)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at 
> org.apache.qpid.server.model.AbstractConfiguredObject$22.onSuccess(AbstractConfiguredObject.java:2623)
> at com.google.common.util.concurrent.Futures$6.run(Futures.java:1319)
> at 
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$ImmediateIfSameThreadExecutor.execute(TaskExecutorImpl.java:392)
> at 
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.execute(TaskExecutorImpl.java:175)
> at 
> com.google.common.util.concurrent.ExecutionList.executeListener(ExecutionList.java:156)
> at 
> com.google.common.util.concurrent.ExecutionList.execute(ExecutionList.java:145)
> at 
> com.google.common.util.concurrent.AbstractFuture.set(AbstractFuture.java:185)
> at 
> com.google.common.util.concurrent.SettableFuture.set(SettableFuture.java:53)
> at 
> org.apache.qpid.server.model.AbstractConfiguredObject$5$4.onSuccess(AbstractConfiguredObject.java:808)
> at 
> 

[jira] [Updated] (QPID-7781) [Java Broker] 500 error whilst deleting a virtualhost.

[Alex Rudyy (JIRA)]

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

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

> [Java Broker] 500 error whilst deleting a virtualhost.
> --
>
> Key: QPID-7781
> URL: https://issues.apache.org/jira/browse/QPID-7781
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Lorenz Quack
>Assignee: Alex Rudyy
> Fix For: qpid-java-broker-7.0.0
>
>
> The following 500 was encountered whilst deleting a JSON/Derby store backed 
> virtualhostnode/virtualhost.  The virtualhost had three messages on two 
> queues.  Clients were connected to the queues at the time (stopped on a 
> breakpoint).  The Broker did not crash.
> This will probably be just a trunk issue.
> {noformat}
> 2017-05-12 15:28:34,596 ERROR [HttpManagement-HTTP-89] 
> (o.a.q.s.m.p.f.ExceptionHandlingFilter) - Unexpected exception in servlet 
> '/api/latest/virtualhostnode':
> java.lang.IllegalStateException: Message store is not open
> at 
> org.apache.qpid.server.store.derby.AbstractDerbyMessageStore.checkMessageStoreOpen(AbstractDerbyMessageStore.java:117)
> at 
> org.apache.qpid.server.store.derby.DerbyMessageStore.getConnection(DerbyMessageStore.java:57)
> at 
> org.apache.qpid.server.virtualhost.derby.DerbyVirtualHostImpl.getConnection(DerbyVirtualHostImpl.java:111)
> at 
> org.apache.qpid.server.protocol.v1_0.store.jdbc.JDBCLinkStore.getConnection(JDBCLinkStore.java:224)
> at 
> org.apache.qpid.server.protocol.v1_0.store.jdbc.JDBCLinkStore.doDelete(JDBCLinkStore.java:189)
> at 
> org.apache.qpid.server.protocol.v1_0.store.AbstractLinkStore.delete(AbstractLinkStore.java:122)
> at 
> org.apache.qpid.server.protocol.v1_0.LinkRegistryImpl.delete(LinkRegistryImpl.java:136)
> at 
> org.apache.qpid.server.virtualhost.AbstractVirtualHost$13.run(AbstractVirtualHost.java:2233)
> at 
> org.apache.qpid.server.model.AbstractConfiguredObject$21.onSuccess(AbstractConfiguredObject.java:2587)
> at 
> org.apache.qpid.server.model.AbstractConfiguredObject$22$1.run(AbstractConfiguredObject.java:2628)
> at 
> org.apache.qpid.server.model.AbstractConfiguredObject$22$1.run(AbstractConfiguredObject.java:2624)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at 
> org.apache.qpid.server.model.AbstractConfiguredObject$22.onSuccess(AbstractConfiguredObject.java:2623)
> at com.google.common.util.concurrent.Futures$6.run(Futures.java:1319)
> at 
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$ImmediateIfSameThreadExecutor.execute(TaskExecutorImpl.java:392)
> at 
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.execute(TaskExecutorImpl.java:175)
> at 
> com.google.common.util.concurrent.ExecutionList.executeListener(ExecutionList.java:156)
> at 
> com.google.common.util.concurrent.ExecutionList.execute(ExecutionList.java:145)
> at 
> com.google.common.util.concurrent.AbstractFuture.set(AbstractFuture.java:185)
> at 
> com.google.common.util.concurrent.SettableFuture.set(SettableFuture.java:53)
> at 
> org.apache.qpid.server.model.AbstractConfiguredObject$2$1.onSuccess(AbstractConfiguredObject.java:641)
> at 
> org.apache.qpid.server.model.AbstractConfiguredObject$22$1.run(AbstractConfiguredObject.java:2628)
> at 
> org.apache.qpid.server.model.AbstractConfiguredObject$22$1.run(AbstractConfiguredObject.java:2624)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at 
> org.apache.qpid.server.model.AbstractConfiguredObject$22.onSuccess(AbstractConfiguredObject.java:2623)
> at com.google.common.util.concurrent.Futures$6.run(Futures.java:1319)
> at 
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$ImmediateIfSameThreadExecutor.execute(TaskExecutorImpl.java:392)
> at 
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.execute(TaskExecutorImpl.java:175)
> at 
> com.google.common.util.concurrent.ExecutionList.executeListener(ExecutionList.java:156)
> at 
> com.google.common.util.concurrent.ExecutionList.execute(ExecutionList.java:145)
> at 
> com.google.common.util.concurrent.AbstractFuture.set(AbstractFuture.java:185)
> at 
> com.google.common.util.concurrent.SettableFuture.set(SettableFuture.java:53)
> at 
> org.apache.qpid.server.model.AbstractConfiguredObject$5$4.onSuccess(AbstractConfiguredObject.java:808)
> at 
> 

[jira] [Commented] (QPID-7434) Mature the AMQP message conversion layer (headers and content)

[ASF subversion and git services (JIRA)]

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

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

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

QPID-7434: [Java Broker] Improve AMQP 1.0 to Internal content conversion and 
add unit tests


> Mature the AMQP message conversion layer (headers and content)
> --
>
> Key: QPID-7434
> URL: https://issues.apache.org/jira/browse/QPID-7434
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
>Assignee: Lorenz Quack
> Fix For: qpid-java-broker-7.0.0
>
>
> There are a number of gaps in our message converters that mean some message 
> are not converted with complete fidelity (particularly in the treatment of 
> application headers), and where complete fidelity cannot be acheived we need 
> sensible rules, uniformly implemented to decide how aspects degrade.
> For instance, for AMQP 0-8..0-10 allow application headers whose values were 
> complex types (e.g. map).  AMQP 1.0 disallows this.  What should the 
> behaviour be?  Should the header be dropped?
> Another instance is the length and constituency of the keys of application 
> headers.  AMQP 0-8..0-10 have a protocol restriction of 255 UTF8 bytes.  AMQP 
> has supports longer strings.  Also AMQP 0-9 says further restricts the key to 
> be formed like a Java identifier.



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

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

[jira] [Commented] (QPID-7781) [Java Broker] 500 error whilst deleting a virtualhost.

[ASF subversion and git services (JIRA)]

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

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

Commit 0e4b9c556000c93d0ccd90959a91c851b7136290 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=0e4b9c5 ]

QPID-7781: [Java Broker] Address review comments

* Destroy Add Virtual Host dialog on pressing cancel button from menu
* Apply metadata to VHN and VH widgets as part of loading UI for the selected 
type
* Fix destroy method for context variable editor


> [Java Broker] 500 error whilst deleting a virtualhost.
> --
>
> Key: QPID-7781
> URL: https://issues.apache.org/jira/browse/QPID-7781
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Lorenz Quack
>Assignee: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
>
> The following 500 was encountered whilst deleting a JSON/Derby store backed 
> virtualhostnode/virtualhost.  The virtualhost had three messages on two 
> queues.  Clients were connected to the queues at the time (stopped on a 
> breakpoint).  The Broker did not crash.
> This will probably be just a trunk issue.
> {noformat}
> 2017-05-12 15:28:34,596 ERROR [HttpManagement-HTTP-89] 
> (o.a.q.s.m.p.f.ExceptionHandlingFilter) - Unexpected exception in servlet 
> '/api/latest/virtualhostnode':
> java.lang.IllegalStateException: Message store is not open
> at 
> org.apache.qpid.server.store.derby.AbstractDerbyMessageStore.checkMessageStoreOpen(AbstractDerbyMessageStore.java:117)
> at 
> org.apache.qpid.server.store.derby.DerbyMessageStore.getConnection(DerbyMessageStore.java:57)
> at 
> org.apache.qpid.server.virtualhost.derby.DerbyVirtualHostImpl.getConnection(DerbyVirtualHostImpl.java:111)
> at 
> org.apache.qpid.server.protocol.v1_0.store.jdbc.JDBCLinkStore.getConnection(JDBCLinkStore.java:224)
> at 
> org.apache.qpid.server.protocol.v1_0.store.jdbc.JDBCLinkStore.doDelete(JDBCLinkStore.java:189)
> at 
> org.apache.qpid.server.protocol.v1_0.store.AbstractLinkStore.delete(AbstractLinkStore.java:122)
> at 
> org.apache.qpid.server.protocol.v1_0.LinkRegistryImpl.delete(LinkRegistryImpl.java:136)
> at 
> org.apache.qpid.server.virtualhost.AbstractVirtualHost$13.run(AbstractVirtualHost.java:2233)
> at 
> org.apache.qpid.server.model.AbstractConfiguredObject$21.onSuccess(AbstractConfiguredObject.java:2587)
> at 
> org.apache.qpid.server.model.AbstractConfiguredObject$22$1.run(AbstractConfiguredObject.java:2628)
> at 
> org.apache.qpid.server.model.AbstractConfiguredObject$22$1.run(AbstractConfiguredObject.java:2624)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at 
> org.apache.qpid.server.model.AbstractConfiguredObject$22.onSuccess(AbstractConfiguredObject.java:2623)
> at com.google.common.util.concurrent.Futures$6.run(Futures.java:1319)
> at 
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$ImmediateIfSameThreadExecutor.execute(TaskExecutorImpl.java:392)
> at 
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.execute(TaskExecutorImpl.java:175)
> at 
> com.google.common.util.concurrent.ExecutionList.executeListener(ExecutionList.java:156)
> at 
> com.google.common.util.concurrent.ExecutionList.execute(ExecutionList.java:145)
> at 
> com.google.common.util.concurrent.AbstractFuture.set(AbstractFuture.java:185)
> at 
> com.google.common.util.concurrent.SettableFuture.set(SettableFuture.java:53)
> at 
> org.apache.qpid.server.model.AbstractConfiguredObject$2$1.onSuccess(AbstractConfiguredObject.java:641)
> at 
> org.apache.qpid.server.model.AbstractConfiguredObject$22$1.run(AbstractConfiguredObject.java:2628)
> at 
> org.apache.qpid.server.model.AbstractConfiguredObject$22$1.run(AbstractConfiguredObject.java:2624)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at 
> org.apache.qpid.server.model.AbstractConfiguredObject$22.onSuccess(AbstractConfiguredObject.java:2623)
> at com.google.common.util.concurrent.Futures$6.run(Futures.java:1319)
> at 
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$ImmediateIfSameThreadExecutor.execute(TaskExecutorImpl.java:392)
> at 
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.execute(TaskExecutorImpl.java:175)
> at 
> 

[jira] [Commented] (PROTON-1517) SyncRequestResponse(BlockingConnection).call() fails with timeout

[Justin Ross (JIRA)]

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

Justin Ross commented on PROTON-1517:
-

I bumped this to 0.19.0, at which point we can consider taking this patch as an 
accommodation or come up with some other approach.

> SyncRequestResponse(BlockingConnection).call() fails with timeout
> -
>
> Key: PROTON-1517
> URL: https://issues.apache.org/jira/browse/PROTON-1517
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: python-binding
>Affects Versions: 0.17.0
> Environment: macOS Sierra 10.12.5
> Python 3.6.1
>Reporter: aikchar
>Assignee: Justin Ross
>  Labels: easyfix, patch
> Fix For: proton-c-0.19.0
>
>
> Send a QMFv2 message using SyncRequestResponse.call(). The response times out.
> h2. Repro
> This repro uses the example from 
> https://qpid.apache.org/releases/qpid-proton-0.17.0/proton/python/examples/sync_client.py.html.
> {noformat}
> $ python
> Python 3.6.1 (default, Apr 24 2017, 09:59:45)
> [GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.42.1)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
> >>> address = 
> >>> 'amqps://REDACTED_USERNAME:REDACTED_PASSWORD@REDACTED_IP_ADDR:5672/qmf.default.direct'
> >>> from proton import Url
> >>> url = Url(address)
> >>>
> >>> from proton.utils import SyncRequestResponse, BlockingConnection
> >>> client = SyncRequestResponse(BlockingConnection(url, timeout=15, 
> >>> target='qmf.default.direct', sasl_enabled=True, allowed_mechs='PLAIN'), 
> >>> 'qmf.default.direct')
> >>>
> >>> content = {'_what': 'OBJECT', '_schema_id': {'_class_name': 'queue'}}
> >>> properties = {'x-amqp-0-10.app-id': 'qmf2', 'qmf.opcode': 
> >>> '_query_request', 'method': 'request'}
> >>>
> >>> from proton import Message
> >>> m = Message(reply_to=client.receiver.remote_source.address, 
> >>> address=address, body=content, properties=properties, subject='broker')
> >>> r = client.call(m)
> Traceback (most recent call last):
>   File "", line 1, in 
>   File 
> "/Users/hamza.sheikh/virtualenvs/flight-test-py36/lib/python3.6/site-packages/proton/utils.py",
>  line 400, in call
> self.connection.wait(wakeup, msg="Waiting for response")
>   File 
> "/Users/hamza.sheikh/virtualenvs/flight-test-py36/lib/python3.6/site-packages/proton/utils.py",
>  line 288, in wait
> raise Timeout(txt)
> proton.Timeout: Connection 
> amqps://REDACTED_USERNAME:REDACTED_PASSWORD@REDACTED_IP_ADDR:5672/qmf.default.direct
>  timed out: Waiting for response
> >>>
> {noformat}
> h2. Patch
> Patch is to make sure correlation_id is a string.
> {noformat}
> $ git diff
> diff --git a/proton-c/bindings/python/proton/utils.py 
> b/proton-c/bindings/python/proton/utils.py
> index 05ef80df..528ce338 100644
> --- a/proton-c/bindings/python/proton/utils.py
> +++ b/proton-c/bindings/python/proton/utils.py
> @@ -349,7 +349,7 @@ class SyncRequestResponse(IncomingMessageHandler):
>  if not self.address and not request.address:
>  raise ValueError("Request message has no address: %s" % request)
>  request.reply_to = self.reply_to
> -request.correlation_id = correlation_id = self.correlation_id.next()
> +request.correlation_id = correlation_id = 
> str(self.correlation_id.next())
>  self.sender.send(request)
>  def wakeup():
>  return self.response and (self.response.correlation_id == 
> correlation_id)
> {noformat}
> After applying the patch, the response does not time out.
> {noformat}
> $ python
> Python 3.6.1 (default, Apr 24 2017, 09:59:45)
> [GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.42.1)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
> >>> address = 
> >>> 'amqps://REDACTED_USERNAME:REDACTED_PASSWORD@REDACTED_IP_ADDR:5672/qmf.default.direct'
> >>> from proton import Url
> >>> url = Url(address)
> >>>
> >>> from proton.utils import SyncRequestResponse, BlockingConnection
> >>> client = SyncRequestResponse(BlockingConnection(url, timeout=15, 
> >>> target='qmf.default.direct', sasl_enabled=True, allowed_mechs='PLAIN'), 
> >>> 'qmf.default.direct')
> >>>
> >>> content = {'_what': 'OBJECT', '_schema_id': {'_class_name': 'queue'}}
> >>> properties = {'x-amqp-0-10.app-id': 'qmf2', 'qmf.opcode': 
> >>> '_query_request', 'method': 'request'}
> >>>
> >>> from proton import Message
> >>> m = Message(reply_to=client.receiver.remote_source.address, 
> >>> address=address, body=content, properties=properties, subject='broker')
> >>> r = client.call(m)
> >>> r.body
> [{'_create_ts': ulong(1500315523092865467), '_delete_ts': ulong(0), 
> '_object_id': {'_agent_epoch': ulong(3), '_object_name': 
> 

[jira] [Commented] (DISPATCH-767) Message Cut-Through/Streaming for efficient handling of large messages

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on DISPATCH-767:
-

Github user ganeshmurthy closed the pull request at:

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


> Message Cut-Through/Streaming for efficient handling of large messages
> --
>
> Key: DISPATCH-767
> URL: https://issues.apache.org/jira/browse/DISPATCH-767
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Router Node
>Reporter: Ted Ross
>Assignee: Ganesh Murthy
> Fix For: 1.0.0
>
>
> When large, multi-frame messages are sent through the router, there is no 
> need to wait for the entire message to arrive before starting to send it 
> onward.
> This feature causes the router to route the first frame and allow subsequent 
> frames in a delivery to be streamed out in pipeline fashion.  Ideally, the 
> memory usage in the router should only involve pending frames.  This would 
> allow the router to handle arbitrary numbers of concurrent arbitrarily large 
> messages.



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

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

[jira] [Closed] (PROTON-1063) ruby: ruby reactor holds GVL in process

[Alan Conway (JIRA)]

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

Alan Conway closed PROTON-1063.
---
   Resolution: Duplicate
Fix Version/s: (was: Future)

> ruby: ruby reactor holds GVL in process
> ---
>
> Key: PROTON-1063
> URL: https://issues.apache.org/jira/browse/PROTON-1063
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: ruby-binding
>Affects Versions: 0.10
>Reporter: Alan Conway
>Assignee: Alan Conway
>
> Ruby has a global lock the GVL, like python's GIL.
> The ruby binding Reactor#process blocks in pn_reactor_process while holding 
> the lock, blocking all other ruby threads.
> This is the same issue as PROTON-752, but it was only fixed for messenger, 
> not for the reactor.
> The fix is more complex, we can't simply call pn_reactor_process in 
> rb_thread_call_without_gvl() because it calls handler functions that call 
> back into ruby. We need to isolate just the blocking IO code in without_gvl 
> and restore the lock before handlers call back into ruby.



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

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

[jira] [Updated] (PROTON-1064) ruby: native IO based on connection_driver.c

[Alan Conway (JIRA)]

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

Alan Conway updated PROTON-1064:

Fix Version/s: (was: Future)
   proton-c-0.18.0

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



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

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

[jira] [Updated] (PROTON-1519) qpid_proton 0.17.0 Ruby gem does not work with Ruby 2.4.1

[Alan Conway (JIRA)]

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

Alan Conway updated PROTON-1519:

Fix Version/s: proton-c-0.18.0

> qpid_proton 0.17.0 Ruby gem does not work with Ruby 2.4.1
> -
>
> Key: PROTON-1519
> URL: https://issues.apache.org/jira/browse/PROTON-1519
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: ruby-binding
>Affects Versions: 0.17.0
> Environment: Ruby 2.4.1 on macOS Sierra 10.12.5
>Reporter: Jason Frey
>Assignee: Alan Conway
>  Labels: patch
> Fix For: proton-c-0.18.0
>
>
> qpid_proton 0.17.0 was built successfully from source with
> {code}
> > cmake -DCMAKE_INSTALL_PREFIX=/usr/local -DLIB_INSTALL_DIR=/usr/local/lib
> > make install
> {code}
> Installing the gem with Ruby 2.4.1 from rubygems.org was successful
> {code}
> > gem install qpid_proton
> Building native extensions.  This could take a while...
> Successfully installed qpid_proton-0.17.0
> 1 gem installed
> {code}
> However, using the gem fails with: "RuntimeError: entry exists for Integer"
> {code}
> > irb
> [1] pry(main)> RUBY_DESCRIPTION
> => "ruby 2.4.1p111 (2017-03-22 revision 58053) [x86_64-darwin15]"
> [2] pry(main)> require 'qpid_proton'
> /Users/jfrey/.gem/ruby/2.4.1/gems/qpid_proton-0.17.0/lib/codec/mapping.rb:99: 
> warning: constant ::Fixnum is deprecated
> /Users/jfrey/.gem/ruby/2.4.1/gems/qpid_proton-0.17.0/lib/codec/mapping.rb:99: 
> warning: constant ::Bignum is deprecated
> RuntimeError: entry exists for Integer
> from (qpid_proton-0.17.0) lib/codec/mapping.rb:55:in `block in initialize'
> (qpid_proton-0.17.0) lib/codec/mapping.rb:54:in `each'
> (qpid_proton-0.17.0) lib/codec/mapping.rb:54:in `initialize'
> (qpid_proton-0.17.0) lib/codec/mapping.rb:99:in `new'
> (qpid_proton-0.17.0) lib/codec/mapping.rb:99:in `'
> (qpid_proton-0.17.0) lib/codec/mapping.rb:20:in `'
> (ruby-2.4.1) lib/ruby/2.4.0/rubygems/core_ext/kernel_require.rb:68:in 
> `require'
> (ruby-2.4.1) lib/ruby/2.4.0/rubygems/core_ext/kernel_require.rb:68:in 
> `require'
> (qpid_proton-0.17.0) lib/qpid_proton.rb:54:in `'
> (ruby-2.4.1) lib/ruby/2.4.0/rubygems/core_ext/kernel_require.rb:133:in 
> `require'
> (ruby-2.4.1) lib/ruby/2.4.0/rubygems/core_ext/kernel_require.rb:133:in 
> `rescue in require'
> (ruby-2.4.1) lib/ruby/2.4.0/rubygems/core_ext/kernel_require.rb:40:in 
> `require'
> (pry):1:in `'
> {code}
> Note that the above steps are all successful with Ruby 2.3.3
> {code}
> > irb
> [1] pry(main)> RUBY_DESCRIPTION
> => "ruby 2.3.3p222 (2016-11-21 revision 56859) [x86_64-darwin15]"
> [2] pry(main)> require 'qpid_proton'
> => true
> [3] pry(main)> Qpid::Proton
> => Qpid::Proton
> {code}



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

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

[jira] [Assigned] (PROTON-1519) qpid_proton 0.17.0 Ruby gem does not work with Ruby 2.4.1

[Alan Conway (JIRA)]

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

Alan Conway reassigned PROTON-1519:
---

Assignee: Alan Conway  (was: Justin Ross)

> qpid_proton 0.17.0 Ruby gem does not work with Ruby 2.4.1
> -
>
> Key: PROTON-1519
> URL: https://issues.apache.org/jira/browse/PROTON-1519
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: ruby-binding
>Affects Versions: 0.17.0
> Environment: Ruby 2.4.1 on macOS Sierra 10.12.5
>Reporter: Jason Frey
>Assignee: Alan Conway
>  Labels: patch
> Fix For: proton-c-0.18.0
>
>
> qpid_proton 0.17.0 was built successfully from source with
> {code}
> > cmake -DCMAKE_INSTALL_PREFIX=/usr/local -DLIB_INSTALL_DIR=/usr/local/lib
> > make install
> {code}
> Installing the gem with Ruby 2.4.1 from rubygems.org was successful
> {code}
> > gem install qpid_proton
> Building native extensions.  This could take a while...
> Successfully installed qpid_proton-0.17.0
> 1 gem installed
> {code}
> However, using the gem fails with: "RuntimeError: entry exists for Integer"
> {code}
> > irb
> [1] pry(main)> RUBY_DESCRIPTION
> => "ruby 2.4.1p111 (2017-03-22 revision 58053) [x86_64-darwin15]"
> [2] pry(main)> require 'qpid_proton'
> /Users/jfrey/.gem/ruby/2.4.1/gems/qpid_proton-0.17.0/lib/codec/mapping.rb:99: 
> warning: constant ::Fixnum is deprecated
> /Users/jfrey/.gem/ruby/2.4.1/gems/qpid_proton-0.17.0/lib/codec/mapping.rb:99: 
> warning: constant ::Bignum is deprecated
> RuntimeError: entry exists for Integer
> from (qpid_proton-0.17.0) lib/codec/mapping.rb:55:in `block in initialize'
> (qpid_proton-0.17.0) lib/codec/mapping.rb:54:in `each'
> (qpid_proton-0.17.0) lib/codec/mapping.rb:54:in `initialize'
> (qpid_proton-0.17.0) lib/codec/mapping.rb:99:in `new'
> (qpid_proton-0.17.0) lib/codec/mapping.rb:99:in `'
> (qpid_proton-0.17.0) lib/codec/mapping.rb:20:in `'
> (ruby-2.4.1) lib/ruby/2.4.0/rubygems/core_ext/kernel_require.rb:68:in 
> `require'
> (ruby-2.4.1) lib/ruby/2.4.0/rubygems/core_ext/kernel_require.rb:68:in 
> `require'
> (qpid_proton-0.17.0) lib/qpid_proton.rb:54:in `'
> (ruby-2.4.1) lib/ruby/2.4.0/rubygems/core_ext/kernel_require.rb:133:in 
> `require'
> (ruby-2.4.1) lib/ruby/2.4.0/rubygems/core_ext/kernel_require.rb:133:in 
> `rescue in require'
> (ruby-2.4.1) lib/ruby/2.4.0/rubygems/core_ext/kernel_require.rb:40:in 
> `require'
> (pry):1:in `'
> {code}
> Note that the above steps are all successful with Ruby 2.3.3
> {code}
> > irb
> [1] pry(main)> RUBY_DESCRIPTION
> => "ruby 2.3.3p222 (2016-11-21 revision 56859) [x86_64-darwin15]"
> [2] pry(main)> require 'qpid_proton'
> => true
> [3] pry(main)> Qpid::Proton
> => Qpid::Proton
> {code}



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

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

[jira] [Updated] (PROTON-1457) Ruby tests fail when dependencies are missing

[Alan Conway (JIRA)]

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

Alan Conway updated PROTON-1457:

Fix Version/s: proton-c-0.18.0

> Ruby tests fail when dependencies are missing
> -
>
> Key: PROTON-1457
> URL: https://issues.apache.org/jira/browse/PROTON-1457
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: ruby-binding
> Environment: Fedora 24
>Reporter: Irina Boverman
>Assignee: Alan Conway
> Fix For: proton-c-0.18.0
>
>
> I was running ruby tests on fedora 26 when I got this error:
> > > The following tests FAILED:
> > > Errors while running CTest
> > >   3 - ruby-example-test (Failed)
> > >   4 - ruby-unit-test (Failed)
> > >
> > > And more specifically:
> > >
> > > 3: Test command: /usr/bin/python "/proton/proton-c/env.py" "--"
> > > "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:
> > > /proton/build/proton-c/bindings/ruby:/proton/build/proton-c"
> > > "RUBYLIB=/proton/tests/ruby:/proton/proton-
> > > c/bindings/ruby:/proton/build/proton-
> > > c/bindings/ruby:/proton/build/proton-c:/proton/proton-
> > > c/bindings/ruby/lib"
> > > "/usr/bin/ruby" "example_test.rb" "-v"
> > > 3: Test timeout computed to be: 1500
> > > 3: /usr/share/rubygems/rubygems/core_ext/kernel_require.rb:55:in
> > > `require':
> > > cannot load such file -- test/unit (LoadError)
> I had ruby-devel, ruby-rspec and ruby-simplecov packages installed, but was 
> missing rubygem-minitest and rubygem-test-unit packages. There should be a 
> hint somewhere about needing them.



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

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

[GitHub] qpid-dispatch pull request #186: DISPATCH-767 - Added code to support multi ...

[ganeshmurthy]

GitHub user ganeshmurthy opened a pull request:

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

DISPATCH-767 - Added code to support multi frame message streaming

1. Added new core API function qdr_deliver_continue() that will continue
delivering a large message
2. Modified qdr_link_process_deliveries() to not remove deliveries from
the undelivered list until they are fully delivered
3. Modified qd_message_receive() to recieve partial messages.
4. Modified qd_message_send() to be able to handle streaming send. This
function can now be called multiple times for the same message. It keeps
internal pointers to the point upto which the message has been sent and
is able to continue where it left off. Message content buffers are freed
as soon as the message has been sent to all recipients.
5. Added peer linkage for large settled deliveries and added a settled
list to handle with abrupt connection terminations when large messages
are being transmitted.
6. Added unit tests to test large messages.

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

$ git pull https://github.com/ganeshmurthy/qpid-dispatch 
DISPATCH-767-SQUASH-1

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

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


commit c9262728dc1a6d1bcdc5a68f4b19f1b9d2221d53
Author: Ganesh Murthy 
Date:   2017-07-05T15:51:06Z

DISPATCH-767 - Added code to support multi frame message streaming
1. Added new core API function qdr_deliver_continue() that will continue
delivering a large message
2. Modified qdr_link_process_deliveries() to not remove deliveries from
the undelivered list until they are fully delivered
3. Modified qd_message_receive() to recieve partial messages.
4. Modified qd_message_send() to be able to handle streaming send. This
function can now be called multiple times for the same message. It keeps
internal pointers to the point upto which the message has been sent and
is able to continue where it left off. Message content buffers are freed
as soon as the message has been sent to all recipients.
5. Added peer linkage for large settled deliveries and added a settled
list to handle with abrupt connection terminations when large messages
are being transmitted.
6. Added unit tests to test large messages.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[jira] [Commented] (DISPATCH-767) Message Cut-Through/Streaming for efficient handling of large messages

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on DISPATCH-767:
-

GitHub user ganeshmurthy opened a pull request:

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

DISPATCH-767 - Added code to support multi frame message streaming

1. Added new core API function qdr_deliver_continue() that will continue
delivering a large message
2. Modified qdr_link_process_deliveries() to not remove deliveries from
the undelivered list until they are fully delivered
3. Modified qd_message_receive() to recieve partial messages.
4. Modified qd_message_send() to be able to handle streaming send. This
function can now be called multiple times for the same message. It keeps
internal pointers to the point upto which the message has been sent and
is able to continue where it left off. Message content buffers are freed
as soon as the message has been sent to all recipients.
5. Added peer linkage for large settled deliveries and added a settled
list to handle with abrupt connection terminations when large messages
are being transmitted.
6. Added unit tests to test large messages.

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

$ git pull https://github.com/ganeshmurthy/qpid-dispatch 
DISPATCH-767-SQUASH-1

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

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


commit c9262728dc1a6d1bcdc5a68f4b19f1b9d2221d53
Author: Ganesh Murthy 
Date:   2017-07-05T15:51:06Z

DISPATCH-767 - Added code to support multi frame message streaming
1. Added new core API function qdr_deliver_continue() that will continue
delivering a large message
2. Modified qdr_link_process_deliveries() to not remove deliveries from
the undelivered list until they are fully delivered
3. Modified qd_message_receive() to recieve partial messages.
4. Modified qd_message_send() to be able to handle streaming send. This
function can now be called multiple times for the same message. It keeps
internal pointers to the point upto which the message has been sent and
is able to continue where it left off. Message content buffers are freed
as soon as the message has been sent to all recipients.
5. Added peer linkage for large settled deliveries and added a settled
list to handle with abrupt connection terminations when large messages
are being transmitted.
6. Added unit tests to test large messages.




> Message Cut-Through/Streaming for efficient handling of large messages
> --
>
> Key: DISPATCH-767
> URL: https://issues.apache.org/jira/browse/DISPATCH-767
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Router Node
>Reporter: Ted Ross
>Assignee: Ganesh Murthy
> Fix For: 1.0.0
>
>
> When large, multi-frame messages are sent through the router, there is no 
> need to wait for the entire message to arrive before starting to send it 
> onward.
> This feature causes the router to route the first frame and allow subsequent 
> frames in a delivery to be streamed out in pipeline fashion.  Ideally, the 
> memory usage in the router should only involve pending frames.  This would 
> allow the router to handle arbitrary numbers of concurrent arbitrarily large 
> messages.



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

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

[jira] [Closed] (PROTON-1532) Undefined method "plain" for SASL in Ruby binding

[Alan Conway (JIRA)]

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

Alan Conway closed PROTON-1532.
---
Resolution: Not A Bug

There is not supposed to be a plain() method on the SASL object. Perhaps you 
want to say:

sasl.mechanisms("PLAIN")

This sets the list of allowed SASL mechanisms to "PLAIN"

> Undefined method "plain" for SASL in Ruby binding
> -
>
> Key: PROTON-1532
> URL: https://issues.apache.org/jira/browse/PROTON-1532
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: ruby-binding
> Environment: Centos, Ubuntu
>Reporter: Gregor Berginc
>Assignee: Alan Conway
>
> When I try to connect to an AMQP endpoint using the URL of the form 
> amqp://user:password@host:port, I get an error about a missing "plain" 
> method. This occurs in [this 
> line|https://github.com/apache/qpid-proton/blob/master/proton-c/bindings/ruby/lib/reactor/connector.rb#L91].
>  This error can be reproduced simply using the following code
> {code:ruby}
> 2.3.3 :001 > require "qpid_proton"
>  => true 
> 2.3.3 :002 > transport = Qpid::Proton::Transport.new
>  => # @impl=# @__swigtype__="_p_pn_transport_t", 
> @proton_wrapper=#>> 
> 2.3.3 :003 > sasl = transport.sasl
>  => # @impl=# @__swigtype__="_p_pn_sasl_t">> 
> 2.3.3 :004 > sasl.plain('', '')
> NoMethodError: undefined method `plain' for 
> #
> from (irb):4
> from /usr/share/rvm/rubies/ruby-2.3.3/bin/irb:11:in `'
> {code}
> I have tried in Ubuntu 16.04 installing Proton via system packages and gem 
> 0.10.1 from Rubygems as well as in Centos 7, following the source code 
> install guide.
> I wonder if this method should be exposed by Swig somehow? Python binding 
> does not use it in that way, but it does set the username and password on the 
> connection.



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

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

[GitHub] qpid-dispatch pull request #186: DISPATCH-767 - Added code to support multi ...

[asfgit]

Github user asfgit closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[jira] [Commented] (DISPATCH-767) Message Cut-Through/Streaming for efficient handling of large messages

[ASF subversion and git services (JIRA)]

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

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

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

DISPATCH-767 - Added code to support multi frame message streaming
1. Added new core API function qdr_deliver_continue() that will continue
delivering a large message
2. Modified qdr_link_process_deliveries() to not remove deliveries from
the undelivered list until they are fully delivered
3. Modified qd_message_receive() to recieve partial messages.
4. Modified qd_message_send() to be able to handle streaming send. This
function can now be called multiple times for the same message. It keeps
internal pointers to the point upto which the message has been sent and
is able to continue where it left off. Message content buffers are freed
as soon as the message has been sent to all recipients.
5. Added peer linkage for large settled deliveries and added a settled
list to handle with abrupt connection terminations when large messages
are being transmitted.
6. Added unit tests to test large messages.


> Message Cut-Through/Streaming for efficient handling of large messages
> --
>
> Key: DISPATCH-767
> URL: https://issues.apache.org/jira/browse/DISPATCH-767
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Router Node
>Reporter: Ted Ross
>Assignee: Ganesh Murthy
> Fix For: 1.0.0
>
>
> When large, multi-frame messages are sent through the router, there is no 
> need to wait for the entire message to arrive before starting to send it 
> onward.
> This feature causes the router to route the first frame and allow subsequent 
> frames in a delivery to be streamed out in pipeline fashion.  Ideally, the 
> memory usage in the router should only involve pending frames.  This would 
> allow the router to handle arbitrary numbers of concurrent arbitrarily large 
> messages.



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

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

[jira] [Commented] (DISPATCH-767) Message Cut-Through/Streaming for efficient handling of large messages

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on DISPATCH-767:
-

Github user asfgit closed the pull request at:

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


> Message Cut-Through/Streaming for efficient handling of large messages
> --
>
> Key: DISPATCH-767
> URL: https://issues.apache.org/jira/browse/DISPATCH-767
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Router Node
>Reporter: Ted Ross
>Assignee: Ganesh Murthy
> Fix For: 1.0.0
>
>
> When large, multi-frame messages are sent through the router, there is no 
> need to wait for the entire message to arrive before starting to send it 
> onward.
> This feature causes the router to route the first frame and allow subsequent 
> frames in a delivery to be streamed out in pipeline fashion.  Ideally, the 
> memory usage in the router should only involve pending frames.  This would 
> allow the router to handle arbitrary numbers of concurrent arbitrarily large 
> messages.



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

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

[jira] [Resolved] (DISPATCH-767) Message Cut-Through/Streaming for efficient handling of large messages

[Ganesh Murthy (JIRA)]

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

Ganesh Murthy resolved DISPATCH-767.

Resolution: Fixed

> Message Cut-Through/Streaming for efficient handling of large messages
> --
>
> Key: DISPATCH-767
> URL: https://issues.apache.org/jira/browse/DISPATCH-767
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Router Node
>Reporter: Ted Ross
>Assignee: Ganesh Murthy
> Fix For: 1.0.0
>
>
> When large, multi-frame messages are sent through the router, there is no 
> need to wait for the entire message to arrive before starting to send it 
> onward.
> This feature causes the router to route the first frame and allow subsequent 
> frames in a delivery to be streamed out in pipeline fashion.  Ideally, the 
> memory usage in the router should only involve pending frames.  This would 
> allow the router to handle arbitrary numbers of concurrent arbitrarily large 
> messages.



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

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

[jira] [Resolved] (DISPATCH-788) Create peer linkage for presettled deliveries so we can use this to handle muticast dispositions

[Ganesh Murthy (JIRA)]

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

Ganesh Murthy resolved DISPATCH-788.

Resolution: Fixed

> Create peer linkage for presettled deliveries so we can use this to handle 
> muticast dispositions
> 
>
> Key: DISPATCH-788
> URL: https://issues.apache.org/jira/browse/DISPATCH-788
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Container
>Affects Versions: 0.8.0
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
> Fix For: 1.0.0
>
>
> Right now peer delivieries are not created for presettled messages. Create 
> peers for presettled messages so that this feature can be used to implement 
> several features like message streaming, handling multicast dispositions etc.



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

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

[jira] [Assigned] (PROTON-448) Ruby bindings need to have their set calls updated to properly map values to pn_data_t*

[Alan Conway (JIRA)]

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

Alan Conway reassigned PROTON-448:
--

Assignee: Alan Conway

> Ruby bindings need to have their set calls updated to properly map values to 
> pn_data_t*
> ---
>
> Key: PROTON-448
> URL: https://issues.apache.org/jira/browse/PROTON-448
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: ruby-binding
>Affects Versions: 0.5
>Reporter: Darryl L. Pierce
>Assignee: Alan Conway
> Fix For: Future
>
>
> When using the APIs in Qpid::Proton::Data I'm seeing:
> irb(main):001:0> require 'qpid_proton'
> => true
> irb(main):002:0> data = Qpid::Proton::Data.new
> => #
> irb(main):003:0> data.ubyte = 3
> value=3
> TypeError: Expected argument 0 of type pn_data_t *, but got Fixnum 16
>   in SWIG method 'pn_data_put_ubyte'
>   from 
> /home/mcpierce/Programming/Proton/proton-c/bindings/ruby/lib/qpid_proton/data.rb:437:in
>  `pn_data_put_ubyte'
>   from 
> /home/mcpierce/Programming/Proton/proton-c/bindings/ruby/lib/qpid_proton/data.rb:437:in
>  `ubyte='
>   from (irb):3
>   from /usr/bin/irb:12:in `'



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

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

[jira] [Closed] (PROTON-1399) messenger does not raise any exception when error happened

[Alan Conway (JIRA)]

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

Alan Conway closed PROTON-1399.
---
Resolution: Won't Fix

The Messenger is being deprecated in favour of the Container class. Container 
events contain complete information about error conditions.

> messenger does not raise any exception when error happened
> --
>
> Key: PROTON-1399
> URL: https://issues.apache.org/jira/browse/PROTON-1399
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: ruby-binding
>Reporter: Wenjie Guo
>Assignee: Alan Conway
>
> {quote}
> [0x1089c90]:  -> AMQP
> [0x1089c90]:0 -> @open(16) 
> [container-id="305A5B5D-0E5B-4E2A-A3CD-0C3ECDFEFA5C", hostname="broker.com", 
> channel-max=32767]
> [0x1089c90]:0 -> @begin(17) [next-outgoing-id=0, incoming-window=2147483647, 
> outgoing-window=2147483647]
> [0x1089c90]:0 -> @attach(18) [name="queue://test-queue", handle=0, role=true, 
> snd-settle-mode=0, rcv-settle-mode=0, source=@source(40) 
> [address="queue://test-queue", durable=0, timeout=0, dynamic=false], 
> target=@target(41) [address="queue://test-queue", durable=0, timeout=0, 
> dynamic=false], initial-delivery-count=0]
> [0x1089c90]:0 -> @flow(19) [incoming-window=2147483647, next-outgoing-id=0, 
> outgoing-window=2147483647, handle=0, delivery-count=0, link-credit=1, 
> drain=false]
> [0x1089c90]:  <- AMQP
> [0x1089c90]:0 <- @open(16) [container-id="broker", hostname="", 
> max-frame-size=4294967295, channel-max=32767, idle-time-out=15000, 
> offered-capabilities=@PN_SYMBOL[:"ANONYMOUS-RELAY"], 
> properties={:product="ActiveMQ", :platform="Java/1.7.0_85", 
> :"topic-prefix"="topic://", :"queue-prefix"="queue://"}]
> [0x1089c90]:0 <- @begin(17) [remote-channel=0, next-outgoing-id=1, 
> incoming-window=2147483647, outgoing-window=2147483647, handle-max=65535]
> [0x1089c90]:0 <- @attach(18) [name="queue://test-queue", handle=0, 
> role=false, snd-settle-mode=2, rcv-settle-mode=0, target=@target(41) 
> [address="queue://test-queue"], incomplete-unsettled=false, 
> initial-delivery-count=0]
> [0x1089c90]:0 <- @detach(22) [handle=0, closed=true, error=@error(29) 
> [condition=:"amqp:unauthorized-access", description="User xxx is not 
> authorized to read from: queue://test-queue"]]
> [0x1089c90]:0 -> @detach(22) [handle=0, closed=true]
> {quote}
> @<- @detach(22) shows there is error happened, 
> error=@error(29) [condition=:"amqp:unauthorized-access", description="User 
> xxx is not authorized to read from: queue://test-queue"]]
> but we cannot catch exception on *messenger.start* or *messenger.send*.
> and even invoke messenger.error, there is nil.  please help to check.



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

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

[jira] [Commented] (PROTON-1532) Undefined method "plain" for SASL in Ruby binding

[Gregor Berginc (JIRA)]

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

Gregor Berginc commented on PROTON-1532:


I agree, however the current ruby binding uses this 
[here|https://github.com/apache/qpid-proton/blob/master/proton-c/bindings/ruby/lib/reactor/connector.rb#L91].

In the meantime I further analysed Python binding and C code and I managed to 
get it working. Not fully tested yet, but it's a start. I extended SASL, 
Connector and Connection classes as well as changed the connect method to be 
more like the one in Python - in particular enable the insecure mechanisms.

I can share a PR if that is an appropriate way?

> Undefined method "plain" for SASL in Ruby binding
> -
>
> Key: PROTON-1532
> URL: https://issues.apache.org/jira/browse/PROTON-1532
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: ruby-binding
> Environment: Centos, Ubuntu
>Reporter: Gregor Berginc
>Assignee: Alan Conway
>
> When I try to connect to an AMQP endpoint using the URL of the form 
> amqp://user:password@host:port, I get an error about a missing "plain" 
> method. This occurs in [this 
> line|https://github.com/apache/qpid-proton/blob/master/proton-c/bindings/ruby/lib/reactor/connector.rb#L91].
>  This error can be reproduced simply using the following code
> {code:ruby}
> 2.3.3 :001 > require "qpid_proton"
>  => true 
> 2.3.3 :002 > transport = Qpid::Proton::Transport.new
>  => # @impl=# @__swigtype__="_p_pn_transport_t", 
> @proton_wrapper=#>> 
> 2.3.3 :003 > sasl = transport.sasl
>  => # @impl=# @__swigtype__="_p_pn_sasl_t">> 
> 2.3.3 :004 > sasl.plain('', '')
> NoMethodError: undefined method `plain' for 
> #
> from (irb):4
> from /usr/share/rvm/rubies/ruby-2.3.3/bin/irb:11:in `'
> {code}
> I have tried in Ubuntu 16.04 installing Proton via system packages and gem 
> 0.10.1 from Rubygems as well as in Centos 7, following the source code 
> install guide.
> I wonder if this method should be exposed by Swig somehow? Python binding 
> does not use it in that way, but it does set the username and password on the 
> connection.



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

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

[jira] [Updated] (PROTON-448) Ruby bindings need to have their set calls updated to properly map values to pn_data_t*

[Alan Conway (JIRA)]

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

Alan Conway updated PROTON-448:
---
Fix Version/s: (was: Future)
   proton-c-0.18.0

> Ruby bindings need to have their set calls updated to properly map values to 
> pn_data_t*
> ---
>
> Key: PROTON-448
> URL: https://issues.apache.org/jira/browse/PROTON-448
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: ruby-binding
>Affects Versions: 0.5
>Reporter: Darryl L. Pierce
>Assignee: Alan Conway
> Fix For: proton-c-0.18.0
>
>
> When using the APIs in Qpid::Proton::Data I'm seeing:
> irb(main):001:0> require 'qpid_proton'
> => true
> irb(main):002:0> data = Qpid::Proton::Data.new
> => #
> irb(main):003:0> data.ubyte = 3
> value=3
> TypeError: Expected argument 0 of type pn_data_t *, but got Fixnum 16
>   in SWIG method 'pn_data_put_ubyte'
>   from 
> /home/mcpierce/Programming/Proton/proton-c/bindings/ruby/lib/qpid_proton/data.rb:437:in
>  `pn_data_put_ubyte'
>   from 
> /home/mcpierce/Programming/Proton/proton-c/bindings/ruby/lib/qpid_proton/data.rb:437:in
>  `ubyte='
>   from (irb):3
>   from /usr/bin/irb:12:in `'



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

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

[jira] [Updated] (PROTON-1079) Ruby Reactor interface fails with SSL.new ArgumentError

[Alan Conway (JIRA)]

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

Alan Conway updated PROTON-1079:

Fix Version/s: (was: Future)
   proton-c-0.18.0

> Ruby Reactor interface fails with SSL.new ArgumentError
> ---
>
> Key: PROTON-1079
> URL: https://issues.apache.org/jira/browse/PROTON-1079
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: ruby-binding
>Affects Versions: 0.12.0
> Environment: Fresh checkout of master (#32fa7cb059). I believe this 
> is happening in any released branch as well.
> Trying to connect to Azure Event Hubs using amqps.
>Reporter: Philippe Le Rohellec
>Assignee: Alan Conway
> Fix For: proton-c-0.18.0
>
>
> Using the vanilla qpid-proton/examples/ruby/reactor/simple_recv.rb. I get the 
> following stacktrace:
> $ ./simple_recv.rb -a 
> 'amqps://eh01-manage:@plrtest-02.servicebus.windows.net/eh01/ConsumerGroups/qpid01/Partitions/1'
>  -m 1 
> /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/core/ssl.rb:104:in
>  `initialize': wrong number of arguments (2 for 4) (ArgumentError)
> from 
> /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/reactor/connector.rb:84:in
>  `new'
> from 
> /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/reactor/connector.rb:84:in
>  `connect'
> from 
> /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/reactor/connector.rb:37:in
>  `on_connection_local_open'
> from 
> /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/event/event_base.rb:26:in
>  `dispatch'
> from 
> /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/event/event.rb:212:in
>  `dispatch'
> from 
> /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/reactor/global_overrides.rb:36:in
>  `override?'
> from 
> /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/reactor/global_overrides.rb:29:in
>  `on_unhandled'
> from 
> /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/event/event_base.rb:28:in
>  `dispatch'
> from 
> /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/event/event.rb:212:in
>  `dispatch'
> from 
> /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/handler/c_adaptor.rb:34:in
>  `dispatch'
> from 
> /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/reactor/reactor.rb:137:in
>  `pn_reactor_process'
> from 
> /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/reactor/reactor.rb:137:in
>  `process'
> from 
> /usr/local/rvm/gems/ruby-1.9.3-p484-railsexpress/gems/qpid_proton-0.3/lib/reactor/reactor.rb:120:in
>  `run'
> from ./simple_recv.rb:57:in `'
> Connector calls "Qpid::Proton::SSL.new(transport, @ssl_domain)" but the SSL 
> constructor takes 4 arguments (and is private).
> I tried replacing the SSL.new call by SSL.create which takes transport and 
> domain but the domain it expects is an SSLDomain instance while the domain 
> passed by the connector is a Qpid::Proton::Reactor::SessionPerConnection.
> I can't figure out why the connector.ssl_domain is assigned to a 
> SessionPerConnection instance.



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

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

[jira] [Assigned] (PROTON-447) Ruby types returned from Data should carry their AMQP type

[Alan Conway (JIRA)]

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

Alan Conway reassigned PROTON-447:
--

Assignee: Alan Conway

> Ruby types returned from Data should carry their AMQP type
> --
>
> Key: PROTON-447
> URL: https://issues.apache.org/jira/browse/PROTON-447
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: ruby-binding
>Reporter: Darryl L. Pierce
>Assignee: Alan Conway
> Fix For: proton-c-0.18.0
>
>
> When a value is pulled out of a Qpid::Proton::Data type, such as a float or 
> integer, it should somehow carry with it its AMQP type. So, for example, if 
> the value returned is a ulong (represented as a Fixnum) then that should be 
> attached to the Fixnum so that it can potentially be put back into another 
> Data instance without losing that detail.



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

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

[jira] [Updated] (PROTON-447) Ruby types returned from Data should carry their AMQP type

[Alan Conway (JIRA)]

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

Alan Conway updated PROTON-447:
---
Fix Version/s: (was: Future)
   proton-c-0.18.0

> Ruby types returned from Data should carry their AMQP type
> --
>
> Key: PROTON-447
> URL: https://issues.apache.org/jira/browse/PROTON-447
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: ruby-binding
>Reporter: Darryl L. Pierce
>Assignee: Alan Conway
> Fix For: proton-c-0.18.0
>
>
> When a value is pulled out of a Qpid::Proton::Data type, such as a float or 
> integer, it should somehow carry with it its AMQP type. So, for example, if 
> the value returned is a ulong (represented as a Fixnum) then that should be 
> attached to the Fixnum so that it can potentially be put back into another 
> Data instance without losing that detail.



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

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

[jira] [Created] (PROTON-1537) ruby: update API in line with new C++ API changes

[Alan Conway (JIRA)]

Alan Conway created PROTON-1537:
---

 Summary: ruby: update API in line with new C++ API changes
 Key: PROTON-1537
 URL: https://issues.apache.org/jira/browse/PROTON-1537
 Project: Qpid Proton
  Issue Type: Bug
  Components: ruby-binding
Affects Versions: 0.17.0
Reporter: Alan Conway
Assignee: Alan Conway
 Fix For: proton-c-0.18.0


Update the ruby Container interface in line with the new C++ container API
Deprecate Reactor (use Container instead)
Deprecate or remove Messenger API.



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

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

[jira] [Commented] (QPID-7781) [Java Broker] 500 error whilst deleting a virtualhost.

[Keith Wall (JIRA)]

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

Keith Wall commented on QPID-7781:
--

Changes look good.

One comment - on {{showVirtualHostNode.js}} shouldn't the Add Virtual Host 
button appear next to the VirtualHost grid, rather than with the 
VirtualHostNode controls.  Wouldn't that follow the UI 's conventions better?

> [Java Broker] 500 error whilst deleting a virtualhost.
> --
>
> Key: QPID-7781
> URL: https://issues.apache.org/jira/browse/QPID-7781
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Lorenz Quack
>Assignee: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
>
> The following 500 was encountered whilst deleting a JSON/Derby store backed 
> virtualhostnode/virtualhost.  The virtualhost had three messages on two 
> queues.  Clients were connected to the queues at the time (stopped on a 
> breakpoint).  The Broker did not crash.
> This will probably be just a trunk issue.
> {noformat}
> 2017-05-12 15:28:34,596 ERROR [HttpManagement-HTTP-89] 
> (o.a.q.s.m.p.f.ExceptionHandlingFilter) - Unexpected exception in servlet 
> '/api/latest/virtualhostnode':
> java.lang.IllegalStateException: Message store is not open
> at 
> org.apache.qpid.server.store.derby.AbstractDerbyMessageStore.checkMessageStoreOpen(AbstractDerbyMessageStore.java:117)
> at 
> org.apache.qpid.server.store.derby.DerbyMessageStore.getConnection(DerbyMessageStore.java:57)
> at 
> org.apache.qpid.server.virtualhost.derby.DerbyVirtualHostImpl.getConnection(DerbyVirtualHostImpl.java:111)
> at 
> org.apache.qpid.server.protocol.v1_0.store.jdbc.JDBCLinkStore.getConnection(JDBCLinkStore.java:224)
> at 
> org.apache.qpid.server.protocol.v1_0.store.jdbc.JDBCLinkStore.doDelete(JDBCLinkStore.java:189)
> at 
> org.apache.qpid.server.protocol.v1_0.store.AbstractLinkStore.delete(AbstractLinkStore.java:122)
> at 
> org.apache.qpid.server.protocol.v1_0.LinkRegistryImpl.delete(LinkRegistryImpl.java:136)
> at 
> org.apache.qpid.server.virtualhost.AbstractVirtualHost$13.run(AbstractVirtualHost.java:2233)
> at 
> org.apache.qpid.server.model.AbstractConfiguredObject$21.onSuccess(AbstractConfiguredObject.java:2587)
> at 
> org.apache.qpid.server.model.AbstractConfiguredObject$22$1.run(AbstractConfiguredObject.java:2628)
> at 
> org.apache.qpid.server.model.AbstractConfiguredObject$22$1.run(AbstractConfiguredObject.java:2624)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at 
> org.apache.qpid.server.model.AbstractConfiguredObject$22.onSuccess(AbstractConfiguredObject.java:2623)
> at com.google.common.util.concurrent.Futures$6.run(Futures.java:1319)
> at 
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$ImmediateIfSameThreadExecutor.execute(TaskExecutorImpl.java:392)
> at 
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.execute(TaskExecutorImpl.java:175)
> at 
> com.google.common.util.concurrent.ExecutionList.executeListener(ExecutionList.java:156)
> at 
> com.google.common.util.concurrent.ExecutionList.execute(ExecutionList.java:145)
> at 
> com.google.common.util.concurrent.AbstractFuture.set(AbstractFuture.java:185)
> at 
> com.google.common.util.concurrent.SettableFuture.set(SettableFuture.java:53)
> at 
> org.apache.qpid.server.model.AbstractConfiguredObject$2$1.onSuccess(AbstractConfiguredObject.java:641)
> at 
> org.apache.qpid.server.model.AbstractConfiguredObject$22$1.run(AbstractConfiguredObject.java:2628)
> at 
> org.apache.qpid.server.model.AbstractConfiguredObject$22$1.run(AbstractConfiguredObject.java:2624)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at 
> org.apache.qpid.server.model.AbstractConfiguredObject$22.onSuccess(AbstractConfiguredObject.java:2623)
> at com.google.common.util.concurrent.Futures$6.run(Futures.java:1319)
> at 
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$ImmediateIfSameThreadExecutor.execute(TaskExecutorImpl.java:392)
> at 
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.execute(TaskExecutorImpl.java:175)
> at 
> com.google.common.util.concurrent.ExecutionList.executeListener(ExecutionList.java:156)
> at 
> com.google.common.util.concurrent.ExecutionList.execute(ExecutionList.java:145)
> at 
> com.google.common.util.concurrent.AbstractFuture.set(AbstractFuture.java:185)
> at 
> 

[jira] [Commented] (PROTON-1519) qpid_proton 0.17.0 Ruby gem does not work with Ruby 2.4.1

[Alan Conway (JIRA)]

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

Alan Conway commented on PROTON-1519:
-

I'd like to apply this fix, but I see you closed the pull request. Did you find 
a problem with the fix?

> qpid_proton 0.17.0 Ruby gem does not work with Ruby 2.4.1
> -
>
> Key: PROTON-1519
> URL: https://issues.apache.org/jira/browse/PROTON-1519
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: ruby-binding
>Affects Versions: 0.17.0
> Environment: Ruby 2.4.1 on macOS Sierra 10.12.5
>Reporter: Jason Frey
>Assignee: Alan Conway
>  Labels: patch
> Fix For: proton-c-0.18.0
>
>
> qpid_proton 0.17.0 was built successfully from source with
> {code}
> > cmake -DCMAKE_INSTALL_PREFIX=/usr/local -DLIB_INSTALL_DIR=/usr/local/lib
> > make install
> {code}
> Installing the gem with Ruby 2.4.1 from rubygems.org was successful
> {code}
> > gem install qpid_proton
> Building native extensions.  This could take a while...
> Successfully installed qpid_proton-0.17.0
> 1 gem installed
> {code}
> However, using the gem fails with: "RuntimeError: entry exists for Integer"
> {code}
> > irb
> [1] pry(main)> RUBY_DESCRIPTION
> => "ruby 2.4.1p111 (2017-03-22 revision 58053) [x86_64-darwin15]"
> [2] pry(main)> require 'qpid_proton'
> /Users/jfrey/.gem/ruby/2.4.1/gems/qpid_proton-0.17.0/lib/codec/mapping.rb:99: 
> warning: constant ::Fixnum is deprecated
> /Users/jfrey/.gem/ruby/2.4.1/gems/qpid_proton-0.17.0/lib/codec/mapping.rb:99: 
> warning: constant ::Bignum is deprecated
> RuntimeError: entry exists for Integer
> from (qpid_proton-0.17.0) lib/codec/mapping.rb:55:in `block in initialize'
> (qpid_proton-0.17.0) lib/codec/mapping.rb:54:in `each'
> (qpid_proton-0.17.0) lib/codec/mapping.rb:54:in `initialize'
> (qpid_proton-0.17.0) lib/codec/mapping.rb:99:in `new'
> (qpid_proton-0.17.0) lib/codec/mapping.rb:99:in `'
> (qpid_proton-0.17.0) lib/codec/mapping.rb:20:in `'
> (ruby-2.4.1) lib/ruby/2.4.0/rubygems/core_ext/kernel_require.rb:68:in 
> `require'
> (ruby-2.4.1) lib/ruby/2.4.0/rubygems/core_ext/kernel_require.rb:68:in 
> `require'
> (qpid_proton-0.17.0) lib/qpid_proton.rb:54:in `'
> (ruby-2.4.1) lib/ruby/2.4.0/rubygems/core_ext/kernel_require.rb:133:in 
> `require'
> (ruby-2.4.1) lib/ruby/2.4.0/rubygems/core_ext/kernel_require.rb:133:in 
> `rescue in require'
> (ruby-2.4.1) lib/ruby/2.4.0/rubygems/core_ext/kernel_require.rb:40:in 
> `require'
> (pry):1:in `'
> {code}
> Note that the above steps are all successful with Ruby 2.3.3
> {code}
> > irb
> [1] pry(main)> RUBY_DESCRIPTION
> => "ruby 2.3.3p222 (2016-11-21 revision 56859) [x86_64-darwin15]"
> [2] pry(main)> require 'qpid_proton'
> => true
> [3] pry(main)> Qpid::Proton
> => Qpid::Proton
> {code}



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

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

[GitHub] qpid-proton issue #111: Fix mapping of LONG for Ruby 2.4+

[alanconway]

Github user alanconway commented on the issue:

https://github.com/apache/qpid-proton/pull/111
  
I'd like to apply this fix - why did you close the PR? Did you find a 
problem? Please respond on https://issues.apache.org/jira/browse/PROTON-1519


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[jira] [Commented] (PROTON-1519) qpid_proton 0.17.0 Ruby gem does not work with Ruby 2.4.1

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on PROTON-1519:


Github user alanconway commented on the issue:

https://github.com/apache/qpid-proton/pull/111
  
I'd like to apply this fix - why did you close the PR? Did you find a 
problem? Please respond on https://issues.apache.org/jira/browse/PROTON-1519


> qpid_proton 0.17.0 Ruby gem does not work with Ruby 2.4.1
> -
>
> Key: PROTON-1519
> URL: https://issues.apache.org/jira/browse/PROTON-1519
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: ruby-binding
>Affects Versions: 0.17.0
> Environment: Ruby 2.4.1 on macOS Sierra 10.12.5
>Reporter: Jason Frey
>Assignee: Alan Conway
>  Labels: patch
> Fix For: proton-c-0.18.0
>
>
> qpid_proton 0.17.0 was built successfully from source with
> {code}
> > cmake -DCMAKE_INSTALL_PREFIX=/usr/local -DLIB_INSTALL_DIR=/usr/local/lib
> > make install
> {code}
> Installing the gem with Ruby 2.4.1 from rubygems.org was successful
> {code}
> > gem install qpid_proton
> Building native extensions.  This could take a while...
> Successfully installed qpid_proton-0.17.0
> 1 gem installed
> {code}
> However, using the gem fails with: "RuntimeError: entry exists for Integer"
> {code}
> > irb
> [1] pry(main)> RUBY_DESCRIPTION
> => "ruby 2.4.1p111 (2017-03-22 revision 58053) [x86_64-darwin15]"
> [2] pry(main)> require 'qpid_proton'
> /Users/jfrey/.gem/ruby/2.4.1/gems/qpid_proton-0.17.0/lib/codec/mapping.rb:99: 
> warning: constant ::Fixnum is deprecated
> /Users/jfrey/.gem/ruby/2.4.1/gems/qpid_proton-0.17.0/lib/codec/mapping.rb:99: 
> warning: constant ::Bignum is deprecated
> RuntimeError: entry exists for Integer
> from (qpid_proton-0.17.0) lib/codec/mapping.rb:55:in `block in initialize'
> (qpid_proton-0.17.0) lib/codec/mapping.rb:54:in `each'
> (qpid_proton-0.17.0) lib/codec/mapping.rb:54:in `initialize'
> (qpid_proton-0.17.0) lib/codec/mapping.rb:99:in `new'
> (qpid_proton-0.17.0) lib/codec/mapping.rb:99:in `'
> (qpid_proton-0.17.0) lib/codec/mapping.rb:20:in `'
> (ruby-2.4.1) lib/ruby/2.4.0/rubygems/core_ext/kernel_require.rb:68:in 
> `require'
> (ruby-2.4.1) lib/ruby/2.4.0/rubygems/core_ext/kernel_require.rb:68:in 
> `require'
> (qpid_proton-0.17.0) lib/qpid_proton.rb:54:in `'
> (ruby-2.4.1) lib/ruby/2.4.0/rubygems/core_ext/kernel_require.rb:133:in 
> `require'
> (ruby-2.4.1) lib/ruby/2.4.0/rubygems/core_ext/kernel_require.rb:133:in 
> `rescue in require'
> (ruby-2.4.1) lib/ruby/2.4.0/rubygems/core_ext/kernel_require.rb:40:in 
> `require'
> (pry):1:in `'
> {code}
> Note that the above steps are all successful with Ruby 2.3.3
> {code}
> > irb
> [1] pry(main)> RUBY_DESCRIPTION
> => "ruby 2.3.3p222 (2016-11-21 revision 56859) [x86_64-darwin15]"
> [2] pry(main)> require 'qpid_proton'
> => true
> [3] pry(main)> Qpid::Proton
> => Qpid::Proton
> {code}



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

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

[jira] [Created] (QPID-7886) [Java Broker] [WMC] Expose ability to get a thread dump

[Keith Wall (JIRA)]

Keith Wall created QPID-7886:


 Summary: [Java Broker] [WMC] Expose ability to get a thread dump
 Key: QPID-7886
 URL: https://issues.apache.org/jira/browse/QPID-7886
 Project: Qpid
  Issue Type: Improvement
  Components: Java Broker
Reporter: Keith Wall
Priority: Minor
 Fix For: qpid-java-broker-7.0.0


For support reasons, it is sometimes desirable for operators to collect a 
thread dump from the Broker's JVM.  The operation is already built into the 
REST API, but needs exposing through the UI to simplify its use.



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

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

[jira] [Assigned] (QPID-7886) [Java Broker] [WMC] Expose ability to get a thread dump

[Keith Wall (JIRA)]

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

Keith Wall reassigned QPID-7886:


Assignee: Keith Wall

> [Java Broker] [WMC] Expose ability to get a thread dump
> ---
>
> Key: QPID-7886
> URL: https://issues.apache.org/jira/browse/QPID-7886
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Minor
> Fix For: qpid-java-broker-7.0.0
>
>
> For support reasons, it is sometimes desirable for operators to collect a 
> thread dump from the Broker's JVM.  The operation is already built into the 
> REST API, but needs exposing through the UI to simplify its use.



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

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

[jira] [Updated] (QPID-7886) [Java Broker] [WMC] Expose ability to get a thread dump

[Keith Wall (JIRA)]

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

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

> [Java Broker] [WMC] Expose ability to get a thread dump
> ---
>
> Key: QPID-7886
> URL: https://issues.apache.org/jira/browse/QPID-7886
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Minor
> Fix For: qpid-java-broker-7.0.0
>
>
> For support reasons, it is sometimes desirable for operators to collect a 
> thread dump from the Broker's JVM.  The operation is already built into the 
> REST API, but needs exposing through the UI to simplify its use.



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

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

[jira] [Commented] (QPID-7886) [Java Broker] [WMC] Expose ability to get a thread dump

[ASF subversion and git services (JIRA)]

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

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

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

QPID-7886: [Java Broker] Expose ability to get a thread dump from the WMC

Also added textual preamble to thread dumps, including the current date/time


> [Java Broker] [WMC] Expose ability to get a thread dump
> ---
>
> Key: QPID-7886
> URL: https://issues.apache.org/jira/browse/QPID-7886
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
>Priority: Minor
> Fix For: qpid-java-broker-7.0.0
>
>
> For support reasons, it is sometimes desirable for operators to collect a 
> thread dump from the Broker's JVM.  The operation is already built into the 
> REST API, but needs exposing through the UI to simplify its use.



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

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

[jira] [Assigned] (QPID-7781) [Java Broker] 500 error whilst deleting a virtualhost.

[Alex Rudyy (JIRA)]

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

Alex Rudyy reassigned QPID-7781:


Assignee: Keith Wall  (was: Alex Rudyy)

> [Java Broker] 500 error whilst deleting a virtualhost.
> --
>
> Key: QPID-7781
> URL: https://issues.apache.org/jira/browse/QPID-7781
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Lorenz Quack
>Assignee: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
>
> The following 500 was encountered whilst deleting a JSON/Derby store backed 
> virtualhostnode/virtualhost.  The virtualhost had three messages on two 
> queues.  Clients were connected to the queues at the time (stopped on a 
> breakpoint).  The Broker did not crash.
> This will probably be just a trunk issue.
> {noformat}
> 2017-05-12 15:28:34,596 ERROR [HttpManagement-HTTP-89] 
> (o.a.q.s.m.p.f.ExceptionHandlingFilter) - Unexpected exception in servlet 
> '/api/latest/virtualhostnode':
> java.lang.IllegalStateException: Message store is not open
> at 
> org.apache.qpid.server.store.derby.AbstractDerbyMessageStore.checkMessageStoreOpen(AbstractDerbyMessageStore.java:117)
> at 
> org.apache.qpid.server.store.derby.DerbyMessageStore.getConnection(DerbyMessageStore.java:57)
> at 
> org.apache.qpid.server.virtualhost.derby.DerbyVirtualHostImpl.getConnection(DerbyVirtualHostImpl.java:111)
> at 
> org.apache.qpid.server.protocol.v1_0.store.jdbc.JDBCLinkStore.getConnection(JDBCLinkStore.java:224)
> at 
> org.apache.qpid.server.protocol.v1_0.store.jdbc.JDBCLinkStore.doDelete(JDBCLinkStore.java:189)
> at 
> org.apache.qpid.server.protocol.v1_0.store.AbstractLinkStore.delete(AbstractLinkStore.java:122)
> at 
> org.apache.qpid.server.protocol.v1_0.LinkRegistryImpl.delete(LinkRegistryImpl.java:136)
> at 
> org.apache.qpid.server.virtualhost.AbstractVirtualHost$13.run(AbstractVirtualHost.java:2233)
> at 
> org.apache.qpid.server.model.AbstractConfiguredObject$21.onSuccess(AbstractConfiguredObject.java:2587)
> at 
> org.apache.qpid.server.model.AbstractConfiguredObject$22$1.run(AbstractConfiguredObject.java:2628)
> at 
> org.apache.qpid.server.model.AbstractConfiguredObject$22$1.run(AbstractConfiguredObject.java:2624)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at 
> org.apache.qpid.server.model.AbstractConfiguredObject$22.onSuccess(AbstractConfiguredObject.java:2623)
> at com.google.common.util.concurrent.Futures$6.run(Futures.java:1319)
> at 
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$ImmediateIfSameThreadExecutor.execute(TaskExecutorImpl.java:392)
> at 
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.execute(TaskExecutorImpl.java:175)
> at 
> com.google.common.util.concurrent.ExecutionList.executeListener(ExecutionList.java:156)
> at 
> com.google.common.util.concurrent.ExecutionList.execute(ExecutionList.java:145)
> at 
> com.google.common.util.concurrent.AbstractFuture.set(AbstractFuture.java:185)
> at 
> com.google.common.util.concurrent.SettableFuture.set(SettableFuture.java:53)
> at 
> org.apache.qpid.server.model.AbstractConfiguredObject$2$1.onSuccess(AbstractConfiguredObject.java:641)
> at 
> org.apache.qpid.server.model.AbstractConfiguredObject$22$1.run(AbstractConfiguredObject.java:2628)
> at 
> org.apache.qpid.server.model.AbstractConfiguredObject$22$1.run(AbstractConfiguredObject.java:2624)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at 
> org.apache.qpid.server.model.AbstractConfiguredObject$22.onSuccess(AbstractConfiguredObject.java:2623)
> at com.google.common.util.concurrent.Futures$6.run(Futures.java:1319)
> at 
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$ImmediateIfSameThreadExecutor.execute(TaskExecutorImpl.java:392)
> at 
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.execute(TaskExecutorImpl.java:175)
> at 
> com.google.common.util.concurrent.ExecutionList.executeListener(ExecutionList.java:156)
> at 
> com.google.common.util.concurrent.ExecutionList.execute(ExecutionList.java:145)
> at 
> com.google.common.util.concurrent.AbstractFuture.set(AbstractFuture.java:185)
> at 
> com.google.common.util.concurrent.SettableFuture.set(SettableFuture.java:53)
> at 
> org.apache.qpid.server.model.AbstractConfiguredObject$5$4.onSuccess(AbstractConfiguredObject.java:808)
> at 
> 

[jira] [Updated] (PROTON-893) Calling session.close() on non-active session causes client segfault

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-893:
---
Summary: Calling session.close() on non-active session causes client 
segfault  (was: Calling the session.close() on non-active session causes client 
seqfault)

> Calling session.close() on non-active session causes client segfault
> 
>
> Key: PROTON-893
> URL: https://issues.apache.org/jira/browse/PROTON-893
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: python-binding
>Affects Versions: 0.9.1
> Environment: packages:
> qpid-proton-c-0.9-3
> qpid-proton-c-devel-0.9-3
> python-qpid-proton-0.9-3
>Reporter: Petr Matousek
>Assignee: Justin Ross
>Priority: Minor
>  Labels: crash, reproducer
> Fix For: proton-c-0.18.0
>
> Attachments: session_close_con.py, session_close_ssn.py, 
> stacktrace.txt
>
>
> Calling the session.close() on non-active session causes client segfault (see 
> the attached reproducer session_close_con.py).
> Moreover calling connection.session().close() causes client seqfault even if 
> the session shall be in active state (see the attached reproducer 
> session_close_ssn.py).



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

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

[jira] [Commented] (QPID-7869) [Java Broker] Truststore improvements

[Alex Rudyy (JIRA)]

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

Alex Rudyy commented on QPID-7869:
--

My review comments
* Improve operational logging for trustore with expired certificates. At the 
moment, for the expired certificates the operational log "Certificate expires 
in 0 days" is issued. I would change it to "Certificate is expired". I think we 
need a ceparate operational log for expired certificate.
* NPE for {{SiteSpecificTrustore}}
* documentation is missed for 
{{qpid.truststore.certificateExpiryCheckFrequency}} and 
{{qpid.truststore.certificateExpiryWarnPeriod}}. It is not obvious that their 
values should be expressed in days.
* On other hand, context variables 
{{qpid.truststore.certificateExpiryCheckFrequency}} and 
{{qpid.truststore.certificateExpiryWarnPeriod}} are affectively are duplicates 
of {{qpid.keystore.certificateExpiryCheckFrequency}} and 
{{qpid.keystore.certificateExpiryWarnPeriod}}. IMHO, it make sense to use one 
set of context variables for both keystores and trustores. Maybe, they could be 
named as 'qpid.certificate.expiryCheckFrequency' and 
'qpid.certificate.expiryWarnPeriod'. I do not see any advatage to have 2 sets 
of conetxt variables
* {{QpidPeersOnlyTrustManager}} declares unused field {{_ts}}. It was there 
before the renaming the field, but, taking that this code was changed as part 
of this JIRA, it makes sense to refactor it farther and remove unused field. 
Addtionally, a constructor of {{QpidPeersOnlyTrustManager}} could be refactored 
to pass a list of trust managers, rather than a trustore.
* Methods {{checkCertificateExpiry()}}, {{getCertificateDetails()}} are pretty 
much the same on trust store implementation. It seems they can be moved into 
{{AbstrauctTrustStore}}, if we introduce a protected method 
getCertificatesInternal() to return the list or an array of cached certificates.
* Alternatively, the above can be achieved bay calling an existing method 
{{getCertificates}} from {{checkCertificateExpiry()}}, 
{{getCertificateDetails()}}, though,  we might need to change the 
implementations of {{getCertificates}}. For example, in 
{{NonJavaTrustStoreImpl}} we load certificates on every invocation (I am not 
convinced that it is the right approach). Perhaps, we should reload it only as 
part of certificate expirary check. The same might apply for 
{{FileTrustStoreImpl}}, {{NonJavaTrustStoreImp}}, etc. The fact, that we check 
only cached versions of certificates but use reloaded certificates in trust 
managers would mean that if certificate on disk is updated whilst broker is 
running we will continue to check validity of previous version of certificate. 
The {{SiteSpecificTrustStore}} returns cached certificates from 
{{getCrtificates}}. It seems we have inconcistent implementations of 
{{getCertificates}} accross trust stores.
* {{SiteSpecificTrustStore}} uses its own executor to refresh certificate. It 
seems that broker house keeping executor could be used for certificate refresh. 
IMHO, it make sense to refresh certificate as part of expiry check.
* {{CertificateGridWidget}}
** IMHO, the name of the widget should be changed to 
{{CertificateDetailsWidget}}
** Taking that it is a new widget, it make sense to use dgrid instead of 
deprecated dojo grid.
** {{CertificateGridWidget.html}} ; dom elements contains class from previous 
implementation used to locate nodes (class="removeCertificates"). 
* {Keystore}
** It make sense to expose certificate data as {{CertificateDetails}}
** Potentially, the certificate details can be displayed in UI using 
{{CertificateGridWidget}}

> [Java Broker] Truststore improvements
> -
>
> Key: QPID-7869
> URL: https://issues.apache.org/jira/browse/QPID-7869
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
>Assignee: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
> Attachments: 
> 0001-QPID-7869-Proof-of-concept-only-validate-the-trust-a.patch
>
>
> The current TrustStore API requires some tidy up/improvements to allow an 
> operator to better manage certificate expiry.
> # Currently the details of certificates contained within the store are not 
> exposed in a uniform manner. {#getCertificateDetails}} should be pulled up 
> and implemented by all truststore types.  I suggest we standardise on the 
> form currently used by 
> {{ManagedPeerCertificateTrustStore#getCertificateDetails}} (i.e. the 
> List).  For the {{SiteSpecificTrustStore}} it should 
> return a singleton list.
> # KeyStores currently warn the user certificate are about to expire via 
> operational log messages.  TrustStores should implement the same feature.
> # For SSL client authentication, we should have a 'strict mode' where the 
> 

[jira] [Commented] (QPID-7869) [Java Broker] Truststore improvements

[ASF subversion and git services (JIRA)]

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

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

Commit 47c64a07543c9a9144bf39a65fce3fe8dc4bae97 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=47c64a0 ]

QPID-7869: Improve trust store implementations

* fix NPE whilst checking expiry in SiteSpecificTrustore
* add documentation to context variables
* Move duplicate code for getCertificateDetails and checkCerificateExpiry into 
AbstractTtrustStore
* Remove unsused field _ts in QpidPeersOnlyTrustManager


> [Java Broker] Truststore improvements
> -
>
> Key: QPID-7869
> URL: https://issues.apache.org/jira/browse/QPID-7869
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
>Assignee: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
> Attachments: 
> 0001-QPID-7869-Proof-of-concept-only-validate-the-trust-a.patch
>
>
> The current TrustStore API requires some tidy up/improvements to allow an 
> operator to better manage certificate expiry.
> # Currently the details of certificates contained within the store are not 
> exposed in a uniform manner. {#getCertificateDetails}} should be pulled up 
> and implemented by all truststore types.  I suggest we standardise on the 
> form currently used by 
> {{ManagedPeerCertificateTrustStore#getCertificateDetails}} (i.e. the 
> List).  For the {{SiteSpecificTrustStore}} it should 
> return a singleton list.
> # KeyStores currently warn the user certificate are about to expire via 
> operational log messages.  TrustStores should implement the same feature.
> # For SSL client authentication, we should have a 'strict mode' where the 
> {{validFrom}}/{{validTo}} date of the peer certificate is validated before 
> the connection is accepted.This will help users utilising self signed 
> certificate for client authentication purpose effectively managed certificate 
> expiration.



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

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

[GitHub] qpid-dispatch pull request #182: DISPATCH-767 - Added code to support multi ...

[ganeshmurthy]

Github user ganeshmurthy closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[jira] [Resolved] (PROTON-1506) Expose max frame size

[Justin Ross (JIRA)]

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

Justin Ross resolved PROTON-1506.
-
Resolution: Fixed

> Expose max frame size
> -
>
> Key: PROTON-1506
> URL: https://issues.apache.org/jira/browse/PROTON-1506
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: python-binding
>Affects Versions: 0.17.0
>Reporter: Justin Ross
>Assignee: Justin Ross
> Fix For: proton-c-0.18.0
>
>
> From Petr Matousek:
> """
> Currently, the python reactive API doesn't have a way for setting the 
> max_frame_size. As other supported clients supports setting the 
> max_frame_size while initializing the connection, the python client should 
> probably expose the setting as well.
> Note: there is a _set_max_frame_size(size) method on Transport object, but 
> the transport object is only available after the connection is opened, which 
> is actually too late for setting the value.
> """



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

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

[jira] [Commented] (PROTON-1506) Expose max frame size

[ASF subversion and git services (JIRA)]

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

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

Commit 9eaca615c5f5aa97d89d1b87471d81bff7237df0 in qpid-proton's branch 
refs/heads/master from [~jr...@redhat.com]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=9eaca61 ]

PROTON-1506: Expose max frame size in the python binding; thanks to Gordon Sim 
for the patch


> Expose max frame size
> -
>
> Key: PROTON-1506
> URL: https://issues.apache.org/jira/browse/PROTON-1506
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: python-binding
>Affects Versions: 0.17.0
>Reporter: Justin Ross
>Assignee: Justin Ross
> Fix For: proton-c-0.18.0
>
>
> From Petr Matousek:
> """
> Currently, the python reactive API doesn't have a way for setting the 
> max_frame_size. As other supported clients supports setting the 
> max_frame_size while initializing the connection, the python client should 
> probably expose the setting as well.
> Note: there is a _set_max_frame_size(size) method on Transport object, but 
> the transport object is only available after the connection is opened, which 
> is actually too late for setting the value.
> """



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

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

[jira] [Updated] (QPID-7869) [Java Broker] Truststore improvements

[Alex Rudyy (JIRA)]

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

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

> [Java Broker] Truststore improvements
> -
>
> Key: QPID-7869
> URL: https://issues.apache.org/jira/browse/QPID-7869
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
>Assignee: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
> Attachments: 
> 0001-QPID-7869-Proof-of-concept-only-validate-the-trust-a.patch
>
>
> The current TrustStore API requires some tidy up/improvements to allow an 
> operator to better manage certificate expiry.
> # Currently the details of certificates contained within the store are not 
> exposed in a uniform manner. {#getCertificateDetails}} should be pulled up 
> and implemented by all truststore types.  I suggest we standardise on the 
> form currently used by 
> {{ManagedPeerCertificateTrustStore#getCertificateDetails}} (i.e. the 
> List).  For the {{SiteSpecificTrustStore}} it should 
> return a singleton list.
> # KeyStores currently warn the user certificate are about to expire via 
> operational log messages.  TrustStores should implement the same feature.
> # For SSL client authentication, we should have a 'strict mode' where the 
> {{validFrom}}/{{validTo}} date of the peer certificate is validated before 
> the connection is accepted.This will help users utilising self signed 
> certificate for client authentication purpose effectively managed certificate 
> expiration.



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

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

[jira] [Resolved] (QPID-7881) [Java Broker] [WMC] Expose broker restart operation through Management Console.

[Alex Rudyy (JIRA)]

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

Alex Rudyy resolved QPID-7881.
--
Resolution: Fixed

The changes look good to me

> [Java Broker] [WMC] Expose broker restart operation through Management 
> Console.
> ---
>
> Key: QPID-7881
> URL: https://issues.apache.org/jira/browse/QPID-7881
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
>Priority: Minor
> Fix For: qpid-java-broker-7.0.0
>
>
> Give the user of the web management console convenient access to the restart 
> broker operation (already exposed by the REST API).  This is useful as some 
> configuration changes require a restart to be applied.



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

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

[jira] [Closed] (PROTON-637) transport does more work than necessary when it has queued deliveries

[Justin Ross (JIRA)]

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

Justin Ross closed PROTON-637.
--
   Resolution: Incomplete
Fix Version/s: (was: proton-c-0.19.0)

Too little info to go on here.  We'll add new tasks based on profiling.

> transport does more work than necessary when it has queued deliveries
> -
>
> Key: PROTON-637
> URL: https://issues.apache.org/jira/browse/PROTON-637
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c, proton-j
>Reporter: Rafael H. Schloming
>Assignee: Alan Conway
>  Labels: perf
>




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

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