[jira] [Commented] (QPID-7630) Add a CMake switch to allow -Werror to be switched off

2017-03-22 Thread Andrew Stitcher (JIRA)

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

Andrew Stitcher commented on QPID-7630:
---

So I think the consensus is:

* Rename the current ENABLE_WARNINGS flag to ENABLE_WARNING_ERROR (this is 
consistent with the name in proton-c).
* Change the behaviour of the flag so that it only stops warnings being treated 
as errors, but still displays warnings.
This is in line with the same functionality in the proton-c build system.

> Add a CMake switch to allow -Werror to be switched off
> --
>
> Key: QPID-7630
> URL: https://issues.apache.org/jira/browse/QPID-7630
> Project: Qpid
>  Issue Type: Improvement
>  Components: C++ Broker, C++ Client
>Affects Versions: qpid-cpp-1.36.0, qpid-cpp-1.37.0
> Environment: GNU compilers
>Reporter: Chris Richardson
>Assignee: Justin Ross
>  Labels: patch
> Fix For: qpid-cpp-1.38.0
>
> Attachments: 1.36.0-disable-warnings-as-errors-switch.patch
>
>
> It could be useful in some situations (eg: when packaging/installing) to be 
> able to disable warnings as errors in the build. This is the recommendation 
> for instance of the Gentoo packaging guide 
> (https://devmanual.gentoo.org/ebuild-writing/common-mistakes, section 
> "-Werror compiler flag not removed").
> See attached patch.
>  



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Resolved] (PROTON-1443) c proactor - change timeout(0) to mean immediate

2017-03-22 Thread Alan Conway (JIRA)

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

Alan Conway resolved PROTON-1443.
-
Resolution: Fixed

> c proactor - change timeout(0) to mean immediate
> 
>
> Key: PROTON-1443
> URL: https://issues.apache.org/jira/browse/PROTON-1443
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.17.0
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: 0.18.0
>
>
> The proactor API defines pn_proactor_timeout(p, 0) to mean "cancel the 
> current timeout" This is confusing, instead change it to mean "timeout 
> immediately" and add pn_proactor_cance_timeoutl(p) to cancel the current 
> timeout.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Updated] (DISPATCH-627) Implement a more systematic batch timeout test to avoid having low timeout value fail the test on slow machines

2017-03-22 Thread Ted Ross (JIRA)

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

Ted Ross updated DISPATCH-627:
--
Fix Version/s: 0.8.0

> Implement a more systematic batch timeout test to avoid having low timeout 
> value fail the test on slow machines
> ---
>
> Key: DISPATCH-627
> URL: https://issues.apache.org/jira/browse/DISPATCH-627
> Project: Qpid Dispatch
>  Issue Type: Improvement
>Affects Versions: 0.7.0
>Reporter: Adel Boutros
> Fix For: 0.8.0
>
> Attachments: 
> 0001-Implement-a-more-systematic-batch-timeout-test-to-av.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Updated] (DISPATCH-624) Add Atomic operations support on Solaris

2017-03-22 Thread Ted Ross (JIRA)

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

Ted Ross updated DISPATCH-624:
--
Fix Version/s: 0.8.0

> Add Atomic operations support on Solaris
> 
>
> Key: DISPATCH-624
> URL: https://issues.apache.org/jira/browse/DISPATCH-624
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 0.7.0
>Reporter: Adel Boutros
> Fix For: 0.8.0
>
> Attachments: 0001-Add-Atomic-operations-for-Solaris.patch
>
>
> Full details here: 
> http://qpid.2158936.n2.nabble.com/Dispatch-Router-0-7-0-SOLARIS-Unit-tests-failing-tp7658341.html
> *Methods added inspired from:*
> https://www.ibm.com/support/knowledgecenter/SSGH2K_13.1.0/com.ibm.xlc131.aix.doc/compiler_ref/bif_gcc_atomic_fetch_sub.html
> https://www.ibm.com/support/knowledgecenter/SSGH2K_13.1.0/com.ibm.xlc131.aix.doc/compiler_ref/bif_gcc_atomic_fetch_add.html
> http://docs.oracle.com/cd/E19253-01/816-5168/atomic-ops-3c/index.html



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Commented] (DISPATCH-729) password-file option doesn't work correctly

2017-03-22 Thread ASF subversion and git services (JIRA)

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

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

Commit 3e7ed2a7fbf0bdb4b0959c4cef818c49cbe46217 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=3e7ed2a ]

DISPATCH-729 - Fixed a bug in the password string loading.


> password-file option doesn't work correctly
> ---
>
> Key: DISPATCH-729
> URL: https://issues.apache.org/jira/browse/DISPATCH-729
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 0.7.0
> Environment: CentOS 7
>Reporter: Rohan Mars
>Assignee: Ganesh Murthy
>Priority: Minor
> Fix For: 0.8.0
>
>
> Using the "password-file" option in a a ssl-profile causes the client not to 
> be able to connect. The router displays a:
> "Enter PEM pass phrase"  log message
> Using the "password" option directly works.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Resolved] (DISPATCH-619) Use memalign instead of posix_memalign which is not defined on Solaris

2017-03-22 Thread Ted Ross (JIRA)

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

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

> Use memalign instead of posix_memalign which is not defined on Solaris
> --
>
> Key: DISPATCH-619
> URL: https://issues.apache.org/jira/browse/DISPATCH-619
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 0.7.0
>Reporter: Adel Boutros
>Assignee: Ted Ross
> Fix For: 0.8.0
>
> Attachments: 
> 0009-Use-memalign-instead-of-posix_memalign-which-is-not-.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Commented] (DISPATCH-619) Use memalign instead of posix_memalign which is not defined on Solaris

2017-03-22 Thread ASF subversion and git services (JIRA)

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

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

Commit 66ac8672f1c0d90eb3fdc09526b9fe892a267f03 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=66ac867 ]

DISPATCH-619 - Added use of memalign for Sun/Solaris (rather than 
posix_memalign).


> Use memalign instead of posix_memalign which is not defined on Solaris
> --
>
> Key: DISPATCH-619
> URL: https://issues.apache.org/jira/browse/DISPATCH-619
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 0.7.0
>Reporter: Adel Boutros
>Assignee: Ted Ross
> Fix For: 0.8.0
>
> Attachments: 
> 0009-Use-memalign-instead-of-posix_memalign-which-is-not-.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Assigned] (DISPATCH-619) Use memalign instead of posix_memalign which is not defined on Solaris

2017-03-22 Thread Ted Ross (JIRA)

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

Ted Ross reassigned DISPATCH-619:
-

Assignee: Ted Ross

> Use memalign instead of posix_memalign which is not defined on Solaris
> --
>
> Key: DISPATCH-619
> URL: https://issues.apache.org/jira/browse/DISPATCH-619
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 0.7.0
>Reporter: Adel Boutros
>Assignee: Ted Ross
> Fix For: 0.8.0
>
> Attachments: 
> 0009-Use-memalign-instead-of-posix_memalign-which-is-not-.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Created] (PROTON-1443) c proactor - change timeout(0) to mean immediate

2017-03-22 Thread Alan Conway (JIRA)
Alan Conway created PROTON-1443:
---

 Summary: c proactor - change timeout(0) to mean immediate
 Key: PROTON-1443
 URL: https://issues.apache.org/jira/browse/PROTON-1443
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-c
Affects Versions: 0.17.0
Reporter: Alan Conway
Assignee: Alan Conway
 Fix For: 0.18.0


The proactor API defines pn_proactor_timeout(p, 0) to mean "cancel the current 
timeout" This is confusing, instead change it to mean "timeout immediately" and 
add pn_proactor_cance_timeoutl(p) to cancel the current timeout.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Resolved] (DISPATCH-618) Revert eventfd on Solaris

2017-03-22 Thread Ted Ross (JIRA)

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

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

> Revert eventfd on Solaris
> -
>
> Key: DISPATCH-618
> URL: https://issues.apache.org/jira/browse/DISPATCH-618
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 0.7.0
>Reporter: Adel Boutros
>Assignee: Ted Ross
> Fix For: 0.8.0
>
> Attachments: 0008-Revert-eventfd-on-Solaris.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Commented] (DISPATCH-618) Revert eventfd on Solaris

2017-03-22 Thread ASF subversion and git services (JIRA)

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

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

Commit 141a1e38327551e80cdde1b0c39e4e201924ccfd 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=141a1e3 ]

DISPATCH-618 - Added back the old fd-pair implementation of wakeup for 
Sun/Solaris.


> Revert eventfd on Solaris
> -
>
> Key: DISPATCH-618
> URL: https://issues.apache.org/jira/browse/DISPATCH-618
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 0.7.0
>Reporter: Adel Boutros
>Assignee: Ted Ross
> Fix For: 0.8.0
>
> Attachments: 0008-Revert-eventfd-on-Solaris.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Commented] (DISPATCH-618) Revert eventfd on Solaris

2017-03-22 Thread Ted Ross (JIRA)

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

Ted Ross commented on DISPATCH-618:
---

Your patch is very polluted with unrelated changes in whitespace.  I'll try to 
filter out the useful content from it.

> Revert eventfd on Solaris
> -
>
> Key: DISPATCH-618
> URL: https://issues.apache.org/jira/browse/DISPATCH-618
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 0.7.0
>Reporter: Adel Boutros
>Assignee: Ted Ross
> Fix For: 0.8.0
>
> Attachments: 0008-Revert-eventfd-on-Solaris.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Assigned] (DISPATCH-618) Revert eventfd on Solaris

2017-03-22 Thread Ted Ross (JIRA)

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

Ted Ross reassigned DISPATCH-618:
-

Assignee: Ted Ross

> Revert eventfd on Solaris
> -
>
> Key: DISPATCH-618
> URL: https://issues.apache.org/jira/browse/DISPATCH-618
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 0.7.0
>Reporter: Adel Boutros
>Assignee: Ted Ross
> Fix For: 0.8.0
>
> Attachments: 0008-Revert-eventfd-on-Solaris.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Resolved] (DISPATCH-616) Arithmetic operations not allowed on void * pointer

2017-03-22 Thread Ted Ross (JIRA)

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

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

> Arithmetic operations not allowed on void * pointer
> ---
>
> Key: DISPATCH-616
> URL: https://issues.apache.org/jira/browse/DISPATCH-616
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 0.7.0
>Reporter: Adel Boutros
>Assignee: Ted Ross
> Fix For: 0.8.0
>
> Attachments: 
> 0006-Arithmetic-operations-not-allowed-on-void-pointer.patch
>
>
> arithmetic on a void* is illegal in both C and C++: 
> 
> http://stackoverflow.com/questions/3523145/pointer-arithmetic-for-void-pointer-in-c
> https://gcc.gnu.org/onlinedocs/gcc-4.8.0/gcc/Pointer-Arith.html



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Commented] (DISPATCH-616) Arithmetic operations not allowed on void * pointer

2017-03-22 Thread ASF subversion and git services (JIRA)

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

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

Commit 8842c71fb18597d25430c425fcac5d977a255294 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=8842c71 ]

DISPATCH-613, DISPATCH-616 - Added -Wpedantic and fixed resulting compiler 
errors.


