[jira] [Commented] (DISPATCH-200) Flexible mapping from x.509 certificates to an identity

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on DISPATCH-200:
-

GitHub user ganeshmurthy opened a pull request:

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

DISPATCH-200 - Add a flexible mapping from x.509 certificate fields t…

…o an identity

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

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

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

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


commit 56e56ce2ee00fcca49d574c276f8e7dba2ca6187
Author: Ganesh Murthy 
Date:   2016-03-29T22:03:29Z

DISPATCH-200 - Add a flexible mapping from x.509 certificate fields to an 
identity




> Flexible mapping from x.509 certificates to an identity
> ---
>
> Key: DISPATCH-200
> URL: https://issues.apache.org/jira/browse/DISPATCH-200
> Project: Qpid Dispatch
>  Issue Type: New Feature
>  Components: Container
>Reporter: Ted Ross
>Assignee: Ganesh Murthy
> Fix For: 0.6
>
>
> x.509 certificates contain structured data.  It is necessary to be able to 
> generate a unique identity from a certificate for the purpose of indexing 
> into access policy.
> The proposed feature will contain a descriptor that is part of an ssl-profile 
> configuration that specifies the format and content of the identity in terms 
> of the fields of a certificate.
> For example, the identity can be the certificate fingerprint, or the 
> distinguished name, or the combination of more than one field.
> A further enhancement is to provide a secondary mapping from the above 
> identity to a configured nickname.  For example, a user may want to use the 
> fingerprint as the identity field but wishes to write policy and view 
> management data containing a more friendly "display" name rather than the raw 
> fingerprint.



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

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

[GitHub] qpid-dispatch pull request: DISPATCH-200 - Add a flexible mapping ...

[ganeshmurthy]

GitHub user ganeshmurthy opened a pull request:

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

DISPATCH-200 - Add a flexible mapping from x.509 certificate fields t…

…o an identity

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

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

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

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


commit 56e56ce2ee00fcca49d574c276f8e7dba2ca6187
Author: Ganesh Murthy 
Date:   2016-03-29T22:03:29Z

DISPATCH-200 - Add a flexible mapping from x.509 certificate fields to an 
identity




---
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] [Assigned] (DISPATCH-242) Add options to qdstat to display autoLinks and linkRoutes

[Ted Ross (JIRA)]

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

Ted Ross reassigned DISPATCH-242:
-

Assignee: Ted Ross

> Add options to qdstat to display autoLinks and linkRoutes
> -
>
> Key: DISPATCH-242
> URL: https://issues.apache.org/jira/browse/DISPATCH-242
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Console
>Reporter: Ted Ross
>Assignee: Ted Ross
> Fix For: 0.6
>
>
> In 0.6, there will be a few new management entities that contain interesting 
> monitoring data:  autoLink and linkRoute.  qdstat should be enhanced to 
> display these entities.



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

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

[jira] [Assigned] (DISPATCH-237) Dispatch Router overwrites delivery tag for link-routed deliveries

[Ted Ross (JIRA)]

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

Ted Ross reassigned DISPATCH-237:
-

Assignee: Ted Ross

> Dispatch Router overwrites delivery tag for link-routed deliveries
> --
>
> Key: DISPATCH-237
> URL: https://issues.apache.org/jira/browse/DISPATCH-237
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 0.5
>Reporter: Ted Ross
>Assignee: Ted Ross
> Fix For: 0.6
>
>
> Dispatch Router overwrites the delivery tags for messages that flow along 
> routed links.  The original delivery tags need to be preserved for link 
> routes.



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

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

[jira] [Updated] (DISPATCH-55) Qdrouterd does not exit when service port is unavailable

[Ted Ross (JIRA)]

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

Ted Ross updated DISPATCH-55:
-
Fix Version/s: (was: 0.6)
   0.7

> Qdrouterd does not exit when service port is unavailable
> 
>
> Key: DISPATCH-55
> URL: https://issues.apache.org/jira/browse/DISPATCH-55
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Container
>Affects Versions: 0.2
> Environment: Fedora 19, trunk build, x86_64
>Reporter: Chuck Rolke
> Fix For: 0.7
>
>
> When qdrouterd's port 5672 is in use then the router prints an error at 
> startup but otherwise keeps running with no apparent open port. Log from 
> failed startup:
> {noformat}
> Fri May 16 09:19:17 2014 CONN_MGR (INFO) Configured Listener: 0.0.0.0:amqp 
> role=normal
> Fri May 16 09:19:17 2014 SERVER (ERROR) Driver Error 0 ((null))
> Fri May 16 09:19:17 2014 SERVER (INFO) Operational, 4 Threads Running
> {noformat}
> Startup from when the port is available have the same log without the (ERROR) 
> line.
> Expected behavior is either 
> * a qpidd-like exit-with-failure-message or 
> * qdrouterd keeps trying to open the port and succeeds eventually.



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

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

[jira] [Updated] (DISPATCH-158) Dispatch should ignore frames after receiving close frame

[Ted Ross (JIRA)]

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

Ted Ross updated DISPATCH-158:
--
Fix Version/s: (was: 0.6)

> Dispatch should ignore frames after receiving close frame
> -
>
> Key: DISPATCH-158
> URL: https://issues.apache.org/jira/browse/DISPATCH-158
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 0.4
>Reporter: Pavel Moravec
>Priority: Minor
>
> (not sure if component matches, or if the bug isn't in proton, please change 
> accordingly)
> Having a client / mobile subscriber receiving messages that suddenly closes 
> the AMQP1.0 connection by sending "close" performative, the dispatch has to 
> ignore any further performatives on the connection (ideally raising a 
> warning). And it should not forward them further.
> See https://issues.jboss.org/browse/ENTMQCL-14 for an example of 
> malfunctioning client that sends close frame followed by flow frame (against 
> AMQP spec). Dispatch then forwards the flow frame (with invalid channel 
> number 65534 and invalid handle 4294967294) before closing the AMQP 
> connection. This flow should not be forwarded but ignored - dont propagate 
> misbehaviour in AMQP 1.0 communication.
> (dispatch router does not violate AMQP1.0 spec, "just" reacts on such 
> violation by sending wrong and ridiculous flow frame)



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

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

[jira] [Updated] (DISPATCH-177) Valgrind finds leaks when running dispatch w/SSL

[Ted Ross (JIRA)]

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

Ted Ross updated DISPATCH-177:
--
Assignee: Ken Giusti

