date:20170814

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

2017-08-14 Thread ASF subversion and git services (JIRA)


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

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

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

DISPATCH-808 - Allow router to respond to addresses with 
non-QD_TREATMENT_UNAVAILABLE treatment. This must have been part of fix to 
DISPATCH-803


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



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

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

[jira] [Resolved] (DISPATCH-808) Setting defaultDistribution: unavailable blocks qdmanage

2017-08-14 Thread Ganesh Murthy (JIRA)


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

Ganesh Murthy resolved DISPATCH-808.

   Resolution: Fixed
Fix Version/s: 1.0.0

> Setting defaultDistribution: unavailable blocks qdmanage
> 
>
> Key: DISPATCH-808
> URL: https://issues.apache.org/jira/browse/DISPATCH-808
> Project: Qpid Dispatch
>  Issue Type: Bug
> Environment: 
>Reporter: Ulf Lilleengen
>Assignee: Ganesh Murthy
>Priority: Minor
> Fix For: 1.0.0
>
>
> If I specify defaultDistribution: unavailable in the router {} block, 
> qdmanage prints
> LinkDetached: sender 2dc356e7-d1cc-45d4-b5f2-2c76023a5e52-$management to 
> $management closed due to: Condition('amqp:not-found', 'Node not found')
> If I add 
> {code}
> address {
>prefix: $management
> }
> {code}
> to the config, it works. As a default, I would expect that an implicit 
> address such as '$management' should just work without any extra config even 
> if the default distribution is unavailable.



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

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

[jira] [Commented] (DISPATCH-808) Setting defaultDistribution: unavailable blocks qdmanage

2017-08-14 Thread ASF subversion and git services (JIRA)


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

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

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

DISPATCH-808 - Allow router to respond to addresses with 
non-QD_TREATMENT_UNAVAILABLE treatment. This must have been part of fix to 
DISPATCH-803


> Setting defaultDistribution: unavailable blocks qdmanage
> 
>
> Key: DISPATCH-808
> URL: https://issues.apache.org/jira/browse/DISPATCH-808
> Project: Qpid Dispatch
>  Issue Type: Bug
> Environment: 
>Reporter: Ulf Lilleengen
>Assignee: Ganesh Murthy
>Priority: Minor
> Fix For: 1.0.0
>
>
> If I specify defaultDistribution: unavailable in the router {} block, 
> qdmanage prints
> LinkDetached: sender 2dc356e7-d1cc-45d4-b5f2-2c76023a5e52-$management to 
> $management closed due to: Condition('amqp:not-found', 'Node not found')
> If I add 
> {code}
> address {
>prefix: $management
> }
> {code}
> to the config, it works. As a default, I would expect that an implicit 
> address such as '$management' should just work without any extra config even 
> if the default distribution is unavailable.



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

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

[jira] [Assigned] (DISPATCH-808) Setting defaultDistribution: unavailable blocks qdmanage

2017-08-14 Thread Ganesh Murthy (JIRA)


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

Ganesh Murthy reassigned DISPATCH-808:
--

Assignee: Ganesh Murthy

> Setting defaultDistribution: unavailable blocks qdmanage
> 
>
> Key: DISPATCH-808
> URL: https://issues.apache.org/jira/browse/DISPATCH-808
> Project: Qpid Dispatch
>  Issue Type: Bug
> Environment: 
>Reporter: Ulf Lilleengen
>Assignee: Ganesh Murthy
>Priority: Minor
>
> If I specify defaultDistribution: unavailable in the router {} block, 
> qdmanage prints
> LinkDetached: sender 2dc356e7-d1cc-45d4-b5f2-2c76023a5e52-$management to 
> $management closed due to: Condition('amqp:not-found', 'Node not found')
> If I add 
> {code}
> address {
>prefix: $management
> }
> {code}
> to the config, it works. As a default, I would expect that an implicit 
> address such as '$management' should just work without any extra config even 
> if the default distribution is unavailable.



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

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

[jira] [Commented] (PROTON-1540) Add options to enable Sanitizers to CMake build

2017-08-14 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on PROTON-1540:


GitHub user jdanekrh opened a pull request:

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

PROTON-1540 Add options to enable Sanitizers to CMake build



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

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

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

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


commit 3f5385c898196312caa33606b3b2ac3d9827f2a2
Author: Jiri Danek 
Date:   2017-08-14T20:08:16Z

NO-JIRA Silence clang 4 error: use of GNU statement expression extension

This silences the following kind of warnings

/home/jdanek/Work/repos/qpid-proton/proton-c/src/tests/engine.c:283:5: 
error: use of GNU statement expression extension 
[-Werror,-Wgnu-statement-expression]
assert(pn_link_current(rx));
^

/nix/store/qy94v105wag3z9rgy1rb34zk0x20lkwj-glibc-2.25-dev/include/assert.h:95:6:
 note: expanded from macro 'assert'