> Arithmetic operations not allowed on void * pointer
> ---
>
> Key: DISPATCH-616
> URL: https://issues.apache.org/jira/browse/DISPATCH-616
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 0.7.0
>Reporter: Adel Boutros
>Assignee: Ted Ross
> Fix For: 0.8.0
>
> Attachments: 
> 0006-Arithmetic-operations-not-allowed-on-void-pointer.patch
>
>
> arithmetic on a void* is illegal in both C and C++: 
> 
> http://stackoverflow.com/questions/3523145/pointer-arithmetic-for-void-pointer-in-c
> https://gcc.gnu.org/onlinedocs/gcc-4.8.0/gcc/Pointer-Arith.html



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Resolved] (DISPATCH-613) Remove semi-column not needed after function definition

2017-03-22 Thread Ted Ross (JIRA)

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

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

> Remove semi-column not needed after function definition
> ---
>
> Key: DISPATCH-613
> URL: https://issues.apache.org/jira/browse/DISPATCH-613
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 0.7.0
>Reporter: Adel Boutros
>Assignee: Ted Ross
> Fix For: 0.8.0
>
> Attachments: 
> 0003-Remove-semi-column-not-needed-after-function-definit.patch
>
>
> Empty statement (an extra ";") causes error on Solaris



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Commented] (DISPATCH-613) Remove semi-column not needed after function definition

2017-03-22 Thread ASF subversion and git services (JIRA)

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

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

Commit 8842c71fb18597d25430c425fcac5d977a255294 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=8842c71 ]

DISPATCH-613, DISPATCH-616 - Added -Wpedantic and fixed resulting compiler 
errors.


> Remove semi-column not needed after function definition
> ---
>
> Key: DISPATCH-613
> URL: https://issues.apache.org/jira/browse/DISPATCH-613
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 0.7.0
>Reporter: Adel Boutros
>Assignee: Ted Ross
> Fix For: 0.8.0
>
> Attachments: 
> 0003-Remove-semi-column-not-needed-after-function-definit.patch
>
>
> Empty statement (an extra ";") causes error on Solaris



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Assigned] (DISPATCH-613) Remove semi-column not needed after function definition

2017-03-22 Thread Ted Ross (JIRA)

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

Ted Ross reassigned DISPATCH-613:
-

Assignee: Ted Ross  (was: Ganesh Murthy)

> Remove semi-column not needed after function definition
> ---
>
> Key: DISPATCH-613
> URL: https://issues.apache.org/jira/browse/DISPATCH-613
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 0.7.0
>Reporter: Adel Boutros
>Assignee: Ted Ross
> Fix For: 0.8.0
>
> Attachments: 
> 0003-Remove-semi-column-not-needed-after-function-definit.patch
>
>
> Empty statement (an extra ";") causes error on Solaris



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Assigned] (DISPATCH-616) Arithmetic operations not allowed on void * pointer

2017-03-22 Thread Ted Ross (JIRA)

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

Ted Ross reassigned DISPATCH-616:
-

Assignee: Ted Ross

> Arithmetic operations not allowed on void * pointer
> ---
>
> Key: DISPATCH-616
> URL: https://issues.apache.org/jira/browse/DISPATCH-616
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 0.7.0
>Reporter: Adel Boutros
>Assignee: Ted Ross
> Fix For: 0.8.0
>
> Attachments: 
> 0006-Arithmetic-operations-not-allowed-on-void-pointer.patch
>
>
> arithmetic on a void* is illegal in both C and C++: 
> 
> http://stackoverflow.com/questions/3523145/pointer-arithmetic-for-void-pointer-in-c
> https://gcc.gnu.org/onlinedocs/gcc-4.8.0/gcc/Pointer-Arith.html



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Commented] (DISPATCH-597) Log enhancements

2017-03-22 Thread ASF subversion and git services (JIRA)

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

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

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

DISPATCH-597 - Set the log level of a couple of connection related log messages 
to INFO level


> Log enhancements
> 
>
> Key: DISPATCH-597
> URL: https://issues.apache.org/jira/browse/DISPATCH-597
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Container
>Affects Versions: 0.7.0
>Reporter: Shibi Sudhakaran
>Assignee: Ganesh Murthy
> Fix For: 0.8.0
>
>
> Print information at INFO level into log that could be used for diagnosing 
> router health.  
> 1. Millisecond precision timestamp
> 2. Avoid logging message body.
> 3. Capability to configure application properties to be logged (messageId, 
> correlationId, creationTime , application custom properties) etc 
> Sample Entries (log level : INFO)
> 
> => Mon 2016-09-26 11:31:44.050750 -0700 ROUTER_HELLO (info) SENT: 
> HELLO(id=Router.A.0 area=0 inst=1474860067 seen=['Router.A.1', 'Router.A.2', 
> 'Router.A.3', 'Router.A.4’])
> => Mon 2016-09-26 14:15:58.088754 -0700 MESSAGE (info) Sending Message{ 
> message-id='' correlation-id='' 
> creation-time='2016-09-26 14:15:58.084 -0700' application properties='[Key: 
> request-creation-time => Value: 1474924558078]' } on link 
> => Mon 2016-09-26 14:15:20.547178 -0700 MESSAGE (info) Received Message{ 
> message-id='' correlation-id='' 
> creation-time='2016-09-26 14:15:20.542 -0700' application properties='[Key: 
> request-creation-time => Value: 1474924520539]'} on link 
> => Mon 2016-09-26 09:40:00.149567 -0700 ROUTER_LS (info) Computed costs: 
> {'Router.A.0': 1, 'Router.A.2': 1, 'Router.A.3': 1, 'Router.A.4': 1}
> => Mon 2016-09-26 14:23:07.376756 -0700 ROUTER (info) Router started in 
> Interior mode, area=0 id=Router.A.1
> => Mon 2016-09-26 14:23:07.408136 -0700 CONN_MGR (info) Configured Listener: 
> 0.0.0.0:5671 proto=any role=normal
> => Mon 2016-09-26 14:14:57.520917 -0700 SERVER (info) Accepting incoming 
> connection from  to  
> => Mon 2016-09-26 14:23:07.376471 -0700 SERVER (info) Container Name: 
> Router.A.1
> => Mon 2016-09-26 14:23:07.439250 -0700 SERVER (info) Connecting to 
>  
> => Mon 2016-09-26 14:23:07.447536 -0700 SERVER (info) [1]:Client SSL socket 
> created.
> => Mon 2016-09-26 14:15:12.310692 -0700 SERVER (info) [8783]:SSL socket freed
> => Mon 2016-09-26 14:23:03.059884 -0700 SERVER (info) Shut Down



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Resolved] (DISPATCH-732) CONN_MGR log module is used in connection_manager.c but is missing from log schema

2017-03-22 Thread Ganesh Murthy (JIRA)

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

Ganesh Murthy resolved DISPATCH-732.

   Resolution: Fixed
Fix Version/s: 0.8.0

> CONN_MGR log module is used in connection_manager.c but is missing from log 
> schema
> --
>
> Key: DISPATCH-732
> URL: https://issues.apache.org/jira/browse/DISPATCH-732
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Container
>Affects Versions: 0.8.0
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
> Fix For: 0.8.0
>
>
> src/connection_manager.c has a constructor that initializes the log source to 
> CONN_MGR
> {noformat}
> qd_connection_manager_t *qd_connection_manager(qd_dispatch_t *qd)
> {
> qd_connection_manager_t *cm = NEW(qd_connection_manager_t);
> if (!cm)
> return 0;
> cm->log_source = qd_log_source("CONN_MGR");
> cm->ssl_profile_lock = sys_mutex();
> cm->server = qd->server;
> DEQ_INIT(cm->config_listeners);
> DEQ_INIT(cm->config_connectors);
> DEQ_INIT(cm->config_ssl_profiles);
> return cm;
> }
> {noformat}
> But the CONN_MGR log module is missing from the qdrouter.json schema
> {noformat}
> "module": {
> "type":[
> "ROUTER",
> "ROUTER_CORE",
> "ROUTER_HELLO",
> "ROUTER_LS",
> "ROUTER_MA",
> "MESSAGE",
> "SERVER",
> "AGENT",
> "CONTAINER",
> "ERROR",
> "POLICY",
> "HTTP",
> "DEFAULT"
> ],
> {noformat}
> Add CONN_MGR list of modules and test if the log messages are printing out 
> correctly .



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Commented] (DISPATCH-732) CONN_MGR log module is used in connection_manager.c but is missing from log schema

2017-03-22 Thread ASF subversion and git services (JIRA)

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

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

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

DISPATCH-732 - Added log modules used in code but missing from schema


> CONN_MGR log module is used in connection_manager.c but is missing from log 
> schema
> --
>
> Key: DISPATCH-732
> URL: https://issues.apache.org/jira/browse/DISPATCH-732
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Container
>Affects Versions: 0.8.0
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>
> src/connection_manager.c has a constructor that initializes the log source to 
> CONN_MGR
> {noformat}
> qd_connection_manager_t *qd_connection_manager(qd_dispatch_t *qd)
> {
> qd_connection_manager_t *cm = NEW(qd_connection_manager_t);
> if (!cm)
> return 0;
> cm->log_source = qd_log_source("CONN_MGR");
> cm->ssl_profile_lock = sys_mutex();
> cm->server = qd->server;
> DEQ_INIT(cm->config_listeners);
> DEQ_INIT(cm->config_connectors);
> DEQ_INIT(cm->config_ssl_profiles);
> return cm;
> }
> {noformat}
> But the CONN_MGR log module is missing from the qdrouter.json schema
> {noformat}
> "module": {
> "type":[
> "ROUTER",
> "ROUTER_CORE",
> "ROUTER_HELLO",
> "ROUTER_LS",
> "ROUTER_MA",
> "MESSAGE",
> "SERVER",
> "AGENT",
> "CONTAINER",
> "ERROR",
> "POLICY",
> "HTTP",
> "DEFAULT"
> ],
> {noformat}
> Add CONN_MGR list of modules and test if the log messages are printing out 
> correctly .



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Resolved] (PROTON-1440) pn_connection_wake to return bool status

2017-03-22 Thread Alan Conway (JIRA)

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

Alan Conway resolved PROTON-1440.
-
Resolution: Fixed

> pn_connection_wake to return bool status
> 
>
> Key: PROTON-1440
> URL: https://issues.apache.org/jira/browse/PROTON-1440
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: 0.17.0
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: 0.18.0
>
>
> pn_connection_wake() allows any thread to send a PN_CONNECTION_WAKE event to 
> a proactor-managed connection. Currently it does not return any value, and 
> the application must ensure it is not called after the PN_TRANSPORT_CLOSED 
> event is processed for that connection.
> This is tricky for the application to synchronize and inconsistent with other 
> pn_connection_ functions. If refcounts are used to keep a pn_connection_t in 
> memory after the TRANSPORT_CLOSED, then calling wake() is an error even 
> though the pn_connection_t is valid.
> Change wake to be safe as long as the pn_connection_t is valid. It returns 
> true if the connection will be woken, false if it is too late.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Resolved] (PROTON-1438) c proactor listening behavior

2017-03-22 Thread Alan Conway (JIRA)

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

Alan Conway resolved PROTON-1438.
-
Resolution: Fixed

