[jira] [Updated] (QPID-7379) [Java Broker] Provide a mechanism to extract messages from a vhost message store and replay them into a new vhost

[Rob Godfrey (JIRA)]

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

Rob Godfrey updated QPID-7379:
--
Assignee: Lorenz Quack  (was: Rob Godfrey)

> [Java Broker] Provide a mechanism to extract messages from a vhost message 
> store and replay them into a new vhost
> -
>
> Key: QPID-7379
> URL: https://issues.apache.org/jira/browse/QPID-7379
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Rob Godfrey
>Assignee: Lorenz Quack
> Fix For: qpid-java-6.1
>
>
> QPID-7359 provided operations to extract the config from a virtual host, but 
> there are not currently any mechanisms to extract the contents of the message 
> store and replay that into a new vhost.  We should add this feature to (for 
> example) allow people to migrate their data from one vhost type to another



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (QPID-7379) [Java Broker] Provide a mechanism to extract messages from a vhost message store and replay them into a new vhost

[Rob Godfrey (JIRA)]

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

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

> [Java Broker] Provide a mechanism to extract messages from a vhost message 
> store and replay them into a new vhost
> -
>
> Key: QPID-7379
> URL: https://issues.apache.org/jira/browse/QPID-7379
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Rob Godfrey
>Assignee: Rob Godfrey
> Fix For: qpid-java-6.1
>
>
> QPID-7359 provided operations to extract the config from a virtual host, but 
> there are not currently any mechanisms to extract the contents of the message 
> store and replay that into a new vhost.  We should add this feature to (for 
> example) allow people to migrate their data from one vhost type to another



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[GitHub] qpid-dispatch pull request #104: DISPATCH-521 - Added -v (--version) command...

[ganeshmurthy]

GitHub user ganeshmurthy opened a pull request:

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

DISPATCH-521 - Added -v (--version) command line option to display ve…

…rsion

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

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

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

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


commit 229250155764b2998ba138b57aafcdefba1f5754
Author: Ganesh Murthy 
Date:   2016-09-27T13:54:39Z

DISPATCH-521 - Added -v (--version) command line option to display version




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

[GitHub] qpid-dispatch pull request #105: DISPATCH-492 - Added module parameter to GE...

[ganeshmurthy]

GitHub user ganeshmurthy opened a pull request:

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

DISPATCH-492 - Added module parameter to GET-LOG management operation



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

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

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

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


commit 6e855d6682b99d3a21b9b227555cdcbbf76c4700
Author: Ganesh Murthy 
Date:   2016-09-22T16:49:00Z

DISPATCH-492 - Added module parameter to GET-LOG management operation




---
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-492) Add a way to request logs for a specific module

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on DISPATCH-492:
-

GitHub user ganeshmurthy opened a pull request:

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

DISPATCH-492 - Added module parameter to GET-LOG management operation



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

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

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

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


commit 6e855d6682b99d3a21b9b227555cdcbbf76c4700
Author: Ganesh Murthy 
Date:   2016-09-22T16:49:00Z

DISPATCH-492 - Added module parameter to GET-LOG management operation




> Add a way to request logs for a specific module
> ---
>
> Key: DISPATCH-492
> URL: https://issues.apache.org/jira/browse/DISPATCH-492
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Management Agent
>Reporter: Ernest Allen
>Assignee: Ganesh Murthy
> Fix For: 0.7.0
>
>
> The current GET-LOGS method returns log entries from all module types. 
> The console is then filtering the returned list to get only the entries for a 
> specific module (like log/ERROR, log/AGENT, etc.) 
> It would be more efficient to have a way to specify which module's logs are 
> needed and return only those.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (QPID-7379) [Java Broker] Provide a mechanism to extract messages from a vhost message store and replay them into a new vhost

[Rob Godfrey (JIRA)]

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

Rob Godfrey commented on QPID-7379:
---

{quote}
extraction and import of message store happens in the http thread rather than 
the config thread meaning it could race with other operations (including 
another import/export, reactivation of the VHost, etc.).
{quote}

I believe we are going to find a more generic solution for this so I have no 
yet addressed this concern here

> [Java Broker] Provide a mechanism to extract messages from a vhost message 
> store and replay them into a new vhost
> -
>
> Key: QPID-7379
> URL: https://issues.apache.org/jira/browse/QPID-7379
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Rob Godfrey
>Assignee: Lorenz Quack
> Fix For: qpid-java-6.1
>
>
> QPID-7359 provided operations to extract the config from a virtual host, but 
> there are not currently any mechanisms to extract the contents of the message 
> store and replay that into a new vhost.  We should add this feature to (for 
> example) allow people to migrate their data from one vhost type to another



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (DISPATCH-521) Switch to verify qdrouterd installation

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on DISPATCH-521:
-

Github user ganeshmurthy closed the pull request at:

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


> Switch to verify qdrouterd installation
> ---
>
> Key: DISPATCH-521
> URL: https://issues.apache.org/jira/browse/DISPATCH-521
> Project: Qpid Dispatch
>  Issue Type: Improvement
>Affects Versions: 0.7.0
>Reporter: Jiri Danek
>
> There should be a {{qdrouterd}} switch that can be used to verify that the 
> router is installed correctly. Its success should
> # Give user opportunity to check that PATH is set correctly. It should print 
> full path to itself (qdrouterd binary) in the output.
> # Print router version, so that user can check the version is correct.
> # Ensure that all dynamically loaded libraries are present and qdrouterd can 
> be started.
> # Ensure that PYTHONPATH is set correctly
> Running just {{qdrouterd}} is not sufficient, because port 5672 may be 
> currently occupied. The command fails, even though router is installed 
> correctly.
> Running {{qdrouterd \-h}} is also not adequate. Currently, on my machine, 
> qdrouterd is failing with {{Wed Sep 21 10:03:52 2016 ERROR (error) Python: 
> ImportError: No module named qpid_dispatch_site}} yet {{qdrouterd \-h}} is 
> working just fine.
> I suggest adding a {{--version}} switch that would do what I listed above.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[GitHub] qpid-dispatch pull request #103: DISPATCH-521 - Added a version command line...

[ganeshmurthy]

Github user ganeshmurthy closed the pull request at:

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


---
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] (DISPATCH-521) Switch to verify qdrouterd installation

[Ted Ross (JIRA)]

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

Ted Ross resolved DISPATCH-521.
---
   Resolution: Fixed
Fix Version/s: 0.7.0