> Valgrind finds leaks when running dispatch w/SSL
> 
>
> Key: DISPATCH-177
> URL: https://issues.apache.org/jira/browse/DISPATCH-177
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 0.5
>Reporter: Ken Giusti
>Assignee: Ken Giusti
> Fix For: 0.6
>
>
> See Pavel's results in https://issues.jboss.org/browse/ENTMQ-1149
> There are a few leaks that seem to be legit and will need investigation:
> ==26079== 7 bytes in 1 blocks are definitely lost in loss record 11 of 5,673
> ==26079==at 0x4C29BFD: malloc (in 
> /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==26079==by 0x5D34529: strdup (strdup.c:42)
> ==26079==by 0x4E4D988: qd_entity_get_string (in 
> /usr/lib64/libqpid-dispatch.so.0.1)
> ==26079==by 0x4E4B666: qd_dispatch_configure_connector (in 
> /usr/lib64/libqpid-dispatch.so.0.1)
> ==26079==by 0x12423DAB: ffi_call_unix64 (in /usr/lib64/libffi.so.6.0.1)
> ==26079==by 0x124236D4: ffi_call (in /usr/lib64/libffi.so.6.0.1)
> ==26079==by 0x12210C8A: _call_function_pointer (callproc.c:832)
> ==26079==by 0x12210C8A: _ctypes_callproc (callproc.c:1179)
> ==26079==by 0x1220AA84: PyCFuncPtr_call (_ctypes.c:3929)
> ==26079==by 0x5932072: PyObject_Call (abstract.c:2529)
> ==26079==by 0x59C634B: do_call (ceval.c:4316)
> ==26079==by 0x59C634B: call_function (ceval.c:4121)
> ==26079==by 0x59C634B: PyEval_EvalFrameEx (ceval.c:2740)
> ==26079==by 0x59C894F: fast_function (ceval.c:4184)
> ==26079==by 0x59C894F: call_function (ceval.c:4119)
> ==26079==by 0x59C894F: PyEval_EvalFrameEx (ceval.c:2740)
> ==26079==by 0x59C894F: fast_function (ceval.c:4184)
> ==26079==by 0x59C894F: call_function (ceval.c:4119)
> ==26079==by 0x59C894F: PyEval_EvalFrameEx (ceval.c:2740)
> ==26079== 10 bytes in 2 blocks are definitely lost in loss record 20 of 5,673
> ==26079==at 0x4C29BFD: malloc (in 
> /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==26079==by 0x5D34529: strdup (strdup.c:42)
> ==26079==by 0x4E4D988: qd_entity_get_string (in 
> /usr/lib64/libqpid-dispatch.so.0.1)
> ==26079==by 0x4E579C4: qd_router_configure_lrp (in 
> /usr/lib64/libqpid-dispatch.so.0.1)
> ==26079==by 0x4E4D671: qd_dispatch_configure_lrp (in 
> /usr/lib64/libqpid-dispatch.so.0.1)
> ==26079==by 0x12423DAB: ffi_call_unix64 (in /usr/lib64/libffi.so.6.0.1)
> ==26079==by 0x124236D4: ffi_call (in /usr/lib64/libffi.so.6.0.1)
> ==26079==by 0x12210C8A: _call_function_pointer (callproc.c:832)
> ==26079==by 0x12210C8A: _ctypes_callproc (callproc.c:1179)
> ==26079==by 0x1220AA84: PyCFuncPtr_call (_ctypes.c:3929)
> ==26079==by 0x5932072: PyObject_Call (abstract.c:2529)
> ==26079==by 0x59C634B: do_call (ceval.c:4316)
> ==26079==by 0x59C634B: call_function (ceval.c:4121)
> ==26079==by 0x59C634B: PyEval_EvalFrameEx (ceval.c:2740)
> ==26079==by 0x59C894F: fast_function (ceval.c:4184)
> ==26079==by 0x59C894F: call_function (ceval.c:4119)
> ==26079==by 0x59C894F: PyEval_EvalFrameEx (ceval.c:2740)
> ==26079== 240 bytes in 4 blocks are definitely lost in loss record 4,198 of 
> 5,673
> ==26079==at 0x4C29BFD: malloc (in 
> /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==26079==by 0x4E48986: qd_alloc (in /usr/lib64/libqpid-dispatch.so.0.1)
> ==26079==by 0x4E59B80: qd_router_add_lrp_ref_LH (in 
> /usr/lib64/libqpid-dispatch.so.0.1)
> ==26079==by 0x4E4E637: ??? (in /usr/lib64/libqpid-dispatch.so.0.1)
> ==26079==by 0x4E4C25B: ??? (in /usr/lib64/libqpid-dispatch.so.0.1)
> ==26079==by 0x4E5E9DB: ??? (in /usr/lib64/libqpid-dispatch.so.0.1)
> ==26079==by 0x52C7DF4: start_thread (pthread_create.c:308)
> ==26079==by 0x5DA41AC: clone (clone.S:113)
> ==26079== 248 bytes in 2 blocks are definitely lost in loss record 4,203 of 
> 5,673
> ==26079==at 0x4C29BFD: malloc (in 
> /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==26079==by 0x4E48986: qd_alloc (in /usr/lib64/libqpid-dispatch.so.0.1)
> ==26079==by 0x4E4FA2E: qd_field_iterator_string (in 
> /usr/lib64/libqpid-dispatch.so.0.1)
> ==26079==by 0x4E4C7E9: qd_container_register_node_type (in 
> /usr/lib64/libqpid-dispatch.so.0.1)
> ==26079==by 0x4E5C045: qd_router (in /usr/lib64/libqpid-dispatch.so.0.1)
> ==26079==by 0x4E4D6D1: qd_dispatch_prepare (in 
> /usr/lib64/libqpid-dispatch.so.0.1)
> ==26079==by 0x12423DAB: ffi_call_unix64 (in /usr/lib64/libffi.so.6.0.1)
> ==26079==by 0x124236D4: ffi_call (in /usr/lib64/libffi.so.6.0.1)
> ==26079==by 0x12210C8A: _call_function_pointer (callproc.c:832)
> ==26079==   

[jira] [Updated] (DISPATCH-187) CMake must choose the Python2 libraries when Python3 is available

[Ted Ross (JIRA)]

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

Ted Ross updated DISPATCH-187:
--
Fix Version/s: (was: 0.6)

> CMake must choose the Python2 libraries when Python3 is available
> -
>
> Key: DISPATCH-187
> URL: https://issues.apache.org/jira/browse/DISPATCH-187
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 0.5
>Reporter: Ted Ross
>Assignee: Ted Ross
>
> If the python3 development packages are present, the Dispatch CMake file 
> chooses version 3 which fails to build.  Dispatch uses the python2 extension 
> API.



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

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

Re: Review Request 45389: WIP PROTON-1133 - Avoid using hostname as a transport address

[Gordon Sim]

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



This looks good to me (and from what I can see is largely backwards compatible 
also?). However it needs to be extended to cover the 
Container.connect()/Connector._connect() and the container based examples.

- Gordon Sim


On March 29, 2016, 8:27 p.m., Kenneth Giusti wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/45389/
> ---
> 
> (Updated March 29, 2016, 8:27 p.m.)
> 
> 
> Review request for qpid, Gordon Sim, Justin Ross, and Robbie Gemmell.
> 
> 
> Bugs: PROTON-1133
> https://issues.apache.org/jira/browse/PROTON-1133
> 
> 
> Repository: qpid-proton-git
> 
> 
> Description
> ---
> 
> This involves a change to the Reactor API.
> 
> This patch implements a new API for creating outgoing connections via the 
> Reactor class: pn_reactor_connection_to_url().  It is meant to replace the 
> existing practice of creating a connection via pn_reactor_connection() then 
> setting the transport address in the connection's hostname field.
> 
> Not 100% convinced this is appropriate.  It introduces a URL parameter to the 
> Proton Connection object, where it may make better sense to associate the URL 
> with the Transport instead (pn_reactor_transport_to_url()???).
> 
> The URL parameter is used by the Proton iohandler to create the socket 
> connection.  If an application does not use the Proton iohandler (by 
> overriding the reactor's global handler), then it is the responsiblity of 
> whatever handler is being provided to use the URL to set up the socket 
> connection.  This was also the case for the old method that used the 
> connection's hostname setting, so this is not a behavioral change.
> 
> 
> Diffs
> -
> 
>   
> examples/java/reactor/src/main/java/org/apache/qpid/proton/example/reactor/Send.java
>  22da720 
>   examples/python/reactor/send.py c718780 
>   examples/python/reactor/tornado-send.py 54b8618 
>   proton-c/bindings/python/proton/reactor.py cda6248 
>   proton-c/include/proton/reactor.h e91b169 
>   proton-c/src/reactor/connection.c 4a57bfd 
>   proton-c/src/tests/reactor.c 1e706e2 
>   proton-j/src/main/java/org/apache/qpid/proton/engine/Connection.java 
> feff80b 
>   
> proton-j/src/main/java/org/apache/qpid/proton/engine/impl/ConnectionImpl.java 
> b708d83 
>   proton-j/src/main/java/org/apache/qpid/proton/reactor/Reactor.java 9d67d49 
>   proton-j/src/main/java/org/apache/qpid/proton/reactor/impl/IOHandler.java 
> 40eddac 
>   proton-j/src/main/java/org/apache/qpid/proton/reactor/impl/ReactorImpl.java 
> 0eb126a 
>   proton-j/src/test/java/org/apache/qpid/proton/reactor/ReactorTest.java 
> 10c591a 
>   tests/java/org/apache/qpid/proton/ProtonJInterop.java 31306ef 
> 
> Diff: https://reviews.apache.org/r/45389/diff/
> 
> 
> Testing
> ---
> 
> Updated unit tests and re-checked modified examples.
> 
> 
> Thanks,
> 
> Kenneth Giusti
> 
>

[jira] [Updated] (DISPATCH-120) qdrouterd command line improvements

[Ted Ross (JIRA)]

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

Ted Ross updated DISPATCH-120:
--
Fix Version/s: (was: 0.6)

> qdrouterd command line improvements
> ---
>
> Key: DISPATCH-120
> URL: https://issues.apache.org/jira/browse/DISPATCH-120
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Router Node
>Affects Versions: 0.4
>Reporter: Justin Ross
>
>  - Remove --include; this is a low priority function, and users can instead 
> use QPID_DISPATCH_HOME to control the python code loaded
>  - Group daemon-related options under a prefix.
> --deamon
> --pidfile -> --daemon-pid-file
> --user -> --daemon-user
> I would lose the short options (-d, -P, -U) for the daemon flags.  Short 
> options make sense for frequently used operations; otherwise they make 
> invocations harder to understand and consume short option namespace you might 
> prefer to use for something else in the future.
> --config, --daemon, and --help should remain unchanged.



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

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

[jira] [Resolved] (DISPATCH-57) Balance deliveries adaptively across all competing consumers in the network

[Ted Ross (JIRA)]

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

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

> Balance deliveries adaptively across all competing consumers in the network
> ---
>
> Key: DISPATCH-57
> URL: https://issues.apache.org/jira/browse/DISPATCH-57
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Router Node
>Reporter: Ted Ross
>Assignee: Ted Ross
> Fix For: 0.6
>
>
> When there are multiple competing consumers on an address across a network, 
> the network should balance deliveries to those consumers adaptively.  This 
> will cause more messages to be delivered to faster consumers and fewer 
> messages to slower consumers.
> The basic idea is that each router tracks the deliveries and can know how 
> many outstanding (unacked) deliveries have been sent via each outbound link.  
> It can then choose a link based on the smallest number of outstanding 
> deliveries.  Faster links will tend to have fewer deliveries and will get 
> preference in the balancing.



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

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

[jira] [Closed] (DISPATCH-236) Provide thread sanitizer build option

[Ted Ross (JIRA)]

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

Ted Ross closed DISPATCH-236.
-
Resolution: Won't Fix

Consider re-raising in the future when the thread-sanitize feature is more 
mature.

> Provide thread sanitizer build option
> -
>
> Key: DISPATCH-236
> URL: https://issues.apache.org/jira/browse/DISPATCH-236
> Project: Qpid Dispatch
>  Issue Type: Test
>  Components: Router Node
>Affects Versions: 0.5
>Reporter: Ken Giusti
>Assignee: Ken Giusti
>Priority: Minor
> Fix For: 0.6
>
>
> GNU C versions >= 4.8 add the ability to enable run-time thread checking.  
> Much like helgrind, but faster as it is built into the run time binary.
> Add a cmake configuration option to enable building the executable with 
> run-time thread checking.



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

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

[jira] [Updated] (DISPATCH-70) Configurable initial-credit and credit batching needed for incoming links

[Ted Ross (JIRA)]

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

Ted Ross updated DISPATCH-70:
-
Fix Version/s: (was: 0.6)

> Configurable initial-credit and credit batching needed for incoming links
> -
>
> Key: DISPATCH-70
> URL: https://issues.apache.org/jira/browse/DISPATCH-70
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Container
>Reporter: Ted Ross
>Assignee: Ted Ross
>
> Dispatch is currently hard-wired to issue initial credit for 1000 messages 
> and to replenish credit by one for every received message.
> Recent research done by Mick Goulish suggests that better performance can be 
> achieved by batching credit replenishment by 10-50 credits at a time, thus 
> amortizing the cost of flow processing.
> Initial credit and batch size should be configurable in the router.  It might 
> make sense to have a global configuration and per-connection configuration.



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

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

[jira] [Updated] (DISPATCH-227) Independent filtering of logging to consoles and log files.

[Ted Ross (JIRA)]

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

Ted Ross updated DISPATCH-227:
--
Fix Version/s: (was: 0.6)

> Independent filtering of logging to consoles and log files.
> ---
>
> Key: DISPATCH-227
> URL: https://issues.apache.org/jira/browse/DISPATCH-227
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Management Agent
>Affects Versions: 0.5
>Reporter: Alan Conway
>Assignee: Alan Conway
>
> Currently the log filter settings are global, the same settings apply to 
> every log destination (files, consoles etc.) We need to be able to configure 
> different log filters on a per-console or per-file basis. We also need a new 
> log output type which sends log messges to an address that a console can 
> subscribe to.



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

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

[jira] [Updated] (DISPATCH-185) Support for management notifications, log messages as notifications

[Ted Ross (JIRA)]

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

Ted Ross updated DISPATCH-185:
--
Fix Version/s: (was: 0.6)

> Support for management notifications, log messages as notifications
> ---
>
> Key: DISPATCH-185
> URL: https://issues.apache.org/jira/browse/DISPATCH-185
> Project: Qpid Dispatch
>  Issue Type: New Feature
>  Components: Management Agent
>Affects Versions: 0.5
>Reporter: Alan Conway
>Assignee: Alan Conway
> Attachments: management-events.rst
>
>
> Implement management notifications along the lines of discussion by the AMQP 
> management working group (draft attached)
> As a first test, allow a management client to subscribe for logging events. 
> Each client subscription should be able to set its own configuration for the 
> logging modules and levels that it wishes to receive, independently of the 
> global logging configuration. 
> The subscription mechanism should be general (as described in attached draft) 
> rather than specific to logging. Other notification event types will be added 
> in future.



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

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

[jira] [Resolved] (DISPATCH-166) Use test-controlled SASL configuration for system tests

[Ted Ross (JIRA)]

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

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

> Use test-controlled SASL configuration for system tests
> ---
>
> Key: DISPATCH-166
> URL: https://issues.apache.org/jira/browse/DISPATCH-166
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Tests
>Affects Versions: 0.5
>Reporter: Ted Ross
>Assignee: Chuck Rolke
> Fix For: 0.6
>
>
> Several of the SSL-related tests in the system-test suite can fail if the 
> in-effect SASL configuration does not support the EXTERNAL mechanism.  What 
> is needed is for the test suite to create a proper configuration and use that 
> for the routers under test.



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

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

[jira] [Updated] (DISPATCH-157) add sasl tests to dispatch unit tests

[Ted Ross (JIRA)]

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

Ted Ross updated DISPATCH-157:
--
Fix Version/s: (was: 0.6)

> add sasl tests to dispatch unit tests
> -
>
> Key: DISPATCH-157
> URL: https://issues.apache.org/jira/browse/DISPATCH-157
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Tests
>Affects Versions: 0.5
>Reporter: michael goulish
>Assignee: michael goulish
>
> Add a complete set of sasl tests to the Dispatch unit test framework.
> ensure correct behavior for cross-product of 
>authenticatePeer  := { no, yes, insecureOk }
>   x
>saslMechanisms:= { NONE, PLAIN, DIGEST-MD5, CRAM-MD5, GSSAPI, SRP }



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

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

[jira] [Assigned] (QPIDJMS-163) support populating the user-id field on produced messages

[Timothy Bish (JIRA)]

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

Timothy Bish reassigned QPIDJMS-163:


Assignee: Timothy Bish

> support populating the user-id field on produced messages
> -
>
> Key: QPIDJMS-163
> URL: https://issues.apache.org/jira/browse/QPIDJMS-163
> Project: Qpid JMS
>  Issue Type: Improvement
>  Components: qpid-jms-client
>Reporter: Robbie Gemmell
>Assignee: Timothy Bish
>
> Whilst the client supports using the JMS-defined "JMSXUserID" property to 
> interact with the contents of the binary user-id field on incoming AMQP 
> messages, it does not yet support automatically populating the value on 
> messages being sent by producers. We should add this support along with a 
> config toggle to enable/disable it.



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

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

Re: Review Request 45389: WIP PROTON-1133 - Avoid using hostname as a transport address

[Kenneth Giusti]

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

(Updated March 29, 2016, 8:27 p.m.)


Review request for qpid, Gordon Sim, Justin Ross, and Robbie Gemmell.


Bugs: PROTON-1133
https://issues.apache.org/jira/browse/PROTON-1133


Repository: qpid-proton-git


Description (updated)
---

This involves a change to the Reactor API.

This patch implements a new API for creating outgoing connections via the 
Reactor class: pn_reactor_connection_to_url().  It is meant to replace the 
existing practice of creating a connection via pn_reactor_connection() then 
setting the transport address in the connection's hostname field.

Not 100% convinced this is appropriate.  It introduces a URL parameter to the 
Proton Connection object, where it may make better sense to associate the URL 
with the Transport instead (pn_reactor_transport_to_url()???).

The URL parameter is used by the Proton iohandler to create the socket 
connection.  If an application does not use the Proton iohandler (by overriding 
the reactor's global handler), then it is the responsiblity of whatever handler 
is being provided to use the URL to set up the socket connection.  This was 
also the case for the old method that used the connection's hostname setting, 
so this is not a behavioral change.


Diffs (updated)
-

  
examples/java/reactor/src/main/java/org/apache/qpid/proton/example/reactor/Send.java
 22da720 
  examples/python/reactor/send.py c718780 
  examples/python/reactor/tornado-send.py 54b8618 
  proton-c/bindings/python/proton/reactor.py cda6248 
  proton-c/include/proton/reactor.h e91b169 
  proton-c/src/reactor/connection.c 4a57bfd 
  proton-c/src/tests/reactor.c 1e706e2 
  proton-j/src/main/java/org/apache/qpid/proton/engine/Connection.java feff80b 
  proton-j/src/main/java/org/apache/qpid/proton/engine/impl/ConnectionImpl.java 
b708d83 
  proton-j/src/main/java/org/apache/qpid/proton/reactor/Reactor.java 9d67d49 
  proton-j/src/main/java/org/apache/qpid/proton/reactor/impl/IOHandler.java 
40eddac 
  proton-j/src/main/java/org/apache/qpid/proton/reactor/impl/ReactorImpl.java 
0eb126a 
  proton-j/src/test/java/org/apache/qpid/proton/reactor/ReactorTest.java 
10c591a 
  tests/java/org/apache/qpid/proton/ProtonJInterop.java 31306ef 

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


Testing (updated)
---

Updated unit tests and re-checked modified examples.


Thanks,

Kenneth Giusti

[jira] [Resolved] (DISPATCH-241) Bias "spread" config with leading "/" on address has a "multicast" behavior

[Ganesh Murthy (JIRA)]

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

Ganesh Murthy resolved DISPATCH-241.

Resolution: Fixed

> Bias "spread" config with leading "/" on address has a "multicast" behavior
> ---
>
> Key: DISPATCH-241
> URL: https://issues.apache.org/jira/browse/DISPATCH-241
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 0.5
>Reporter: Paolo Patierno
>Assignee: Ganesh Murthy
> Fix For: 0.6
>
>
> I have following config :
> fixedAddress {
> prefix: /spread/
> fanout: single
> bias: spread
> }
> - fanout: single means that only one consumer will receive a message 
> published on /spread/ address (in a competing consumers fashion)
> - bias: spread means that the router sends message to only one consumer but 
> as documentation says "in an approximately even manner". It sounds to me that 
> the router tracks the consumers which receive message on that address and for 
> a new message tries to send it to another consumer.
> The problem is following :
> if more consumers attach to "spread/" all works fine (only one of them 
> receives message) but if they attach to "/spread/" (with leading "/") then 
> all consumers receive the message like a "multicast" configuration.



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

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

[jira] [Resolved] (DISPATCH-240) qdstat : leading "/" character effects a wrong showed address

[Ganesh Murthy (JIRA)]

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

Ganesh Murthy resolved DISPATCH-240.

Resolution: Fixed

> qdstat : leading "/" character effects a wrong showed address
> -
>
> Key: DISPATCH-240
> URL: https://issues.apache.org/jira/browse/DISPATCH-240
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 0.5
>Reporter: Paolo Patierno
>Assignee: Ganesh Murthy
>Priority: Minor
> Fix For: 0.6
>
>
> Hello,
> it seems that the qdstat tool has some problem with leading "/" character.
> If we connect to an address like "/multicast/" it's showed like "ulticast"; 
> instead removing the leading "/" the name is showed correctly.



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

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

[jira] [Closed] (DISPATCH-244) SASL library generates un-necessary DNS and LDAP requests

[Alan Conway (JIRA)]

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

Alan Conway closed DISPATCH-244.

Resolution: Fixed

Not a dispatch bug, this appears to be a problem with cyrus SASL in general. 
Has been observed with qpid C++ clients that are not even using proton.

> SASL library generates un-necessary DNS and LDAP requests
> -
>
> Key: DISPATCH-244
> URL: https://issues.apache.org/jira/browse/DISPATCH-244
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Tests
>Affects Versions: 0.5
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: 0.6
>
>
> The dispatch system tests (e.g. system_tests_management) run very slowly when 
> connected to a VPN.
> -  about 10x slower on VPN configured to use TCP connection
> -  about 5x slower on VPN configured for UDP connection
> Wireshark shows unexpected LDAP and DNS queries on the VPN interface. 
> `wallace` below is the local host name, but is not mentioned in any tests so 
> must be picked up by proton or dispatch at runtime:
> {code}
> 1 0.0 10.3.113.10810.11.6.1   LDAP242 
> searchRequest(11) "dc=redhat,dc=com" wholeSubtree 
> 2 0.035161000 10.3.113.10810.5.30.160 DNS 72  
> Standard query 0xd03f  A wallace.lab.bos.redhat.com
> {code}



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

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

[jira] [Closed] (DISPATCH-218) Dispatch system tests run very slowly if connected to a VPN

[Alan Conway (JIRA)]

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

Alan Conway closed DISPATCH-218.

Resolution: Fixed

Not a dispatch bug, this appears to be a problem with cyrus SASL in general. 
Has been observed with qpid C++ clients that are not even using proton.

> Dispatch system tests run very slowly if connected to a VPN
> ---
>
> Key: DISPATCH-218
> URL: https://issues.apache.org/jira/browse/DISPATCH-218
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Tests
>Affects Versions: 0.5
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: 0.6
>
>
> The dispatch system tests (e.g. system_tests_management) run very slowly when 
> connected to a VPN.
> -  about 10x slower on VPN configured to use TCP connection
> -  about 5x slower on VPN configured for UDP connection
> Wireshark shows unexpected LDAP and DNS queries on the VPN interface. 
> `wallace` below is the local host name, but is not mentioned in any tests so 
> must be picked up by proton or dispatch at runtime:
> {code}
> 1 0.0 10.3.113.10810.11.6.1   LDAP242 
> searchRequest(11) "dc=redhat,dc=com" wholeSubtree 
> 2 0.035161000 10.3.113.10810.5.30.160 DNS 72  
> Standard query 0xd03f  A wallace.lab.bos.redhat.com
> {code}



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

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

[jira] [Updated] (DISPATCH-194) Move libqpid-dispatch.so out of /lib

[Ted Ross (JIRA)]

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

Ted Ross updated DISPATCH-194:
--
Assignee: Chuck Rolke

> Move libqpid-dispatch.so out of /lib
> 
>
> Key: DISPATCH-194
> URL: https://issues.apache.org/jira/browse/DISPATCH-194
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Container
>Reporter: Ted Ross
>Assignee: Chuck Rolke
> Fix For: 0.6
>
>
> libqpid-dispatch.so currently is installed in /usr/lib[64].  This is overly 
> suggestive that this is a general-purpose library, which it is not.  This 
> file needs to be installed in a different location (libexec or 
> /lib/qpid-dispatch) to clarify its purpose.



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

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

[jira] [Updated] (QPID-7168) Allow authentication providers to resolve a realm qualified user identity into a displayable name

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7168:
-
Fix Version/s: qpid-java-6.1

> Allow authentication providers to resolve a realm qualified user identity 
> into a displayable name
> -
>
> Key: QPID-7168
> URL: https://issues.apache.org/jira/browse/QPID-7168
> Project: Qpid
>  Issue Type: New Feature
>  Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-6.1
>
>
> Extend the Authentication Provider interface to allow implementations to 
> resolve a realm qualified user identity into a human readable name.  If the 
> authentication provider does not recognise the realm, it is not capable of 
> resolving names or the name is not known, the provider must return null.  
> Callers must be prepared to handle null.
> Internally, providers may implement this method by calling out to the 
> authentication backend. Alternatively, the provider may maintain a cache of 
> names, populated as users authenticate.  The provider should be prepared to 
> be queried many times for a user's name during the lifetime of Broker's 
> execution, so should take steps to avoid expensive processing, if necessary.



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

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

[jira] [Created] (QPID-7168) Allow authentication providers to resolve a realm qualified user identity into a displayable name

[Keith Wall (JIRA)]

Keith Wall created QPID-7168:


 Summary: Allow authentication providers to resolve a realm 
qualified user identity into a displayable name
 Key: QPID-7168
 URL: https://issues.apache.org/jira/browse/QPID-7168
 Project: Qpid
  Issue Type: New Feature
  Components: Java Broker
Reporter: Keith Wall


Extend the Authentication Provider interface to allow implementations to 
resolve a realm qualified user identity into a human readable name.  If the 
authentication provider does not recognise the realm, it is not capable of 
resolving names or the name is not known, the provider must return null.  
Callers must be prepared to handle null.

Internally, providers may implement this method by calling out to the 
authentication backend. Alternatively, the provider may maintain a cache of 
names, populated as users authenticate.  The provider should be prepared to be 
queried many times for a user's name during the lifetime of Broker's execution, 
so should take steps to avoid expensive processing, if necessary.






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

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

[jira] [Resolved] (QPIDJMS-159) support producers having their existing credit drained

[Robbie Gemmell (JIRA)]

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

Robbie Gemmell resolved QPIDJMS-159.

   Resolution: Fixed
Fix Version/s: 0.9.0

> support producers having their existing credit drained
> --
>
> Key: QPIDJMS-159
> URL: https://issues.apache.org/jira/browse/QPIDJMS-159
> Project: Qpid JMS
>  Issue Type: Improvement
>  Components: qpid-jms-client
>Affects Versions: 0.8.0
>Reporter: Robbie Gemmell
>Assignee: Timothy Bish
> Fix For: 0.9.0
>
>
> Whilst the client does block/buffer messages upon send operations when a 
> producer link has no credit, and sends those messages when credit is again 
> granted, it doesnt appear to cooperate in existing credit being revoked 
> through the receiving broker/peer draining existing credit it previously 
> issued.



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

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

[jira] [Updated] (QPID-7159) [Java Client] Disabling user ids in AMQP messages

[Jakub Scholz (JIRA)]

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

Jakub Scholz updated QPID-7159:
---
Attachment: QPID-7159-conn-option.patch

Alternative patch which uses connection option instead of system property.

> [Java Client] Disabling user ids in AMQP messages
> -
>
> Key: QPID-7159
> URL: https://issues.apache.org/jira/browse/QPID-7159
> Project: Qpid
>  Issue Type: New Feature
>  Components: Java Client
>Reporter: Jakub Scholz
> Attachments: QPID-7159-conn-option.patch, QPID-7159.patch
>
>
> The AMQP 0-10 JMS client seems to always attach the user-id message property 
> to the AMQP message. 
> In some cases, I don't think this is desired. For example when I send 
> messages to my customers, I do not really want them to know which other users 
> exist on the broker and are used to send messages.
> It would be great to have a possibility to disable the user-id when needed. 
> The attached patch disables the user id in the BasicMessageProducer based on 
> a system property qpid.attach_user_id (true/false). Does that look like a 
> reasonable solution? If yes, I can try to add some tests.



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

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

[jira] [Commented] (QPID-7159) [Java Client] Disabling user ids in AMQP messages

[Jakub Scholz (JIRA)]

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

Jakub Scholz commented on QPID-7159:


Hi Alex,

You are right, connection option would be much better. I probably used system 
property just because it was easier to implement at the moment - I do not have 
any special reason why I need system property, so maybe we don't need it at 
all. 

I attached updated patch with new connection option attachUserId (I'm not sure 
what is preferred - whether camel case or snake case - both seem to be used by 
different options). Please have a look.

Thanks & Regards
Jakub

> [Java Client] Disabling user ids in AMQP messages
> -
>
> Key: QPID-7159
> URL: https://issues.apache.org/jira/browse/QPID-7159
> Project: Qpid
>  Issue Type: New Feature
>  Components: Java Client
>Reporter: Jakub Scholz
> Attachments: QPID-7159.patch
>
>
> The AMQP 0-10 JMS client seems to always attach the user-id message property 
> to the AMQP message. 
> In some cases, I don't think this is desired. For example when I send 
> messages to my customers, I do not really want them to know which other users 
> exist on the broker and are used to send messages.
> It would be great to have a possibility to disable the user-id when needed. 
> The attached patch disables the user id in the BasicMessageProducer based on 
> a system property qpid.attach_user_id (true/false). Does that look like a 
> reasonable solution? If yes, I can try to add some tests.



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

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

[jira] [Created] (QPIDJMS-163) support populating the user-id field on produced messages

[Robbie Gemmell (JIRA)]

Robbie Gemmell created QPIDJMS-163:
--

 Summary: support populating the user-id field on produced messages
 Key: QPIDJMS-163
 URL: https://issues.apache.org/jira/browse/QPIDJMS-163
 Project: Qpid JMS
  Issue Type: Improvement
  Components: qpid-jms-client
Reporter: Robbie Gemmell


Whilst the client supports using the JMS-defined "JMSXUserID" property to 
interact with the contents of the binary user-id field on incoming AMQP 
messages, it does not yet support automatically populating the value on 
messages being sent by producers. We should add this support along with a 
config toggle to enable/disable it.



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

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

[jira] [Comment Edited] (QPID-7116) Ability to utilise group information from a LDAP compatible directory

[Keith Wall (JIRA)]

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

Keith Wall edited comment on QPID-7116 at 3/29/16 4:18 PM:
---

There is also a second common way of representing group membership within a 
Directory.  The group names may also be held as values of the a {{memberOf}} 
attribute within the user's directory entry itself.  For this, no separate 
group query is required.  It is not clear to me if we can hint to the bind to 
bring back this extra attribute, or in a separate search is required including 
{{memberOf}}.  


was (Author: k-wall):
There is also a second common way of representing group membership within a 
Directory.  The group names may also be hold as values of the a {{memberOf}} 
attribute within the user's directory entry itself.  For this, no separate 
group query is required.  It is not clear to me if we can hint to the bind to 
bring back this extra attribute, or in a separate search is required including 
{{memberOf}}.  

> Ability to utilise group information from a LDAP compatible directory
> -
>
> Key: QPID-7116
> URL: https://issues.apache.org/jira/browse/QPID-7116
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-6.1
>
>
> The Java Broker can already authenticate users against an LDAP compatible 
> directory.  It should also be able to use the same information source as a 
> source of group information too.
> The authentication provide needs to accept optional attributes governing 
> where the group information will be found:
> {{groupSearchContext}} - the base entry for the role search. If not 
> specified, the search base is the top-level directory context.
> {{groupSearchFilter}} - the LDAP search filter for selecting group entries.  
> A {0} token within the filter will be replaced by the distinguish name of the 
> authenticated user.
> {{groupAttributeName}} - the name of the attribute that contains the name of 
> the role.
> After the authentication provider has successfully bound (authenticated) the 
> user, it should perform a second query for the groups.  It should build a 
> {{GroupPrincipal}} for each group to which the user belongs and return this 
> as part of the AuthenticationResult.   If the group search attributes are not 
> found, the group search should be skipped.
> A future version if the LDAP Authentication Provider may offer the ability to 
> cache the group results for a DN period of time.  This would serve to avoid 
> hitting the Directory several times authentication (it already hits the 
> Directory twice if {{bindWithoutSearch}} is false, this will add a third).



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

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

[jira] [Resolved] (QPIDJMS-157) Add support for send timeout and request timeout options

[Timothy Bish (JIRA)]

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

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

> Add support for send timeout and request timeout options
> 
>
> Key: QPIDJMS-157
> URL: https://issues.apache.org/jira/browse/QPIDJMS-157
> Project: Qpid JMS
>  Issue Type: New Feature
>  Components: qpid-jms-client
>Affects Versions: 0.8.0
>Reporter: Timothy Bish
>Assignee: Timothy Bish
> Fix For: 0.9.0
>
>
> Add support for a timeout option for message sends.  In the case of failover 
> allow the send to timeout after some configured interval with an error 
> indicating the send failed.



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

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

[jira] [Updated] (QPID-7167) Make user/group names produced by LDAP authentication and group provider be realm qualified

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7167:
-
Description: 
For the LDAP provider, identities (users/groups) produced should be in the form:

{noformat}{identity}@{realm}{noformat}

where identity is the distinguished name of the user which has been encoded 
(how?).  The realm should be any valid realm defined by Section 6 RFC-4120.

For the LDAP Provider, the realm could be defaulted, perhaps to be the full 
qualified host name of the LDAP server itself.


  was:
For the LDAP provider, identities produced should be in the form:

{noformat}{identity}@{realm}{noformat}

where identity is the distinguished name of the user which has been encoded 
(how?).  The realm should be any valid realm defined by Section 6 RFC-4120.

For the LDAP Provider, the realm could be defaulted, perhaps to be the full 
qualified host name of the LDAP server itself.



> Make user/group names produced by LDAP authentication and group provider be 
> realm qualified
> ---
>
> Key: QPID-7167
> URL: https://issues.apache.org/jira/browse/QPID-7167
> Project: Qpid
>  Issue Type: Sub-task
>  Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-6.1
>
>
> For the LDAP provider, identities (users/groups) produced should be in the 
> form:
> {noformat}{identity}@{realm}{noformat}
> where identity is the distinguished name of the user which has been encoded 
> (how?).  The realm should be any valid realm defined by Section 6 RFC-4120.
> For the LDAP Provider, the realm could be defaulted, perhaps to be the full 
> qualified host name of the LDAP server itself.



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

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

[jira] [Updated] (QPID-7167) Make user/group names produced by LDAP authentication and group provider be realm qualified

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7167:
-
Description: 
For the LDAP provider, identities produced should be in the form:

{noformat}{identity}@{realm}{noformat}

where identity is the distinguished name of the user which has been encoded 
(how?).  The realm should be any valid realm defined by Section 6 RFC-4120.

For the LDAP Provider, the realm could be defaulted, perhaps to be the full 
qualified host name of the LDAP server itself.


  was:For the LDAP provider, identities produced should be in the form {norma


> Make user/group names produced by LDAP authentication and group provider be 
> realm qualified
> ---
>
> Key: QPID-7167
> URL: https://issues.apache.org/jira/browse/QPID-7167
> Project: Qpid
>  Issue Type: Sub-task
>  Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-6.1
>
>
> For the LDAP provider, identities produced should be in the form:
> {noformat}{identity}@{realm}{noformat}
> where identity is the distinguished name of the user which has been encoded 
> (how?).  The realm should be any valid realm defined by Section 6 RFC-4120.
> For the LDAP Provider, the realm could be defaulted, perhaps to be the full 
> qualified host name of the LDAP server itself.



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

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

[jira] [Commented] (QPID-6984) [Web Management Console] Allow queries to the saved for later use

[Rob Godfrey (JIRA)]

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

Rob Godfrey commented on QPID-6984:
---

So, I don't really think that Queries are managed/configured objects... I think 
we have a general class of things (like user preferences) which can be 
associated with a Principal, and that those things might attach anywhere in the 
object hierarchy...  I wonder if what we have is a "preferences store" (which 
might be provided by the config store in the same way that message stores can 
be).  When an object is deleted, all preferences associated with that object 
would need deleting too - we perhaps would also need to think about how to 
remove preferences for principals which are no longer in use.

I worry about using config to model preferences a) because we'd need a new 
category every time we invent a new sort of preference and b) because using 
configured objects makes changes to preferences single-threads and block other 
(actual) config operations.

> [Web Management Console] Allow queries to the saved for later use
> -
>
> Key: QPID-6984
> URL: https://issues.apache.org/jira/browse/QPID-6984
> Project: Qpid
>  Issue Type: Improvement
>Reporter: Keith Wall
>
> After defining a query (QPID-6969) the user should be able to save query so 
> it may be conveniently re-run at a later time either during the same session, 
> or future sessions (after logging in again).  The user should also have the 
> ability to recall an existing query for edit, or delete a query.  In the long 
> term queries should be sharable amongst members of a group.
> This will require the ability to persist the query to the configuration 
> store.  To support HA properly, a query defined against a virtual host when 
> the mastership is a node A should be still available to the user when the 
> mastership flips to another node.  This implies that virtual host based 
> queries should be part of the virtualhost's configuration.



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

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

[jira] [Updated] (QPID-7167) Make user/group names produced by LDAP authentication and group provider be realm qualified

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7167:
-
Description: For the LDAP provider, identities produced should be in the 
form {norma

> Make user/group names produced by LDAP authentication and group provider be 
> realm qualified
> ---
>
> Key: QPID-7167
> URL: https://issues.apache.org/jira/browse/QPID-7167
> Project: Qpid
>  Issue Type: Sub-task
>  Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-6.1
>
>
> For the LDAP provider, identities produced should be in the form {norma



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

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

[jira] [Created] (QPID-7167) Make user/group names produced by LDAP authentication and group provider be realm qualified

[Keith Wall (JIRA)]

Keith Wall created QPID-7167:


 Summary: Make user/group names produced by LDAP authentication and 
group provider be realm qualified
 Key: QPID-7167
 URL: https://issues.apache.org/jira/browse/QPID-7167
 Project: Qpid
  Issue Type: Sub-task
  Components: Java Broker
Reporter: Keith Wall
 Fix For: qpid-java-6.1






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

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

[jira] [Updated] (QPID-7166) Make user/group names produced by authentication and group providers realm qualified

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7166:
-
Description: 
Change the existing authentication providers/group providers to produce 
principals contain a realm qualified names.

The realm qualified name will be in the form: 
{noformat}{identity}@{realm}{noformat}  The identity and realm will need to be 
encoded (how?).

The formation of the realm name will follow Section 6 RFC-4120. Ultimately all 
authentication and group providers will have an {{realmName}}.  The Broker will 
enforce a business rule that all realm names are unique.

Some authentication provides will capable of defaulting the realm name.  For 
instance, an LDAP authentication provider might default its realm name to be 
the full qualified domain name of the LDAP server itself.  If the provider has 
a default, this must be overridable, to allow duplicate realm names to be avoid.

https://cwiki.apache.org/confluence/display/qpid/Identity+in+the+Java+Broker

  was:
Change the existing authentication providers/group providers to produce 
principals contain a realm qualified names.

The realm qualified name will be in the form {identity}@{realm}.  The identity 
and realm will need to be encoded (how?).

The formation of the realm name will follow Section 6 RFC-4120. Ultimately all 
authentication and group providers will have an {{realmName}}.  The Broker will 
enforce a business rule that all realm names are unique.

Some authentication provides will capable of defaulting the realm name.  For 
instance, an LDAP authentication provider might default its realm name to be 
the full qualified domain name of the LDAP server itself.  If the provider has 
a default, this must be overridable, to allow duplicate realm names to be avoid.

https://cwiki.apache.org/confluence/display/qpid/Identity+in+the+Java+Broker


> Make user/group names produced by authentication and group providers realm 
> qualified
> 
>
> Key: QPID-7166
> URL: https://issues.apache.org/jira/browse/QPID-7166
> Project: Qpid
>  Issue Type: New Feature
>  Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-6.1
>
>
> Change the existing authentication providers/group providers to produce 
> principals contain a realm qualified names.
> The realm qualified name will be in the form: 
> {noformat}{identity}@{realm}{noformat}  The identity and realm will need to 
> be encoded (how?).
> The formation of the realm name will follow Section 6 RFC-4120. Ultimately 
> all authentication and group providers will have an {{realmName}}.  The 
> Broker will enforce a business rule that all realm names are unique.
> Some authentication provides will capable of defaulting the realm name.  For 
> instance, an LDAP authentication provider might default its realm name to be 
> the full qualified domain name of the LDAP server itself.  If the provider 
> has a default, this must be overridable, to allow duplicate realm names to be 
> avoid.
> https://cwiki.apache.org/confluence/display/qpid/Identity+in+the+Java+Broker



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

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

[jira] [Created] (QPID-7166) Make user/group names produced by authentication and group providers realm qualified

[Keith Wall (JIRA)]

Keith Wall created QPID-7166:


 Summary: Make user/group names produced by authentication and 
group providers realm qualified
 Key: QPID-7166
 URL: https://issues.apache.org/jira/browse/QPID-7166
 Project: Qpid
  Issue Type: New Feature
  Components: Java Broker
Reporter: Keith Wall
 Fix For: qpid-java-6.1


Change the existing authentication providers/group providers to produce 
principals contain a realm qualified names.

The realm qualified name will be in the form {identity}@{realm}.  The identity 
and realm will need to be encoded (how?).

The formation of the realm name will follow Section 6 RFC-4120. Ultimately all 
authentication and group providers will have an {{realmName}}.  The Broker will 
enforce a business rule that all realm names are unique.

Some authentication provides will capable of defaulting the realm name.  For 
instance, an LDAP authentication provider might default its realm name to be 
the full qualified domain name of the LDAP server itself.  If the provider has 
a default, this must be overridable, to allow duplicate realm names to be avoid.

https://cwiki.apache.org/confluence/display/qpid/Identity+in+the+Java+Broker



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

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

[jira] [Commented] (QPID-7116) Ability to utilise group information from a LDAP compatible directory

[Keith Wall (JIRA)]

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

Keith Wall commented on QPID-7116:
--

There is also a second common way of representing group membership within a 
Directory.  The group names may also be hold as values of the a {{memberOf}} 
attribute within the user's directory entry itself.  For this, no separate 
group query is required.  It is not clear to me if we can hint to the bind to 
bring back this extra attribute, or in a separate search is required including 
{{memberOf}}.  

> Ability to utilise group information from a LDAP compatible directory
> -
>
> Key: QPID-7116
> URL: https://issues.apache.org/jira/browse/QPID-7116
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-6.1
>
>
> The Java Broker can already authenticate users against an LDAP compatible 
> directory.  It should also be able to use the same information source as a 
> source of group information too.
> The authentication provide needs to accept optional attributes governing 
> where the group information will be found:
> {{groupSearchContext}} - the base entry for the role search. If not 
> specified, the search base is the top-level directory context.
> {{groupSearchFilter}} - the LDAP search filter for selecting group entries.  
> A {0} token within the filter will be replaced by the distinguish name of the 
> authenticated user.
> {{groupAttributeName}} - the name of the attribute that contains the name of 
> the role.
> After the authentication provider has successfully bound (authenticated) the 
> user, it should perform a second query for the groups.  It should build a 
> {{GroupPrincipal}} for each group to which the user belongs and return this 
> as part of the AuthenticationResult.   If the group search attributes are not 
> found, the group search should be skipped.
> A future version if the LDAP Authentication Provider may offer the ability to 
> cache the group results for a DN period of time.  This would serve to avoid 
> hitting the Directory several times authentication (it already hits the 
> Directory twice if {{bindWithoutSearch}} is false, this will add a third).



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

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

[jira] [Updated] (QPID-7116) Ability to utilise group information from a LDAP compatible directory

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7116:
-
Description: 
The Java Broker can already authenticate users against an LDAP compatible 
directory.  It should also be able to use the same information source as a 
source of group information too.

The authentication provide needs to accept optional attributes governing where 
the group information will be found:

{{groupSearchContext}} - the base entry for the role search. If not specified, 
the search base is the top-level directory context.
{{groupSearchFilter}} - the LDAP search filter for selecting group entries.  A 
{0} token within the filter will be replaced by the distinguish name of the 
authenticated user.
{{groupAttributeName}} - the name of the attribute that contains the name of 
the role.

After the authentication provider has successfully bound (authenticated) the 
user, it should perform a second query for the groups.  It should build a 
{{GroupPrincipal}} for each group to which the user belongs and return this as 
part of the AuthenticationResult.   If the group search attributes are not 
found, the group search should be skipped.

A future version if the LDAP Authentication Provider may offer the ability to 
cache the group results for a DN period of time.  This would serve to avoid 
hitting the Directory several times authentication (it already hits the 
Directory twice if {{bindWithoutSearch}} is false, this will add a third).



  was:
The Java Broker can already authenticate users against an LDAP compatible 
directory.  It should also be able to use the same information source as a 
source of group information too.

The authentication provide needs to accept optional attributes governing where 
the group information will be found:

{{groupSearchContext}} - the base entry for the role search. If not specified, 
the search base is the top-level directory context.
{{groupSearchFilter}} - the LDAP search filter for selecting group entries.  A 
{0} token within the filter will be replaced by the distinguish name of the 
authenticated user.
{{groupAttributeName}} - the name of the attribute that contains the name of 
the role.

After the authentication provider has successfully bound (authenticated) the 
user, it should perform a second query for the groups.  It should build a 
{{GroupPrincipal}} for each group to which the user belongs and return this as 
part of the AuthenticationResult.   If the group search attributes are not 
found, the group search should be skipped.

A future version if the LDAP Authentication Provider may offer the ability to 
cache the group results for a DN period of time.  This would serve to avoid 
hitting the Directory several times authentication (it already hits the 
Directory twice if {{bindWithoutSearch}} is false, this will add a third).

 


> Ability to utilise group information from a LDAP compatible directory
> -
>
> Key: QPID-7116
> URL: https://issues.apache.org/jira/browse/QPID-7116
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-6.1
>
>
> The Java Broker can already authenticate users against an LDAP compatible 
> directory.  It should also be able to use the same information source as a 
> source of group information too.
> The authentication provide needs to accept optional attributes governing 
> where the group information will be found:
> {{groupSearchContext}} - the base entry for the role search. If not 
> specified, the search base is the top-level directory context.
> {{groupSearchFilter}} - the LDAP search filter for selecting group entries.  
> A {0} token within the filter will be replaced by the distinguish name of the 
> authenticated user.
> {{groupAttributeName}} - the name of the attribute that contains the name of 
> the role.
> After the authentication provider has successfully bound (authenticated) the 
> user, it should perform a second query for the groups.  It should build a 
> {{GroupPrincipal}} for each group to which the user belongs and return this 
> as part of the AuthenticationResult.   If the group search attributes are not 
> found, the group search should be skipped.
> A future version if the LDAP Authentication Provider may offer the ability to 
> cache the group results for a DN period of time.  This would serve to avoid 
> hitting the Directory several times authentication (it already hits the 
> Directory twice if {{bindWithoutSearch}} is false, this will add a third).



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

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

[jira] [Commented] (QPID-7159) [Java Client] Disabling user ids in AMQP messages

[Alex Rudyy (JIRA)]

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

Alex Rudyy commented on QPID-7159:
--

Hi Jakub,

The requested feature looks  really useful to me. We definitely should add it 
into client.
However, system properties are not very friendly in container environment. It 
seems it would be better also to add a connection option which would control 
whether user identity should be sent with messages.
What do you think about having both system property and connection option to 
disable sending of user IDs?


> [Java Client] Disabling user ids in AMQP messages
> -
>
> Key: QPID-7159
> URL: https://issues.apache.org/jira/browse/QPID-7159
> Project: Qpid
>  Issue Type: New Feature
>  Components: Java Client
>Reporter: Jakub Scholz
> Attachments: QPID-7159.patch
>
>
> The AMQP 0-10 JMS client seems to always attach the user-id message property 
> to the AMQP message. 
> In some cases, I don't think this is desired. For example when I send 
> messages to my customers, I do not really want them to know which other users 
> exist on the broker and are used to send messages.
> It would be great to have a possibility to disable the user-id when needed. 
> The attached patch disables the user id in the BasicMessageProducer based on 
> a system property qpid.attach_user_id (true/false). Does that look like a 
> reasonable solution? If yes, I can try to add some tests.



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

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

[jira] [Updated] (QPID-7116) Ability to utilise group information from a LDAP compatible directory

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7116:
-
Description: 
The Java Broker can already authenticate users against an LDAP compatible 
directory.  It should also be able to use the same information source as a 
source of group information too.

The authentication provide needs to accept optional attributes governing where 
the group information will be found:

{{groupSearchContext}} - the base entry for the role search. If not specified, 
the search base is the top-level directory context.
{{groupSearchFilter}} - the LDAP search filter for selecting group entries.  A 
{0} token within the filter will be replaced by the distinguish name of the 
authenticated user.
{{groupAttributeName}} - the name of the attribute that contains the name of 
the role.

After the authentication provider has successfully bound (authenticated) the 
user, it should perform a second query for the groups.  It should build a 
{{GroupPrincipal}} for each group to which the user belongs and return this as 
part of the AuthenticationResult.   If the group search attributes are not 
found, the group search should be skipped.

A future version if the LDAP Authentication Provider may offer the ability to 
cache the group results for a DN period of time.  This would serve to avoid 
hitting the Directory several times authentication (it already hits the 
Directory twice if {{bindWithoutSearch}} is false, this will add a third).

 

  was:
The Java Broker can already authenticate against an LDAP compatible directory.  
It should also be able to use the same information source as a source of group 
information too.




> Ability to utilise group information from a LDAP compatible directory
> -
>
> Key: QPID-7116
> URL: https://issues.apache.org/jira/browse/QPID-7116
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-6.1
>
>
> The Java Broker can already authenticate users against an LDAP compatible 
> directory.  It should also be able to use the same information source as a 
> source of group information too.
> The authentication provide needs to accept optional attributes governing 
> where the group information will be found:
> {{groupSearchContext}} - the base entry for the role search. If not 
> specified, the search base is the top-level directory context.
> {{groupSearchFilter}} - the LDAP search filter for selecting group entries.  
> A {0} token within the filter will be replaced by the distinguish name of the 
> authenticated user.
> {{groupAttributeName}} - the name of the attribute that contains the name of 
> the role.
> After the authentication provider has successfully bound (authenticated) the 
> user, it should perform a second query for the groups.  It should build a 
> {{GroupPrincipal}} for each group to which the user belongs and return this 
> as part of the AuthenticationResult.   If the group search attributes are not 
> found, the group search should be skipped.
> A future version if the LDAP Authentication Provider may offer the ability to 
> cache the group results for a DN period of time.  This would serve to avoid 
> hitting the Directory several times authentication (it already hits the 
> Directory twice if {{bindWithoutSearch}} is false, this will add a third).
>  



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

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

[jira] [Commented] (DISPATCH-201) Initial release of management console

[ASF subversion and git services (JIRA)]

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

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

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

DISPATCH-201 Updates for dispatch 0.6.0


> Initial release of management console
> -
>
> Key: DISPATCH-201
> URL: https://issues.apache.org/jira/browse/DISPATCH-201
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Console
>Affects Versions: 0.6
>Reporter: Ernest Allen
>Assignee: Ernest Allen
> Fix For: 0.6
>
>
> Add a management console. This is a web site that uses the router management 
> api to display topology and qdstat information.



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

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

[jira] [Updated] (QPID-7165) Allow query results to be sorted and paginated

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7165:
-
Issue Type: New Feature  (was: Bug)

> Allow query results to be sorted and paginated
> --
>
> Key: QPID-7165
> URL: https://issues.apache.org/jira/browse/QPID-7165
> Project: Qpid
>  Issue Type: New Feature
>  Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-6.1
>
>
> Extend the mechanism provided by QPID-6969 to allow for the results set to be 
> sorted by one or more columns and results set to be paginated.
> For the ordering clause, we could use SQL:2011 ORDER BY clause as a guide 
> {{orderBy='x,y,z'}} and orderDirection=ASC|DESC.
> For the pagination, SQL standardisation does not include it. 
> https://en.wikipedia.org/wiki/Select_%28SQL%29#Result_limits We could opt for 
> {{limit=}} {{offset=}} like MySQL/Sybase.   We could also consider HTTP Range 
> headers.



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

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

[jira] [Created] (QPID-7165) Allow query results to be sorted and paginated

[Keith Wall (JIRA)]

Keith Wall created QPID-7165:


 Summary: Allow query results to be sorted and paginated
 Key: QPID-7165
 URL: https://issues.apache.org/jira/browse/QPID-7165
 Project: Qpid
  Issue Type: Bug
  Components: Java Broker
Reporter: Keith Wall
 Fix For: qpid-java-6.1


Extend the mechanism provided by QPID-6969 to allow for the results set to be 
sorted by one or more columns and results set to be paginated.

For the ordering clause, we could use SQL:2011 ORDER BY clause as a guide 
{{orderBy='x,y,z'}} and orderDirection=ASC|DESC.

For the pagination, SQL standardisation does not include it. 
https://en.wikipedia.org/wiki/Select_%28SQL%29#Result_limits We could opt for 
{{limit=}} {{offset=}} like MySQL/Sybase.   We could also consider HTTP Range 
headers.





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

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

[jira] [Comment Edited] (QPID-6984) [Web Management Console] Allow queries to the saved for later use

[Keith Wall (JIRA)]

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

Keith Wall edited comment on QPID-6984 at 3/29/16 1:46 PM:
---

Perhaps the model should have a {{Query}} object that is a child of Broker and 
Virtualhost (BrokerQuery, VirtualhostQuery given the model's current 
limitations).   The Query would encapsulate the query and capture somehow the 
notion of visibility.  A user when saving a query could opt to make the query 
visible to members of a group to which he belongs.  A user logging on would see 
queries that belongs to him, and queries belonging to other users that have 
been made visible to him.  Perhaps something like this:

{code:javascript}
{
 "category" : "Virtualhost",
 "select": "a,b,c",
 "where": "name like 'wobble%'",
 "visible": ['mygroup']
}
{code}


was (Author: k-wall):
Perhaps the model should have a {{Query}} object that is a child of Broker and 
Virtualhost (BrokerQuery, VirtualhostQuery given the model's current 
limitations).   The Query would encapsulate the query and capture somehow the 
notion of visibility.  A user when saving a query could opt to make the query 
visible to members of a group to which he belongs.  A user logging on would see 
queries that belongs to him, and queries belonging to other users that have 
been made visible to him.  Perhaps something like this:

{code:javascript}
{
 "category" : "Virtualhost",
 "select": "a,b,c",
 "where": "name like 'wobble%'",
 "visible": ['mygroup']
{code}

> [Web Management Console] Allow queries to the saved for later use
> -
>
> Key: QPID-6984
> URL: https://issues.apache.org/jira/browse/QPID-6984
> Project: Qpid
>  Issue Type: Improvement
>Reporter: Keith Wall
>
> After defining a query (QPID-6969) the user should be able to save query so 
> it may be conveniently re-run at a later time either during the same session, 
> or future sessions (after logging in again).  The user should also have the 
> ability to recall an existing query for edit, or delete a query.  In the long 
> term queries should be sharable amongst members of a group.
> This will require the ability to persist the query to the configuration 
> store.  To support HA properly, a query defined against a virtual host when 
> the mastership is a node A should be still available to the user when the 
> mastership flips to another node.  This implies that virtual host based 
> queries should be part of the virtualhost's configuration.



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

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

[jira] [Commented] (QPID-6984) [Web Management Console] Allow queries to the saved for later use

[Keith Wall (JIRA)]

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

Keith Wall commented on QPID-6984:
--

Perhaps the model should have a {{Query}} object that is a child of Broker and 
Virtualhost (BrokerQuery, VirtualhostQuery given the model's current 
limitations).   The Query would encapsulate the query and capture somehow the 
notion of visibility.  A user when saving a query could opt to make the query 
visible to members of a group to which he belongs.  A user logging on would see 
queries that belongs to him, and queries belonging to other users that have 
been made visible to him.  Perhaps something like this:

{code:javascript}
{
 "category" : "Virtualhost",
 "select": "a,b,c",
 "where": "name like 'wobble%'",
 "visible": ['mygroup']
{code}

> [Web Management Console] Allow queries to the saved for later use
> -
>
> Key: QPID-6984
> URL: https://issues.apache.org/jira/browse/QPID-6984
> Project: Qpid
>  Issue Type: Improvement
>Reporter: Keith Wall
>
> After defining a query (QPID-6969) the user should be able to save query so 
> it may be conveniently re-run at a later time either during the same session, 
> or future sessions (after logging in again).  The user should also have the 
> ability to recall an existing query for edit, or delete a query.  In the long 
> term queries should be sharable amongst members of a group.
> This will require the ability to persist the query to the configuration 
> store.  To support HA properly, a query defined against a virtual host when 
> the mastership is a node A should be still available to the user when the 
> mastership flips to another node.  This implies that virtual host based 
> queries should be part of the virtualhost's configuration.



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

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

[jira] [Updated] (QPID-6984) [Web Management Console] Allow queries to the saved for later use

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-6984:
-
Description: 
After defining a query (QPID-6969) the user should be able to save query so it 
may be conveniently re-run at a later time either during the same session, or 
future sessions (after logging in again).  The user should also have the 
ability to recall an existing query for edit, or delete a query.  In the long 
term queries should be sharable amongst members of a group.

This will require the ability to persist the query to the configuration store.  
To support HA properly, a query defined against a virtual host when the 
mastership is a node A should be still available to the user when the 
mastership flips to another node.  This implies that virtual host based queries 
should be part of the virtualhost's configuration.




  was:
After defining a query (QPID-6969) the user should be able to save query so it 
may be conveniently re-run at a later time either during the same session, or 
future sessions (after logging in again).  The user should also have the 
ability to recall an existing query for edit, or delete a query.





> [Web Management Console] Allow queries to the saved for later use
> -
>
> Key: QPID-6984
> URL: https://issues.apache.org/jira/browse/QPID-6984
> Project: Qpid
>  Issue Type: Improvement
>Reporter: Keith Wall
>
> After defining a query (QPID-6969) the user should be able to save query so 
> it may be conveniently re-run at a later time either during the same session, 
> or future sessions (after logging in again).  The user should also have the 
> ability to recall an existing query for edit, or delete a query.  In the long 
> term queries should be sharable amongst members of a group.
> This will require the ability to persist the query to the configuration 
> store.  To support HA properly, a query defined against a virtual host when 
> the mastership is a node A should be still available to the user when the 
> mastership flips to another node.  This implies that virtual host based 
> queries should be part of the virtualhost's configuration.



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

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

[jira] [Updated] (QPID-6984) [Web Management Console] Allow queries to the saved for later use

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-6984:
-
Description: 
After defining a query (QPID-6969) the user should be able to save query so it 
may be conveniently re-run at a later time either during the same session, or 
future sessions (after logging in again).  The user should also have the 
ability to recall an existing query for edit, or delete a query.




  was:
After defining a query the user should be able to save query so it may be 
conveniently re-run at a later time either during this session, or future 
sessions.  The user should also have the ability to recall an existing query 
for edit, or delete a query.

There is no requirement for queries to be shared between users.




> [Web Management Console] Allow queries to the saved for later use
> -
>
> Key: QPID-6984
> URL: https://issues.apache.org/jira/browse/QPID-6984
> Project: Qpid
>  Issue Type: Improvement
>Reporter: Keith Wall
>
> After defining a query (QPID-6969) the user should be able to save query so 
> it may be conveniently re-run at a later time either during the same session, 
> or future sessions (after logging in again).  The user should also have the 
> ability to recall an existing query for edit, or delete a query.



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

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

[jira] [Commented] (DISPATCH-57) Balance deliveries adaptively across all competing consumers in the network

[ASF subversion and git services (JIRA)]

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

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

Commit 8475aca8f61e52128df3f932db1d880129196ea9 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=8475aca ]

DISPATCH-57 - Implemented "balanced" delivery based on lowest number of 
unsettled deliveries.


> Balance deliveries adaptively across all competing consumers in the network
> ---
>
> Key: DISPATCH-57
> URL: https://issues.apache.org/jira/browse/DISPATCH-57
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Router Node
>Reporter: Ted Ross
>Assignee: Ted Ross
> Fix For: 0.6
>
>
> When there are multiple competing consumers on an address across a network, 
> the network should balance deliveries to those consumers adaptively.  This 
> will cause more messages to be delivered to faster consumers and fewer 
> messages to slower consumers.
> The basic idea is that each router tracks the deliveries and can know how 
> many outstanding (unacked) deliveries have been sent via each outbound link.  
> It can then choose a link based on the smallest number of outstanding 
> deliveries.  Faster links will tend to have fewer deliveries and will get 
> preference in the balancing.



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

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

[jira] [Updated] (QPID-7082) [Java Broker] Created AccessControllerContext for SystemTasks should not reference current context

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7082:
-
Fix Version/s: qpid-java-6.1

> [Java Broker] Created AccessControllerContext for SystemTasks should not 
> reference current context
> --
>
> Key: QPID-7082
> URL: https://issues.apache.org/jira/browse/QPID-7082
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.0, qpid-java-6.0.1
>Reporter: Alex Rudyy
> Fix For: qpid-java-6.1
>
> Attachments: 
> QPID-7082-Stop-referencing-current-context-from-queue-immediate-delivery-context.diff
>
>
> The code within {code}SecurityManager.getSystemTaskControllerContext(String 
> taskName, Principal principal){code} creates a context which inherits from 
> the current thread AcessControllerContext.  This current context may contain 
> references to the current user / connection / session.  On queue creation an 
> instance of AcessControllerContext created with 
> }SecurityManager.getSystemTaskControllerContext is referenced from 
> Queue#_immediateDeliveryContext. If queue is created via messaging layer, the 
> existing AccessControlContext can hold references to ConnectionPrincipal and 
> SessionPrincipal and their connection and session object accordingly.  As 
> result, Queue#_immediateDeliveryContext can refer  ConnectionPrincipal and 
> SessionPrincipa preventing garbage collection of corresponding AMQPConnection 
> and AMQSessionModel objects for the duration of the queue life. With lots of 
> long lived queues that were created by lots of different connections the 
> broker memory consumption might grow in time and eventially Broker can run 
> OOM if not bounced.
> The AccessContollerContext created by the method should not inherit and 
> context, and thus no references to users/connection/sessions etc. will be 
> retained.



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

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

[jira] [Updated] (QPID-7037) [Java Broker] Add UI for exposing trust stores as message sources

[Alex Rudyy (JIRA)]

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

Alex Rudyy updated QPID-7037:
-
Attachment: 0001-QPID-7037-Add-ability-into-Web-Management-Console-to.patch

Attached a patch with possible solution

> [Java Broker] Add UI for exposing trust stores as message sources
> -
>
> Key: QPID-7037
> URL: https://issues.apache.org/jira/browse/QPID-7037
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Rob Godfrey
>Assignee: Alex Rudyy
> Fix For: qpid-java-6.1
>
> Attachments: 
> 0001-QPID-7037-Add-ability-into-Web-Management-Console-to.patch
>
>
> In order to aid end to end encryption, a trust store containing certificates 
> can be exposed as a message source to enable certificate distribution to 
> clients.  Currently there is no way through the UI to enable this feature, 
> nor for selecting which virtual hosts the message source should be included / 
> excluded.



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

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

[jira] [Updated] (QPID-7023) BDB HA: JE Cleaner warnings written to qpid log during apparently normal operation

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7023:
-
Fix Version/s: qpid-java-6.0.2

> BDB HA: JE Cleaner warnings written to qpid log during apparently normal 
> operation 
> ---
>
> Key: QPID-7023
> URL: https://issues.apache.org/jira/browse/QPID-7023
> Project: Qpid
>  Issue Type: Bug
>Affects Versions: 0.32, qpid-java-6.0
>Reporter: Keith Wall
> Fix For: qpid-java-6.0.2, qpid-java-6.1
>
>
> The Java Broker directs JE log log messages to the qpid.log bridging from JUL 
> to SLF4J.
> During operation of the group, with a relatively high transactional 
> publish/consume workload, messages like this are seen. These are written to 
> all nodes (master and replica) even when all nodes are on-line:
> {noformat}
> 2016-01-26 08:59:36,360 WARN  [Checkpointer] (BDB) - [mynode1] Cleaner has 3 
> files not deleted because they are protected by replication.
> 2016-01-26 08:59:38,966 WARN  [Checkpointer] (BDB) - [mynode1] Cleaner has 2 
> files not deleted because they are protected by DbBackup or replication.
> 2016-01-26 08:59:41,646 WARN  [Checkpointer] (BDB) - [mynode1] Cleaner has 2 
> files not deleted because they are protected by DbBackup or replication.
> 2016-01-26 08:59:43,987 WARN  [Checkpointer] (BDB) - [mynode1] Cleaner has 1 
> files not deleted because they are protected by DbBackup or replication.
> 2016-01-26 08:59:46,494 WARN  [Checkpointer] (BDB) - [mynode1] Cleaner has 2 
> files not deleted because they are protected by DbBackup or replication.
> 2016-01-26 08:59:52,588 WARN  [Checkpointer] (BDB) - [mynode1] Cleaner has 1 
> files not deleted because they are protected by DbBackup or replication.
> 2016-01-26 09:00:45,684 WARN  [Checkpointer] (BDB) - [mynode1] Cleaner has 2 
> files not deleted because they are protected by DbBackup or replication.
> {noformat}
> Additionally replicas see messages like this:
> {noformat}
> 2016-01-26 08:59:36,359 WARN  [Checkpointer] (BDB) - [mynode1] Replication 
> prevents deletion of 3 files by Cleaner. Start file=0x280 holds CBVLSN 
> 27,742,300, end file=0x287 holds end VLSN 28,040,638
> {noformat}
> The extent of the backlog never seems to get worse, and there is no 
> functional impact.
> The forum post https://community.oracle.com/thread/2541709 makes me suspect 
> that this warning might be normal if the backlogs remains 'small'.
> I have reproduced this problem on 0.32 and qpid-java-6.0.  It is possible it 
> occurs on 0.30 too, but there the JE log file was not redirected.



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

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

[jira] [Updated] (QPID-7155) [Java Broker] Idle timeout ticker times out connection before heartbeating is negotiated

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7155:
-
Fix Version/s: qpid-java-6.1
   qpid-java-6.0.2

> [Java Broker] Idle timeout ticker times out connection before heartbeating is 
> negotiated
> 
>
> Key: QPID-7155
> URL: https://issues.apache.org/jira/browse/QPID-7155
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Reporter: Lorenz Quack
> Fix For: qpid-java-6.0.2, qpid-java-6.1
>
> Attachments: 
> TEST-org.apache.qpid.client.failover.MultipleBrokersFailoverTest.testFailoverOnBrokerStop.txt
>
>
> Recently, {{MultipleBrokersFailoverTest#testFailoverOnBrokerStop}} failed. 
> Log attached.
> Analysis has shown the following sequence of events:
> * 01:58:24,044 broker receives connectionStartOk
> * 01:58:25,894 broker sends connectionSecure
> * 01:58:26,010 broker times out the connection
> * 01:58:26,061 client tries to send connectionSecureOk
> The problem seems to be that the ServerIdleReadTimeoutTicker times out the 
> connection even though the broker is the one being slow and heartbeating not 
> being negotiated yet.



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

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

[jira] [Updated] (QPID-7160) No X509TrustManager implementation available when using truststore captured by SiteSpecificTrustStore

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7160:
-
Fix Version/s: qpid-java-6.1

> No X509TrustManager implementation available when using truststore captured 
> by SiteSpecificTrustStore
> -
>
> Key: QPID-7160
> URL: https://issues.apache.org/jira/browse/QPID-7160
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Reporter: Keith Wall
>Priority: Minor
> Fix For: qpid-java-6.1
>
>
> I am testing the Java Broker with ApacheDS as an authentication provider. I 
> find secure connections to the Directory secured with a self signed 
> certificate fail if the truststore was captured using 
> {{SiteSpecificTrustStore}}.  If I upload the truststore as a PEM, the 
> exception does not occur.
> Keystore for ApacheDS was generated like so:
> {{keytool -genkey -keyalg RSA -alias selfsigned -keystore apacheds.jks 
> -storepass password -validity 360 -keysize 2048}}
> Truststore captured by pointing SiteSpecificTrustStore at 
> https://localhost:10636
> Alternative approach (that works), export the PEM from the ApacheDS UI, then 
> import into Java Broker as NonJavaTrustStore.
> {noformat}
> 2016-03-23 22:49:14,464 WARN  [HttpManagement-myhttps-150] 
> (o.a.q.s.s.a.m.SimpleLDAPAuthenticationManagerImpl) - SASL Authentication 
> Exception
> javax.naming.CommunicationException: simple bind failed: Oslo.local:10636
>   at com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:219) 
> ~[na:1.8.0_45]
>   at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2788) ~[na:1.8.0_45]
>   at com.sun.jndi.ldap.LdapCtx.(LdapCtx.java:319) ~[na:1.8.0_45]
>   at 
> com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:192) 
> ~[na:1.8.0_45]
>   at 
> com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:210) 
> ~[na:1.8.0_45]
>   at 
> com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:153) 
> ~[na:1.8.0_45]
>   at 
> com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:83) 
> ~[na:1.8.0_45]
>   at 
> javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684) 
> ~[na:1.8.0_45]
>   at 
> javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313) 
> ~[na:1.8.0_45]
>   at javax.naming.InitialContext.init(InitialContext.java:244) 
> ~[na:1.8.0_45]
>   at javax.naming.InitialContext.(InitialContext.java:216) 
> ~[na:1.8.0_45]
>   at 
> javax.naming.directory.InitialDirContext.(InitialDirContext.java:101) 
> ~[na:1.8.0_45]
>   at 
> org.apache.qpid.server.security.auth.manager.SimpleLDAPAuthenticationManagerImpl.createInitialDirContext(SimpleLDAPAuthenticationManagerImpl.java:344)
>  ~[classes/:na]
>   at 
> org.apache.qpid.server.security.auth.manager.SimpleLDAPAuthenticationManagerImpl.getNameFromId(SimpleLDAPAuthenticationManagerImpl.java:491)
>  ~[classes/:na]
>   at 
> org.apache.qpid.server.security.auth.manager.SimpleLDAPAuthenticationManagerImpl.access$100(SimpleLDAPAuthenticationManagerImpl.java:72)
>  ~[classes/:na]
>   at 
> org.apache.qpid.server.security.auth.manager.SimpleLDAPAuthenticationManagerImpl$SimpleLDAPPlainCallbackHandler.handle(SimpleLDAPAuthenticationManagerImpl.java:448)
>  ~[classes/:na]
>   at 
> org.apache.qpid.server.security.auth.sasl.plain.PlainSaslServer.evaluateResponse(PlainSaslServer.java:83)
>  [classes/:na]
>   at 
> org.apache.qpid.server.management.plugin.servlet.rest.SaslServlet.evaluateSaslResponse(SaslServlet.java:217)
>  [classes/:na]
>   at 
> org.apache.qpid.server.management.plugin.servlet.rest.SaslServlet.doPostWithSubjectAndActor(SaslServlet.java:135)
>  [classes/:na]
>   at 
> org.apache.qpid.server.management.plugin.servlet.rest.AbstractServlet$2.run(AbstractServlet.java:118)
>  [classes/:na]
>   at 
> org.apache.qpid.server.management.plugin.servlet.rest.AbstractServlet$2.run(AbstractServlet.java:114)
>  [classes/:na]
>   at java.security.AccessController.doPrivileged(Native Method) 
> [na:1.8.0_45]
>   at javax.security.auth.Subject.doAs(Subject.java:422) [na:1.8.0_45]
>   at 
> org.apache.qpid.server.management.plugin.servlet.rest.AbstractServlet.doWithSubjectAndActor(AbstractServlet.java:215)
>  [classes/:na]
>   at 
> org.apache.qpid.server.management.plugin.servlet.rest.AbstractServlet.doPost(AbstractServlet.java:112)
>  [classes/:na]
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) 
> [geronimo-servlet_3.0_spec-1.0.jar:1.0]
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:668) 
> [geronimo-servlet_3.0_spec-1.0.jar:1.0]
>   at 
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:684) 
> 