> c proactor listening behavior
> -
>
> Key: PROTON-1438
> URL: https://issues.apache.org/jira/browse/PROTON-1438
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: 0.17.0
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: 0.18.0
>
>
> Improved listening behavior for pn_proactor_listen to allow selective 
> listening by protocol (ipv4/v6) or portable "listen to everything".
> Host can be a host name, IPV4 or IPV6 literal,
> or the empty string/NULL (treated the same). The empty string listens on all 
> local addresses. A host name listens on all addresses associated with the 
> name. An IPV6 literal address (or wildcard '[::]') listens only for IPV6. An 
> IPV4 literal address (or wildcard '0.0.0.0') listens only for IPV4.
> - pn_proactor_listen may listen on more than one socket for ipv6/v4 or
> for DNS names with multiple address records.
> - the 'backlog' applies to *each* socket (open for debate - we might
> want to divide the backlog among sockets with some minimum if there's
> not enough)
> - pn_listener_close() closes all sockets, PN_LISTENER_CLOSE event
> indicates all sockets are closed.
> - An error on any socket will close all the sockets of the listener,
> PN_LISTERN_CLOSE event indicates all sockets are closed and provides
> the error that triggered the close.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Commented] (PROTON-1438) c proactor listening behavior

2017-03-22 Thread Alan Conway (JIRA)

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

Alan Conway commented on PROTON-1438:
-

Sorry [~astitcher] just spotted your comment: "I'm not sure I like the 
https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=03ca9be change."

We can revert this if you think it really makes things worse. I wanted to make 
this argument work as a simple "host:port" string, as well as a formal URL. 
Notation like ::1:5672 is pretty common in standard tools, e.g. do 'ss -tl6'. 
It is potentially ambiguous but that's built-in to ipv6. Note that [::1] is not 
a valid hostname on it's own, it is only valid as an escape in a URL, and while 
not using the [] escapes is illegal in a URL, so is dropping the amqp:// scheme 
part so we're already being more lax than standard URLs.

If you feel strongly I can probably be persuaded.

> c proactor listening behavior
> -
>
> Key: PROTON-1438
> URL: https://issues.apache.org/jira/browse/PROTON-1438
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: 0.17.0
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: 0.18.0
>
>
> Improved listening behavior for pn_proactor_listen to allow selective 
> listening by protocol (ipv4/v6) or portable "listen to everything".
> Host can be a host name, IPV4 or IPV6 literal,
> or the empty string/NULL (treated the same). The empty string listens on all 
> local addresses. A host name listens on all addresses associated with the 
> name. An IPV6 literal address (or wildcard '[::]') listens only for IPV6. An 
> IPV4 literal address (or wildcard '0.0.0.0') listens only for IPV4.
> - pn_proactor_listen may listen on more than one socket for ipv6/v4 or
> for DNS names with multiple address records.
> - the 'backlog' applies to *each* socket (open for debate - we might
> want to divide the backlog among sockets with some minimum if there's
> not enough)
> - pn_listener_close() closes all sockets, PN_LISTENER_CLOSE event
> indicates all sockets are closed.
> - An error on any socket will close all the sockets of the listener,
> PN_LISTERN_CLOSE event indicates all sockets are closed and provides
> the error that triggered the close.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Commented] (QPID-7653) [Java Broker] Separate JDBC and Derby Plugins from Broker Core

2017-03-22 Thread ASF subversion and git services (JIRA)

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

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

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

QPID-7653: [Java Broker, JDBC, Derby] Move JDBC classes out of core. Make Derby 
plugin depend on JDBC plugin

> [Java Broker] Separate JDBC and Derby Plugins from Broker Core
> --
>
> Key: QPID-7653
> URL: https://issues.apache.org/jira/browse/QPID-7653
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Lorenz Quack
>
> Currently there are some parts of the JDBC and Derby plugins that leak into 
> broker-core. The reason for this is that the two plugins share some code. It 
> would probably be more reasonable to move the common code to the JDBC plugin 
> and make the Derby Plugin depend on the JDBC plugin.
> I identified the following JDBC top-level classes in core (might not be 
> exhaustive):
> * {{org.apache.qpid.server.store.AbstractJDBCConfigurationStore}}
> * {{org.apache.qpid.server.store.AbstractJDBCMessageStore}}
> * {{org.apache.qpid.server.store.preferences.AbstractJDBCPreferenceStore}}
> * {{org.apache.qpid.server.store.jdbc.JDBCDetails}}
> * {{org.apache.qpid.server.store.jdbc.ConnectionProvider}}
> * {{org.apache.qpid.server.plugin.JDBCConnectionProviderFactory}}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Created] (DISPATCH-732) CONN_MGR log module is used in connection_manager.c but is missing from log schema

2017-03-22 Thread Ganesh Murthy (JIRA)
Ganesh Murthy created DISPATCH-732:
--

 Summary: CONN_MGR log module is used in connection_manager.c but 
is missing from log schema
 Key: DISPATCH-732
 URL: https://issues.apache.org/jira/browse/DISPATCH-732
 Project: Qpid Dispatch
  Issue Type: Bug
  Components: Container
Affects Versions: 0.8.0
Reporter: Ganesh Murthy
Assignee: Ganesh Murthy


src/connection_manager.c has a constructor that initializes the log source to 
CONN_MGR

{noformat}
qd_connection_manager_t *qd_connection_manager(qd_dispatch_t *qd)
{
qd_connection_manager_t *cm = NEW(qd_connection_manager_t);
if (!cm)
return 0;

cm->log_source = qd_log_source("CONN_MGR");
cm->ssl_profile_lock = sys_mutex();
cm->server = qd->server;
DEQ_INIT(cm->config_listeners);
DEQ_INIT(cm->config_connectors);
DEQ_INIT(cm->config_ssl_profiles);

return cm;
}
{noformat}

But the CONN_MGR log module is missing from the qdrouter.json schema
{noformat}
"module": {
"type":[
"ROUTER",
"ROUTER_CORE",
"ROUTER_HELLO",
"ROUTER_LS",
"ROUTER_MA",
"MESSAGE",
"SERVER",
"AGENT",
"CONTAINER",
"ERROR",
"POLICY",
"HTTP",
"DEFAULT"
],
{noformat}

Add CONN_MGR list of modules and test if the log messages are printing out 
correctly .



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Updated] (DISPATCH-525) What are proper names and units for protocol configuration settings?

2017-03-22 Thread Ted Ross (JIRA)

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

Ted Ross updated DISPATCH-525:
--
Fix Version/s: (was: 0.8.0)
   1.0.0

> What are proper names and units for protocol configuration settings?
> 
>
> Key: DISPATCH-525
> URL: https://issues.apache.org/jira/browse/DISPATCH-525
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Management Agent
>Affects Versions: 0.7.0
>Reporter: Chuck Rolke
> Fix For: 1.0.0
>
>
> Several settings are available in configuration objects that are used in AMQP 
> negotiations with clients. Some of them are confusing as they exist now and 
> could be redefined to make their understanding and usage easier for end 
> users. The same settings are defined for Router Listener and Connector and 
> for Policy Vhost objects.
> ||Setting||Units||Range||
> |maxFrameSize|octets|uint|
> |maxSessions|sessions|uint16|
> |maxSessionWindow|octets|uint|
> |maxMessageSize *not implemented*|octets|uint|
> |linkCapacity|messages|integer|
> These settings have to work in cooperation with the proton engine interface.
> h2. maxFrameSize
> This setting is straightforward. The range is 0..ULONG_MAX.
> Using octets is fine. This value must be 512 or larger per AMQP spec.
> h4. Proposal
> Leave this setting unchanged.
> h2. maxSessions
> This setting is in units of 'sessions'. The acceptable values are in the 
> range 1..65536. 
> The number given in the configuration is one larger than the value used by 
> AMQP and proton. In AMQP the channel-max value of an Open is the largest 
> channel number that can be used. So a channel-max of 0 allows one session, 
> and a value of 1 allows two sessions, and so on.
> I prefer to have the spec values be equal to the number of sessions allowed.
> * Dispatch code subtracts one from the specified value and puts it into 
> proton channel-max. 
> * A value of zero in the spec can be disallowed or it can mean some default 
> value.
> h4. Proposal
> Leave this setting unchanged.
> h2. maxSessionWindow
> This setting is in octets. The range is 0..ULONG_MAX with a minimum of 
> max-frame-size octets.
> This setting is slightly confusing as the specification is in octets. Then 
> that value of octets is passed to proton in pn_session_set_incoming_capacity. 
> Proton divides the incoming_capacity by the max-frame-size and uses the 
> result in a Begin incoming-window. The incoming-window then is measured in 
> transfer frames. For example:
> * maxFrameSize = 65,536.
> * maxSessionWindow = 1,000,000.
> Dividing (100 / 65536) = 15 frames. The 15 is used in the 
> Begin/incoming-window field during negotiation with the peer.
> A user expecting to have about a megabyte of buffering on the session might 
> be surprised to find all the buffering consumed by 15 100-byte transfer 
> frames.
> h4. Proposal
> * Rename this setting to *maxSessionFrames*.
> * Change this setting's units of 'transfer frame'. Then the value sent to 
> proton in incoming_capacity would be calculated by (maxSessionFrames * 
> maxFrameSize). The value of maxSessionFrames would then appear in the 
> Begin/incoming-window field.
> h2. maxMessageSize
> This setting is in octets. The range is 0..ULONG_MAX. 
> This setting is TBD. No interface in proton engine is available to change it. 
> If this value is zero or, more typically, not set then there is no maximum 
> message size.
> h4. Proposal
> Leave this setting unchanged.
> h2. linkCapacity
> This setting is in transfer frames. The range is 0..LONG_MAX.
> This setting defines how much credit is issued on links created on a 
> connection. It specifies how many transfers can be in-flight concurrently for 
> each link.
> This setting is for Listener and Connector objects only. It is not defined 
> for Policy Vhost objects.
> h4. Proposal
> * Leave the units and current meaning of this setting unchanged. 
> * Add this value to the Policy Vhost settings so that it may be overridden on 
> a Vhost Usergroup basis.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Commented] (DISPATCH-597) Log enhancements

2017-03-22 Thread ASF subversion and git services (JIRA)

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

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

Commit 801b5908a9532f3cdc57a0151b42956889f76ab7 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=801b590 ]

DISPATCH-597 - Changed topology-related logs from trace to info.


> Log enhancements
> 
>
> Key: DISPATCH-597
> URL: https://issues.apache.org/jira/browse/DISPATCH-597
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Container
>Affects Versions: 0.7.0
>Reporter: Shibi Sudhakaran
>Assignee: Ganesh Murthy
> Fix For: 0.8.0
>
>
> Print information at INFO level into log that could be used for diagnosing 
> router health.  
> 1. Millisecond precision timestamp
> 2. Avoid logging message body.
> 3. Capability to configure application properties to be logged (messageId, 
> correlationId, creationTime , application custom properties) etc 
> Sample Entries (log level : INFO)
> 
> => Mon 2016-09-26 11:31:44.050750 -0700 ROUTER_HELLO (info) SENT: 
> HELLO(id=Router.A.0 area=0 inst=1474860067 seen=['Router.A.1', 'Router.A.2', 
> 'Router.A.3', 'Router.A.4’])
> => Mon 2016-09-26 14:15:58.088754 -0700 MESSAGE (info) Sending Message{ 
> message-id='' correlation-id='' 
> creation-time='2016-09-26 14:15:58.084 -0700' application properties='[Key: 
> request-creation-time => Value: 1474924558078]' } on link 
> => Mon 2016-09-26 14:15:20.547178 -0700 MESSAGE (info) Received Message{ 
> message-id='' correlation-id='' 
> creation-time='2016-09-26 14:15:20.542 -0700' application properties='[Key: 
> request-creation-time => Value: 1474924520539]'} on link 
> => Mon 2016-09-26 09:40:00.149567 -0700 ROUTER_LS (info) Computed costs: 
> {'Router.A.0': 1, 'Router.A.2': 1, 'Router.A.3': 1, 'Router.A.4': 1}
> => Mon 2016-09-26 14:23:07.376756 -0700 ROUTER (info) Router started in 
> Interior mode, area=0 id=Router.A.1
> => Mon 2016-09-26 14:23:07.408136 -0700 CONN_MGR (info) Configured Listener: 
> 0.0.0.0:5671 proto=any role=normal
> => Mon 2016-09-26 14:14:57.520917 -0700 SERVER (info) Accepting incoming 
> connection from  to  
> => Mon 2016-09-26 14:23:07.376471 -0700 SERVER (info) Container Name: 
> Router.A.1
> => Mon 2016-09-26 14:23:07.439250 -0700 SERVER (info) Connecting to 
>  
> => Mon 2016-09-26 14:23:07.447536 -0700 SERVER (info) [1]:Client SSL socket 
> created.
> => Mon 2016-09-26 14:15:12.310692 -0700 SERVER (info) [8783]:SSL socket freed
> => Mon 2016-09-26 14:23:03.059884 -0700 SERVER (info) Shut Down



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Commented] (DISPATCH-730) Coverity scan reported errors in Qpid Dispatch master

2017-03-22 Thread ASF subversion and git services (JIRA)

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

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

Commit 0c6359981b3c642e2d5ed3c4ddc66a9299a54c95 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=0c63599 ]