> Switch to verify qdrouterd installation
> ---
>
> Key: DISPATCH-521
> URL: https://issues.apache.org/jira/browse/DISPATCH-521
> Project: Qpid Dispatch
>  Issue Type: Improvement
>Affects Versions: 0.7.0
>Reporter: Jiri Danek
>Assignee: Ganesh Murthy
> Fix For: 0.7.0
>
>
> There should be a {{qdrouterd}} switch that can be used to verify that the 
> router is installed correctly. Its success should
> # Give user opportunity to check that PATH is set correctly. It should print 
> full path to itself (qdrouterd binary) in the output.
> # Print router version, so that user can check the version is correct.
> # Ensure that all dynamically loaded libraries are present and qdrouterd can 
> be started.
> # Ensure that PYTHONPATH is set correctly
> Running just {{qdrouterd}} is not sufficient, because port 5672 may be 
> currently occupied. The command fails, even though router is installed 
> correctly.
> Running {{qdrouterd \-h}} is also not adequate. Currently, on my machine, 
> qdrouterd is failing with {{Wed Sep 21 10:03:52 2016 ERROR (error) Python: 
> ImportError: No module named qpid_dispatch_site}} yet {{qdrouterd \-h}} is 
> working just fine.
> I suggest adding a {{--version}} switch that would do what I listed above.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (DISPATCH-521) Switch to verify qdrouterd installation

[Ted Ross (JIRA)]

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

Ted Ross updated DISPATCH-521:
--
Assignee: Ganesh Murthy

> Switch to verify qdrouterd installation
> ---
>
> Key: DISPATCH-521
> URL: https://issues.apache.org/jira/browse/DISPATCH-521
> Project: Qpid Dispatch
>  Issue Type: Improvement
>Affects Versions: 0.7.0
>Reporter: Jiri Danek
>Assignee: Ganesh Murthy
> Fix For: 0.7.0
>
>
> There should be a {{qdrouterd}} switch that can be used to verify that the 
> router is installed correctly. Its success should
> # Give user opportunity to check that PATH is set correctly. It should print 
> full path to itself (qdrouterd binary) in the output.
> # Print router version, so that user can check the version is correct.
> # Ensure that all dynamically loaded libraries are present and qdrouterd can 
> be started.
> # Ensure that PYTHONPATH is set correctly
> Running just {{qdrouterd}} is not sufficient, because port 5672 may be 
> currently occupied. The command fails, even though router is installed 
> correctly.
> Running {{qdrouterd \-h}} is also not adequate. Currently, on my machine, 
> qdrouterd is failing with {{Wed Sep 21 10:03:52 2016 ERROR (error) Python: 
> ImportError: No module named qpid_dispatch_site}} yet {{qdrouterd \-h}} is 
> working just fine.
> I suggest adding a {{--version}} switch that would do what I listed above.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (QPID-7379) [Java Broker] Provide a mechanism to extract messages from a vhost message store and replay them into a new vhost

[ASF subversion and git services (JIRA)]

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

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