({

commit c96107c0768ec98a6b5e5af5db56f918ee108cc5
Author: Jiri Danek 
Date:   2017-08-14T20:11:59Z

PROTON-1540 Add options to enable Sanitizers to CMake build

Tested to work with gcc 5.4.0, 7.1.0 and clang 4.0.1




> Add options to enable Sanitizers to CMake build
> ---
>
> Key: PROTON-1540
> URL: https://issues.apache.org/jira/browse/PROTON-1540
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: build
>Reporter: Jiri Danek
>Assignee: Jiri Danek
>Priority: Minor
>
> To get the most out of sanitizers in Qpid Dispatch, it helps to compile 
> Proton with sanitizers as well.



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

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

[GitHub] qpid-proton pull request #117: PROTON-1540 Add options to enable Sanitizers ...

2017-08-14 Thread jdanekrh

GitHub user jdanekrh opened a pull request:

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

PROTON-1540 Add options to enable Sanitizers to CMake build



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

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

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

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


commit 3f5385c898196312caa33606b3b2ac3d9827f2a2
Author: Jiri Danek 
Date:   2017-08-14T20:08:16Z

NO-JIRA Silence clang 4 error: use of GNU statement expression extension

This silences the following kind of warnings

/home/jdanek/Work/repos/qpid-proton/proton-c/src/tests/engine.c:283:5: 
error: use of GNU statement expression extension 
[-Werror,-Wgnu-statement-expression]
assert(pn_link_current(rx));
^

/nix/store/qy94v105wag3z9rgy1rb34zk0x20lkwj-glibc-2.25-dev/include/assert.h:95:6:
 note: expanded from macro 'assert'
({

commit c96107c0768ec98a6b5e5af5db56f918ee108cc5
Author: Jiri Danek 
Date:   2017-08-14T20:11:59Z

PROTON-1540 Add options to enable Sanitizers to CMake build

Tested to work with gcc 5.4.0, 7.1.0 and clang 4.0.1




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

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

[jira] [Created] (PROTON-1540) Add options to enable Sanitizers to CMake build

2017-08-14 Thread Jiri Danek (JIRA)

Jiri Danek created PROTON-1540:
--

 Summary: Add options to enable Sanitizers to CMake build
 Key: PROTON-1540
 URL: https://issues.apache.org/jira/browse/PROTON-1540
 Project: Qpid Proton
  Issue Type: Improvement
  Components: build
Reporter: Jiri Danek
Assignee: Jiri Danek
Priority: Minor


To get the most out of sanitizers in Qpid Dispatch, it helps to compile Proton 
with sanitizers as well.



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

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

[jira] [Commented] (DISPATCH-809) Add options to enable Sanitizers to CMake build

2017-08-14 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on DISPATCH-809:
-

GitHub user jdanekrh opened a pull request:

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

DISPATCH-809 Add options to enable Sanitizers to CMake build



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

$ git pull https://github.com/jdanekrh/qpid-dispatch jd_sanitizers

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

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


commit 34c70f703c09b1883ea125a3d0bbc4b528f6e535
Author: Jiri Danek 
Date:   2017-08-14T16:54:36Z

NO-JIRA Fix alloc-size-larger-than warning from gcc 7

The following warning is fixed by this commit

```
/home/jdanek/Work/repos/qpid-dispatch/src/entity.c: In function 
‘qd_entity_set_stringf’:
/home/jdanek/Work/repos/qpid-dispatch/src/entity.c:235:10: error: argument 
1 range [18446744071562067968, 18446744073709551615] exceeds maximum object 
size 9223372036854775807 [-Werror=alloc-size-larger-than=]
 char buf[len+1];
  ^~~
/home/jdanek/Work/repos/qpid-dispatch/src/entity.c:235:10: note: in a call 
to built-in allocation function ‘__builtin_alloca_with_align’
/home/jdanek/Work/repos/qpid-dispatch/src/entity.c:235:10: error: argument 
1 range [18446744071562067968, 18446744073709551615] exceeds maximum object 
size 9223372036854775807 [-Werror=alloc-size-larger-than=]
/home/jdanek/Work/repos/qpid-dispatch/src/entity.c:235:10: note: in a call 
to built-in allocation function ‘__builtin_alloca_with_align’
cc1: all warnings being treated as errors
make[2]: *** [src/CMakeFiles/qpid-dispatch.dir/build.make:273: 
src/CMakeFiles/qpid-dispatch.dir/entity.c.o] Error 1
make[2]: *** Waiting for unfinished jobs
make[1]: *** [CMakeFiles/Makefile2:982: 
src/CMakeFiles/qpid-dispatch.dir/all] Error 2
make: *** [Makefile:141: all] Error 2
```

commit 1e9708be2fc79540c3228affd677ae85648be8b2
Author: Jiri Danek 
Date:   2017-08-14T19:48:18Z

NO-JIRA Silence clang 4 error: use of GNU statement expression extension

This fixes the following kind of warnings

/home/jdanek/Work/repos/qpid-dispatch/src/posix/threading.c:147:5: error: 
use of GNU statement expression extension [-Werror,-Wgnu-statement-expression]
assert(result == 0);
^

/nix/store/qy94v105wag3z9rgy1rb34zk0x20lkwj-glibc-2.25-dev/include/assert.h:95:6:
 note: expanded from macro 'assert'
({  \
 ^

commit de16048f3b577dbf7fc831475d02acaa9581e543
Author: Jiri Danek 
Date:   2017-08-14T19:36:50Z

DISPATCH-809 Add options to enable Sanitizers to CMake build

Tested to work with gcc 5.4.0, 7.1.0 and clang 4.0.1




> Add options to enable Sanitizers to CMake build
> ---
>
> Key: DISPATCH-809
> URL: https://issues.apache.org/jira/browse/DISPATCH-809
> Project: Qpid Dispatch
>  Issue Type: Improvement
>Affects Versions: 1.0.0
>Reporter: Jiri Danek
>Priority: Minor
>
> The usage is to first enable sanitizers during compilation
> {noformat}
> cmake .. -DUSE_SANITIZERS=ON -DProton_DIR=... -DCMAKE_BUILD_TYPE=Release
> {noformat}
> or
> {noformat}
> cmake .. -DUSE_TSAN=ON -DProton_DIR=... -DCMAKE_BUILD_TYPE=Release
> {noformat}
> (TSan is incompatible with the other sanitizers.)
> Then, either run unit tests with the usual {{ctest -VV}}, or run 
> {{qdrouterd}}.
> Sanitizers can be given parameters in environment variable. For example, 
> {{TSAN_OPTIONS="color=always" ctest -VV}} to see colored error messages in 
> ctest output. Other options are described on the Sanitizers website, e.g. 
> https://github.com/google/sanitizers/wiki/ThreadSanitizerFlags
> For best results, also compile Proton with sanitizers.



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

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

[GitHub] qpid-dispatch pull request #189: DISPATCH-809 Add options to enable Sanitize...

2017-08-14 Thread jdanekrh

GitHub user jdanekrh opened a pull request:

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

DISPATCH-809 Add options to enable Sanitizers to CMake build



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

$ git pull https://github.com/jdanekrh/qpid-dispatch jd_sanitizers

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

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


commit 34c70f703c09b1883ea125a3d0bbc4b528f6e535
Author: Jiri Danek 
Date:   2017-08-14T16:54:36Z

NO-JIRA Fix alloc-size-larger-than warning from gcc 7

The following warning is fixed by this commit

```
/home/jdanek/Work/repos/qpid-dispatch/src/entity.c: In function 
âqd_entity_set_stringfâ:
/home/jdanek/Work/repos/qpid-dispatch/src/entity.c:235:10: error: argument 
1 range [18446744071562067968, 18446744073709551615] exceeds maximum object 
size 9223372036854775807 [-Werror=alloc-size-larger-than=]
 char buf[len+1];
  ^~~
/home/jdanek/Work/repos/qpid-dispatch/src/entity.c:235:10: note: in a call 
to built-in allocation function â__builtin_alloca_with_alignâ
/home/jdanek/Work/repos/qpid-dispatch/src/entity.c:235:10: error: argument 
1 range [18446744071562067968, 18446744073709551615] exceeds maximum object 
size 9223372036854775807 [-Werror=alloc-size-larger-than=]
/home/jdanek/Work/repos/qpid-dispatch/src/entity.c:235:10: note: in a call 
to built-in allocation function â__builtin_alloca_with_alignâ
cc1: all warnings being treated as errors
make[2]: *** [src/CMakeFiles/qpid-dispatch.dir/build.make:273: 
src/CMakeFiles/qpid-dispatch.dir/entity.c.o] Error 1
make[2]: *** Waiting for unfinished jobs
make[1]: *** [CMakeFiles/Makefile2:982: 
src/CMakeFiles/qpid-dispatch.dir/all] Error 2
make: *** [Makefile:141: all] Error 2
```

commit 1e9708be2fc79540c3228affd677ae85648be8b2
Author: Jiri Danek 
Date:   2017-08-14T19:48:18Z

NO-JIRA Silence clang 4 error: use of GNU statement expression extension

This fixes the following kind of warnings

/home/jdanek/Work/repos/qpid-dispatch/src/posix/threading.c:147:5: error: 
use of GNU statement expression extension [-Werror,-Wgnu-statement-expression]
assert(result == 0);
^

/nix/store/qy94v105wag3z9rgy1rb34zk0x20lkwj-glibc-2.25-dev/include/assert.h:95:6:
 note: expanded from macro 'assert'
({  \
 ^

commit de16048f3b577dbf7fc831475d02acaa9581e543
Author: Jiri Danek 
Date:   2017-08-14T19:36:50Z

DISPATCH-809 Add options to enable Sanitizers to CMake build

Tested to work with gcc 5.4.0, 7.1.0 and clang 4.0.1




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

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

[jira] [Created] (DISPATCH-809) Add options to enable Sanitizers to CMake build

2017-08-14 Thread Jiri Danek (JIRA)

Jiri Danek created DISPATCH-809:
---

 Summary: Add options to enable Sanitizers to CMake build
 Key: DISPATCH-809
 URL: https://issues.apache.org/jira/browse/DISPATCH-809
 Project: Qpid Dispatch
  Issue Type: Improvement
Affects Versions: 1.0.0
Reporter: Jiri Danek
Priority: Minor


The usage is to first enable sanitizers during compilation

{noformat}
cmake .. -DUSE_SANITIZERS=ON -DProton_DIR=... -DCMAKE_BUILD_TYPE=Release
{noformat}

or

{noformat}
cmake .. -DUSE_TSAN=ON -DProton_DIR=... -DCMAKE_BUILD_TYPE=Release
{noformat}

(TSan is incompatible with the other sanitizers.)

Then, either run unit tests with the usual {{ctest -VV}}, or run {{qdrouterd}}.

Sanitizers can be given parameters in environment variable. For example, 
{{TSAN_OPTIONS="color=always" ctest -VV}} to see colored error messages in 
ctest output. Other options are described on the Sanitizers website, e.g. 
https://github.com/google/sanitizers/wiki/ThreadSanitizerFlags

For best results, also compile Proton with sanitizers.



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

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

[jira] [Resolved] (PROTON-1539) Kerberos SASL exchange results in malformed SASL response frame

2017-08-14 Thread Andrew Stitcher (JIRA)


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

Andrew Stitcher resolved PROTON-1539.
-
   Resolution: Fixed
Fix Version/s: proton-c-0.18.0

> Kerberos SASL exchange results in malformed SASL response frame
> ---
>
> Key: PROTON-1539
> URL: https://issues.apache.org/jira/browse/PROTON-1539
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Reporter: Justin Ross
>Assignee: Andrew Stitcher
> Fix For: proton-c-0.18.0
>
>
> {noformat}
> [jross@localhost clients]$ PN_TRACE_FRM=1 ./connect upto.nogood.industries 
> jgecko@NOGOOD.INDUSTRIES
> [0x2187480]:  -> SASL
> [0x2187480]:  <- SASL
> [0x2187480]:0 <- @sasl-mechanisms(64) 
> [sasl-server-mechanisms=@PN_SYMBOL[:GSSAPI]]
> [15271] 1502727697.649006: ccselect module realm chose cache 
> KEYRING:persistent:1000:1000 with client principal jgecko@NOGOOD.INDUSTRIES 
> for server principal amqp/upto.nogood.industries@NOGOOD.INDUSTRIES
> [15271] 1502727697.649050: Getting credentials jgecko@NOGOOD.INDUSTRIES -> 
> amqp/upto.nogood.industries@NOGOOD.INDUSTRIES using ccache 
> KEYRING:persistent:1000:1000
> [15271] 1502727697.649097: Retrieving jgecko@NOGOOD.INDUSTRIES -> 
> amqp/upto.nogood.industries@NOGOOD.INDUSTRIES from 
> KEYRING:persistent:1000:1000 with result: 0/Success
> [15271] 1502727697.649127: Creating authenticator for 
> jgecko@NOGOOD.INDUSTRIES -> amqp/upto.nogood.industries@NOGOOD.INDUSTRIES, 
> seqnum 160996154, subkey aes128-cts/4C79, session key aes128-cts/3329
> [0x2187480]:0 -> @sasl-init(65) [mechanism=:GSSAPI, 
> initial-response=b"`\x82\x02c\x06\x09*\x86H\x86\xf7\x12\x01\x02\x02\x01\x00n\x82\x02R0\x82\x02N\xa0\x03\x02\x01\x05\xa1\x03\x02\x01\x0e\xa2\x07\x03\x05\x00
>  
> \x00\x00\x00\xa3\x82\x01oa\x82\x01k0\x82\x01g\xa0\x03\x02\x01\x05\xa1\x13\x1b\x11NOGOOD.INDUSTRIES\xa2)0'\xa0\x03\x02\x01\x03\xa1
>  
> 0\x1e\x1b\x04amqp\x1b\x16upto.nogood.industries\xa3\x82\x01\x1e0\x82\x01\x1a\xa0\x03\x02\x01\x11\xa1\x03\x02\x01\x06\xa2\x82\x01\x0c\x04\x82\x01\x08\x91\x86\xd8\x9f\x081\xde\x87{?\x02a\xdf\xdc\x82\x81{L%+u\xd9\\xad\xf4J\xdbO\x9cAhi\x97\x97\xdd/q\xa7\xd2a\xa9\x0e\x88H\x00\x87S\xf3\xdc\xcf\x1c\xfc\xbd\x1b\x10\xb0\xf1\xf6\x88p'et-4~HQ\xce\x86d\x00\xd5\x99q\x90\xd7p\xee\x06`\xfc<\x85\xed\xbd\xe7xO\x09\xc6\x1d'\xb7j\x88l4\xa3\xfc\x9b\xab\xc6\x18\x12/!d\xdd\x13\x11\x84\x950\xa2z_2\x82#qb\x16\xa5Dz\x7f\x0a\xbb\xe1\xc9\xa9\xd6\xea\x14\xed\x8e\x0e\x96\xe3\x04\x9bz{\x7f\x9ff\xc4\xbd\x1cn\x1d\x8f\xe8\x18\x1bp\xc7\xbf\x1c(\xcb\xfa5yG|\x8f\x09FI\x86\x93?\x10\x13\x17Q\xfc\xa3\x9d\xe3R\xe1\x00\xb1\xe0\x90\x9a\x99\x01\x00\xdduS_\xd7<\x96\xceE\xf1"'pW\xa1T\x0f\xc9\xff\x83t\x01>\x8b\xb40\xcbD\xb2e\xb3\xdd\x0dN(\x15\xe8_\xf4\xf5H\xc0#\xb1\x07=\x07\x85!)\xf2\xd7\xb6\xef\xb6<\xc2\xcb\x06\xc6\xc9\xa7f\xe7\xe6'\xe6C\x05\xf2\x9d\xe2\xa4\x81\xc50\x81\xc2\xa0\x03\x02\x01\x11\xa2\x81\xba\x04\x81\xb7\x94\xb9\xcb\x10\xb4(?\xee\xa5s\x01\xe0\x8fh\xbf[\xa5w\x9a\xe5\x8az\xaa\xbasC\xfd\xf4\xa5\x12O\x19T\x15\xcce\x0b\x84/6\x00\x9c\xec\xb9\xc7\x1f\x0b\x1fY\x94\xc4\xd2\xa74(=\xbfL:oS\xcc\xe8\xe1\xceBA"\xcd\xa3\xd5s\\xfcG\x1aW\x8c)\xb5:V\xc3|\x97\xc0Q\x12Y
>  
> \xfc\xaaK\x95A$s\xdc\xcb\xc5\xdb\x86\xff\x11\xbb\xbe\xfd\xf0A\xb6Q\xf3.QP\xfb\xa5\x85\xb8\xd7f\xe8\xb9\xb8\xa6\x13h\x82q\x80\x08\xf8\\xcb\x19\xa7\xd3\x94\xf4\xa8\xcf\x89,\x8a\xa4(\x10(\x0aj\xa9[0\x87\x14\xb7|y\x83\x81z\x16\xe8\xf6i\\x19\x0b\xc4\xa1\x87$\xc0\x0bi.\x7f\xea\xd4\xfan*B"]
> [0x2187480]:0 <- @sasl-challenge(66) 
> [challenge=b"`j\x06\x09*\x86H\x86\xf7\x12\x01\x02\x02\x02\x00o[0Y\xa0\x03\x02\x01\x05\xa1\x03\x02\x01\x0f\xa2M0K\xa0\x03\x02\x01\x11\xa2D\x04BkF\x94\x1f\x1a\x00\xf24\xbd\xa0r\x1f\x08\xac\x88\x8c\xa4\x9af\xc1#\xd6\x08\x0b=k~\xf1>"\xbflBgi\x1a"\x1f
>  
> \xbd\x80\x1a4\xd5\xc1\xb4\xe1\x85j-\x9e\x81\xa2\xc9\xd9B>\xc8\xb5a<\xf2\x06\x1a"]
> [15271] 1502727697.949917: Read AP-REP, time 1502727697.649131, subkey 
> (null), seqnum 804124638
> [0x2187480]:0 -> @sasl-response(67) []<
> [0x2187480]:0 <- @sasl-challenge(66) 
> [challenge=b"\x05\x04\x01\xff\x00\x0c\x00\x00\x00\x00\x00\x00/\xed\xf7\xde\x01\x01\x00\x00L\xea\xca\x166j\x1b\xf7hVmq"]
> [0x2187480]:0 -> @sasl-response(67) 
> [response=b"\x05\x04\x00\xff\x00\x0c\x00\x00\x00\x00\x00\x00\x09\x98\x9b:\x01\x00\x00\x00\xf7Q\xd1\x86\x91\x87]
>  \xe3\xbaH\xfd"]
> [0x2187480]:  <- EOS
> [0x2187480]:  -> EOS
> terminate called after throwing an instance of 'proton::error'
>   what():  amqp:connection:framing-error: connection aborted
> Aborted (core dumped)
> {noformat}
> {noformat}
> Caused by: org.apache.qpid.proton.codec.DecodeException: Unexpected null 
> value - mandatory field not set? (the response field is mandatory)
> at 
> org.apache.qpid.proton.codec.DynamicTypeConstructor.readValue(DynamicTypeConstructor.java:43)
>

[jira] [Commented] (PROTON-1539) Kerberos SASL exchange results in malformed SASL response frame

2017-08-14 Thread ASF subversion and git services (JIRA)


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

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

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

PROTON-1539: Ensure that SASL challenge and response frames generate a binary
- And never a null even if the binary is zero length


> Kerberos SASL exchange results in malformed SASL response frame
> ---
>
> Key: PROTON-1539
> URL: https://issues.apache.org/jira/browse/PROTON-1539
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Reporter: Justin Ross
>Assignee: Andrew Stitcher
>
> {noformat}
> [jross@localhost clients]$ PN_TRACE_FRM=1 ./connect upto.nogood.industries 
> jgecko@NOGOOD.INDUSTRIES
> [0x2187480]:  -> SASL
> [0x2187480]:  <- SASL
> [0x2187480]:0 <- @sasl-mechanisms(64) 
> [sasl-server-mechanisms=@PN_SYMBOL[:GSSAPI]]
> [15271] 1502727697.649006: ccselect module realm chose cache 
> KEYRING:persistent:1000:1000 with client principal jgecko@NOGOOD.INDUSTRIES 
> for server principal amqp/upto.nogood.industries@NOGOOD.INDUSTRIES
> [15271] 1502727697.649050: Getting credentials jgecko@NOGOOD.INDUSTRIES -> 
> amqp/upto.nogood.industries@NOGOOD.INDUSTRIES using ccache 
> KEYRING:persistent:1000:1000
> [15271] 1502727697.649097: Retrieving jgecko@NOGOOD.INDUSTRIES -> 
> amqp/upto.nogood.industries@NOGOOD.INDUSTRIES from 
> KEYRING:persistent:1000:1000 with result: 0/Success
> [15271] 1502727697.649127: Creating authenticator for 
> jgecko@NOGOOD.INDUSTRIES -> amqp/upto.nogood.industries@NOGOOD.INDUSTRIES, 
> seqnum 160996154, subkey aes128-cts/4C79, session key aes128-cts/3329
> [0x2187480]:0 -> @sasl-init(65) [mechanism=:GSSAPI, 
> initial-response=b"`\x82\x02c\x06\x09*\x86H\x86\xf7\x12\x01\x02\x02\x01\x00n\x82\x02R0\x82\x02N\xa0\x03\x02\x01\x05\xa1\x03\x02\x01\x0e\xa2\x07\x03\x05\x00
>  
> \x00\x00\x00\xa3\x82\x01oa\x82\x01k0\x82\x01g\xa0\x03\x02\x01\x05\xa1\x13\x1b\x11NOGOOD.INDUSTRIES\xa2)0'\xa0\x03\x02\x01\x03\xa1
>  
> 0\x1e\x1b\x04amqp\x1b\x16upto.nogood.industries\xa3\x82\x01\x1e0\x82\x01\x1a\xa0\x03\x02\x01\x11\xa1\x03\x02\x01\x06\xa2\x82\x01\x0c\x04\x82\x01\x08\x91\x86\xd8\x9f\x081\xde\x87{?\x02a\xdf\xdc\x82\x81{L%+u\xd9\\xad\xf4J\xdbO\x9cAhi\x97\x97\xdd/q\xa7\xd2a\xa9\x0e\x88H\x00\x87S\xf3\xdc\xcf\x1c\xfc\xbd\x1b\x10\xb0\xf1\xf6\x88p'et-4~HQ\xce\x86d\x00\xd5\x99q\x90\xd7p\xee\x06`\xfc<\x85\xed\xbd\xe7xO\x09\xc6\x1d'\xb7j\x88l4\xa3\xfc\x9b\xab\xc6\x18\x12/!d\xdd\x13\x11\x84\x950\xa2z_2\x82#qb\x16\xa5Dz\x7f\x0a\xbb\xe1\xc9\xa9\xd6\xea\x14\xed\x8e\x0e\x96\xe3\x04\x9bz{\x7f\x9ff\xc4\xbd\x1cn\x1d\x8f\xe8\x18\x1bp\xc7\xbf\x1c(\xcb\xfa5yG|\x8f\x09FI\x86\x93?\x10\x13\x17Q\xfc\xa3\x9d\xe3R\xe1\x00\xb1\xe0\x90\x9a\x99\x01\x00\xdduS_\xd7<\x96\xceE\xf1"'pW\xa1T\x0f\xc9\xff\x83t\x01>\x8b\xb40\xcbD\xb2e\xb3\xdd\x0dN(\x15\xe8_\xf4\xf5H\xc0#\xb1\x07=\x07\x85!)\xf2\xd7\xb6\xef\xb6<\xc2\xcb\x06\xc6\xc9\xa7f\xe7\xe6'\xe6C\x05\xf2\x9d\xe2\xa4\x81\xc50\x81\xc2\xa0\x03\x02\x01\x11\xa2\x81\xba\x04\x81\xb7\x94\xb9\xcb\x10\xb4(?\xee\xa5s\x01\xe0\x8fh\xbf[\xa5w\x9a\xe5\x8az\xaa\xbasC\xfd\xf4\xa5\x12O\x19T\x15\xcce\x0b\x84/6\x00\x9c\xec\xb9\xc7\x1f\x0b\x1fY\x94\xc4\xd2\xa74(=\xbfL:oS\xcc\xe8\xe1\xceBA"\xcd\xa3\xd5s\\xfcG\x1aW\x8c)\xb5:V\xc3|\x97\xc0Q\x12Y
>  
> \xfc\xaaK\x95A$s\xdc\xcb\xc5\xdb\x86\xff\x11\xbb\xbe\xfd\xf0A\xb6Q\xf3.QP\xfb\xa5\x85\xb8\xd7f\xe8\xb9\xb8\xa6\x13h\x82q\x80\x08\xf8\\xcb\x19\xa7\xd3\x94\xf4\xa8\xcf\x89,\x8a\xa4(\x10(\x0aj\xa9[0\x87\x14\xb7|y\x83\x81z\x16\xe8\xf6i\\x19\x0b\xc4\xa1\x87$\xc0\x0bi.\x7f\xea\xd4\xfan*B"]
> [0x2187480]:0 <- @sasl-challenge(66) 
> [challenge=b"`j\x06\x09*\x86H\x86\xf7\x12\x01\x02\x02\x02\x00o[0Y\xa0\x03\x02\x01\x05\xa1\x03\x02\x01\x0f\xa2M0K\xa0\x03\x02\x01\x11\xa2D\x04BkF\x94\x1f\x1a\x00\xf24\xbd\xa0r\x1f\x08\xac\x88\x8c\xa4\x9af\xc1#\xd6\x08\x0b=k~\xf1>"\xbflBgi\x1a"\x1f
>  
> \xbd\x80\x1a4\xd5\xc1\xb4\xe1\x85j-\x9e\x81\xa2\xc9\xd9B>\xc8\xb5a<\xf2\x06\x1a"]
> [15271] 1502727697.949917: Read AP-REP, time 1502727697.649131, subkey 
> (null), seqnum 804124638
> [0x2187480]:0 -> @sasl-response(67) []<
> [0x2187480]:0 <- @sasl-challenge(66) 
> [challenge=b"\x05\x04\x01\xff\x00\x0c\x00\x00\x00\x00\x00\x00/\xed\xf7\xde\x01\x01\x00\x00L\xea\xca\x166j\x1b\xf7hVmq"]
> [0x2187480]:0 -> @sasl-response(67) 
> [response=b"\x05\x04\x00\xff\x00\x0c\x00\x00\x00\x00\x00\x00\x09\x98\x9b:\x01\x00\x00\x00\xf7Q\xd1\x86\x91\x87]
>  \xe3\xbaH\xfd"]
> [0x2187480]:  <- EOS
> [0x2187480]:  -> EOS
> terminate called after throwing an instance of 'proton::error'
>   what():  amqp:connection:framing-error: connection aborted
> Aborted (core dumped)
>

[jira] [Commented] (DISPATCH-209) Three+ router test is needed in the system test suite.

2017-08-14 Thread ASF subversion and git services (JIRA)


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

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

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

DISPATCH-209 : change name and add new all-test topology


> Three+ router test is needed in the system test suite.
> --
>
> Key: DISPATCH-209
> URL: https://issues.apache.org/jira/browse/DISPATCH-209
> Project: Qpid Dispatch
>  Issue Type: New Feature
>  Components: Tests
>Reporter: Ted Ross
>Assignee: michael goulish
> Fix For: 1.0.0
>
>
> There have arisen some issues that would have been caught had there been a 
> three-router test in the regression suite.  This test should be added.



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

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

[jira] [Created] (PROTON-1539) Kerberos SASL exchange results in malformed SASL response frame

2017-08-14 Thread Justin Ross (JIRA)

Justin Ross created PROTON-1539:
---

 Summary: Kerberos SASL exchange results in malformed SASL response 
frame
 Key: PROTON-1539
 URL: https://issues.apache.org/jira/browse/PROTON-1539
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-c
Reporter: Justin Ross
Assignee: Andrew Stitcher


{noformat}
[jross@localhost clients]$ PN_TRACE_FRM=1 ./connect upto.nogood.industries 
jgecko@NOGOOD.INDUSTRIES
[0x2187480]:  -> SASL
[0x2187480]:  <- SASL
[0x2187480]:0 <- @sasl-mechanisms(64) 
[sasl-server-mechanisms=@PN_SYMBOL[:GSSAPI]]
[15271] 1502727697.649006: ccselect module realm chose cache 
KEYRING:persistent:1000:1000 with client principal jgecko@NOGOOD.INDUSTRIES for 
server principal amqp/upto.nogood.industries@NOGOOD.INDUSTRIES
[15271] 1502727697.649050: Getting credentials jgecko@NOGOOD.INDUSTRIES -> 
amqp/upto.nogood.industries@NOGOOD.INDUSTRIES using ccache 
KEYRING:persistent:1000:1000
[15271] 1502727697.649097: Retrieving jgecko@NOGOOD.INDUSTRIES -> 
amqp/upto.nogood.industries@NOGOOD.INDUSTRIES from KEYRING:persistent:1000:1000 
with result: 0/Success
[15271] 1502727697.649127: Creating authenticator for jgecko@NOGOOD.INDUSTRIES 
-> amqp/upto.nogood.industries@NOGOOD.INDUSTRIES, seqnum 160996154, subkey 
aes128-cts/4C79, session key aes128-cts/3329
[0x2187480]:0 -> @sasl-init(65) [mechanism=:GSSAPI, 
initial-response=b"`\x82\x02c\x06\x09*\x86H\x86\xf7\x12\x01\x02\x02\x01\x00n\x82\x02R0\x82\x02N\xa0\x03\x02\x01\x05\xa1\x03\x02\x01\x0e\xa2\x07\x03\x05\x00
 
\x00\x00\x00\xa3\x82\x01oa\x82\x01k0\x82\x01g\xa0\x03\x02\x01\x05\xa1\x13\x1b\x11NOGOOD.INDUSTRIES\xa2)0'\xa0\x03\x02\x01\x03\xa1
 
0\x1e\x1b\x04amqp\x1b\x16upto.nogood.industries\xa3\x82\x01\x1e0\x82\x01\x1a\xa0\x03\x02\x01\x11\xa1\x03\x02\x01\x06\xa2\x82\x01\x0c\x04\x82\x01\x08\x91\x86\xd8\x9f\x081\xde\x87{?\x02a\xdf\xdc\x82\x81{L%+u\xd9\\xad\xf4J\xdbO\x9cAhi\x97\x97\xdd/q\xa7\xd2a\xa9\x0e\x88H\x00\x87S\xf3\xdc\xcf\x1c\xfc\xbd\x1b\x10\xb0\xf1\xf6\x88p'et-4~HQ\xce\x86d\x00\xd5\x99q\x90\xd7p\xee\x06`\xfc<\x85\xed\xbd\xe7xO\x09\xc6\x1d'\xb7j\x88l4\xa3\xfc\x9b\xab\xc6\x18\x12/!d\xdd\x13\x11\x84\x950\xa2z_2\x82#qb\x16\xa5Dz\x7f\x0a\xbb\xe1\xc9\xa9\xd6\xea\x14\xed\x8e\x0e\x96\xe3\x04\x9bz{\x7f\x9ff\xc4\xbd\x1cn\x1d\x8f\xe8\x18\x1bp\xc7\xbf\x1c(\xcb\xfa5yG|\x8f\x09FI\x86\x93?\x10\x13\x17Q\xfc\xa3\x9d\xe3R\xe1\x00\xb1\xe0\x90\x9a\x99\x01\x00\xdduS_\xd7<\x96\xceE\xf1"'pW\xa1T\x0f\xc9\xff\x83t\x01>\x8b\xb40\xcbD\xb2e\xb3\xdd\x0dN(\x15\xe8_\xf4\xf5H\xc0#\xb1\x07=\x07\x85!)\xf2\xd7\xb6\xef\xb6<\xc2\xcb\x06\xc6\xc9\xa7f\xe7\xe6'\xe6C\x05\xf2\x9d\xe2\xa4\x81\xc50\x81\xc2\xa0\x03\x02\x01\x11\xa2\x81\xba\x04\x81\xb7\x94\xb9\xcb\x10\xb4(?\xee\xa5s\x01\xe0\x8fh\xbf[\xa5w\x9a\xe5\x8az\xaa\xbasC\xfd\xf4\xa5\x12O\x19T\x15\xcce\x0b\x84/6\x00\x9c\xec\xb9\xc7\x1f\x0b\x1fY\x94\xc4\xd2\xa74(=\xbfL:oS\xcc\xe8\xe1\xceBA"\xcd\xa3\xd5s\\xfcG\x1aW\x8c)\xb5:V\xc3|\x97\xc0Q\x12Y
 
\xfc\xaaK\x95A$s\xdc\xcb\xc5\xdb\x86\xff\x11\xbb\xbe\xfd\xf0A\xb6Q\xf3.QP\xfb\xa5\x85\xb8\xd7f\xe8\xb9\xb8\xa6\x13h\x82q\x80\x08\xf8\\xcb\x19\xa7\xd3\x94\xf4\xa8\xcf\x89,\x8a\xa4(\x10(\x0aj\xa9[0\x87\x14\xb7|y\x83\x81z\x16\xe8\xf6i\\x19\x0b\xc4\xa1\x87$\xc0\x0bi.\x7f\xea\xd4\xfan*B"]
[0x2187480]:0 <- @sasl-challenge(66) 
[challenge=b"`j\x06\x09*\x86H\x86\xf7\x12\x01\x02\x02\x02\x00o[0Y\xa0\x03\x02\x01\x05\xa1\x03\x02\x01\x0f\xa2M0K\xa0\x03\x02\x01\x11\xa2D\x04BkF\x94\x1f\x1a\x00\xf24\xbd\xa0r\x1f\x08\xac\x88\x8c\xa4\x9af\xc1#\xd6\x08\x0b=k~\xf1>"\xbflBgi\x1a"\x1f
 
\xbd\x80\x1a4\xd5\xc1\xb4\xe1\x85j-\x9e\x81\xa2\xc9\xd9B>\xc8\xb5a<\xf2\x06\x1a"]
[15271] 1502727697.949917: Read AP-REP, time 1502727697.649131, subkey (null), 
seqnum 804124638
[0x2187480]:0 -> @sasl-response(67) []<
[0x2187480]:0 <- @sasl-challenge(66) 
[challenge=b"\x05\x04\x01\xff\x00\x0c\x00\x00\x00\x00\x00\x00/\xed\xf7\xde\x01\x01\x00\x00L\xea\xca\x166j\x1b\xf7hVmq"]
[0x2187480]:0 -> @sasl-response(67) 
[response=b"\x05\x04\x00\xff\x00\x0c\x00\x00\x00\x00\x00\x00\x09\x98\x9b:\x01\x00\x00\x00\xf7Q\xd1\x86\x91\x87]
 \xe3\xbaH\xfd"]
[0x2187480]:  <- EOS
[0x2187480]:  -> EOS
terminate called after throwing an instance of 'proton::error'
  what():  amqp:connection:framing-error: connection aborted
Aborted (core dumped)
{noformat}

{noformat}
Caused by: org.apache.qpid.proton.codec.DecodeException: Unexpected null value 
- mandatory field not set? (the response field is mandatory)
at 
org.apache.qpid.proton.codec.DynamicTypeConstructor.readValue(DynamicTypeConstructor.java:43)
 [proton-j-0.20.0.jar:]
at 
org.apache.qpid.proton.codec.DecoderImpl.readObject(DecoderImpl.java:885) 
[proton-j-0.20.0.jar:]
at 
org.apache.qpid.proton.engine.impl.SaslFrameParser.input(SaslFrameParser.java:349)
 [proton-j-0.20.0.jar:]
... 22 more
Caused by: java.lang.NullPointerException: the response field is mandatory
at

[jira] [Resolved] (DISPATCH-802) refuse transaction coordination links if they can't be routed to a coordinator

2017-08-14 Thread Ganesh Murthy (JIRA)


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

Ganesh Murthy resolved DISPATCH-802.

   Resolution: Fixed
Fix Version/s: 1.0.0

> refuse transaction coordination links if they can't be routed to a coordinator
> --
>
> Key: DISPATCH-802
> URL: https://issues.apache.org/jira/browse/DISPATCH-802
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 0.8.0
>Reporter: Robbie Gemmell
>Assignee: Ganesh Murthy
> Fix For: 1.0.0
>
>
> The router is accepting transaction coordinator links even if the support 
> from DISPATCH-195 is not being used to link-route them somewhere that can 
> handle coordination. If the router can't link-route to a coordinator, and 
> knows it can't coordinate transactions itself, it shouldn't accept the links 
> to begin with but rather refuse them so clients know they will never work and 
> why.
> Prior to 0.8.0, credit was also given on these links, allowing attempt to 
> declare transactions. From 0.8.0 no credit is given since there is no 
> receiver, so clients have no way to use the accepted link and no indication 
> why.



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

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

[jira] [Resolved] (DISPATCH-775) allow authentication against a remote server

2017-08-14 Thread Gordon Sim (JIRA)


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

Gordon Sim resolved DISPATCH-775.
-
Resolution: Fixed

> allow authentication against a remote server
> 
>
> Key: DISPATCH-775
> URL: https://issues.apache.org/jira/browse/DISPATCH-775
> Project: Qpid Dispatch
>  Issue Type: New Feature
>Reporter: Gordon Sim
>Assignee: Gordon Sim
>
> When running lots of routers, it would be handy to be able to have them all 
> authenticate against some centralized, external auth service. This can be 
> done by relaying the AMQP SASL frames to that remote service.



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

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

[jira] [Commented] (DISPATCH-802) refuse transaction coordination links if they can't be routed to a coordinator

2017-08-14 Thread ASF subversion and git services (JIRA)


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

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

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

DISPATCH-802 - Refuse transaction coordination links if they can't be routed to 
a coordinator since the router by itself cannot coordinate transactions.

(cherry picked from commit d17f7b58b95886ca4ee03aac7deba4eb5cad679d)


> refuse transaction coordination links if they can't be routed to a coordinator
> --
>
> Key: DISPATCH-802
> URL: https://issues.apache.org/jira/browse/DISPATCH-802
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 0.8.0
>Reporter: Robbie Gemmell
>Assignee: Ganesh Murthy
>
> The router is accepting transaction coordinator links even if the support 
> from DISPATCH-195 is not being used to link-route them somewhere that can 
> handle coordination. If the router can't link-route to a coordinator, and 
> knows it can't coordinate transactions itself, it shouldn't accept the links 
> to begin with but rather refuse them so clients know they will never work and 
> why.
> Prior to 0.8.0, credit was also given on these links, allowing attempt to 
> declare transactions. From 0.8.0 no credit is given since there is no 
> receiver, so clients have no way to use the accepted link and no indication 
> why.



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

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

[jira] [Commented] (DISPATCH-775) allow authentication against a remote server

2017-08-14 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on DISPATCH-775:
-

Github user grs closed the pull request at:

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


> allow authentication against a remote server
> 
>
> Key: DISPATCH-775
> URL: https://issues.apache.org/jira/browse/DISPATCH-775
> Project: Qpid Dispatch
>  Issue Type: New Feature
>Reporter: Gordon Sim
>Assignee: Gordon Sim
>
> When running lots of routers, it would be handy to be able to have them all 
> authenticate against some centralized, external auth service. This can be 
> done by relaying the AMQP SASL frames to that remote service.



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

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

[GitHub] qpid-dispatch pull request #188: DISPATCH-775: provide a plugin that will de...

2017-08-14 Thread grs

Github user grs closed the pull request at:

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


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

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

[jira] [Created] (DISPATCH-808) Setting defaultDistribution: unavailable blocks qdmanage

2017-08-14 Thread Ulf Lilleengen (JIRA)

Ulf Lilleengen created DISPATCH-808:
---

 Summary: Setting defaultDistribution: unavailable blocks qdmanage
 Key: DISPATCH-808
 URL: https://issues.apache.org/jira/browse/DISPATCH-808
 Project: Qpid Dispatch
  Issue Type: Bug
 Environment: 

Reporter: Ulf Lilleengen
Priority: Minor


If I specify defaultDistribution: unavailable in the router {} block, qdmanage 
prints

LinkDetached: sender 2dc356e7-d1cc-45d4-b5f2-2c76023a5e52-$management to 
$management closed due to: Condition('amqp:not-found', 'Node not found')

If I add 

{code}
address {
   prefix: $management
}
{code}


to the config, it works. As a default, I would expect that an implicit address 
such as '$management' should just work without any extra config even if the 
default distribution is unavailable.



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

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

[jira] [Commented] (DISPATCH-775) allow authentication against a remote server

2017-08-14 Thread ASF subversion and git services (JIRA)


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

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

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

DISPATCH-775: allow delegation of sasl authentication to a remote 
authentication service


> allow authentication against a remote server
> 
>
> Key: DISPATCH-775
> URL: https://issues.apache.org/jira/browse/DISPATCH-775
> Project: Qpid Dispatch
>  Issue Type: New Feature
>Reporter: Gordon Sim
>Assignee: Gordon Sim
>
> When running lots of routers, it would be handy to be able to have them all 
> authenticate against some centralized, external auth service. This can be 
> done by relaying the AMQP SASL frames to that remote service.



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

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

[jira] [Commented] (DISPATCH-775) allow authentication against a remote server

2017-08-14 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on DISPATCH-775:
-

GitHub user grs opened a pull request:

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

DISPATCH-775: provide a plugin that will delegate sasl authentication…

… to a specified authentication service

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

$ git pull https://github.com/grs/qpid-dispatch DISPATCH-775

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

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


commit dae2cfa8689e2f309e1763bd2b0afeb9db09d926
Author: Gordon Sim 
Date:   2017-08-14T15:59:32Z

DISPATCH-775: provide a plugin that will delegate sasl authentication to a 
specified authentication service




> allow authentication against a remote server
> 
>
> Key: DISPATCH-775
> URL: https://issues.apache.org/jira/browse/DISPATCH-775
> Project: Qpid Dispatch
>  Issue Type: New Feature
>Reporter: Gordon Sim
>Assignee: Gordon Sim
>
> When running lots of routers, it would be handy to be able to have them all 
> authenticate against some centralized, external auth service. This can be 
> done by relaying the AMQP SASL frames to that remote service.



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

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

[GitHub] qpid-dispatch pull request #188: DISPATCH-775: provide a plugin that will de...

2017-08-14 Thread grs

GitHub user grs opened a pull request:

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

DISPATCH-775: provide a plugin that will delegate sasl authenticationâ¦

â¦ to a specified authentication service

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

$ git pull https://github.com/grs/qpid-dispatch DISPATCH-775

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

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


commit dae2cfa8689e2f309e1763bd2b0afeb9db09d926
Author: Gordon Sim 
Date:   2017-08-14T15:59:32Z

DISPATCH-775: provide a plugin that will delegate sasl authentication to a 
specified authentication service




---
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] [Comment Edited] (QPID-7869) [Java Broker] Truststore improvements

2017-08-14 Thread Keith Wall (JIRA)


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

Keith Wall edited comment on QPID-7869 at 8/14/17 3:29 PM:
---

Further comment as discussed:

# getCertificatesInternal/getCertificates are near duplicates.   If we change 
{{FileTrustStore}} so that trustManagers and certificates are cached onOpen, 
the need for {{getCertificatesInternal}} disappears.
# The text of the descriptions reads slightly awkwardly:
## TrustStore#CERTIFICATE_EXPIRY_WARN_PERIOD  perhaps "The number of days 
before a certificate's expiry that certificate expiration warnings will be 
written to the log".
## TrustStore#CERTIFICATE_EXPIRY_CHECK_FREQUENCY perhaps "Period (in days) with 
which the Broker will repeat the certificate expiration warning'.




was (Author: k-wall):
Further comment as discussed:

# getCertificatesInternal/getCertificates are near duplicates.   If we change 
{{FileTrustStore}} so that trustManagers and certificates are cached onOpen, 
the need for {{getCertificatesInternal}} disappears.
# The text of the descriptions reads slightly awkwardly:
## TrustStore#CERTIFICATE_EXPIRY_WARN_PERIOD  perhaps "The number of days 
before a certificate's expiry that certificate expiration warnings will be 
written to the log".
## TrustStore#CERTIFICATE_EXPIRY_CHECK_FREQUENCY perhaps "Period (in days) with 
which the Broker will repeat the certificate expiration warning'.


The number of days before a certificate expires that warnings willl

certificate expire warnings will be produced n days  
The amount of notice given  before a certificate expirations.

The point in time (days

The number of days before the certificate expiry date"
  + " to issue the operational log warning about the 
certificate expiry

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



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

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

[jira] [Resolved] (QPID-7888) [Java Client] [Documentation] Correct typo in end to end encryption connection url examples

2017-08-14 Thread Lorenz Quack (JIRA)


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

Lorenz Quack resolved QPID-7888.

Resolution: Fixed

> [Java Client] [Documentation] Correct typo in end to end encryption 
> connection url examples
> ---
>
> Key: QPID-7888
> URL: https://issues.apache.org/jira/browse/QPID-7888
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Client, Java Documentation
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Minor
> Fix For: qpid-java-client-0-x-6.3.0
>
>
> As highlighted by this thread:
> https://stackoverflow.com/questions/45583101/encrypted-messages-using-apache-qpid
> there is a typo in the connection urls used in the example.



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

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

[jira] [Updated] (QPID-7888) [Java Client] [Documentation] Correct typo in end to end encryption connection url examples

2017-08-14 Thread Lorenz Quack (JIRA)


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

Lorenz Quack updated QPID-7888:
---
Status: Reviewable  (was: In Progress)

> [Java Client] [Documentation] Correct typo in end to end encryption 
> connection url examples
> ---
>
> Key: QPID-7888
> URL: https://issues.apache.org/jira/browse/QPID-7888
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Client, Java Documentation
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Minor
> Fix For: qpid-java-client-0-x-6.3.0
>
>
> As highlighted by this thread:
> https://stackoverflow.com/questions/45583101/encrypted-messages-using-apache-qpid
> there is a typo in the connection urls used in the example.



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

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

[jira] [Commented] (QPID-7887) [Java Broker] Message conversion error handling

2017-08-14 Thread Rob Godfrey (JIRA)


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

Rob Godfrey commented on QPID-7887:
---

would it not make sense to add a "reject" policy which would reject the message 
instance (thus making it ineligible for sending to this target again) while 
leaving it eligible for consumption by consumers of the native protocol?

> [Java Broker] Message conversion error handling
> ---
>
> Key: QPID-7887
> URL: https://issues.apache.org/jira/browse/QPID-7887
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Lorenz Quack
> Fix For: qpid-java-broker-7.0.0
>
>
> The work done in QPID-7434 means that {{MessageConversionExceptions}} are now 
> thrown when errors in message conversion are encountered. These exceptions 
> need to be handled.
> The following handling is proposed:
> There is a context variable 
> {{qpid.queue.messageConversion.exceptionHandlingPolicy}} which materialises 
> at the {{Queue}} level and can take one of these values:
> * {{"close"}} - the connection(0-x)/link(1.0) to the consumer will be closed
> * {{"routeToAlternate"}} - the message will be routed to the alternate 
> destination or deleted if no alternative destination is configured. If the 
> consumer is a QueueBrowser it should simply skip the message in question 
> without triggering this behaviour.
> {{"close"}} should be the default.



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

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

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

2017-08-14 Thread Keith Wall (JIRA)


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

Keith Wall commented on QPID-7869:
--

Further comment as discussed:

# getCertificatesInternal/getCertificates are near duplicates.   If we change 
{{FileTrustStore}} so that trustManagers and certificates are cached onOpen, 
the need for {{getCertificatesInternal}} disappears.
# The text of the descriptions reads slightly awkwardly:
## TrustStore#CERTIFICATE_EXPIRY_WARN_PERIOD  perhaps "The number of days 
before a certificate's expiry that certificate expiration warnings will be 
written to the log".
## TrustStore#CERTIFICATE_EXPIRY_CHECK_FREQUENCY perhaps "Period (in days) with 
which the Broker will repeat the certificate expiration warning'.


The number of days before a certificate expires that warnings willl

certificate expire warnings will be produced n days  
The amount of notice given  before a certificate expirations.

The point in time (days

The number of days before the certificate expiry date"
  + " to issue the operational log warning about the 
certificate expiry

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



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

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

[jira] [Commented] (QPID-7815) Reject policy type

2017-08-14 Thread Lorenz Quack (JIRA)


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

Lorenz Quack commented on QPID-7815:


The stuff around {{AbstractQueue#createPostEnqueueOverflowPolicyHandler}} seems 
weird.
There are two calls to it, in {{onOpen}} and {{changeAttributes}}. After both 
calls we create a {{RejectPolicyHandler}} if necessary but {{onOpen}} we also 
call {{RejectPolicyHandler#onQueueOpen}}. However, {{onQueueOpen}} seems to 
duplicate the work done in the constructor (which in turn duplicates the work 
done in {{RejectPolicyHandler#addMessageDeleteListener}}).
I suggest 
* call {{RejectPolicyHandler#addMessageDeleteListener}} from the constructor 
instead of duplicating the code.
* remove {{RejectPolicyHandler#onQueueOpen}} and the call to it from 
{{AbstractQueue#onOpen}}.
* move creation of {{RejectPolicyHandler}} to 
{{AbstractQueue#createPostEnqueueOverflowPolicyHandler}}

> Reject policy type
> --
>
> Key: QPID-7815
> URL: https://issues.apache.org/jira/browse/QPID-7815
> Project: Qpid
>  Issue Type: New Feature
>  Components: Java Broker
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Tomas Vavricka
>  Labels: policy-type, queue, reject
> Fix For: qpid-java-broker-7.0.0
>
> Attachments: 0001-QPID-7815-Add-support-for-reject-policy.patch, 
> 0001-QPID-7815-Fix-recovery-of-queue-with-reject-policy.patch, 
> 0001-QPID-7815-Java-Broker-Enable-QueuePolicyTests-on-all.patch, 
> 0001-QPID-7815-Reject-policy-type.patch, 1 before restart.png, 2 after 
> restart.png, broker.log, default.json
>
>
> It would be good if Java Broker will support reject policy.
> Reject policy - reject incoming message(s) when queue capacity is reached
> Queue capacity can be defined by maximum count of message and maximum size of 
> messages (including header).



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

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

[jira] [Commented] (QPID-7887) [Java Broker] Message conversion error handling

2017-08-14 Thread ASF subversion and git services (JIRA)


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

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

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

QPID-7887: [Java Broker] Message conversion error handling


> [Java Broker] Message conversion error handling
> ---
>
> Key: QPID-7887
> URL: https://issues.apache.org/jira/browse/QPID-7887
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Lorenz Quack
> Fix For: qpid-java-broker-7.0.0
>
>
> The work done in QPID-7434 means that {{MessageConversionExceptions}} are now 
> thrown when errors in message conversion are encountered. These exceptions 
> need to be handled.
> The following handling is proposed:
> There is a context variable 
> {{qpid.queue.messageConversion.exceptionHandlingPolicy}} which materialises 
> at the {{Queue}} level and can take one of these values:
> * {{"close"}} - the connection(0-x)/link(1.0) to the consumer will be closed
> * {{"routeToAlternate"}} - the message will be routed to the alternate 
> destination or deleted if no alternative destination is configured. If the 
> consumer is a QueueBrowser it should simply skip the message in question 
> without triggering this behaviour.
> {{"close"}} should be the default.



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

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

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

2017-08-14 Thread Keith Wall (JIRA)


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

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

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

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

2017-08-14 Thread Keith Wall (JIRA)


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

Keith Wall commented on QPID-7781:
--

Looks reasonable to me.

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

[jira] [Commented] (QPID-7872) [Java Broker] [AMQP 1.0] Message expiry should be driven from ttl header only

2017-08-14 Thread Lorenz Quack (JIRA)


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

Lorenz Quack commented on QPID-7872:


It seems that the part of the JIRA description that says "Ensure TTL is 
adjusted before sending the message" was not implemented.
Either that needs to be done or it needs to be split out into another JIRA.

> [Java Broker] [AMQP 1.0] Message expiry should be driven from ttl header only
> -
>
> Key: QPID-7872
> URL: https://issues.apache.org/jira/browse/QPID-7872
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Reporter: Alex Rudyy
> Fix For: qpid-java-broker-7.0.0
>
>
> Java broker should only discard message with ttl header set if TTL expires 
> including 0 values. Ensure TTL is adjusted before sending the message.



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

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

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

2017-08-14 Thread Keith Wall (JIRA)


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

Keith Wall commented on QPID-7434:
--

I notice that the conversion layer currently does not take into account 
{{JMS_QPID_DESTTYPE}} which is used to help the 0-8..91 path of the AMQP 0-x 
Qpid JMS Client reconstitute the {{Message#JMSDestination}} when BURLs are in 
use.   It would be possible of the Broker's conversion layer to add this hint 
when converting from 0-8..0-91, but I don't think this is required.  The 
existing client code already has a fallback 
{{AbstractAMQMessageDelegate#generateDestination}} which is used when the  
{{JMS_QPID_DESTTYPE}}  is absent.  This should given usable address, which is 
probably good enough for most use-cases.   

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



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

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

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

2017-08-14 Thread Keith Wall (JIRA)


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

Keith Wall edited comment on QPID-7434 at 8/14/17 1:16 PM:
---

I notice that the conversion layer currently does not take into account 
{{JMS_QPID_DESTTYPE}} which is used to help tAMQP 0-x Qpid JMS Client 
reconstitute the {{Message#JMSDestination}} when BURLs are in use.   It would 
be possible of the Broker's conversion layer to add this hint when converting 
from 0-8..0-91, but I don't think this is required.  The existing client code 
already has a fallback {{AbstractAMQMessageDelegate#generateDestination}} which 
is used when the  {{JMS_QPID_DESTTYPE}}  is absent.  This should given usable 
address, which is probably good enough for most use-cases.   


was (Author: k-wall):
I notice that the conversion layer currently does not take into account 
{{JMS_QPID_DESTTYPE}} which is used to help the 0-8..91 path of the AMQP 0-x 
Qpid JMS Client reconstitute the {{Message#JMSDestination}} when BURLs are in 
use.   It would be possible of the Broker's conversion layer to add this hint 
when converting from 0-8..0-91, but I don't think this is required.  The 
existing client code already has a fallback 
{{AbstractAMQMessageDelegate#generateDestination}} which is used when the  
{{JMS_QPID_DESTTYPE}}  is absent.  This should given usable address, which is 
probably good enough for most use-cases.   

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



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

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

[jira] [Commented] (QPID-7607) AMQP 1.0 conversion layer to use 'Map' x-opt-jms-msg-type annotation when message is representable as a JMS Map Message and recipent known to be the Qpid JMS Client

2017-08-14 Thread Keith Wall (JIRA)


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

Keith Wall commented on QPID-7607:
--

QPID-7434 changed the conversion layer.  {{x-opt-jms-msg-type}} is now set for 
converted stream or map messages, regardless of the client, if the content 
complies within the JMS restrictions for those messages types.   

> AMQP 1.0 conversion layer to use 'Map' x-opt-jms-msg-type annotation when 
> message is representable as a JMS Map Message and recipent known to be the 
> Qpid JMS Client 
> -
>
> Key: QPID-7607
> URL: https://issues.apache.org/jira/browse/QPID-7607
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
>Priority: Minor
> Fix For: qpid-java-broker-7.0.0
>
>
> If the AMQP 1.0 converts a message for the Qpid JMS Client and the body is a 
> Map whose content conforms to the JMSMapMessage restrictions (string keys, 
> restricted domain of values etc), the conversion layer should set the 
> “x-opt-jms-msg-type”  annotation with a Map value so that the client, on 
> receipt, will produce a JMS Map Message for the application.
> For map messages converted from other protocols to AMQP 1.0, this will ensure 
> fidelity (currently the user receives an ObjectMessage - see test 
> {{org.apache.qpid.jms.provider.amqp.message.AmqpCodecTest#testCreateAmqpObjectMessageFromAmqpValueWithMap}}).
> For management responses, this will ensure that many management responses can 
> be handled simply.  
> If the map does not conform to the JMS restrictions or the client is not a 
> Qpid JMS Client, the annotation must not be applied.
> Q:  how should the broker know the client understands the 
> “x-opt-jms-msg-type” annotation? 



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

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

[jira] [Resolved] (QPID-7607) AMQP 1.0 conversion layer to use 'Map' x-opt-jms-msg-type annotation when message is representable as a JMS Map Message and recipent known to be the Qpid JMS Client

2017-08-14 Thread Keith Wall (JIRA)


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

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

> AMQP 1.0 conversion layer to use 'Map' x-opt-jms-msg-type annotation when 
> message is representable as a JMS Map Message and recipent known to be the 
> Qpid JMS Client 
> -
>
> Key: QPID-7607
> URL: https://issues.apache.org/jira/browse/QPID-7607
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
>Priority: Minor
> Fix For: qpid-java-broker-7.0.0
>
>
> If the AMQP 1.0 converts a message for the Qpid JMS Client and the body is a 
> Map whose content conforms to the JMSMapMessage restrictions (string keys, 
> restricted domain of values etc), the conversion layer should set the 
> “x-opt-jms-msg-type”  annotation with a Map value so that the client, on 
> receipt, will produce a JMS Map Message for the application.
> For map messages converted from other protocols to AMQP 1.0, this will ensure 
> fidelity (currently the user receives an ObjectMessage - see test 
> {{org.apache.qpid.jms.provider.amqp.message.AmqpCodecTest#testCreateAmqpObjectMessageFromAmqpValueWithMap}}).
> For management responses, this will ensure that many management responses can 
> be handled simply.  
> If the map does not conform to the JMS restrictions or the client is not a 
> Qpid JMS Client, the annotation must not be applied.
> Q:  how should the broker know the client understands the 
> “x-opt-jms-msg-type” annotation? 



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

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

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

2017-08-14 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on PROTON-1532:


Github user alanconway commented on the issue:

https://github.com/apache/qpid-proton/pull/116
  
Already in progress. The patch is basically correct but I want to rework 
how initial-only configuration is passed to  use "connection options" passed to 
connect() rather than adding setters to the Connection, similar to the new C++ 
API. Will post for review shortly.


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



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

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

[GitHub] qpid-proton issue #116: PROTON-1532: Allow insecure mechanism in SASL

2017-08-14 Thread alanconway

Github user alanconway commented on the issue:

https://github.com/apache/qpid-proton/pull/116
  
Already in progress. The patch is basically correct but I want to rework 
how initial-only configuration is passed to  use "connection options" passed to 
connect() rather than adding setters to the Connection, similar to the new C++ 
API. Will post for review shortly.


---
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-7872) [Java Broker] [AMQP 1.0] Message expiry should be driven from ttl header only

2017-08-14 Thread Alex Rudyy (JIRA)


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

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

> [Java Broker] [AMQP 1.0] Message expiry should be driven from ttl header only
> -
>
> Key: QPID-7872
> URL: https://issues.apache.org/jira/browse/QPID-7872
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
> Fix For: qpid-java-broker-7.0.0
>
>
> Java broker should only discard message with ttl header set if TTL expires 
> including 0 values. Ensure TTL is adjusted before sending the message.



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

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

[jira] [Assigned] (QPID-7872) [Java Broker] [AMQP 1.0] Message expiry should be driven from ttl header only

2017-08-14 Thread Alex Rudyy (JIRA)


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

Alex Rudyy reassigned QPID-7872:


Assignee: Alex Rudyy

> [Java Broker] [AMQP 1.0] Message expiry should be driven from ttl header only
> -
>
> Key: QPID-7872
> URL: https://issues.apache.org/jira/browse/QPID-7872
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
> Fix For: qpid-java-broker-7.0.0
>
>
> Java broker should only discard message with ttl header set if TTL expires 
> including 0 values. Ensure TTL is adjusted before sending the message.



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

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

[jira] [Assigned] (QPID-7872) [Java Broker] [AMQP 1.0] Message expiry should be driven from ttl header only

2017-08-14 Thread Alex Rudyy (JIRA)


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

Alex Rudyy reassigned QPID-7872:


Assignee: (was: Alex Rudyy)

> [Java Broker] [AMQP 1.0] Message expiry should be driven from ttl header only
> -
>
> Key: QPID-7872
> URL: https://issues.apache.org/jira/browse/QPID-7872
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Reporter: Alex Rudyy
> Fix For: qpid-java-broker-7.0.0
>
>
> Java broker should only discard message with ttl header set if TTL expires 
> including 0 values. Ensure TTL is adjusted before sending the message.



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

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

[jira] [Commented] (QPID-7872) [Java Broker] [AMQP 1.0] Message expiry should be driven from ttl header only

2017-08-14 Thread ASF subversion and git services (JIRA)


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

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

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

QPID-7872: [Java Broker] [AMQP 1.0] Message expiry should be driven from ttl 
header only


> [Java Broker] [AMQP 1.0] Message expiry should be driven from ttl header only
> -
>
> Key: QPID-7872
> URL: https://issues.apache.org/jira/browse/QPID-7872
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Reporter: Alex Rudyy
> Fix For: qpid-java-broker-7.0.0
>
>
> Java broker should only discard message with ttl header set if TTL expires 
> including 0 values. Ensure TTL is adjusted before sending the message.



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

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

[jira] [Assigned] (QPID-7888) [Java Client] [Documentation] Correct typo in end to end encryption connection url examples

2017-08-14 Thread Keith Wall (JIRA)


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

Keith Wall reassigned QPID-7888:


Assignee: Keith Wall

> [Java Client] [Documentation] Correct typo in end to end encryption 
> connection url examples
> ---
>
> Key: QPID-7888
> URL: https://issues.apache.org/jira/browse/QPID-7888
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Client, Java Documentation
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Minor
> Fix For: qpid-java-client-0-x-6.3.0
>
>
> As highlighted by this thread:
> https://stackoverflow.com/questions/45583101/encrypted-messages-using-apache-qpid
> there is a typo in the connection urls used in the example.



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

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

44 matches

Mail list logo