DISPATCH-730 - Fixed several Coverity-flagged bugs.


> Coverity scan reported errors in Qpid Dispatch master
> -
>
> Key: DISPATCH-730
> URL: https://issues.apache.org/jira/browse/DISPATCH-730
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Container
>Affects Versions: 0.8.0
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
> Fix For: 0.8.0
>
>
> 5 new defect(s) introduced to Apache Qpid dispatch-router found with Coverity 
> Scan.
> New defect(s) Reported-by: Coverity Scan
> Showing 5 of 5 defect(s)
> ** CID 142339:(USE_AFTER_FREE)
> /home/gmurthy/opensource/dispatch/src/router_core/connections.c: 284 in 
> qdr_connection_process()
> /home/gmurthy/opensource/dispatch/src/router_core/connections.c: 284 in 
> qdr_connection_process()
> 
> *** CID 142339:(USE_AFTER_FREE)
> /home/gmurthy/opensource/dispatch/src/router_core/connections.c: 284 in 
> qdr_connection_process()
> 278 if (link_work->work_type == QDR_LINK_WORK_DELIVERY && 
> link_work->value > 0) {
> 279 DEQ_INSERT_HEAD(link->work_list, link_work);
> 280 link_work = 0; // Halt work processing
> 281 } else {
> 282 qdr_error_free(link_work->error);
> 283 free_qdr_link_work_t(link_work);
> >>> CID 142339:(USE_AFTER_FREE)
> >>> Dereferencing freed pointer "link".
> 284 link_work = DEQ_HEAD(link->work_list);
> 285 if (link_work)
> 286 DEQ_REMOVE_HEAD(link->work_list);
> 287 }
> 288 sys_mutex_unlock(conn->work_lock);
> 289 event_count++;
> /home/gmurthy/opensource/dispatch/src/router_core/connections.c: 284 in 
> qdr_connection_process()
> 278 if (link_work->work_type == QDR_LINK_WORK_DELIVERY && 
> link_work->value > 0) {
> 279 DEQ_INSERT_HEAD(link->work_list, link_work);
> 280 link_work = 0; // Halt work processing
> 281 } else {
> 282 qdr_error_free(link_work->error);
> 283 free_qdr_link_work_t(link_work);
> >>> CID 142339:(USE_AFTER_FREE)
> >>> Dereferencing freed pointer "link".
> 284 link_work = DEQ_HEAD(link->work_list);
> 285 if (link_work)
> 286 DEQ_REMOVE_HEAD(link->work_list);
> 287 }
> 288 sys_mutex_unlock(conn->work_lock);
> 289 event_count++;
> ** CID 142338:  Resource leaks  (RESOURCE_LEAK)
> /home/gmurthy/opensource/dispatch/src/failoverlist.c: 103 in 
> qd_failover_list()
> 
> *** CID 142338:  Resource leaks  (RESOURCE_LEAK)
> /home/gmurthy/opensource/dispatch/src/failoverlist.c: 103 in 
> qd_failover_list()
> 97 char *cursor = list->text;
> 98 char *next;
> 99 do {
> 100 next = qd_fol_next(cursor, ",");
> 101 qd_failover_item_t *item = qd_fol_item(cursor, error);
> 102 if (item == 0)
> >>> CID 142338:  Resource leaks  (RESOURCE_LEAK)
> >>> Variable "list" going out of scope leaks the storage it points to.
> 103 return 0;
> 104 DEQ_INSERT_TAIL(list->item_list, item);
> 105 cursor = next;
> 106 } while (cursor && *cursor);
> 107
> 108 return list;
> ** CID 142337:  Null pointer dereferences  (FORWARD_NULL)
> /home/gmurthy/opensource/dispatch/src/server.c: 564 in decorate_connection()
> 
> *** CID 142337:  Null pointer dereferences  (FORWARD_NULL)
> /home/gmurthy/opensource/dispatch/src/server.c: 564 in decorate_connection()
> 558 if (config && config->inter_router_cost > 1) {
> 559 pn_data_put_symbol(pn_connection_properties(conn),
> 560
> pn_bytes(strlen(QD_CONNECTION_PROPERTY_COST_KEY), 
> QD_CONNECTION_PROPERTY_COST_KEY));
> 561 

[jira] [Resolved] (DISPATCH-730) Coverity scan reported errors in Qpid Dispatch master

2017-03-22 Thread Ted Ross (JIRA)

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

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

> Coverity scan reported errors in Qpid Dispatch master
> -
>
> Key: DISPATCH-730
> URL: https://issues.apache.org/jira/browse/DISPATCH-730
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Container
>Affects Versions: 0.8.0
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
> Fix For: 0.8.0
>
>
> 5 new defect(s) introduced to Apache Qpid dispatch-router found with Coverity 
> Scan.
> New defect(s) Reported-by: Coverity Scan
> Showing 5 of 5 defect(s)
> ** CID 142339:(USE_AFTER_FREE)
> /home/gmurthy/opensource/dispatch/src/router_core/connections.c: 284 in 
> qdr_connection_process()
> /home/gmurthy/opensource/dispatch/src/router_core/connections.c: 284 in 
> qdr_connection_process()
> 
> *** CID 142339:(USE_AFTER_FREE)
> /home/gmurthy/opensource/dispatch/src/router_core/connections.c: 284 in 
> qdr_connection_process()
> 278 if (link_work->work_type == QDR_LINK_WORK_DELIVERY && 
> link_work->value > 0) {
> 279 DEQ_INSERT_HEAD(link->work_list, link_work);
> 280 link_work = 0; // Halt work processing
> 281 } else {
> 282 qdr_error_free(link_work->error);
> 283 free_qdr_link_work_t(link_work);
> >>> CID 142339:(USE_AFTER_FREE)
> >>> Dereferencing freed pointer "link".
> 284 link_work = DEQ_HEAD(link->work_list);
> 285 if (link_work)
> 286 DEQ_REMOVE_HEAD(link->work_list);
> 287 }
> 288 sys_mutex_unlock(conn->work_lock);
> 289 event_count++;
> /home/gmurthy/opensource/dispatch/src/router_core/connections.c: 284 in 
> qdr_connection_process()
> 278 if (link_work->work_type == QDR_LINK_WORK_DELIVERY && 
> link_work->value > 0) {
> 279 DEQ_INSERT_HEAD(link->work_list, link_work);
> 280 link_work = 0; // Halt work processing
> 281 } else {
> 282 qdr_error_free(link_work->error);
> 283 free_qdr_link_work_t(link_work);
> >>> CID 142339:(USE_AFTER_FREE)
> >>> Dereferencing freed pointer "link".
> 284 link_work = DEQ_HEAD(link->work_list);
> 285 if (link_work)
> 286 DEQ_REMOVE_HEAD(link->work_list);
> 287 }
> 288 sys_mutex_unlock(conn->work_lock);
> 289 event_count++;
> ** CID 142338:  Resource leaks  (RESOURCE_LEAK)
> /home/gmurthy/opensource/dispatch/src/failoverlist.c: 103 in 
> qd_failover_list()
> 
> *** CID 142338:  Resource leaks  (RESOURCE_LEAK)
> /home/gmurthy/opensource/dispatch/src/failoverlist.c: 103 in 
> qd_failover_list()
> 97 char *cursor = list->text;
> 98 char *next;
> 99 do {
> 100 next = qd_fol_next(cursor, ",");
> 101 qd_failover_item_t *item = qd_fol_item(cursor, error);
> 102 if (item == 0)
> >>> CID 142338:  Resource leaks  (RESOURCE_LEAK)
> >>> Variable "list" going out of scope leaks the storage it points to.
> 103 return 0;
> 104 DEQ_INSERT_TAIL(list->item_list, item);
> 105 cursor = next;
> 106 } while (cursor && *cursor);
> 107
> 108 return list;
> ** CID 142337:  Null pointer dereferences  (FORWARD_NULL)
> /home/gmurthy/opensource/dispatch/src/server.c: 564 in decorate_connection()
> 
> *** CID 142337:  Null pointer dereferences  (FORWARD_NULL)
> /home/gmurthy/opensource/dispatch/src/server.c: 564 in decorate_connection()
> 558 if (config && config->inter_router_cost > 1) {
> 559 pn_data_put_symbol(pn_connection_properties(conn),
> 560
> pn_bytes(strlen(QD_CONNECTION_PROPERTY_COST_KEY), 
> QD_CONNECTION_PROPERTY_COST_KEY));
> 561 pn_data_put_int(pn_connection_properties(conn), 
> config->inter_router_cost);
> 562 }
> 563
> >>> CID 142337:  Null pointer dereferences  (FORWARD_NULL)
> >>> Dereferencing null pointer "config".
> 564 qd_failover_list_t *fol = config->failover_list;
> 565 if (fol) {
> 566 

[jira] [Commented] (PROTON-1438) c proactor listening behavior

2017-03-22 Thread ASF subversion and git services (JIRA)

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

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

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

PROTON-1438: added pn_event_condition convenience function

A convenience function to make it easier to write generic error handling
functions for events.

/*
 * If the event context object has a condition and the condition is set
 * return it, otherwise return NULL.
 * If the event context object has remote and local conditions,
 * try the remote condition first, then the local.
 */
PN_EXTERN struct pn_condition_t *pn_event_condition(pn_event_t *event);


> c proactor listening behavior
> -
>
> Key: PROTON-1438
> URL: https://issues.apache.org/jira/browse/PROTON-1438
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: 0.17.0
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: 0.18.0
>
>
> Improved listening behavior for pn_proactor_listen to allow selective 
> listening by protocol (ipv4/v6) or portable "listen to everything".
> Host can be a host name, IPV4 or IPV6 literal,
> or the empty string/NULL (treated the same). The empty string listens on all 
> local addresses. A host name listens on all addresses associated with the 
> name. An IPV6 literal address (or wildcard '[::]') listens only for IPV6. An 
> IPV4 literal address (or wildcard '0.0.0.0') listens only for IPV4.
> - pn_proactor_listen may listen on more than one socket for ipv6/v4 or
> for DNS names with multiple address records.
> - the 'backlog' applies to *each* socket (open for debate - we might
> want to divide the backlog among sockets with some minimum if there's
> not enough)
> - pn_listener_close() closes all sockets, PN_LISTENER_CLOSE event
> indicates all sockets are closed.
> - An error on any socket will close all the sockets of the listener,
> PN_LISTERN_CLOSE event indicates all sockets are closed and provides
> the error that triggered the close.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Commented] (PROTON-1438) c proactor listening behavior

2017-03-22 Thread ASF subversion and git services (JIRA)

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

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

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

PROTON-1438: C libuv proactor, fix occasional timeout hangs


> c proactor listening behavior
> -
>
> Key: PROTON-1438
> URL: https://issues.apache.org/jira/browse/PROTON-1438
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: 0.17.0
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: 0.18.0
>
>
> Improved listening behavior for pn_proactor_listen to allow selective 
> listening by protocol (ipv4/v6) or portable "listen to everything".
> Host can be a host name, IPV4 or IPV6 literal,
> or the empty string/NULL (treated the same). The empty string listens on all 
> local addresses. A host name listens on all addresses associated with the 
> name. An IPV6 literal address (or wildcard '[::]') listens only for IPV6. An 
> IPV4 literal address (or wildcard '0.0.0.0') listens only for IPV4.
> - pn_proactor_listen may listen on more than one socket for ipv6/v4 or
> for DNS names with multiple address records.
> - the 'backlog' applies to *each* socket (open for debate - we might
> want to divide the backlog among sockets with some minimum if there's
> not enough)
> - pn_listener_close() closes all sockets, PN_LISTENER_CLOSE event
> indicates all sockets are closed.
> - An error on any socket will close all the sockets of the listener,
> PN_LISTERN_CLOSE event indicates all sockets are closed and provides
> the error that triggered the close.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Commented] (PROTON-1438) c proactor listening behavior