Commit 1762490 from [~godfrer] in branch 'java/trunk'
[ https://svn.apache.org/r1762490 ]

QPID-7379 : Address review comments

> [Java Broker] Provide a mechanism to extract messages from a vhost message 
> store and replay them into a new vhost
> -
>
> Key: QPID-7379
> URL: https://issues.apache.org/jira/browse/QPID-7379
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Rob Godfrey
>Assignee: Rob Godfrey
> Fix For: qpid-java-6.1
>
>
> QPID-7359 provided operations to extract the config from a virtual host, but 
> there are not currently any mechanisms to extract the contents of the message 
> store and replay that into a new vhost.  We should add this feature to (for 
> example) allow people to migrate their data from one vhost type to another



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (QPID-7379) [Java Broker] Provide a mechanism to extract messages from a vhost message store and replay them into a new vhost

[Rob Godfrey (JIRA)]

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

Rob Godfrey commented on QPID-7379:
---

{quote}
I was under the impression that qpid.max_message_size is a mechanism to 
(amongst other things) prevent a broker from going OOM due to large messages 
exceeding memory limitations. Would it then not make sense to reject message 
stores with large messages instead of accepting them and then crashing with OOM?
{quote}

The existence of messages in the store that are greater in size than the 
current max message size could also be caused by a later reduction of the max 
message size after a message had previously been deemed acceptable.  I think we 
should treat the extract in the same way that we would the underlying store - 
the underlying store may contain arbitrarily large messages, and we would just 
accept them.

{quote}
What I meant was on serialisation we could copy the data from the message 
directly to the output stream without first copying it to the interal _content 
field by holding on to a reference to the StoredMessage in the constructor. I 
did not appreciate the deserialisation path where this does not seem possible 
and then the additional complication is probably not worth it.
{quote}

I think the best approach here would be to change the interface of record to 
maybe write to an OutputStream-like object - I have made this change in my 
latest commit

> [Java Broker] Provide a mechanism to extract messages from a vhost message 
> store and replay them into a new vhost
> -
>
> Key: QPID-7379
> URL: https://issues.apache.org/jira/browse/QPID-7379
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Rob Godfrey
>Assignee: Rob Godfrey
> Fix For: qpid-java-6.1
>
>
> QPID-7359 provided operations to extract the config from a virtual host, but 
> there are not currently any mechanisms to extract the contents of the message 
> store and replay that into a new vhost.  We should add this feature to (for 
> example) allow people to migrate their data from one vhost type to another



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (DISPATCH-521) Switch to verify qdrouterd installation

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on DISPATCH-521:
-

GitHub user ganeshmurthy opened a pull request:

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

DISPATCH-521 - Added -v (--version) command line option to display ve…

…rsion

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

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

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

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


commit 229250155764b2998ba138b57aafcdefba1f5754
Author: Ganesh Murthy 
Date:   2016-09-27T13:54:39Z

DISPATCH-521 - Added -v (--version) command line option to display version




> Switch to verify qdrouterd installation
> ---
>
> Key: DISPATCH-521
> URL: https://issues.apache.org/jira/browse/DISPATCH-521
> Project: Qpid Dispatch
>  Issue Type: Improvement
>Affects Versions: 0.7.0
>Reporter: Jiri Danek
>
> There should be a {{qdrouterd}} switch that can be used to verify that the 
> router is installed correctly. Its success should
> # Give user opportunity to check that PATH is set correctly. It should print 
> full path to itself (qdrouterd binary) in the output.
> # Print router version, so that user can check the version is correct.
> # Ensure that all dynamically loaded libraries are present and qdrouterd can 
> be started.
> # Ensure that PYTHONPATH is set correctly
> Running just {{qdrouterd}} is not sufficient, because port 5672 may be 
> currently occupied. The command fails, even though router is installed 
> correctly.
> Running {{qdrouterd \-h}} is also not adequate. Currently, on my machine, 
> qdrouterd is failing with {{Wed Sep 21 10:03:52 2016 ERROR (error) Python: 
> ImportError: No module named qpid_dispatch_site}} yet {{qdrouterd \-h}} is 
> working just fine.
> I suggest adding a {{--version}} switch that would do what I listed above.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (DISPATCH-521) Switch to verify qdrouterd installation

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on DISPATCH-521:
-

Github user asfgit closed the pull request at:

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


> Switch to verify qdrouterd installation
> ---
>
> Key: DISPATCH-521
> URL: https://issues.apache.org/jira/browse/DISPATCH-521
> Project: Qpid Dispatch
>  Issue Type: Improvement
>Affects Versions: 0.7.0
>Reporter: Jiri Danek
>
> There should be a {{qdrouterd}} switch that can be used to verify that the 
> router is installed correctly. Its success should
> # Give user opportunity to check that PATH is set correctly. It should print 
> full path to itself (qdrouterd binary) in the output.
> # Print router version, so that user can check the version is correct.
> # Ensure that all dynamically loaded libraries are present and qdrouterd can 
> be started.
> # Ensure that PYTHONPATH is set correctly
> Running just {{qdrouterd}} is not sufficient, because port 5672 may be 
> currently occupied. The command fails, even though router is installed 
> correctly.
> Running {{qdrouterd \-h}} is also not adequate. Currently, on my machine, 
> qdrouterd is failing with {{Wed Sep 21 10:03:52 2016 ERROR (error) Python: 
> ImportError: No module named qpid_dispatch_site}} yet {{qdrouterd \-h}} is 
> working just fine.
> I suggest adding a {{--version}} switch that would do what I listed above.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (DISPATCH-521) Switch to verify qdrouterd installation

[ASF subversion and git services (JIRA)]

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

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

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

DISPATCH-521 - Added -v (--version) command line option to display version


> Switch to verify qdrouterd installation
> ---
>
> Key: DISPATCH-521
> URL: https://issues.apache.org/jira/browse/DISPATCH-521
> Project: Qpid Dispatch
>  Issue Type: Improvement
>Affects Versions: 0.7.0
>Reporter: Jiri Danek
>
> There should be a {{qdrouterd}} switch that can be used to verify that the 
> router is installed correctly. Its success should
> # Give user opportunity to check that PATH is set correctly. It should print 
> full path to itself (qdrouterd binary) in the output.
> # Print router version, so that user can check the version is correct.
> # Ensure that all dynamically loaded libraries are present and qdrouterd can 
> be started.
> # Ensure that PYTHONPATH is set correctly
> Running just {{qdrouterd}} is not sufficient, because port 5672 may be 
> currently occupied. The command fails, even though router is installed 
> correctly.
> Running {{qdrouterd \-h}} is also not adequate. Currently, on my machine, 
> qdrouterd is failing with {{Wed Sep 21 10:03:52 2016 ERROR (error) Python: 
> ImportError: No module named qpid_dispatch_site}} yet {{qdrouterd \-h}} is 
> working just fine.
> I suggest adding a {{--version}} switch that would do what I listed above.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[GitHub] qpid-dispatch pull request #104: DISPATCH-521 - Added -v (--version) command...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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] (QPID-7409) Support preview of maps/list message content

[ASF subversion and git services (JIRA)]

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

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

Commit 1762460 from [~lorenz.quack] in branch 'java/trunk'
[ https://svn.apache.org/r1762460 ]

QPID-7409: [Java Broker] Move responsibility to limit message content to 
ManagedOperation getMessageContent

* returnJson always returns uncompressed data
* new parameter decompressBeforeLimiting (default "false")

> Support preview of maps/list message content
> 
>
> Key: QPID-7409
> URL: https://issues.apache.org/jira/browse/QPID-7409
> Project: Qpid
>  Issue Type: Improvement
>Reporter: Keith Wall
>Assignee: Keith Wall
> Fix For: qpid-java-6.1
>
> Attachments: 
> 0001-QPID-7409-Java-Broker-Move-responsibility-to-limit-m.patch, 
> 0001-QPID-7409-Java-Broker-WMC-Limit-the-message-content-.patch, 
> 0001-QPID-7409-WIP-add-support-for-getting-of-message-con.patch
>
>
> When viewing messages through the web management console, if the message is 
> of type such as a list or map currently the user sees the bytes of the 
> underlying AMQP datastructure.  Instead, the preview area should display the 
> data in a human friendly way.
> The managed operation {{Queue#getMessageContent}} will be enhanced to be 
> capable of returning a message in JSON format if possible with an optional 
> parameter {{returnJson}}.  If rather than returning the message's content 
> bytes directly, it should first convert the message to an {{InternalMessage}} 
> (MessageConverterRegistry.getConverter(serverMessage.getClass, 
> InternalMessage.class).convert(...)) then use the JSON serialiser to serial 
> the MessageBody of the resulting internal message.
> Within the WMC, if the resulting object is of a previewable type (string, 
> map, list etc) and the content is not too long, the content should be added 
> to a scrollable preview pane of the message dialogue by traversing the object 
> tree and producing a human readable representation of its structure and 
> content.  (Perhaps an approach such as 
> https://stackoverflow.com/questions/13341373/render-arbitrary-json-in-html 
> will help)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Resolved] (QPID-7435) Avoid BDB fetching dummy single byte database entries during message instance recovery

[Lorenz Quack (JIRA)]

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

Lorenz Quack resolved QPID-7435.

Resolution: Fixed

looks good to me

> Avoid BDB fetching dummy single byte database entries during message instance 
> recovery
> --
>
> Key: QPID-7435
> URL: https://issues.apache.org/jira/browse/QPID-7435
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
>Assignee: Keith Wall
> Fix For: qpid-java-6.1
>
>
> We represent message instances in BDB as a tuple comprising a key (formed of 
> queue id and message id) and a dummy record (formed of 1 byte).  The dummy 
> record serves no purpose other than to fulfil the contract with JE's 
> Database#put() which cannot accept a null entry value.
> The JE API has a mechanism to instruct a cursor operations to retrieve only 
> the key values.  We can exploit this feature when recovering message 
> instances to suppress the retrieval of the dummy entry.
> On my box, this improves (synchronous) recovery time for a store containing 4 
> queues with 2,000,000 messages from about 1min to about 30seconds.  This 
> should benefit any user who uses BDB and has a large store.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Resolved] (QPID-7437) [BDB] Avoid storing unnecessary single byte with message enqueue records

[Lorenz Quack (JIRA)]

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

Lorenz Quack resolved QPID-7437.

Resolution: Fixed

> [BDB] Avoid storing unnecessary single byte with message enqueue records
> 
>
> Key: QPID-7437
> URL: https://issues.apache.org/jira/browse/QPID-7437
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
>Assignee: Keith Wall
> Fix For: qpid-java-6.1
>
>
> We represent message instances in BDB as a tuple comprising a key (formed of 
> queue id and message id) and a dummy record (currently formed of 1 byte).  
> The reason why we chose to store a single byte dummy byte is unclear as JE 
> supports zero length values.  Storing of the single byte will be causing an 
> unnecessary overhead and should be removed.
> There is no need for a store version change.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (QPID-7379) [Java Broker] Provide a mechanism to extract messages from a vhost message store and replay them into a new vhost

[Lorenz Quack (JIRA)]

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

Lorenz Quack commented on QPID-7379:


{quote}
I think anyone who has sufficient privileges to import a data store probably 
also has all sorts of other ways to bring down the broker. I think the issue 
with qpid.max_message_size is that we don't know that the source host had the 
same or smaller limit. Overall I don't see this as a priority.
{quote}
I was under the impression that {{qpid.max_message_size}} is a mechanism to 
(amongst other things) prevent a broker from going OOM due to large messages 
exceeding memory limitations. Would it then not make sense to reject message 
stores with large messages instead of accepting them and then crashing with OOM?

{quote}
OutputStreams only work with byte[], not ByteBuffers which means heap memory 
has to be used. I don't believe (given the prior constraint) that any 
unnecessary copy is made... on reading the record we read the bytes into an 
array from the output stream. On writing we create an array and copy the data 
from the content into the array. This value is then written to the outputstream.
{quote}
What I meant was on serialisation we could copy the data from the message 
directly to the output stream without first copying it to the interal _content 
field by holding on to a reference to the StoredMessage in the constructor. I 
did not appreciate the deserialisation path where this does not seem possible 
and then the additional complication is probably not worth it.

> [Java Broker] Provide a mechanism to extract messages from a vhost message 
> store and replay them into a new vhost
> -
>
> Key: QPID-7379
> URL: https://issues.apache.org/jira/browse/QPID-7379
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Rob Godfrey
>Assignee: Rob Godfrey
> Fix For: qpid-java-6.1
>
>
> QPID-7359 provided operations to extract the config from a virtual host, but 
> there are not currently any mechanisms to extract the contents of the message 
> store and replay that into a new vhost.  We should add this feature to (for 
> example) allow people to migrate their data from one vhost type to another



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[GitHub] qpid-dispatch pull request #103: DISPATCH-521 - Added a version command line...

[ted-ross]

Github user ted-ross commented on a diff in the pull request:

https://github.com/apache/qpid-dispatch/pull/103#discussion_r80685950
  
--- Diff: CMakeLists.txt ---
@@ -51,6 +51,10 @@ set (SO_VERSION_MAJOR 2)
 set (SO_VERSION_MINOR 0)
 set (SO_VERSION "${SO_VERSION_MAJOR}.${SO_VERSION_MINOR}")
 
+set (QPID_DISPATCH_VERSION_MAJOR 0)
--- End diff --

The CMake file already passes the version from VERSION.txt into the set of 
defined macros in config.h.  I don't think it's desirable to create yet another 
authoritative source-of-version that needs to be maintained manually on each 
release.


---
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] [Created] (QPID-7440) [Java Broker] Stop ProtocolOutputConverterImpl from leaking QpidByteBuffers

[Lorenz Quack (JIRA)]

Lorenz Quack created QPID-7440:
--

 Summary: [Java Broker] Stop ProtocolOutputConverterImpl from 
leaking QpidByteBuffers
 Key: QPID-7440
 URL: https://issues.apache.org/jira/browse/QPID-7440
 Project: Qpid
  Issue Type: Bug
  Components: Java Broker
Affects Versions: qpid-java-6.0, qpid-java-6.0.5, qpid-java-6.1
Reporter: Lorenz Quack


ProtocolOutputConverterImpl seems to leak QBBs in deflateIfPossible and 
inflateIfPossible. Those methods pass QBBs from 
MessageContentSource.getContent() to QBB.deflate/inflate but those methods do 
not take ownership of the buffers so they are not disposed of.

Keith thinks that ownership should remain with the caller and that 
ProtocolOutputConverterImpl should dispose of the QBBs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (DISPATCH-521) Switch to verify qdrouterd installation

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on DISPATCH-521:
-

Github user ted-ross commented on a diff in the pull request:

https://github.com/apache/qpid-dispatch/pull/103#discussion_r80685950
  
--- Diff: CMakeLists.txt ---
@@ -51,6 +51,10 @@ set (SO_VERSION_MAJOR 2)
 set (SO_VERSION_MINOR 0)
 set (SO_VERSION "${SO_VERSION_MAJOR}.${SO_VERSION_MINOR}")
 
+set (QPID_DISPATCH_VERSION_MAJOR 0)
--- End diff --

The CMake file already passes the version from VERSION.txt into the set of 
defined macros in config.h.  I don't think it's desirable to create yet another 
authoritative source-of-version that needs to be maintained manually on each 
release.


> Switch to verify qdrouterd installation
> ---
>
> Key: DISPATCH-521
> URL: https://issues.apache.org/jira/browse/DISPATCH-521
> Project: Qpid Dispatch
>  Issue Type: Improvement
>Affects Versions: 0.7.0
>Reporter: Jiri Danek
>
> There should be a {{qdrouterd}} switch that can be used to verify that the 
> router is installed correctly. Its success should
> # Give user opportunity to check that PATH is set correctly. It should print 
> full path to itself (qdrouterd binary) in the output.
> # Print router version, so that user can check the version is correct.
> # Ensure that all dynamically loaded libraries are present and qdrouterd can 
> be started.
> # Ensure that PYTHONPATH is set correctly
> Running just {{qdrouterd}} is not sufficient, because port 5672 may be 
> currently occupied. The command fails, even though router is installed 
> correctly.
> Running {{qdrouterd \-h}} is also not adequate. Currently, on my machine, 
> qdrouterd is failing with {{Wed Sep 21 10:03:52 2016 ERROR (error) Python: 
> ImportError: No module named qpid_dispatch_site}} yet {{qdrouterd \-h}} is 
> working just fine.
> I suggest adding a {{--version}} switch that would do what I listed above.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (PROTON-1308) Support Idle Timeout setting in electron Transport

[Richard Laos (JIRA)]

Richard Laos created PROTON-1308:


 Summary: Support Idle Timeout setting in electron Transport  
 Key: PROTON-1308
 URL: https://issues.apache.org/jira/browse/PROTON-1308
 Project: Qpid Proton
  Issue Type: Improvement
  Components: go-binding
Affects Versions: 0.15.0
Reporter: Richard Laos
Assignee: Alan Conway
Priority: Minor


It would be nice to be able to set the Idle Timeout property of the electron 
Transport as part of the connection configuration.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (PROTON-1307) go binding amqp.message does not honor Inferred flag

[ASF subversion and git services (JIRA)]

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

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

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

PROTON-1307: go binding amqp.message does not honor Inferred flag

Applied fix provided by Richard Laos for typo in the SetInferred method.


> go binding amqp.message does not honor Inferred flag
> 
>
> Key: PROTON-1307
> URL: https://issues.apache.org/jira/browse/PROTON-1307
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: go-binding
>Affects Versions: 0.15.0
>Reporter: Richard Laos
>Assignee: Alan Conway
>Priority: Minor
>
> Calling SetInferred() has no effect when sending a message using the 
> go-binding. Also, calling Inferred() against amqp.message does not reflect 
> calls to SetInferred(). Looks like the problem is on line 264 in 
> amqp/message.go. I tested the following change:
> {code}
> func (m *message) SetInferred(b bool)  { C.pn_message_set_inferred(m.pn, 
> C.bool(b)) }
> {code}
> Seems to behave as expected afterwards.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Resolved] (PROTON-1307) go binding amqp.message does not honor Inferred flag