Re: qpid_tests/broker_1_0 not in tests/setup.py

[Gordon Sim]

On 29/03/16 12:22, Keith W wrote:

On 29 March 2016 at 09:13, Gordon Sim  wrote:

On 28/03/16 08:57, Keith W wrote:


Hi all,

I am trying to automate the running of the existing Python AMQP 1.0
broker tests against the Java Broker with the proton-c/cpp binary
dependencies built from their respective trunks.

I am installing the Python modules to a private site-package
directory, but I notice the tests/setup.py does not seem to install
the broker_1_0 module.  Is this an oversight? Or is the running of the
broker_1_0 tests different to the others?



The qpid.messaging python client does not support AMQP 1.0. The
qpid::messaging c++ client has been swigged though (mainly only for ease of
testing), and provides _almost_ the same api.




I am trying to use the python swigged qpid::messaging c++ client API
from the tests.  My question simply is about
https://svn.apache.org/repos/asf/qpid/trunk/qpid/tests/setup.py.  Why
does it omit broker_1_0 on line 26?  Is it that we run these tests in
a different way to the others?


Yes, in so far as they require a different client. However, personally I 
have no objection to adding the 1.0 tests as well. I'm not sure whether 
a conscious decision was ever made about whether or not to include them.



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

[jira] [Updated] (QPID-7164) Python test qpid_tests.broker_0_10.new_api.GeneralTests.test_qpid_3481_acquired_to_alt_exchange fails against Java Broker

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7164:
-
Fix Version/s: Future