2017-03-22 Thread ASF subversion and git services (JIRA)

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

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

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

PROTON-1438: C proactor listening behavior

Improved listening behavior for pn_proactor_listen to allow selective listening 
by protocol (ipv4/v6) or portable "listen to everything".

Host can be a host name, IPV4 or IPV6 literal, or the empty string/NULL 
(treated the same). The empty string listens on all local addresses. A host 
name listens on all addresses associated with the name. An IPV6 literal address 
(or wildcard '[::]') listens only for IPV6. An IPV4 literal address (or 
wildcard '0.0.0.0') listens only for IPV4.

- pn_proactor_listen may listen on more than one socket for ipv6/v4 or for DNS 
names with multiple address records.

- the 'backlog' applies to *each* socket

- an error on any socket will close all the sockets of the listener,  
PN_LISTERN_CLOSE event indicates all sockets are closed and provides the error 
that triggered the close.


> c proactor listening behavior
> -
>
> Key: PROTON-1438
> URL: https://issues.apache.org/jira/browse/PROTON-1438
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: 0.17.0
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: 0.18.0
>
>
> Improved listening behavior for pn_proactor_listen to allow selective 
> listening by protocol (ipv4/v6) or portable "listen to everything".
> Host can be a host name, IPV4 or IPV6 literal,
> or the empty string/NULL (treated the same). The empty string listens on all 
> local addresses. A host name listens on all addresses associated with the 
> name. An IPV6 literal address (or wildcard '[::]') listens only for IPV6. An 
> IPV4 literal address (or wildcard '0.0.0.0') listens only for IPV4.
> - pn_proactor_listen may listen on more than one socket for ipv6/v4 or
> for DNS names with multiple address records.
> - the 'backlog' applies to *each* socket (open for debate - we might
> want to divide the backlog among sockets with some minimum if there's
> not enough)
> - pn_listener_close() closes all sockets, PN_LISTENER_CLOSE event
> indicates all sockets are closed.
> - An error on any socket will close all the sockets of the listener,
> PN_LISTERN_CLOSE event indicates all sockets are closed and provides
> the error that triggered the close.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Commented] (DISPATCH-617) Define HOST_NAME_MAX on Unix OSes where _POSIX_HOST_NAME_MAX is defined instead

2017-03-22 Thread Ganesh Murthy (JIRA)

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

Ganesh Murthy commented on DISPATCH-617:


git show d84356fe394bc375073d8bde0d935262906e97be

the above commit removed reference to HOST_NAME_MAX from the code. This 
attached patch is not relevant anymore since HOST_NAME_MAX is not referenced 
anymore in the code.

> Define HOST_NAME_MAX on Unix OSes where _POSIX_HOST_NAME_MAX is defined 
> instead
> ---
>
> Key: DISPATCH-617
> URL: https://issues.apache.org/jira/browse/DISPATCH-617
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 0.7.0
>Reporter: Adel Boutros
> Fix For: 0.8.0
>
> Attachments: 
> 0007-Define-HOST_NAME_MAX-on-Unix-OSes-where-_POSIX_HOST_.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Comment Edited] (DISPATCH-617) Define HOST_NAME_MAX on Unix OSes where _POSIX_HOST_NAME_MAX is defined instead

2017-03-22 Thread Ganesh Murthy (JIRA)

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

Ganesh Murthy edited comment on DISPATCH-617 at 3/22/17 2:41 PM:
-

git show d84356fe394bc375073d8bde0d935262906e97be

the above commit removed reference to HOST_NAME_MAX from the code. This 
attached patch is not relevant anymore since HOST_NAME_MAX is not referenced 
anymore in the code.

Commit d84356fe394bc375073d8bde0d935262906e97be resolved this issue.


was (Author: ganeshmurthy):
git show d84356fe394bc375073d8bde0d935262906e97be

the above commit removed reference to HOST_NAME_MAX from the code. This 
attached patch is not relevant anymore since HOST_NAME_MAX is not referenced 
anymore in the code.

> Define HOST_NAME_MAX on Unix OSes where _POSIX_HOST_NAME_MAX is defined 
> instead
> ---
>
> Key: DISPATCH-617
> URL: https://issues.apache.org/jira/browse/DISPATCH-617
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 0.7.0
>Reporter: Adel Boutros
> Fix For: 0.8.0
>
> Attachments: 
> 0007-Define-HOST_NAME_MAX-on-Unix-OSes-where-_POSIX_HOST_.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Resolved] (DISPATCH-617) Define HOST_NAME_MAX on Unix OSes where _POSIX_HOST_NAME_MAX is defined instead

2017-03-22 Thread Ganesh Murthy (JIRA)

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

Ganesh Murthy resolved DISPATCH-617.

Resolution: Fixed
  Assignee: Ganesh Murthy

> Define HOST_NAME_MAX on Unix OSes where _POSIX_HOST_NAME_MAX is defined 
> instead
> ---
>
> Key: DISPATCH-617
> URL: https://issues.apache.org/jira/browse/DISPATCH-617
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 0.7.0
>Reporter: Adel Boutros
>Assignee: Ganesh Murthy
> Fix For: 0.8.0
>
> Attachments: 
> 0007-Define-HOST_NAME_MAX-on-Unix-OSes-where-_POSIX_HOST_.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Commented] (DISPATCH-525) What are proper names and units for protocol configuration settings?

2017-03-22 Thread Ted Ross (JIRA)

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

Ted Ross commented on DISPATCH-525:
---

For the record:  The units for linkCapacity are not transfer frames, but 
transfers.  A single flow credit allows a multi-frame transfer to take place.


> What are proper names and units for protocol configuration settings?
> 
>
> Key: DISPATCH-525
> URL: https://issues.apache.org/jira/browse/DISPATCH-525
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Management Agent
>Affects Versions: 0.7.0
>Reporter: Chuck Rolke
> Fix For: 0.8.0
>
>
> Several settings are available in configuration objects that are used in AMQP 
> negotiations with clients. Some of them are confusing as they exist now and 
> could be redefined to make their understanding and usage easier for end 
> users. The same settings are defined for Router Listener and Connector and 
> for Policy Vhost objects.
> ||Setting||Units||Range||
> |maxFrameSize|octets|uint|
> |maxSessions|sessions|uint16|
> |maxSessionWindow|octets|uint|
> |maxMessageSize *not implemented*|octets|uint|
> |linkCapacity|messages|integer|
> These settings have to work in cooperation with the proton engine interface.
> h2. maxFrameSize
> This setting is straightforward. The range is 0..ULONG_MAX.
> Using octets is fine. This value must be 512 or larger per AMQP spec.
> h4. Proposal
> Leave this setting unchanged.
> h2. maxSessions
> This setting is in units of 'sessions'. The acceptable values are in the 
> range 1..65536. 
> The number given in the configuration is one larger than the value used by 
> AMQP and proton. In AMQP the channel-max value of an Open is the largest 
> channel number that can be used. So a channel-max of 0 allows one session, 
> and a value of 1 allows two sessions, and so on.
> I prefer to have the spec values be equal to the number of sessions allowed.
> * Dispatch code subtracts one from the specified value and puts it into 
> proton channel-max. 
> * A value of zero in the spec can be disallowed or it can mean some default 
> value.
> h4. Proposal
> Leave this setting unchanged.
> h2. maxSessionWindow
> This setting is in octets. The range is 0..ULONG_MAX with a minimum of 
> max-frame-size octets.
> This setting is slightly confusing as the specification is in octets. Then 
> that value of octets is passed to proton in pn_session_set_incoming_capacity. 
> Proton divides the incoming_capacity by the max-frame-size and uses the 
> result in a Begin incoming-window. The incoming-window then is measured in 
> transfer frames. For example:
> * maxFrameSize = 65,536.
> * maxSessionWindow = 1,000,000.
> Dividing (100 / 65536) = 15 frames. The 15 is used in the 
> Begin/incoming-window field during negotiation with the peer.
> A user expecting to have about a megabyte of buffering on the session might 
> be surprised to find all the buffering consumed by 15 100-byte transfer 
> frames.
> h4. Proposal
> * Rename this setting to *maxSessionFrames*.
> * Change this setting's units of 'transfer frame'. Then the value sent to 
> proton in incoming_capacity would be calculated by (maxSessionFrames * 
> maxFrameSize). The value of maxSessionFrames would then appear in the 
> Begin/incoming-window field.
> h2. maxMessageSize
> This setting is in octets. The range is 0..ULONG_MAX. 
> This setting is TBD. No interface in proton engine is available to change it. 
> If this value is zero or, more typically, not set then there is no maximum 
> message size.
> h4. Proposal
> Leave this setting unchanged.
> h2. linkCapacity
> This setting is in transfer frames. The range is 0..LONG_MAX.
> This setting defines how much credit is issued on links created on a 
> connection. It specifies how many transfers can be in-flight concurrently for 
> each link.
> This setting is for Listener and Connector objects only. It is not defined 
> for Policy Vhost objects.
> h4. Proposal
> * Leave the units and current meaning of this setting unchanged. 
> * Add this value to the Policy Vhost settings so that it may be overridden on 
> a Vhost Usergroup basis.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Commented] (QPID-7714) Suppress auto_ptr warnings

2017-03-22 Thread Justin Ross (JIRA)

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

Justin Ross commented on QPID-7714:
---

[~chris.richardson], I removed the SYSTEM keyword based on a concern from 
[~astitcher], so I'll let him speak to that.  You're right that I conflated the 
two separate issues in the original commit.  In the reversion, I've separated 
them, so this discussion should probably go against QPID-7629.