[Alan Conway (JIRA)]

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

Alan Conway resolved PROTON-1307.
-
   Resolution: Fixed
Fix Version/s: 0.15.0

Well spotted, thanks for the fix.

> go binding amqp.message does not honor Inferred flag
> 
>
> Key: PROTON-1307
> URL: https://issues.apache.org/jira/browse/PROTON-1307
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: go-binding
>Affects Versions: 0.15.0
>Reporter: Richard Laos
>Assignee: Alan Conway
>Priority: Minor
> Fix For: 0.15.0
>
>
> Calling SetInferred() has no effect when sending a message using the 
> go-binding. Also, calling Inferred() against amqp.message does not reflect 
> calls to SetInferred(). Looks like the problem is on line 264 in 
> amqp/message.go. I tested the following change:
> {code}
> func (m *message) SetInferred(b bool)  { C.pn_message_set_inferred(m.pn, 
> C.bool(b)) }
> {code}
> Seems to behave as expected afterwards.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (QPIDJMS-210) Add documentation for the WebSocket transport

[Timothy Bish (JIRA)]

Timothy Bish created QPIDJMS-210:


 Summary: Add documentation for the WebSocket transport
 Key: QPIDJMS-210
 URL: https://issues.apache.org/jira/browse/QPIDJMS-210
 Project: Qpid JMS
  Issue Type: Task
  Components: qpid-jms-client