> Python test 
> qpid_tests.broker_0_10.new_api.GeneralTests.test_qpid_3481_acquired_to_alt_exchange
>  fails against Java Broker
> -
>
> Key: QPID-7164
> URL: https://issues.apache.org/jira/browse/QPID-7164
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker, Python Test Suite
>Reporter: Keith Wall
> Fix For: Future
>
>
> The following Python test is currently failing against the Java Broker.
> This is related to the routing of messages to the alternate exchanges.
> {noformat}
> Error during test:  Traceback (most recent call last):
> File "qpid-python-test", line 340, in run
>   phase()
> File 
> "/home/jenkins/jenkins-slave/workspace/Qpid-Python-Java-Test/trunk/qpid/tests/src/py/qpid_tests/broker_0_10/new_api.py",
>  line 85, in test_qpid_3481_acquired_to_alt_exchange
>   self.assertEqual(rx_alt.available(), 5, "All 5 messages should have 
> been routed to the alt_exchange")
> File 
> "/home/jenkins/jenkins-slave/workspace/Qpid-Python-Java-Test/trunk/qpid/tests/src/py/qpid_tests/broker_0_10/new_api.py",
>  line 39, in assertEqual
>   assert None
>   AssertionError
> {noformat}



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

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

[jira] [Resolved] (QPID-6995) [Java Broker] Keystores should warn of pending certificate expiration

[Keith Wall (JIRA)]

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

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

> [Java Broker] Keystores should warn of pending certificate expiration
> -
>
> Key: QPID-6995
> URL: https://issues.apache.org/jira/browse/QPID-6995
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
>Assignee: Rob Godfrey
>Priority: Minor
> Fix For: qpid-java-6.1
>
>
> Keystores should have the ability to warn that a certificate is pending 
> expiry. 
> This would take the form of an operation log message which is written 
> regularly to the log, say on a day interval once a certificate reaches a 
> certain proximity to its expiration date.



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

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

Re: qpid_tests/broker_1_0 not in tests/setup.py

[Keith W]

On 29 March 2016 at 09:13, Gordon Sim  wrote:
> On 28/03/16 08:57, Keith W wrote:
>>
>> Hi all,
>>
>> I am trying to automate the running of the existing Python AMQP 1.0
>> broker tests against the Java Broker with the proton-c/cpp binary
>> dependencies built from their respective trunks.
>>
>> I am installing the Python modules to a private site-package
>> directory, but I notice the tests/setup.py does not seem to install
>> the broker_1_0 module.  Is this an oversight? Or is the running of the
>> broker_1_0 tests different to the others?
>
>
> The qpid.messaging python client does not support AMQP 1.0. The
> qpid::messaging c++ client has been swigged though (mainly only for ease of
> testing), and provides _almost_ the same api.
>
>

I am trying to use the python swigged qpid::messaging c++ client API
from the tests.  My question simply is about
https://svn.apache.org/repos/asf/qpid/trunk/qpid/tests/setup.py.  Why
does it omit broker_1_0 on line 26?  Is it that we run these tests in
a different way to the others?




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

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

[jira] [Comment Edited] (QPID-7154) Dead lettering of a message may timeout at store level, causing unexpected Broker shutdown

[Keith Wall (JIRA)]

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

Keith Wall edited comment on QPID-7154 at 3/29/16 11:12 AM:



(Previous incorrect analysis deleted).

The issue is that the dead letter code path 
{{QueueEntryImpl#routeToAlternative}} does not in the case the entry was 
acquired by a consumer, lock the consumer's acquisition.  Management operations 
(such as #clearQueue) are allowed to steal consumers' acquisitions unless they 
are locked.  It this hole through which the problem occurred.

The fix is to have the code lock the acquisition, if it acquisition belongs to 
a consumer.

This problem has existed since QPID-3978 (0.30).




was (Author: k-wall):
In 6.0.1 the issue is isolated to the JMX layer (which is disabled by default). 
 The {{QueueMBean#clearQueue}} implements its own queue clearing mechanism.  It 
uses single transaction to clear the whole queue, but omits to acquire the 
queue entries.  This means that two threads can be trying to act on same store 
record at once.  In the user's case, the queue was very deep, so the 
transaction will have been very long running.  The messaging thread (which had 
acquired the queue entry) was also trying to dequeue it.  It was blocked at 
store level by the long running clearQueue, until BDB timed out the 
transaction.  AMQ purgeQueue and HTTP clearQueue are not affected.

In the earlier releases (0.32, 0.30, 0.22, 0.18) the same problem existed on 
both JMX and HTTP paths.





> Dead lettering of a message may timeout at store level, causing unexpected 
> Broker shutdown
> --
>
> Key: QPID-7154
> URL: https://issues.apache.org/jira/browse/QPID-7154
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: 0.30, 0.32, qpid-java-6.0.1
>Reporter: Keith Wall
> Fix For: qpid-java-6.0.2
>
>
> The following was reported by a user using a 0.32 derivative.
> The background was an operator was attempting to clear queue with very large 
> depth using JMX management {{QueueMBean#clearQueue}} as the same time as a 
> messaging client (consumer - connected to the same queue) was rejecting 
> messages which were being routed to another queue and then dequeued.
> The message client (consumer) store level transaction timed out. This caused 
> the Broker to fail (uncaught exception).
> {code}
> com.sleepycat.je.LockTimeoutException: (JE 5.0.104) Lock expired. Locker 
> 792611890 1557851806_IoReceiver - /xxx.xx.xx.xx:32962_Txn: waited for lock on 
> database=QUEUE_ENTRIES LockAddr:1959781711 LSN=0x74a70/0x94db8e type=WRITE 
> grant=WAIT_NEW timeoutMillis=500 startTime=1458223769602 endTime=1458223770102
> Owners: []
> Waiters: []
>  
> at 
> com.sleepycat.je.txn.LockManager.newLockTimeoutException(LockManager.java:665)
> at 
> com.sleepycat.je.txn.LockManager.makeTimeoutMsgInternal(LockManager.java:623)
> at 
> com.sleepycat.je.txn.SyncedLockManager.makeTimeoutMsg(SyncedLockManager.java:97)
> at 
> com.sleepycat.je.txn.LockManager.lockInternal(LockManager.java:390)
> at com.sleepycat.je.txn.LockManager.lock(LockManager.java:276)
> at com.sleepycat.je.txn.Txn.lockInternal(Txn.java:522)
> at com.sleepycat.je.txn.Locker.lock(Locker.java:443)
> at 
> com.sleepycat.je.dbi.CursorImpl.lockLN(CursorImpl.java:2642)
> at 
> com.sleepycat.je.dbi.CursorImpl.lockLN(CursorImpl.java:2443)
> at 
> com.sleepycat.je.dbi.CursorImpl.searchAndPosition(CursorImpl.java:2168)
> at com.sleepycat.je.Cursor.searchInternal(Cursor.java:2822)
> at 
> com.sleepycat.je.Cursor.searchAllowPhantoms(Cursor.java:2732)
> at com.sleepycat.je.Cursor.searchNoDups(Cursor.java:2586)
> at com.sleepycat.je.Cursor.search(Cursor.java:2553)
> at 
> com.sleepycat.je.Database.deleteInternal(Database.java:1151)
> at com.sleepycat.je.Database.delete(Database.java:1080)
> at 
> org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore.dequeueMessage(AbstractBDBMessageStore.java:819)
> at 
> org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore.access$1000(AbstractBDBMessageStore.java:71)
> at 
> org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore$BDBTransaction.dequeueMessage(AbstractBDBMessageStore.java:1496)
> at 
> org.apache.qpid.server.txn.LocalTransaction.dequeue(LocalTransaction.java:110)
> at 
> org.apache.qpid.server.queue.QueueEntryImpl.routeToAlternate(QueueEntryImpl.java:463)
> 

[jira] [Commented] (QPID-6995) [Java Broker] Keystores should warn of pending certificate expiration

[ASF subversion and git services (JIRA)]

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

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

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

QPID-6995 : Move duplicate code into base class, address comment from [~k-wall] 
regarding exception handling

> [Java Broker] Keystores should warn of pending certificate expiration
> -
>
> Key: QPID-6995
> URL: https://issues.apache.org/jira/browse/QPID-6995
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
>Assignee: Rob Godfrey
>Priority: Minor
> Fix For: qpid-java-6.1
>
>
> Keystores should have the ability to warn that a certificate is pending 
> expiry. 
> This would take the form of an operation log message which is written 
> regularly to the log, say on a day interval once a certificate reaches a 
> certain proximity to its expiration date.



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

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

[jira] [Commented] (QPIDJMS-157) Add support for send timeout and request timeout options

[ASF subversion and git services (JIRA)]

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

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

Commit fb4c3ab3581512e04d1e6ab177c67b594740b649 in qpid-jms's branch 
refs/heads/master from Robert Gemmell
[ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=fb4c3ab ]

QPIDJMS-157: remove credit delay, test doesnt need/use it


> Add support for send timeout and request timeout options
> 
>
> Key: QPIDJMS-157
> URL: https://issues.apache.org/jira/browse/QPIDJMS-157
> Project: Qpid JMS
>  Issue Type: New Feature
>  Components: qpid-jms-client
>Affects Versions: 0.8.0
>Reporter: Timothy Bish
>Assignee: Timothy Bish
> Fix For: 0.9.0
>
>
> Add support for a timeout option for message sends.  In the case of failover 
> allow the send to timeout after some configured interval with an error 
> indicating the send failed.



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

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

[jira] [Commented] (QPIDJMS-159) support producers having their existing credit drained

[ASF subversion and git services (JIRA)]

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

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

Commit cb5abb04623e73baf4bc6f9a0fe8a497198e10a6 in qpid-jms's branch 
refs/heads/master from Robert Gemmell
[ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=cb5abb0 ]

QPIDJMS-159: update to ensure the flow better reflects previous activity, 
generalise peer method a little


> support producers having their existing credit drained
> --
>
> Key: QPIDJMS-159
> URL: https://issues.apache.org/jira/browse/QPIDJMS-159
> Project: Qpid JMS
>  Issue Type: Improvement
>  Components: qpid-jms-client
>Affects Versions: 0.8.0
>Reporter: Robbie Gemmell
>Assignee: Timothy Bish
>
> Whilst the client does block/buffer messages upon send operations when a 
> producer link has no credit, and sends those messages when credit is again 
> granted, it doesnt appear to cooperate in existing credit being revoked 
> through the receiving broker/peer draining existing credit it previously 
> issued.



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

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

[jira] [Assigned] (QPID-7037) [Java Broker] Add UI for exposing trust stores as message sources

[Alex Rudyy (JIRA)]

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

Alex Rudyy reassigned QPID-7037:


Assignee: Alex Rudyy

> [Java Broker] Add UI for exposing trust stores as message sources
> -
>
> Key: QPID-7037
> URL: https://issues.apache.org/jira/browse/QPID-7037
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Rob Godfrey
>Assignee: Alex Rudyy
> Fix For: qpid-java-6.1
>
>
> In order to aid end to end encryption, a trust store containing certificates 
> can be exposed as a message source to enable certificate distribution to 
> clients.  Currently there is no way through the UI to enable this feature, 
> nor for selecting which virtual hosts the message source should be included / 
> excluded.



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

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

[jira] [Updated] (QPID-7154) Dead lettering of a message may timeout at store level, causing unexpected Broker shutdown

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7154:
-
Affects Version/s: (was: 0.22)
   (was: 0.18)

> Dead lettering of a message may timeout at store level, causing unexpected 
> Broker shutdown
> --
>
> Key: QPID-7154
> URL: https://issues.apache.org/jira/browse/QPID-7154
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: 0.30, 0.32, qpid-java-6.0.1
>Reporter: Keith Wall
> Fix For: qpid-java-6.0.2
>
>
> The following was reported by a user using a 0.32 derivative.
> The background was an operator was attempting to clear queue with very large 
> depth using JMX management {{QueueMBean#clearQueue}} as the same time as a 
> messaging client (consumer - connected to the same queue) was rejecting 
> messages which were being routed to another queue and then dequeued.
> The message client (consumer) store level transaction timed out. This caused 
> the Broker to fail (uncaught exception).
> {code}
> com.sleepycat.je.LockTimeoutException: (JE 5.0.104) Lock expired. Locker 
> 792611890 1557851806_IoReceiver - /xxx.xx.xx.xx:32962_Txn: waited for lock on 
> database=QUEUE_ENTRIES LockAddr:1959781711 LSN=0x74a70/0x94db8e type=WRITE 
> grant=WAIT_NEW timeoutMillis=500 startTime=1458223769602 endTime=1458223770102
> Owners: []
> Waiters: []
>  
> at 
> com.sleepycat.je.txn.LockManager.newLockTimeoutException(LockManager.java:665)
> at 
> com.sleepycat.je.txn.LockManager.makeTimeoutMsgInternal(LockManager.java:623)
> at 
> com.sleepycat.je.txn.SyncedLockManager.makeTimeoutMsg(SyncedLockManager.java:97)
> at 
> com.sleepycat.je.txn.LockManager.lockInternal(LockManager.java:390)
> at com.sleepycat.je.txn.LockManager.lock(LockManager.java:276)
> at com.sleepycat.je.txn.Txn.lockInternal(Txn.java:522)
> at com.sleepycat.je.txn.Locker.lock(Locker.java:443)
> at 
> com.sleepycat.je.dbi.CursorImpl.lockLN(CursorImpl.java:2642)
> at 
> com.sleepycat.je.dbi.CursorImpl.lockLN(CursorImpl.java:2443)
> at 
> com.sleepycat.je.dbi.CursorImpl.searchAndPosition(CursorImpl.java:2168)
> at com.sleepycat.je.Cursor.searchInternal(Cursor.java:2822)
> at 
> com.sleepycat.je.Cursor.searchAllowPhantoms(Cursor.java:2732)
> at com.sleepycat.je.Cursor.searchNoDups(Cursor.java:2586)
> at com.sleepycat.je.Cursor.search(Cursor.java:2553)
> at 
> com.sleepycat.je.Database.deleteInternal(Database.java:1151)
> at com.sleepycat.je.Database.delete(Database.java:1080)
> at 
> org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore.dequeueMessage(AbstractBDBMessageStore.java:819)
> at 
> org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore.access$1000(AbstractBDBMessageStore.java:71)
> at 
> org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore$BDBTransaction.dequeueMessage(AbstractBDBMessageStore.java:1496)
> at 
> org.apache.qpid.server.txn.LocalTransaction.dequeue(LocalTransaction.java:110)
> at 
> org.apache.qpid.server.queue.QueueEntryImpl.routeToAlternate(QueueEntryImpl.java:463)
> at 
> org.apache.qpid.server.protocol.v0_8.AMQChannel.deadLetter(AMQChannel.java:1795)
> at 
> org.apache.qpid.server.protocol.v0_8.AMQChannel.receiveBasicReject(AMQChannel.java:2431)
> at 
> org.apache.qpid.framing.BasicRejectBody.process(BasicRejectBody.java:123)
> at 
> org.apache.qpid.codec.ServerDecoder.processMethod(ServerDecoder.java:188)
> at 
> org.apache.qpid.codec.AMQDecoder.processFrame(AMQDecoder.java:388)
> at 
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.doProcessFrame(BrokerDecoder.java:113)
> at 
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.access$000(BrokerDecoder.java:36)
> at 
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder$1.run(BrokerDecoder.java:79)
> at 
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder$1.run(BrokerDecoder.java:75)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:415)
> at 
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.processFrame(BrokerDecoder.java:74)
> at 
> org.apache.qpid.codec.AMQDecoder.processInput(AMQDecoder.java:370)
> at 
> 

[jira] [Resolved] (QPID-7095) [Java Broker] Add mechanism to extract meta data for context variables describing their usage

[Rob Godfrey (JIRA)]

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

Rob Godfrey resolved QPID-7095.
---
Resolution: Fixed

> [Java Broker] Add mechanism to extract meta data for context variables 
> describing their usage
> -
>
> Key: QPID-7095
> URL: https://issues.apache.org/jira/browse/QPID-7095
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Rob Godfrey
>
> Currently there is no way to discover which context variables are used by the 
> broker, and the description of what they do.  We should add a meta data 
> mechanism to describe these relationships, and also provide this information 
> through the dynamic API docs.



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

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

[jira] [Updated] (QPID-7095) [Java Broker] Add mechanism to extract meta data for context variables describing their usage

[Rob Godfrey (JIRA)]

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

Rob Godfrey updated QPID-7095:
--
Description: Currently there is no way to discover which context variables 
are used by the broker, and the description of what they do.  We should add a 
meta data mechanism to describe these relationships, and also provide this 
information through the dynamic API docs.  (was: Currently there is no way to 
discover which context variables are used by the broker, and the description of 
what they do.  We should add meta data covering this and also provide this 
information through the dynamic API docs.)

> [Java Broker] Add mechanism to extract meta data for context variables 
> describing their usage
> -
>
> Key: QPID-7095
> URL: https://issues.apache.org/jira/browse/QPID-7095
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Rob Godfrey
>
> Currently there is no way to discover which context variables are used by the 
> broker, and the description of what they do.  We should add a meta data 
> mechanism to describe these relationships, and also provide this information 
> through the dynamic API docs.



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

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

[jira] [Updated] (QPID-7095) [Java Broker] Add mechanism to extract meta data for context variables describing their usage

[Rob Godfrey (JIRA)]

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

Rob Godfrey updated QPID-7095:
--
Summary: [Java Broker] Add mechanism to extract meta data for context 
variables describing their usage  (was: [Java Broker] Add meta data for context 
variables describing their usage)

> [Java Broker] Add mechanism to extract meta data for context variables 
> describing their usage
> -
>
> Key: QPID-7095
> URL: https://issues.apache.org/jira/browse/QPID-7095
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Rob Godfrey
>
> Currently there is no way to discover which context variables are used by the 
> broker, and the description of what they do.  We should add meta data 
> covering this and also provide this information through the dynamic API docs.



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

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

[jira] [Updated] (QPID-7154) Dead lettering of a message may timeout at store level, causing unexpected Broker shutdown

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7154:
-
Summary: Dead lettering of a message may timeout at store level, causing 
unexpected Broker shutdown  (was: Dead lettering of a message may timeout)

> Dead lettering of a message may timeout at store level, causing unexpected 
> Broker shutdown
> --
>
> Key: QPID-7154
> URL: https://issues.apache.org/jira/browse/QPID-7154
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: 0.18, 0.22, 0.30, 0.32, qpid-java-6.0.1
>Reporter: Keith Wall
> Fix For: qpid-java-6.0.2
>
>
> The following was reported by a user using a 0.32 derivative.
> The background was an operator was attempting to clear queue with very large 
> depth using JMX management {{QueueMBean#clearQueue}} as the same time as a 
> messaging client (consumer - connected to the same queue) was rejecting 
> messages which were being routed to another queue and then dequeued.
> The message client (consumer) store level transaction timed out. This caused 
> the Broker to fail (uncaught exception).
> {code}
> com.sleepycat.je.LockTimeoutException: (JE 5.0.104) Lock expired. Locker 
> 792611890 1557851806_IoReceiver - /xxx.xx.xx.xx:32962_Txn: waited for lock on 
> database=QUEUE_ENTRIES LockAddr:1959781711 LSN=0x74a70/0x94db8e type=WRITE 
> grant=WAIT_NEW timeoutMillis=500 startTime=1458223769602 endTime=1458223770102
> Owners: []
> Waiters: []
>  
> at 
> com.sleepycat.je.txn.LockManager.newLockTimeoutException(LockManager.java:665)
> at 
> com.sleepycat.je.txn.LockManager.makeTimeoutMsgInternal(LockManager.java:623)
> at 
> com.sleepycat.je.txn.SyncedLockManager.makeTimeoutMsg(SyncedLockManager.java:97)
> at 
> com.sleepycat.je.txn.LockManager.lockInternal(LockManager.java:390)
> at com.sleepycat.je.txn.LockManager.lock(LockManager.java:276)
> at com.sleepycat.je.txn.Txn.lockInternal(Txn.java:522)
> at com.sleepycat.je.txn.Locker.lock(Locker.java:443)
> at 
> com.sleepycat.je.dbi.CursorImpl.lockLN(CursorImpl.java:2642)
> at 
> com.sleepycat.je.dbi.CursorImpl.lockLN(CursorImpl.java:2443)
> at 
> com.sleepycat.je.dbi.CursorImpl.searchAndPosition(CursorImpl.java:2168)
> at com.sleepycat.je.Cursor.searchInternal(Cursor.java:2822)
> at 
> com.sleepycat.je.Cursor.searchAllowPhantoms(Cursor.java:2732)
> at com.sleepycat.je.Cursor.searchNoDups(Cursor.java:2586)
> at com.sleepycat.je.Cursor.search(Cursor.java:2553)
> at 
> com.sleepycat.je.Database.deleteInternal(Database.java:1151)
> at com.sleepycat.je.Database.delete(Database.java:1080)
> at 
> org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore.dequeueMessage(AbstractBDBMessageStore.java:819)
> at 
> org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore.access$1000(AbstractBDBMessageStore.java:71)
> at 
> org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore$BDBTransaction.dequeueMessage(AbstractBDBMessageStore.java:1496)
> at 
> org.apache.qpid.server.txn.LocalTransaction.dequeue(LocalTransaction.java:110)
> at 
> org.apache.qpid.server.queue.QueueEntryImpl.routeToAlternate(QueueEntryImpl.java:463)
> at 
> org.apache.qpid.server.protocol.v0_8.AMQChannel.deadLetter(AMQChannel.java:1795)
> at 
> org.apache.qpid.server.protocol.v0_8.AMQChannel.receiveBasicReject(AMQChannel.java:2431)
> at 
> org.apache.qpid.framing.BasicRejectBody.process(BasicRejectBody.java:123)
> at 
> org.apache.qpid.codec.ServerDecoder.processMethod(ServerDecoder.java:188)
> at 
> org.apache.qpid.codec.AMQDecoder.processFrame(AMQDecoder.java:388)
> at 
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.doProcessFrame(BrokerDecoder.java:113)
> at 
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.access$000(BrokerDecoder.java:36)
> at 
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder$1.run(BrokerDecoder.java:79)
> at 
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder$1.run(BrokerDecoder.java:75)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:415)
> at 
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.processFrame(BrokerDecoder.java:74)
> at 
> 

[jira] [Updated] (QPID-7154) Dead lettering of a message may timeout

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7154:
-
Summary: Dead lettering of a message may timeout  (was: JMX 
QueueMBean#clearQueue operation does not acquire messages prior to dequeue 
which allows for store level lock timeout )

> Dead lettering of a message may timeout
> ---
>
> Key: QPID-7154
> URL: https://issues.apache.org/jira/browse/QPID-7154
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: 0.18, 0.22, 0.30, 0.32, qpid-java-6.0.1
>Reporter: Keith Wall
> Fix For: qpid-java-6.0.2
>
>
> The following was reported by a user using a 0.32 derivative.
> The background was an operator was attempting to clear queue with very large 
> depth using JMX management {{QueueMBean#clearQueue}} as the same time as a 
> messaging client (consumer - connected to the same queue) was rejecting 
> messages which were being routed to another queue and then dequeued.
> The message client (consumer) store level transaction timed out. This caused 
> the Broker to fail (uncaught exception).
> {code}
> com.sleepycat.je.LockTimeoutException: (JE 5.0.104) Lock expired. Locker 
> 792611890 1557851806_IoReceiver - /xxx.xx.xx.xx:32962_Txn: waited for lock on 
> database=QUEUE_ENTRIES LockAddr:1959781711 LSN=0x74a70/0x94db8e type=WRITE 
> grant=WAIT_NEW timeoutMillis=500 startTime=1458223769602 endTime=1458223770102
> Owners: []
> Waiters: []
>  
> at 
> com.sleepycat.je.txn.LockManager.newLockTimeoutException(LockManager.java:665)
> at 
> com.sleepycat.je.txn.LockManager.makeTimeoutMsgInternal(LockManager.java:623)
> at 
> com.sleepycat.je.txn.SyncedLockManager.makeTimeoutMsg(SyncedLockManager.java:97)
> at 
> com.sleepycat.je.txn.LockManager.lockInternal(LockManager.java:390)
> at com.sleepycat.je.txn.LockManager.lock(LockManager.java:276)
> at com.sleepycat.je.txn.Txn.lockInternal(Txn.java:522)
> at com.sleepycat.je.txn.Locker.lock(Locker.java:443)
> at 
> com.sleepycat.je.dbi.CursorImpl.lockLN(CursorImpl.java:2642)
> at 
> com.sleepycat.je.dbi.CursorImpl.lockLN(CursorImpl.java:2443)
> at 
> com.sleepycat.je.dbi.CursorImpl.searchAndPosition(CursorImpl.java:2168)
> at com.sleepycat.je.Cursor.searchInternal(Cursor.java:2822)
> at 
> com.sleepycat.je.Cursor.searchAllowPhantoms(Cursor.java:2732)
> at com.sleepycat.je.Cursor.searchNoDups(Cursor.java:2586)
> at com.sleepycat.je.Cursor.search(Cursor.java:2553)
> at 
> com.sleepycat.je.Database.deleteInternal(Database.java:1151)
> at com.sleepycat.je.Database.delete(Database.java:1080)
> at 
> org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore.dequeueMessage(AbstractBDBMessageStore.java:819)
> at 
> org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore.access$1000(AbstractBDBMessageStore.java:71)
> at 
> org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore$BDBTransaction.dequeueMessage(AbstractBDBMessageStore.java:1496)
> at 
> org.apache.qpid.server.txn.LocalTransaction.dequeue(LocalTransaction.java:110)
> at 
> org.apache.qpid.server.queue.QueueEntryImpl.routeToAlternate(QueueEntryImpl.java:463)
> at 
> org.apache.qpid.server.protocol.v0_8.AMQChannel.deadLetter(AMQChannel.java:1795)
> at 
> org.apache.qpid.server.protocol.v0_8.AMQChannel.receiveBasicReject(AMQChannel.java:2431)
> at 
> org.apache.qpid.framing.BasicRejectBody.process(BasicRejectBody.java:123)
> at 
> org.apache.qpid.codec.ServerDecoder.processMethod(ServerDecoder.java:188)
> at 
> org.apache.qpid.codec.AMQDecoder.processFrame(AMQDecoder.java:388)
> at 
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.doProcessFrame(BrokerDecoder.java:113)
> at 
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.access$000(BrokerDecoder.java:36)
> at 
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder$1.run(BrokerDecoder.java:79)
> at 
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder$1.run(BrokerDecoder.java:75)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:415)
> at 
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.processFrame(BrokerDecoder.java:74)
> at 
> org.apache.qpid.codec.AMQDecoder.processInput(AMQDecoder.java:370)
> at 
> 

[jira] [Updated] (QPID-7157) [Java Broker] Change metadata for management attributes having enum types to list all possible enum values in validValues property

[Alex Rudyy (JIRA)]

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

Alex Rudyy updated QPID-7157:
-
Description: metadata information should drive implementation of UI widgets 
for rendering attribute values.We need to change metadata of attributes having  
enum types to list enum values in validValues property. That would allow 
creation of widgets which can represent enum attribute editor as a "select" 
widget with options containing all possible enum values   (was: metadata 
information should drive implementation of UI widgets for rendering attribute 
values. It would be nice to provide in metadata the details of such custom 
types like enums. That would allow creation of widgets which can represent enum 
attribute editor as a "select" widget with options containing all possible enum 
values )

> [Java Broker] Change metadata for management attributes having enum types to 
> list all possible enum values in validValues property
> --
>
> Key: QPID-7157
> URL: https://issues.apache.org/jira/browse/QPID-7157
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Affects Versions: qpid-java-6.0.1
>Reporter: Alex Rudyy
> Fix For: qpid-java-6.1
>
>
> metadata information should drive implementation of UI widgets for rendering 
> attribute values.We need to change metadata of attributes having  enum types 
> to list enum values in validValues property. That would allow creation of 
> widgets which can represent enum attribute editor as a "select" widget with 
> options containing all possible enum values 



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

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

[jira] [Updated] (QPID-7157) [Java Broker] Change metadata for management attributes having enum types to list all possible enum values in validValues property

[Alex Rudyy (JIRA)]

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

Alex Rudyy updated QPID-7157:
-
Summary: [Java Broker] Change metadata for management attributes having 
enum types to list all possible enum values in validValues property  (was: 
[Java Broker] Enhance metadata service to provide more information about custom 
attribute types like enums which would include all possible enum values, etc)

> [Java Broker] Change metadata for management attributes having enum types to 
> list all possible enum values in validValues property
> --
>
> Key: QPID-7157
> URL: https://issues.apache.org/jira/browse/QPID-7157
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Affects Versions: qpid-java-6.0.1
>Reporter: Alex Rudyy
> Fix For: qpid-java-6.1
>
>
> metadata information should drive implementation of UI widgets for rendering 
> attribute values. It would be nice to provide in metadata the details of such 
> custom types like enums. That would allow creation of widgets which can 
> represent enum attribute editor as a "select" widget with options containing 
> all possible enum values 



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

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

[jira] [Commented] (QPID-7157) [Java Broker] Change metadata for management attributes having enum types to list all possible enum values in validValues property

[Keith Wall (JIRA)]

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

Keith Wall commented on QPID-7157:
--

For enums, we will automatically populate valid values with the values from the 
enum's domain, unless valid values is already overridden to provide a more 
restrictive set.

> [Java Broker] Change metadata for management attributes having enum types to 
> list all possible enum values in validValues property
> --
>
> Key: QPID-7157
> URL: https://issues.apache.org/jira/browse/QPID-7157
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Affects Versions: qpid-java-6.0.1
>Reporter: Alex Rudyy
> Fix For: qpid-java-6.1
>
>
> metadata information should drive implementation of UI widgets for rendering 
> attribute values. It would be nice to provide in metadata the details of such 
> custom types like enums. That would allow creation of widgets which can 
> represent enum attribute editor as a "select" widget with options containing 
> all possible enum values 



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

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

[jira] [Updated] (QPID-7158) [Java Broker] Change type of datetime management attributes from Long to java.util.Date

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7158:
-
Fix Version/s: qpid-java-6.1

> [Java Broker] Change type of datetime management attributes from Long to 
> java.util.Date
> ---
>
> Key: QPID-7158
> URL: https://issues.apache.org/jira/browse/QPID-7158
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Alex Rudyy
> Fix For: qpid-java-6.1
>
>
> It is unclear from metadata that datetime attribute having type Long  
> actually represent  datetime values. We need to change datetime attributes 
> type from Long to java.util.Date which can still be serialized into json as 
> long values



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

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

[jira] [Updated] (QPID-7157) [Java Broker] Enhance metadata service to provide more information about custom attribute types like enums which would include all possible enum values, etc

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7157:
-
Fix Version/s: qpid-java-6.1

> [Java Broker] Enhance metadata service to provide more information about 
> custom attribute types like enums which would include all possible enum 
> values, etc
> 
>
> Key: QPID-7157
> URL: https://issues.apache.org/jira/browse/QPID-7157
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Affects Versions: qpid-java-6.0.1
>Reporter: Alex Rudyy
> Fix For: qpid-java-6.1
>
>
> metadata information should drive implementation of UI widgets for rendering 
> attribute values. It would be nice to provide in metadata the details of such 
> custom types like enums. That would allow creation of widgets which can 
> represent enum attribute editor as a "select" widget with options containing 
> all possible enum values 



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

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

[jira] [Updated] (QPID-7158) [Java Broker] Change type of datetime management attributes from Long to java.util.Date

[Alex Rudyy (JIRA)]

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

Alex Rudyy updated QPID-7158:
-
Summary: [Java Broker] Change type of datetime management attributes from 
Long to java.util.Date  (was: [Java Broker] Change datetime management 
attributes to have Date type rather then Long)

> [Java Broker] Change type of datetime management attributes from Long to 
> java.util.Date
> ---
>
> Key: QPID-7158
> URL: https://issues.apache.org/jira/browse/QPID-7158
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Alex Rudyy
>
> It is unclear from metadata that datetime attribute having type Long  
> actually represent  datetime values. We need to change datetime attributes 
> type from Long to java.util.Date which can still be serialized into json as 
> long values



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

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

[jira] [Updated] (QPID-7158) [Java Broker] Change datetime management attributes to have Date type rather then Long

[Alex Rudyy (JIRA)]

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

Alex Rudyy updated QPID-7158:
-
Description: It is unclear from metadata that datetime attribute having 
type Long  actually represent  datetime values. We need to change datetime 
attributes type from Long to java.util.Date which can still be serialized into 
json as long values  (was: It is unclear from metadata that datetime attribute 
having type Long  actually represent a datetime value. Adding an extra property 
into metadata about attribute nature would allow displaying a datetime widget 
for such attributes)

> [Java Broker] Change datetime management attributes to have Date type rather 
> then Long
> --
>
> Key: QPID-7158
> URL: https://issues.apache.org/jira/browse/QPID-7158
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Alex Rudyy
>
> It is unclear from metadata that datetime attribute having type Long  
> actually represent  datetime values. We need to change datetime attributes 
> type from Long to java.util.Date which can still be serialized into json as 
> long values



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

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

[jira] [Updated] (QPID-7158) [Java Broker] Change datetime management attributes to have Date type rather then Long

[Alex Rudyy (JIRA)]

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

Alex Rudyy updated QPID-7158:
-
Summary: [Java Broker] Change datetime management attributes to have Date 
type rather then Long  (was: [Java Broker] Enhance metadata service to provide 
extra property for datetime atttribute having  Long type which would indicate 
that attribute actually represents datetime value)

> [Java Broker] Change datetime management attributes to have Date type rather 
> then Long
> --
>
> Key: QPID-7158
> URL: https://issues.apache.org/jira/browse/QPID-7158
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Alex Rudyy
>
> It is unclear from metadata that datetime attribute having type Long  
> actually represent a datetime value. Adding an extra property into metadata 
> about attribute nature would allow displaying a datetime widget for such 
> attributes



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

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

[jira] [Commented] (QPIDJMS-157) Add support for send timeout and request timeout options

[ASF subversion and git services (JIRA)]

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

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

Commit 3c0f4117baf3554165376fa028a28cacc6507e72 in qpid-jms's branch 
refs/heads/master from Robert Gemmell
[ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=3c0f411 ]

QPIDJMS-157: expect links to detach after timeout, avoid race to shut down the 
test peer


> Add support for send timeout and request timeout options
> 
>
> Key: QPIDJMS-157
> URL: https://issues.apache.org/jira/browse/QPIDJMS-157
> Project: Qpid JMS
>  Issue Type: New Feature
>  Components: qpid-jms-client
>Affects Versions: 0.8.0
>Reporter: Timothy Bish
>Assignee: Timothy Bish
> Fix For: 0.9.0
>
>
> Add support for a timeout option for message sends.  In the case of failover 
> allow the send to timeout after some configured interval with an error 
> indicating the send failed.



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

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

[jira] [Resolved] (QPID-7161) System test output lost owing to orphaned shutdown hooks

[Lorenz Quack (JIRA)]

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

Lorenz Quack resolved QPID-7161.

Resolution: Fixed

looks good to me

> System test output lost owing to orphaned shutdown hooks
> 
>
> Key: QPID-7161
> URL: https://issues.apache.org/jira/browse/QPID-7161
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker, Java Tests
>Reporter: Keith Wall
>Assignee: Lorenz Quack
>Priority: Minor
>
> When the Broker exits, normally {{AbstractSystemConfig}} organises for the 
> shutdown hook to be removed ({{#onClose}}).  If {{AbstractSystemConfig}} 
> fails to close all its children, the step to remove the shutdown hook never 
> gets executed.  For normal production use cases this is harmless; the Broker 
> is going down anyway.  However when testing the Broker using its system test 
> suite this is problematic.
> Our Logback configuration associates threads to test specific log file.  The 
> ShutdownHook still maintains this association, even though QpidTestCase has 
> already told Logback that the test is through {{org.slf4j.MDC#remove}}.  As 
> Logback believes the test is through, when the Shutdown hook awakes and logs, 
> Logback truncates the tests' logfiles, removing the details of why the test 
> actually failed in the first place.



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

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

Re: qpid_tests/broker_1_0 not in tests/setup.py

[Gordon Sim]

On 28/03/16 08:57, Keith W wrote:

Hi all,

I am trying to automate the running of the existing Python AMQP 1.0
broker tests against the Java Broker with the proton-c/cpp binary
dependencies built from their respective trunks.

I am installing the Python modules to a private site-package
directory, but I notice the tests/setup.py does not seem to install
the broker_1_0 module.  Is this an oversight? Or is the running of the
broker_1_0 tests different to the others?


The qpid.messaging python client does not support AMQP 1.0. The 
qpid::messaging c++ client has been swigged though (mainly only for ease 
of testing), and provides _almost_ the same api.



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

[jira] [Commented] (QPID-7149) [HA] active HA broker memory leak when ring queue discards overflow messages

[Pavel Moravec (JIRA)]

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

Pavel Moravec commented on QPID-7149:
-

It allows everything:

acl allow all all

I explicitly set that to overwrite the default used ACL file with a rule 
disabling federation links (what would _prevent_ the mem.leak).

> [HA] active HA broker memory leak when ring queue discards overflow messages
> 
>
> Key: QPID-7149
> URL: https://issues.apache.org/jira/browse/QPID-7149
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker
> Environment: RHEL6
> qpid trunk svn rev. 1735384
> - issue seen in very old releases (since active-passive HA cluster initial 
> implementation, most probably)
> libstdc++-devel-4.4.7-4.el6.x86_64
> gcc-c++-4.4.7-4.el6.x86_64
> libgcc-4.4.7-4.el6.x86_64
> libstdc++-4.4.7-4.el6.x86_64
> gcc-4.4.7-4.el6.x86_64
>Reporter: Pavel Moravec
>Assignee: Alan Conway
>
> There is a memory leak on active HA broker, triggered most probably by 
> purging overflow message from a ring queue. Basic scenario is to setup HA 
> cluster, promote to primary and feed forever a ring queue with messages.
> Detailed scenario:
> 1) Start brokers and promote one to primary:
> {noformat}
> start_broker() {
>   port=$1
>   shift
>   rm -rf _${port}
>   mkdir _${port}
>   nohup qpidd --load-module=ha.so --port=$port 
> --log-to-file=qpidd.$port.log --data-dir=_${port} --auth=no 
> --log-to-stderr=no --ha-cluster=yes 
> --ha-brokers-url="$(hostname):5672,$(hostname):5673,$(hostname):5674" 
> --ha-replicate=all --acl-file=/root/qpidd.acl "$@" > /dev/null 2>&1 &
>   sleep 1
> }
> killall qpidd qpid-receive 2> /dev/null
> rm -f qpidd.*.log
> start_broker 5672
> sleep 1
> qpid-ha promote -b $(hostname):5672 --cluster-manager
> sleep 1
> start_broker 5673
> sleep 1
> start_broker 5674
> {noformat}
> 2) Create ring queues and send there messages (it is enough to have 1 queue, 
> having more should show the leak faster):
> {noformat}
> for i in $(seq 0 9); do
>   qpid-config add queue FromKeyServer_$i --max-queue-size=1 
> --max-queue-count=10 --limit-policy=ring --argument=x-qpid-priorities=10
> done
> while true; do
>   for j in $(seq 1 10); do
>   for i in $(seq 1 10); do
>   for k in $(seq 0 9); do
>   qpid-send -a FromKeyServer_$k -m 100 
> --send-rate=50 -- priority=$(($((RANDOM))%10)) &
>   done
>   done
>   wait
>   while [ $(qpid-stat -q | grep broker-replicator | sed "s/Y//g" 
> | awk '{ print $2 }' | sort -n | tail -n1) != "0" ]; do
>   sleep 1
>   done
>   done
>   date
>   ps aux | grep qpidd | grep "port=5672" | awk -F "--store-dir" '{ print 
> $1 }'
> done
> {noformat}
> (the "while [ $(qpid-stat -q | .." cycle is there just to slow down the 
> message enqueues to ensure replication federation queues dont have big 
> backlog - that would interfere with memory consumpiton observation)
> 3) Run those scripts and monitor memory consumption.
> - without using priority queues and sending messages without priorities, leak 
> is evident as well - sometimes smaller, sometimes the same
> - valgrind (on some older versions I tested before more thoroughly) detects 
> nothing (neither leaked memory or reachable at shutdown)
> - same leak is evident even with --ha-replicate=none
> - number of backup brokers does not affect the memory leak



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

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