> Suppress auto_ptr warnings
> --
>
> Key: QPID-7714
> URL: https://issues.apache.org/jira/browse/QPID-7714
> Project: Qpid
>  Issue Type: Improvement
>  Components: C++ Build
>Reporter: Justin Ross
>Assignee: Justin Ross
> Fix For: qpid-cpp-1.37.0
>
>
> Now that some compilers have made C++11 their default, our use of auto_ptr is 
> producing too many warnings.  There's a fix in place for this, but it may 
> affect portability, so we will use another approach.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Closed] (DISPATCH-380) Router stops receiving messages from multiple senders publishing to multiple queues in parallel

2017-03-22 Thread Ted Ross (JIRA)

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

Ted Ross closed DISPATCH-380.
-
   Resolution: Cannot Reproduce
Fix Version/s: (was: 0.8.0)

> Router stops receiving messages from multiple senders publishing to multiple 
> queues in parallel
> ---
>
> Key: DISPATCH-380
> URL: https://issues.apache.org/jira/browse/DISPATCH-380
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Routing Engine
> Environment: Debian 8.3, Apache Qpid Proton 0.13.0-RC for drivers and 
> dependencies, Hardware: 2 CPUs, 15 GB RAM, 60 GB HDD each on 3 separate 
> machines
>Reporter: Vishal Sharda
>Priority: Critical
> Attachments: AWS_hung_at_round_figures.png, 
> AWS_hung_for_4_seconds.png, AWS_uneven_start.png, qdstat_wrong_output.png, 
> Senders_1.png, Senders_2.png, Senders_3_10_Queues.png, 
> Senders_4_10_queues.png, Single_router_testing_results.pdf
>
>
> I am running a Java Client against a cluster of 3 interior routers connected 
> to each other.  2-way SSL is enabled for all the connections.
> There were 20 simultaneous queues with 20 senders on each queue and each 
> sender publishing 1000 messages.  All the senders were connected to Router 1. 
>  20 receivers were connected to Router 2 with 1 receiver receiving from each 
> queue.
> In the first run, router stopped receiving incoming messages after delivering 
> 386,339 out of 400K "Hello World!" messages.
> In the second run, 388,781 messages out of 400K were delivered.
> I reduced the number of queues to 10 (halving total number of messages to 
> 200K) and the issue occurred again.
> I ran the Java client on an 8 CPU machine again with 10 queues and the issue 
> occurred again after delivering just 54K out of 200K messages.
> All the senders were hung (still connected) with no messages flowing at all.
> Connection information from qdstat:
> When the messages are flowing properly and I run "qdstat -c", I see all the 
> senders as secure and authenticated.
> After they hang and I run "qdstat -c", it erroneously shows all the clients 
> as insecure and unauthenticated.
> Shortly after the clients hang, all the queues are deleted from the router 
> network but connections are still shown until I terminate the clients.
> I saw this erroneous situation before also when "qdstat -c" showed some 
> senders as secure and authentic but some as insecure/unauthentic.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Commented] (QPID-7714) Suppress auto_ptr warnings

2017-03-22 Thread Chris Richardson (JIRA)

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

Chris Richardson commented on QPID-7714:


[~jr...@redhat.com] Can you please check your conclusion regarding the SYSTEM 
keyword and portability? My understanding is that the SYSTEM keyword should be 
perfectly portable - perhaps the unrelated "gnu++03" compiler directive you 
added in the same commit 
(https://git-wip-us.apache.org/repos/asf?p=qpid-cpp.git;h=2ee9f79) is actually 
the portability culprit?

My patch for the SYSTEM keyword has nothing to do with the auto_ptr deprecation 
warnings (I've tested this and get the same 2500 warnings); could we have it 
reinstated in the 1.37 release?

> Suppress auto_ptr warnings
> --
>
> Key: QPID-7714
> URL: https://issues.apache.org/jira/browse/QPID-7714
> Project: Qpid
>  Issue Type: Improvement
>  Components: C++ Build
>Reporter: Justin Ross
>Assignee: Justin Ross
> Fix For: qpid-cpp-1.37.0
>
>
> Now that some compilers have made C++11 their default, our use of auto_ptr is 
> producing too many warnings.  There's a fix in place for this, but it may 
> affect portability, so we will use another approach.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Updated] (DISPATCH-571) Driver spins when a listener accepts a socket while FDs are all in use

2017-03-22 Thread Ted Ross (JIRA)

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

Ted Ross updated DISPATCH-571:
--
Fix Version/s: (was: 0.8.0)
   1.0.0

> Driver spins when a listener accepts a socket while FDs are all in use
> --
>
> Key: DISPATCH-571
> URL: https://issues.apache.org/jira/browse/DISPATCH-571
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Container
>Reporter: Ted Ross
>Assignee: Alan Conway
> Fix For: 1.0.0
>
>
> when operating as a server and using listeners, if the number of open FDs is 
> equal to the limit on FDs, accept will return an error and the driver will 
> spin at 100% cpu until an FD is freed up for the incoming connection.
> Suggested fix:
> If "accept" returns a "too many open files" error (ENFILE or EMFILE), the 
> listening socket should be taken out of the read-fds for a time (say one 
> second) before retrying.
> If this is not practical to do in Proton, the driver should provide hooks for 
> the encapsulating application to use to provide this holdoff.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Updated] (DISPATCH-551) disconnect connections that do not complete initial protocol handshake within a given time

2017-03-22 Thread Ted Ross (JIRA)

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

Ted Ross updated DISPATCH-551:
--
Fix Version/s: (was: 0.8.0)
   1.0.0

> disconnect connections that do not complete initial protocol handshake within 
> a given time 
> ---
>
> Key: DISPATCH-551
> URL: https://issues.apache.org/jira/browse/DISPATCH-551
> Project: Qpid Dispatch
>  Issue Type: Improvement
>Reporter: Gordon Sim
> Fix For: 1.0.0
>
>
> Prevents lots of file handles being used without having to authenticate.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Updated] (DISPATCH-466) Orderly Quiescence of Links

2017-03-22 Thread Ted Ross (JIRA)

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

Ted Ross updated DISPATCH-466:
--
Fix Version/s: (was: 0.8.0)
   1.0.0

> Orderly Quiescence of Links
> ---
>
> Key: DISPATCH-466
> URL: https://issues.apache.org/jira/browse/DISPATCH-466
> Project: Qpid Dispatch
>  Issue Type: New Feature
>  Components: Router Node
>Reporter: Ted Ross
>Assignee: Ted Ross
> Fix For: 1.0.0
>
>
> This features provides an "adminStatus" field for links which is "enabled" or 
> "disabled".  When a link is set to disabled, its operStatus transitions from 
> UP to IDLE in an orderly fashion, such that message deliveries are not 
> dropped if an idle link is closed.
> For incoming links, this means draining remaining credit and waiting for 
> unsettled deliveries to be settled.
> For outgoing links, stop routing new deliveries to the link and wait for 
> unsettled deliveries to be settled.
> Note that this feature is neither meaningful nor supported for routed links.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Updated] (DISPATCH-584) Large, highly redundant router networks generate excessive inter-router message traffic

2017-03-22 Thread Ted Ross (JIRA)

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

Ted Ross updated DISPATCH-584:
--
Fix Version/s: (was: 0.8.0)
   1.0.0

> Large, highly redundant router networks generate excessive inter-router 
> message traffic
> ---
>
> Key: DISPATCH-584
> URL: https://issues.apache.org/jira/browse/DISPATCH-584
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Routing Engine
>Affects Versions: 0.7.0
>Reporter: Ted Ross
>Assignee: Ted Ross
> Fix For: 1.0.0
>
>
> When the router network is discovering and maintaining the distributed 
> understanding of the topology, router-advertisement (RA) messages are flooded 
> across the network.  Flooded messages are multicast without the tree-trimming 
> done using valid-origins.  In very redundant networks, many distinct paths 
> are followed for these messages, using excessive amounts of network and CPU 
> bandwidth.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Updated] (DISPATCH-731) Support wildcard tennat vhosts in address prefix configuration

2017-03-22 Thread Ted Ross (JIRA)

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

Ted Ross updated DISPATCH-731:
--
Fix Version/s: (was: 0.8.0)
   1.0.0