Affects Versions: 0.11.0
Reporter: Timothy Bish
Assignee: Timothy Bish
Priority: Trivial
 Fix For: 0.1X.Y, 0.20.0






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (QPIDJMS-210) Add documentation for the WebSocket transport

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on QPIDJMS-210:
-

Commit f19b01cb45ac1c01a5c34ffa7e7ec0a137700b5a in qpid-jms's branch 
refs/heads/master from [~tabish121]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=f19b01c ]

QPIDJMS-210 Add documentation for the WebSocket transport

> Add documentation for the WebSocket transport
> -
>
> Key: QPIDJMS-210
> URL: https://issues.apache.org/jira/browse/QPIDJMS-210
> Project: Qpid JMS
>  Issue Type: Task
>  Components: qpid-jms-client
>Affects Versions: 0.11.0
>Reporter: Timothy Bish
>Assignee: Timothy Bish
>Priority: Trivial
> Fix For: 0.1X.Y, 0.20.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: Review Request 52280: QPID-7439: Proton-based library for QMF management.

[Justin Ross]

> On Sept. 26, 2016, 10:16 p.m., Justin Ross wrote:
> > management/python/lib/qmf/client.py, line 171
> > 
> >
> > Since we're making a fresh start, do we want to use studly method 
> > names?  Unless there's a compatibility reason, I'd go with 
> > this_sort_of_thing instead.
> 
> Alan Conway wrote:
> Actually there is a compat issue - QMF uses mixedCase so changing python 
> props/methods that reflect QMF props/methods would involve trickery and be 
> confusing. If we leave those alone to repsect QMF then making the non-QMF 
> BrokerAgent methods different would be inconsistent. Since QMF Is a legacy 
> thing anyway I'm inclined to just leave it, although I have experience with 
> underscore-wobbleCase conversion from converting dispatch :)
> 
> What do you think?

I agree.  Let's keep it simple and stay with the mixedCase names.


- Justin


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/52280/#review150468
---


On Sept. 27, 2016, 4:01 p.m., Alan Conway wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/52280/
> ---
> 
> (Updated Sept. 27, 2016, 4:01 p.m.)
> 
> 
> Review request for qpid, Brian Bouterse and Justin Ross.
> 
> 
> Bugs: QPID-7439
> https://issues.apache.org/jira/browse/QPID-7439
> 
> 
> Repository: qpid-cpp
> 
> 
> Description
> ---
> 
> qmf.client is a port of qpidtoolibs to the proton AMQP 1.0 client library.
> 
> 
> Diffs
> -
> 
>   management/python/lib/qmf/client.py PRE-CREATION 
>   src/tests/CMakeLists.txt a1a33341f2100f951f9e2465bd1c5325453be0d1 
>   src/tests/qmf_client_tests.py PRE-CREATION 
>   src/tests/run_qmf_client_tests PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/52280/diff/
> 
> 
> Testing
> ---
> 
> New auto-test added, tests creating/deleting/binding/unbinding queues and 
> exchanges.
> 
> 
> Thanks,
> 
> Alan Conway
> 
>

Re: Review Request 52280: QPID-7439: Proton-based library for QMF management.

[Alan Conway]

> On Sept. 26, 2016, 10:16 p.m., Justin Ross wrote:
> > management/python/lib/qmf/client.py, line 171
> > 
> >
> > Since we're making a fresh start, do we want to use studly method 
> > names?  Unless there's a compatibility reason, I'd go with 
> > this_sort_of_thing instead.

Actually there is a compat issue - QMF uses mixedCase so changing python 
props/methods that reflect QMF props/methods would involve trickery and be 
confusing. If we leave those alone to repsect QMF then making the non-QMF 
BrokerAgent methods different would be inconsistent. Since QMF Is a legacy 
thing anyway I'm inclined to just leave it, although I have experience with 
underscore-wobbleCase conversion from converting dispatch :)

What do you think?


- Alan


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/52280/#review150468
---


On Sept. 26, 2016, 9:34 p.m., Alan Conway wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/52280/
> ---
> 
> (Updated Sept. 26, 2016, 9:34 p.m.)
> 
> 
> Review request for qpid, Brian Bouterse and Justin Ross.
> 
> 
> Bugs: QPID-7439
> https://issues.apache.org/jira/browse/QPID-7439
> 
> 
> Repository: qpid-cpp
> 
> 
> Description
> ---
> 
> qmf.client is a port of qpidtoolibs to the proton AMQP 1.0 client library.
> 
> 
> Diffs
> -
> 
>   management/python/lib/qmf/client.py PRE-CREATION 
>   src/tests/CMakeLists.txt a1a33341f2100f951f9e2465bd1c5325453be0d1 
>   src/tests/qmf_client_tests.py PRE-CREATION 
>   src/tests/run_qmf_client_tests PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/52280/diff/
> 
> 
> Testing
> ---
> 
> New auto-test added, tests creating/deleting/binding/unbinding queues and 
> exchanges.
> 
> 
> Thanks,
> 
> Alan Conway
> 
>

Re: Review Request 52280: QPID-7439: Proton-based library for QMF management.

[Alan Conway]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/52280/
---

(Updated Sept. 27, 2016, 4:01 p.m.)


Review request for qpid, Brian Bouterse and Justin Ross.


Changes
---

Added test for fork-safety


Bugs: QPID-7439
https://issues.apache.org/jira/browse/QPID-7439


Repository: qpid-cpp


Description
---

qmf.client is a port of qpidtoolibs to the proton AMQP 1.0 client library.


Diffs (updated)
-

  management/python/lib/qmf/client.py PRE-CREATION 
  src/tests/CMakeLists.txt a1a33341f2100f951f9e2465bd1c5325453be0d1 
  src/tests/qmf_client_tests.py PRE-CREATION 
  src/tests/run_qmf_client_tests PRE-CREATION 

Diff: https://reviews.apache.org/r/52280/diff/


Testing
---

New auto-test added, tests creating/deleting/binding/unbinding queues and 
exchanges.


Thanks,

Alan Conway

[jira] [Resolved] (QPID-7439) Proton-based library for QMF management.

[Alan Conway (JIRA)]

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

Alan Conway resolved QPID-7439.
---
   Resolution: Fixed
Fix Version/s: qpid-cpp-1.36.0

> Proton-based library for QMF management.
> 
>
> Key: QPID-7439
> URL: https://issues.apache.org/jira/browse/QPID-7439
> Project: Qpid
>  Issue Type: Improvement
>  Components: Python Tools
>Affects Versions: qpid-cpp-1.35.0
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: qpid-cpp-1.36.0
>
>
> A proton based python library for doing QMF management, similar to 
> qpidtoollibs. Customers are moving towards AMQP 1.0 clients, and proton based 
> clients have a better future than qpid.messaging. A particular requirement is 
> for the library to be fork-safe so it should not start threads like 
> qpid.messaging does. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: Review Request 52280: QPID-7439: Proton-based library for QMF management.

[Alan Conway]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/52280/
---

(Updated Sept. 27, 2016, 3:30 p.m.)


Review request for qpid, Brian Bouterse and Justin Ross.


Changes
---

Fix Justin's comments except for studly names, see comment.


Bugs: QPID-7439
https://issues.apache.org/jira/browse/QPID-7439


Repository: qpid-cpp


Description
---

qmf.client is a port of qpidtoolibs to the proton AMQP 1.0 client library.


Diffs (updated)
-

  management/python/lib/qmf/client.py PRE-CREATION 
  src/tests/CMakeLists.txt a1a33341f2100f951f9e2465bd1c5325453be0d1 
  src/tests/qmf_client_tests.py PRE-CREATION 
  src/tests/run_qmf_client_tests PRE-CREATION 

Diff: https://reviews.apache.org/r/52280/diff/


Testing
---

New auto-test added, tests creating/deleting/binding/unbinding queues and 
exchanges.


Thanks,

Alan Conway

[jira] [Commented] (QPID-7439) Proton-based library for QMF management.

[ASF subversion and git services (JIRA)]

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

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

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

QPID-7439: Proton-based library for QMF management.

qmf.client is a port of qpidtoolibs to the proton AMQP 1.0 client library.


> Proton-based library for QMF management.
> 
>
> Key: QPID-7439
> URL: https://issues.apache.org/jira/browse/QPID-7439
> Project: Qpid
>  Issue Type: Improvement
>  Components: Python Tools
>Affects Versions: qpid-cpp-1.35.0
>Reporter: Alan Conway
>Assignee: Alan Conway
>
> A proton based python library for doing QMF management, similar to 
> qpidtoollibs. Customers are moving towards AMQP 1.0 clients, and proton based 
> clients have a better future than qpid.messaging. A particular requirement is 
> for the library to be fork-safe so it should not start threads like 
> qpid.messaging does. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (PROTON-1307) go binding amqp.message does not honor Inferred flag

[Richard Laos (JIRA)]

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

Richard Laos updated PROTON-1307:
-
Description: 
Calling SetInferred() has no effect when sending a message using the 
go-binding. Also, calling Inferred() against amqp.message does not reflect 
calls to SetInferred(). Looks like the problem is on line 264 in 
amqp/message.go. I tested the following change:
{code}
func (m *message) SetInferred(b bool)  { C.pn_message_set_inferred(m.pn, 
C.bool(b)) }
{code}

Seems to behave as expected afterwards.

  was:
Calling SetInferred() has no effect when sending a message using the 
go-binding. Also, calling Infferred() against amqp.message does not frelect 
calls to SetInferred(). Looks like the problem is on line 264 in 
amqp/message.go. I tested the following change:
{code}
func (m *message) SetInferred(b bool)  { C.pn_message_set_inferred(m.pn, 
C.bool(b)) }
{code}

Seems to behave as expected afterwards.


> go binding amqp.message does not honor Inferred flag
> 
>
> Key: PROTON-1307
> URL: https://issues.apache.org/jira/browse/PROTON-1307
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: go-binding
>Affects Versions: 0.15.0
>Reporter: Richard Laos
>Assignee: Alan Conway
>Priority: Minor
>
> Calling SetInferred() has no effect when sending a message using the 
> go-binding. Also, calling Inferred() against amqp.message does not reflect 
> calls to SetInferred(). Looks like the problem is on line 264 in 
> amqp/message.go. I tested the following change:
> {code}
> func (m *message) SetInferred(b bool)  { C.pn_message_set_inferred(m.pn, 
> C.bool(b)) }
> {code}
> Seems to behave as expected afterwards.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (DISPATCH-524) Unfair handling of multiple connections to the router