> Support wildcard tennat vhosts in address prefix configuration
> --
>
> Key: DISPATCH-731
> URL: https://issues.apache.org/jira/browse/DISPATCH-731
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Management Agent
>Affects Versions: 0.7.0
>Reporter: Ken Giusti
>Priority: Minor
> Fix For: 1.0.0
>
>
> When specifying address prefix patterns it should be possible to use a 
> wildcard match for the vhost.  Example:
> address {
> prefix: a_prefix   # matches current vhost (from open frame)
> }
> address {
> prefix: /my-vhost.com/other_prefix  # matched only if vhost=my-vhost
> }
> address {
> prefix:  /*.#.domain1.com/prefix_3 # matched if vhost ends with 
> domain1.com
> }
> address {
> prefix: /my.vhost.*.com/prefix_4  #matched if vhost starts with 
> 'my.vhost', has a single wildcard component, and ends with '.com'
> }
> Or something like that, I think.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Resolved] (DISPATCH-357) Address field is empty for link routed links in the qdstat "links" output

2017-03-22 Thread Ted Ross (JIRA)

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

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

> Address field is empty for link routed links in the qdstat "links" output
> -
>
> Key: DISPATCH-357
> URL: https://issues.apache.org/jira/browse/DISPATCH-357
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 0.6.0
>Reporter: Paolo Patierno
>Assignee: Ganesh Murthy
> Fix For: 0.8.0
>
> Attachments: qdstat_links.txt
>
>
> I have a router with a link routed link for address "my_queue" configured (in 
> both directions in and out).
> Executing "qdstat -l", it doesn't show me the address name; the "addr" field 
> is empty.
> Attached you can find the file with output.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Commented] (DISPATCH-357) Address field is empty for link routed links in the qdstat "links" output

2017-03-22 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on DISPATCH-357:
-

Github user asfgit closed the pull request at:

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


> Address field is empty for link routed links in the qdstat "links" output
> -
>
> Key: DISPATCH-357
> URL: https://issues.apache.org/jira/browse/DISPATCH-357
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 0.6.0
>Reporter: Paolo Patierno
>Assignee: Ganesh Murthy
> Fix For: 0.8.0
>
> Attachments: qdstat_links.txt
>
>
> I have a router with a link routed link for address "my_queue" configured (in 
> both directions in and out).
> Executing "qdstat -l", it doesn't show me the address name; the "addr" field 
> is empty.
> Attached you can find the file with output.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[GitHub] qpid-dispatch pull request #151: DISPATCH-357 - Added terminus_addr field on...

2017-03-22 Thread asfgit
Github user asfgit closed the pull request at:

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


---
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-357) Address field is empty for link routed links in the qdstat "links" output

2017-03-22 Thread ASF subversion and git services (JIRA)

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

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

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

DISPATCH-357 - Added terminus_addr field on link to display the terminus addr 
of a link route


> Address field is empty for link routed links in the qdstat "links" output
> -
>
> Key: DISPATCH-357
> URL: https://issues.apache.org/jira/browse/DISPATCH-357
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 0.6.0
>Reporter: Paolo Patierno
>Assignee: Ganesh Murthy
> Fix For: 0.8.0
>
> Attachments: qdstat_links.txt
>
>
> I have a router with a link routed link for address "my_queue" configured (in 
> both directions in and out).
> Executing "qdstat -l", it doesn't show me the address name; the "addr" field 
> is empty.
> Attached you can find the file with output.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Commented] (DISPATCH-357) Address field is empty for link routed links in the qdstat "links" output

2017-03-22 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on DISPATCH-357:
-

GitHub user ganeshmurthy opened a pull request:

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

DISPATCH-357 - Added terminus_addr field on link to display the termi…

…nus addr of a link route

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

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

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

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


commit adc3ca6a4b98572a8f18f99fe75349ef0b84fb71
Author: Ganesh Murthy 
Date:   2017-03-21T17:16:59Z

DISPATCH-357 - Added terminus_addr field on link to display the terminus 
addr of a link route




> Address field is empty for link routed links in the qdstat "links" output
> -
>
> Key: DISPATCH-357
> URL: https://issues.apache.org/jira/browse/DISPATCH-357
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 0.6.0
>Reporter: Paolo Patierno
>Assignee: Ganesh Murthy
> Fix For: 0.8.0
>
> Attachments: qdstat_links.txt
>
>
> I have a router with a link routed link for address "my_queue" configured (in 
> both directions in and out).
> Executing "qdstat -l", it doesn't show me the address name; the "addr" field 
> is empty.
> Attached you can find the file with output.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[ANNOUNCE] Apache Qpid for Java 6.1.2 released

2017-03-22 Thread Oleksandr Rudyy
The Apache Qpid (http://qpid.apache.org) community is pleased to announce
the immediate availability of Apache Qpid for Java 6.1.2.

This release incorporates a number of defect fixes and enhancements in
Qpid Broker for Java.

The release is available now from our website:
http://qpid.apache.org/download.html

Binaries are also available via Maven Central:
http://qpid.apache.org/maven.html

Release notes can be found at:
http://qpid.apache.org/releases/qpid-java-6.1.2/release-notes.html

Qpid Java 6.1.2 release page can be found here:
http://qpid.apache.org/releases/qpid-java-6.1.2/index.html


Thanks to all involved,
Alex

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



[GitHub] qpid-dispatch pull request #151: DISPATCH-357 - Added terminus_addr field on...

2017-03-22 Thread ganeshmurthy
GitHub user ganeshmurthy opened a pull request:

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

DISPATCH-357 - Added terminus_addr field on link to display the termi…

…nus addr of a link route

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

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

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

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


commit adc3ca6a4b98572a8f18f99fe75349ef0b84fb71
Author: Ganesh Murthy 
Date:   2017-03-21T17:16:59Z

DISPATCH-357 - Added terminus_addr field on link to display the terminus 
addr of a link route




---
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-357) Address field is empty for link routed links in the qdstat "links" output

2017-03-22 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on DISPATCH-357:
-

Github user ganeshmurthy closed the pull request at:

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


> Address field is empty for link routed links in the qdstat "links" output
> -
>
> Key: DISPATCH-357
> URL: https://issues.apache.org/jira/browse/DISPATCH-357
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 0.6.0
>Reporter: Paolo Patierno
>Assignee: Ganesh Murthy
> Fix For: 0.8.0
>
> Attachments: qdstat_links.txt
>
>
> I have a router with a link routed link for address "my_queue" configured (in 
> both directions in and out).
> Executing "qdstat -l", it doesn't show me the address name; the "addr" field 
> is empty.
> Attached you can find the file with output.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[GitHub] qpid-dispatch pull request #150: DISPATCH-357 - Added terminus_addr field on...

2017-03-22 Thread ganeshmurthy
Github user ganeshmurthy closed the pull request at:

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


---
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] [Updated] (QPID-7629) Use CMake "SYSTEM" keyword when including headers

2017-03-22 Thread Justin Ross (JIRA)

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

Justin Ross updated QPID-7629:
--
Fix Version/s: (was: qpid-cpp-1.37.0)
   qpid-cpp-1.38.0

> Use CMake "SYSTEM" keyword when including headers
> -
>
> Key: QPID-7629
> URL: https://issues.apache.org/jira/browse/QPID-7629
> Project: Qpid
>  Issue Type: Improvement
>  Components: C++ Broker, C++ Client
>Affects Versions: qpid-cpp-1.36.0
>Reporter: Chris Richardson
>Assignee: Justin Ross
>  Labels: patch
> Fix For: qpid-cpp-1.38.0
>
> Attachments: 1.36.0-system-includes.patch
>
>
> See attached patch which applies this change to the NSS and SASL include 
> directories. The patch does not affect the included headers from perl, 
> python, ruby, boost or qpid-proton since it is probably not necessary to 
> consider those dependencies.
> This change would prevent -Werror being applied to code in header files 
> included from dependent libraries, which can cause failures such as:
> [ 25%] Building CXX object src/CMakeFiles/qpidcommon.dir/qpid/Modules.cpp.o
> In file included from /usr/include/nss/ssl.h:18:0,
>  from 
> /var/tmp/portage/net-misc/qpid-cpp-1.36.0/work/qpid-cpp-1.36.0/src/qpid/sys/ssl/util.cpp:30:
> /usr/include/nss/sslt.h:121:40: error: comma at end of enumerator list 
> [-Werror=pedantic]
>  ssl_sig_rsa_pkcs1_sha1md5 = 0x10101,
> ^
> cc1plus: all warnings being treated as errors



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Resolved] (QPID-7714) Suppress auto_ptr warnings

2017-03-22 Thread Justin Ross (JIRA)

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

Justin Ross resolved QPID-7714.
---
Resolution: Fixed

> Suppress auto_ptr warnings
> --
>
> Key: QPID-7714
> URL: https://issues.apache.org/jira/browse/QPID-7714
> Project: Qpid
>  Issue Type: Improvement
>  Components: C++ Build
>Reporter: Justin Ross
>Assignee: Justin Ross
> Fix For: qpid-cpp-1.37.0
>
>
> Now that some compilers have made C++11 their default, our use of auto_ptr is 
> producing too many warnings.  There's a fix in place for this, but it may 
> affect portability, so we will use another approach.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Reopened] (QPID-7629) Use CMake "SYSTEM" keyword when including headers

2017-03-22 Thread Justin Ross (JIRA)

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

Justin Ross reopened QPID-7629:
---

> Use CMake "SYSTEM" keyword when including headers
> -
>
> Key: QPID-7629
> URL: https://issues.apache.org/jira/browse/QPID-7629
> Project: Qpid
>  Issue Type: Improvement
>  Components: C++ Broker, C++ Client
>Affects Versions: qpid-cpp-1.36.0
>Reporter: Chris Richardson
>Assignee: Justin Ross
>  Labels: patch
> Fix For: qpid-cpp-1.37.0
>
> Attachments: 1.36.0-system-includes.patch
>
>
> See attached patch which applies this change to the NSS and SASL include 
> directories. The patch does not affect the included headers from perl, 
> python, ruby, boost or qpid-proton since it is probably not necessary to 
> consider those dependencies.
> This change would prevent -Werror being applied to code in header files 
> included from dependent libraries, which can cause failures such as:
> [ 25%] Building CXX object src/CMakeFiles/qpidcommon.dir/qpid/Modules.cpp.o
> In file included from /usr/include/nss/ssl.h:18:0,
>  from 
> /var/tmp/portage/net-misc/qpid-cpp-1.36.0/work/qpid-cpp-1.36.0/src/qpid/sys/ssl/util.cpp:30:
> /usr/include/nss/sslt.h:121:40: error: comma at end of enumerator list 
> [-Werror=pedantic]
>  ssl_sig_rsa_pkcs1_sha1md5 = 0x10101,
> ^
> cc1plus: all warnings being treated as errors



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Commented] (QPID-7714) Suppress auto_ptr warnings

2017-03-22 Thread ASF subversion and git services (JIRA)

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

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

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

QPID-7714: Suppress very verbose warnings


> Suppress auto_ptr warnings
> --
>
> Key: QPID-7714
> URL: https://issues.apache.org/jira/browse/QPID-7714
> Project: Qpid
>  Issue Type: Improvement
>  Components: C++ Build
>Reporter: Justin Ross
>Assignee: Justin Ross
> Fix For: qpid-cpp-1.37.0
>
>
> Now that some compilers have made C++11 their default, our use of auto_ptr is 
> producing too many warnings.  There's a fix in place for this, but it may 
> affect portability, so we will use another approach.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Commented] (QPID-7629) Use CMake "SYSTEM" keyword when including headers

2017-03-22 Thread ASF subversion and git services (JIRA)

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

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

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

QPID-7629: Revert the use of SYSTEM for now; there is a concern that it will 
impact portability


> Use CMake "SYSTEM" keyword when including headers
> -
>
> Key: QPID-7629
> URL: https://issues.apache.org/jira/browse/QPID-7629
> Project: Qpid
>  Issue Type: Improvement
>  Components: C++ Broker, C++ Client
>Affects Versions: qpid-cpp-1.36.0
>Reporter: Chris Richardson
>Assignee: Justin Ross
>  Labels: patch
> Fix For: qpid-cpp-1.37.0
>
> Attachments: 1.36.0-system-includes.patch
>
>
> See attached patch which applies this change to the NSS and SASL include 
> directories. The patch does not affect the included headers from perl, 
> python, ruby, boost or qpid-proton since it is probably not necessary to 
> consider those dependencies.
> This change would prevent -Werror being applied to code in header files 
> included from dependent libraries, which can cause failures such as:
> [ 25%] Building CXX object src/CMakeFiles/qpidcommon.dir/qpid/Modules.cpp.o
> In file included from /usr/include/nss/ssl.h:18:0,
>  from 
> /var/tmp/portage/net-misc/qpid-cpp-1.36.0/work/qpid-cpp-1.36.0/src/qpid/sys/ssl/util.cpp:30:
> /usr/include/nss/sslt.h:121:40: error: comma at end of enumerator list 
> [-Werror=pedantic]
>  ssl_sig_rsa_pkcs1_sha1md5 = 0x10101,
> ^
> cc1plus: all warnings being treated as errors



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Commented] (DISPATCH-357) Address field is empty for link routed links in the qdstat "links" output

2017-03-22 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on DISPATCH-357:
-

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

https://github.com/apache/qpid-dispatch/pull/150#discussion_r107394882
  
--- Diff: src/router_core/forwarder.c ---
@@ -704,6 +704,16 @@ bool qdr_forward_link_balanced_CT(qdr_core_t *core,
 out_link->link_type  = QD_LINK_ENDPOINT;
 out_link->link_direction = qdr_link_direction(in_link) == 
QD_OUTGOING ? QD_INCOMING : QD_OUTGOING;
 out_link->admin_enabled  = true;
+if (in_link->terminus_addr) {
--- End diff --

Why is this necessary?  It looks like you are ensuring that both connected 
links have their own copy of the terminus name.  However, in the agent code, 
you get the terminus name from either the direct link or the connected link.  
Isn't it sufficient to have the terminus name in only one of the connected 
links?


> Address field is empty for link routed links in the qdstat "links" output
> -
>
> Key: DISPATCH-357
> URL: https://issues.apache.org/jira/browse/DISPATCH-357
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 0.6.0
>Reporter: Paolo Patierno
>Assignee: Ganesh Murthy
> Fix For: 0.8.0
>
> Attachments: qdstat_links.txt
>
>
> I have a router with a link routed link for address "my_queue" configured (in 
> both directions in and out).
> Executing "qdstat -l", it doesn't show me the address name; the "addr" field 
> is empty.
> Attached you can find the file with output.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[GitHub] qpid-dispatch pull request #150: DISPATCH-357 - Added terminus_addr field on...

2017-03-22 Thread ted-ross
Github user ted-ross commented on a diff in the pull request:

https://github.com/apache/qpid-dispatch/pull/150#discussion_r107394882
  
--- Diff: src/router_core/forwarder.c ---
@@ -704,6 +704,16 @@ bool qdr_forward_link_balanced_CT(qdr_core_t *core,
 out_link->link_type  = QD_LINK_ENDPOINT;
 out_link->link_direction = qdr_link_direction(in_link) == 
QD_OUTGOING ? QD_INCOMING : QD_OUTGOING;
 out_link->admin_enabled  = true;
+if (in_link->terminus_addr) {
--- End diff --

Why is this necessary?  It looks like you are ensuring that both connected 
links have their own copy of the terminus name.  However, in the agent code, 
you get the terminus name from either the direct link or the connected link.  
Isn't it sufficient to have the terminus name in only one of the connected 
links?


---
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-7663) [Java Broker] Implement persistent storage of LinkRegistry

2017-03-22 Thread ASF subversion and git services (JIRA)

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

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

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

QPID-7663: [Java Broker] fix failing tests

> [Java Broker] Implement persistent storage of LinkRegistry
> --
>
> Key: QPID-7663
> URL: https://issues.apache.org/jira/browse/QPID-7663
> Project: Qpid
>  Issue Type: Task
>  Components: Java Broker
>Reporter: Lorenz Quack
> Fix For: qpid-java-broker-7.0.0
>
>
> The LinkRegistry as described in [this 
> document|https://cwiki.apache.org/confluence/display/qpid/Link+Registry+Design#LinkRegistryDesign-Designv3]
>  should have a persistent storage in case a persistent ConfigurationStore is 
> used.
> The linked document details some suggestions how the storage is structured.
> As access to the LinkRegistry is multi-threaded care must be taken to make 
> all store operations thread-safe.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Updated] (QPID-7695) [Java Broker, BDB HA] Indefinite hang when new node joins existing group but existing node is unresponsive

2017-03-22 Thread Alex Rudyy (JIRA)

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

Alex Rudyy updated QPID-7695:
-
Summary: [Java Broker, BDB HA] Indefinite hang when new node joins existing 
group but existing node is unresponsive  (was: [Java Broker, HA] Indefinite 
hang when new node joins existing group but existing node is unresponsive)

> [Java Broker, BDB HA] Indefinite hang when new node joins existing group but 
> existing node is unresponsive
> --
>
> Key: QPID-7695
> URL: https://issues.apache.org/jira/browse/QPID-7695
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.0.6, qpid-java-6.1.1, qpid-java-broker-7.0.0
>Reporter: Keith Wall
>Assignee: Keith Wall
> Fix For: qpid-java-6.0.7, qpid-java-6.1.2, qpid-java-broker-7.0.0
>
>
> When adding a new node to an existing group, internally Qpid uses 
> com.sleepycat.je.rep.util.DbPing#DbPing() to establish initial contact with 
> the node and perform some preliminary checks.   If this node is somehow 
> unresponsive, Qpid (the Broker's Confif Thread) hangs indefinitely and is 
> unrecoverable. BDB JE 5.0.104 is in use.
> The Broker Config thread stack trace looks like this:
> {noformat}
>  java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.FileDispatcherImpl.read0(FileDispatcherImpl.java:-1)
> at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
> at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223)
> at sun.nio.ch.IOUtil.read(IOUtil.java:197)
> at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:380)
> - locked <0x168d> (a java.lang.Object)
> at 
> com.sleepycat.je.rep.utilint.ServiceDispatcher.doServiceHandshake(ServiceDispatcher.java:325)
> at com.sleepycat.je.rep.util.DbPing.getNodeState(DbPing.java:194)
> at 
> org.apache.qpid.server.store.berkeleydb.replication.ReplicatedEnvironmentFacade.getRemoteNodeState(ReplicatedEnvironmentFacade.java:1807)
> at 
> org.apache.qpid.server.store.berkeleydb.replication.ReplicatedEnvironmentFacade.connectToHelperNodeAndCheckPermittedHosts(ReplicatedEnvironmentFacade.java:1846)
> at 
> org.apache.qpid.server.virtualhostnode.berkeleydb.BDBHAVirtualHostNodeImpl.getPermittedNodesFromHelper(BDBHAVirtualHostNodeImpl.java:566)
> at 
> org.apache.qpid.server.virtualhostnode.berkeleydb.BDBHAVirtualHostNodeImpl.validateOnCreate(BDBHAVirtualHostNodeImpl.java:546)
> at 
> org.apache.qpid.server.model.AbstractConfiguredObject$6.execute(AbstractConfiguredObject.java:878)
> at 
> org.apache.qpid.server.model.AbstractConfiguredObject$6.execute(AbstractConfiguredObject.java:865)
> at 
> org.apache.qpid.server.model.AbstractConfiguredObject$2.execute(AbstractConfiguredObject.java:636)
> at 
> org.apache.qpid.server.model.AbstractConfiguredObject$2.execute(AbstractConfiguredObject.java:629)
> at 
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$TaskLoggingWrapper.execute(TaskExecutorImpl.java:240)
> at 
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.submitWrappedTask(TaskExecutorImpl.java:157)
> at 
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.submit(TaskExecutorImpl.java:145)
> at 
> org.apache.qpid.server.model.AbstractConfiguredObject.doOnConfigThread(AbstractConfiguredObject.java:628)
> at 
> org.apache.qpid.server.model.AbstractConfiguredObject.createAsync(AbstractConfiguredObject.java:864)
> at 
> org.apache.qpid.server.model.AbstractConfiguredObjectTypeFactory.createAsync(AbstractConfiguredObjectTypeFactory.java:75)
> at 
> org.apache.qpid.server.model.ConfiguredObjectFactoryImpl.createAsync(ConfiguredObjectFactoryImpl.java:145)
> at 
> org.apache.qpid.server.model.BrokerImpl.createVirtualHostNodeAsync(BrokerImpl.java:605)
> at 
> org.apache.qpid.server.model.BrokerImpl.addChildAsync(BrokerImpl.java:660)
> at 
> org.apache.qpid.server.model.AbstractConfiguredObject$17.execute(AbstractConfiguredObject.java:2094)
> at 
> org.apache.qpid.server.model.AbstractConfiguredObject$17.execute(AbstractConfiguredObject.java:2089)
> at 
> org.apache.qpid.server.model.AbstractConfiguredObject$2.execute(AbstractConfiguredObject.java:636)
> at 
> org.apache.qpid.server.model.AbstractConfiguredObject$2.execute(AbstractConfiguredObject.java:629)
> at 
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$TaskLoggingWrapper.execute(TaskExecutorImpl.java:240)
> at 
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$CallableWrapper$1.run(TaskExecutorImpl.java:312)
> at 
> 

[jira] [Commented] (QPID-7622) Separate Qpid Broker for Java and 0-x JMS Client in source tree

2017-03-22 Thread ASF subversion and git services (JIRA)

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

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

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

QPID-7622: Remove accidentally committed velocity.timestamp

> Separate Qpid Broker for Java and 0-x JMS Client in source tree
> ---
>
> Key: QPID-7622
> URL: https://issues.apache.org/jira/browse/QPID-7622
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker, Java Client
>Reporter: Keith Wall
>Assignee: Keith Wall
> Fix For: qpid-java-client-0-x-6.3.0, qpid-java-broker-7.0.0
>
>
> As discussed here:
> http://qpid.2158936.n2.nabble.com/DISCUSS-Drop-the-AMQP-0-x-client-from-the-Qpid-for-Java-7-0-release-td7657770.html
> The proposal is to move the code and documentation that comprises the 0-x 
> client to its own SVN root:
> https://svn.apache.org/repos/asf/qpid/qpid-jms-0-x
> The Java Broker and integration tests suites will remain at: 
> https://svn.apache.org/repos/asf/qpid/qpid-java
> Maven dependencies will be used to pull in the appropriate 0-x client for 
> integration testing purposes (as we already do with the Qpid JMS Client).
> The {{qpid-common}} module (and maven release artefact) will be eliminated.
> * Classes that the Broker requires will be moved into the class hierarchy of 
> the existing plugin modules {{amqp-0-10-protocol}} and {{amqp-0-8-protocol}} 
> e.g. {{org/apache/qpid/server/protocol/vx_y}}.*   There is some generic code 
> used by many modules such as BindingURL whose copy shall live in broker-core.
> * Code that the 0-x client requires will be copied into the client module.  
> The package names will be unchanged.
> This will allow the Broker and 0-x Client to co-exist in the same JVM without 
> class loading collision.   Class movements will be organised in such a way to 
> preserve SVN history.
> The structure of trunk  qpid-jms-0-x will look like:
> - qpid-jms-0-x
>  + client
>+ example
>  + jaa
>   + example
>   + ra
> + docs
>   + jms-client-0-10
>   + jms-client-0-8
> There will need to be a new parent POM.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Commented] (QPID-7719) [Java Broker] Set response code to 500 when unexpected error occurs during REST call

2017-03-22 Thread Lorenz Quack (JIRA)

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

Lorenz Quack commented on QPID-7719:


Furthermore, it seems that the responsibilities between 
{{RestServlet#setResponseStatus}} and the {{ExceptionHandlingFilter}} are 
unclear. For example the handling of {{ExternalServiceTimeoutException}} seems 
to be duplicated.
IMHO, {{RestServlet#setResponseStatus}} should die and the functionality be 
moved into the {{ExceptionHandlingFilter}}.

> [Java Broker] Set response code to 500 when unexpected error occurs during 
> REST call 
> -
>
> Key: QPID-7719
> URL: https://issues.apache.org/jira/browse/QPID-7719
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Reporter: Lorenz Quack
>
> Currently if there is an unhandled exception in the REST layer we do not set 
> a error response code. The servlet ends up returning 200 which is clearly 
> incorrect.
> we should set the error code to 500 and ideally return a JSON error message.
> The code in question is the final {{else}} block in 
> {{RestServlet#setResponseStatus}} (~line 960). 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Updated] (QPID-7719) [Java Broker] Set response code to 500 when unexpected error occurs during REST call

2017-03-22 Thread Lorenz Quack (JIRA)

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

Lorenz Quack updated QPID-7719:
---
Description: 
Currently if there is an unhandled exception in the REST layer we do not set a 
error response code. The servlet ends up returning 200 which is clearly 
incorrect.
we should set the error code to 500 and ideally return a JSON error message.

The code in question is the final {{else}} block in 
{{RestServlet#setResponseStatus}} (~line 960). 

  was:
Currently if there is an unhandled exception in the REST layer we do not set a 
error response code. The servlet ends up returning 200 which is clearly 
incorrect.
we should set the error code to 500 and ideally return a JSON error message.


> [Java Broker] Set response code to 500 when unexpected error occurs during 
> REST call 
> -
>
> Key: QPID-7719
> URL: https://issues.apache.org/jira/browse/QPID-7719
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Reporter: Lorenz Quack
>
> Currently if there is an unhandled exception in the REST layer we do not set 
> a error response code. The servlet ends up returning 200 which is clearly 
> incorrect.
> we should set the error code to 500 and ideally return a JSON error message.
> The code in question is the final {{else}} block in 
> {{RestServlet#setResponseStatus}} (~line 960). 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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