[Ted Ross (JIRA)]

Ted Ross created DISPATCH-524:
-

 Summary: Unfair handling of multiple connections to the router
 Key: DISPATCH-524
 URL: https://issues.apache.org/jira/browse/DISPATCH-524
 Project: Qpid Dispatch
  Issue Type: Bug
  Components: Container
Affects Versions: 0.6.1
Reporter: Ted Ross
Assignee: Ted Ross
 Fix For: 0.7.0


When there are multiple clients connected to the router at the same time and 
the aggregate traffic volume is high, some connections consistently get better 
service (transfer more messages) than others.  This unfairness appears to be 
correlated to the order in which connections are established.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: Azure Service Bus receiver timing out with electron go binding

[Alan Conway]

On Thu, 2016-09-22 at 15:27 +, Richard Laos wrote:
> I am getting the following error while waiting to receive messages
> from an Azure Service Bus queue after about 7 minutes of inactivity:
> 
> amqp:connection:forced: The connection was inactive for more than the
> allowed period of time.
> 
> My assumption is that I need to adjust the idle timeout of the
> connection transport to account for this. I am using the go electron
> binding which doesn't seem to support this yet so I can't test my
> theory.
> 

Thanks for raising that - it isn't supported but is easy to fix. Can
you  raise a JIRA (so you'll get some contributer points for the Qpid
project)? I will get on it ASAP.

Cheers,
Alan.


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

[jira] [Resolved] (QPIDJMS-210) Add documentation for the WebSocket transport

[Timothy Bish (JIRA)]

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

Timothy Bish resolved QPIDJMS-210.
--
Resolution: Fixed

> Add documentation for the WebSocket transport
> -
>
> Key: QPIDJMS-210
> URL: https://issues.apache.org/jira/browse/QPIDJMS-210
> Project: Qpid JMS
>  Issue Type: Task
>  Components: qpid-jms-client
>Affects Versions: 0.11.0
>Reporter: Timothy Bish
>Assignee: Timothy Bish
>Priority: Trivial
> Fix For: 0.1X.Y, 0.20.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (DISPATCH-524) Unfair handling of multiple connections to the router

[ASF subversion and git services (JIRA)]

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

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

Commit 5bf550fb294cf60f77537928c5c7c07b1679e125 in qpid-dispatch's branch 
refs/heads/master from [~tr...@redhat.com]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=5bf550f ]

DISPATCH-524 - Rotate connectors in the driver to distribute the poll 
unfairness fairly


> Unfair handling of multiple connections to the router
> -
>
> Key: DISPATCH-524
> URL: https://issues.apache.org/jira/browse/DISPATCH-524
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Container
>Affects Versions: 0.6.1
>Reporter: Ted Ross
>Assignee: Ted Ross
> Fix For: 0.7.0
>
>
> When there are multiple clients connected to the router at the same time and 
> the aggregate traffic volume is high, some connections consistently get 
> better service (transfer more messages) than others.  This unfairness appears 
> to be correlated to the order in which connections are established.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

API and terms: idle-time-out and heartbeat intervals.

[Alan Conway]

I want to clarify and document the meaning of these terms for our APIs,
presently I can't find anywhere where they are documented clearly.

The AMQP spec says: "Each peer has its own (independent) idle timeout.
At connection open each peer communicates the maximum
period between activity (frames) on the connection that it desires from
its partner.The open frame carries the idletime-out
field for this purpose. To avoid spurious timeouts, the value in idle-
time-out SHOULD be half the peer’s
actual timeout threshold."

In other words: if I send you an "open" frame with idle-time-out=N that
means *you* should not wait for longer than N milliseconds to send a
frame to me. It does not mean *I* will close the connection after N
milliseconds, I SHOULD be more patient and wait for N*2 ms to avoid
closing prematurely due to minor timing wobbles.

I think the choice of name is slightly ambiguous but the spec is clear
on the semantics, so it's important to document it to remove the
ambiguity.

Anybody disagree?

Cheers,
Alan.


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

[jira] [Updated] (QPID-7409) Support preview of maps/list message content

[Lorenz Quack (JIRA)]

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

Lorenz Quack updated QPID-7409:
---
Attachment: 0001-QPID-7409-Java-Broker-Move-responsibility-to-limit-m.patch

The attached patch moves the responsibility to limit the messageContent to the 
managed operation. The managed operation does not change the message content 
encoding. The REST layer remains responsible for changing the message content 
encoding to accommodate the client requirements (i.e., Accept-Encoding).
This might lead to unnecessary compression/decompression cycles but IMHO it is 
worth the clean separation of concerns. This is also only and issue when the 
content is limited meaning only a limited amount of data will be going through 
these additional cycles.

> Support preview of maps/list message content
> 
>
> Key: QPID-7409
> URL: https://issues.apache.org/jira/browse/QPID-7409
> Project: Qpid
>  Issue Type: Improvement
>Reporter: Keith Wall
>Assignee: Keith Wall
> Fix For: qpid-java-6.1
>
> Attachments: 
> 0001-QPID-7409-Java-Broker-Move-responsibility-to-limit-m.patch, 
> 0001-QPID-7409-Java-Broker-WMC-Limit-the-message-content-.patch, 
> 0001-QPID-7409-WIP-add-support-for-getting-of-message-con.patch
>
>
> When viewing messages through the web management console, if the message is 
> of type such as a list or map currently the user sees the bytes of the 
> underlying AMQP datastructure.  Instead, the preview area should display the 
> data in a human friendly way.
> The managed operation {{Queue#getMessageContent}} will be enhanced to be 
> capable of returning a message in JSON format if possible with an optional 
> parameter {{returnJson}}.  If rather than returning the message's content 
> bytes directly, it should first convert the message to an {{InternalMessage}} 
> (MessageConverterRegistry.getConverter(serverMessage.getClass, 
> InternalMessage.class).convert(...)) then use the JSON serialiser to serial 
> the MessageBody of the resulting internal message.
> Within the WMC, if the resulting object is of a previewable type (string, 
> map, list etc) and the content is not too long, the content should be added 
> to a scrollable preview pane of the message dialogue by traversing the object 
> tree and producing a human readable representation of its structure and 
> content.  (Perhaps an approach such as 
> https://stackoverflow.com/questions/13341373/render-arbitrary-json-in-html 
> will help)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: ctest nit: rename cpp and go tests.

[Alan Conway]

On Fri, 2016-09-23 at 12:13 -0400, Chuck Rolke wrote:
> +1 The presumption is that you are referring to qpid-proton tests
> and 
> not qpid-cpp or qpid-dispatch or ...
> 
> The widest ranging test is 'python-test'. This could be renamed to 
> 'proton-tests-of-all-sorts-using-python-test-framework'. When you 
> run python-test all the test logs print 'proton_tests.xx.yy'. 
> Is it python-test or proton_tests? 
> 

python-test is the ctest target name, proton_tests is the python module
name. You're right it is a big grab bag.

Post my fix the test list is below. All tests start with -,
except for java which is called "proton-java". All the auto-tested
examples are called -example-, after that it
depends on the language: cpp is cpp-, go just has one "go-
test" target that runs `go test` on the entire package set.

Some of the tests (go, python) can be run directly for finer control,
e.g. 

    source config.sh && go test qpid.apache.org/electron -run SASL

Here's the list:

$ ctest -N
Test project /home/aconway/proton/reldbg_cl11
  Test  #1: proton-java
  Test  #2: python-test
  Test  #3: ruby-example-test
  Test  #4: ruby-unit-test
  Test  #5: ruby-spec-test
  Test  #6: cpp-codec_test
  Test  #7: cpp-engine_test
  Test  #8: cpp-thread_safe_test
  Test  #9: cpp-interop_test
  Test #10: cpp-message_test
  Test #11: cpp-scalar_test
  Test #12: cpp-value_test
  Test #13: cpp-container_test
  Test #14: cpp-url_test
  Test #15: go-test
  Test #16: c-object-tests
  Test #17: c-message-tests
  Test #18: c-engine-tests
  Test #19: c-parse-url-tests
  Test #20: c-refcount-tests
  Test #21: c-reactor-tests
  Test #22: c-event-tests
  Test #23: c-data-tests
  Test #24: c-condition-tests
  Test #25: go-example-electron
  Test #26: go-example-proton
  Test #27: cpp-example-mt
  Test #28: cpp-example-container

> The test scheme is what it is and there's only so much to gain by 
> cleaning it up. But if there is any gain at all then please do
> make improvements!
> 
> -Chuck
> 
> - Original Message -
> > 
> > From: "Alan Conway" 
> > To: "dev" 
> > Sent: Friday, September 23, 2016 11:33:23 AM
> > Subject: ctest nit: rename cpp and go tests.
> > 
> > I'd like to rename the C++ and Go tests to use "-" instead of "_"
> > so
> > they are consistent with the other tests. This is my fault, I
> > wasn't
> > paying attention when I added the tests. The original tests are
> > like:
> > 
> >   Test  #2: python-test
> >   Test  #5: ruby-spec-test
> >   Test #16: c-object-tests
> > 
> > The offending tests are like:
> > 
> >   Test  #6: cpp_codec_test
> >   Test #25: go_example_electron_test
> > 
> > I want to rename them as cpp-codec-test, go-example-electron-test
> > etc.
> > 
> > Only impact is if you use `ctest -R` to run tests selectively.
> > 
> > Any objection? Silence is consent...
> > 
> > 
> > -
> > 
> > To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
> > For additional commands, e-mail: dev-h...@qpid.apache.org
> > 
> > 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
> For additional commands, e-mail: dev-h...@qpid.apache.org
> 


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

[jira] [Resolved] (DISPATCH-524) Unfair handling of multiple connections to the router

[Ted Ross (JIRA)]

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

Ted Ross resolved DISPATCH-524.
---
Resolution: Fixed

> Unfair handling of multiple connections to the router
> -
>
> Key: DISPATCH-524
> URL: https://issues.apache.org/jira/browse/DISPATCH-524
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Container
>Affects Versions: 0.6.1
>Reporter: Ted Ross
>Assignee: Ted Ross
> Fix For: 0.7.0
>
>
> When there are multiple clients connected to the router at the same time and 
> the aggregate traffic volume is high, some connections consistently get 
> better service (transfer more messages) than others.  This unfairness appears 
> to be correlated to the order in which connections are established.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (QPID-7433) Add minimal maven module to invoke TCK

[ASF subversion and git services (JIRA)]

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

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

Commit 1762562 from [~k-wall] in branch 'java/trunk'
[ https://svn.apache.org/r1762562 ]

QPID-7433: [TCK Config] Bug fix to the overriding of parameters for 
ManageQpidJMSResources

> Add minimal maven module to invoke TCK
> --
>
> Key: QPID-7433
> URL: https://issues.apache.org/jira/browse/QPID-7433
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker, Java Tests
>Reporter: Keith Wall
>Assignee: Keith Wall
> Attachments: 0001-wip-working.patch
>
>
> Add a miminal  maven module to the Java build, rather like the Joram one, 
> that allows the TCK to be run against the Qpid JMS client and the legacy 
> client too against a pre-running Broker.   The TCK is proprietary.  The 
> caller will need to provide the TCK himself. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: API and terms: idle-time-out and heartbeat intervals.

[Alan Conway]

On Tue, 2016-09-27 at 15:37 -0400, Alan Conway wrote:
> I want to clarify and document the meaning of these terms for our
> APIs,
> presently I can't find anywhere where they are documented clearly.
> 
> The AMQP spec says: "Each peer has its own (independent) idle
> timeout.
> At connection open each peer communicates the maximum
> period between activity (frames) on the connection that it desires
> from
> its partner.The open frame carries the idletime-out
> field for this purpose. To avoid spurious timeouts, the value in
> idle-
> time-out SHOULD be half the peer’s
> actual timeout threshold."
> 
> In other words: if I send you an "open" frame with idle-time-out=N
> that
> means *you* should not wait for longer than N milliseconds to send a
> frame to me. It does not mean *I* will close the connection after N
> milliseconds, I SHOULD be more patient and wait for N*2 ms to avoid
> closing prematurely due to minor timing wobbles.
> 
> I think the choice of name is slightly ambiguous but the spec is
> clear
> on the semantics, so it's important to document it to remove the
> ambiguity.
> 
> Anybody disagree?
> 

Sigh. Sadly proton-C interprets "idle-timeout" differently depending on
which end of the connection you are on:

      // as per the recommendation in the spec, advertise half our
  // actual timeout to the remote
  const pn_millis_t idle_timeout = transport->local_idle_timeout
  ? (transport->local_idle_timeout/2)
  : 0;

So in proton, pn_set_idle_timeout does NOT mean set the AMQP idle-
timeout value, it means set the local "receive timeout" value and send
half that as the AMQP "send timeout" for the peer.

I'm tempted to use a new term in the Go API: "heartbeat". To me that
clearly means the "send timeout" (hearts beat, they don't listen for
beats) so it coincides with the meaning of the AMQP "idle-timeout", but
without the ambiguity that is exacerbated by proton interpreting it
both ways.



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