[GitHub] qpid-jms pull request: Implements QPIDJMS-164 - Provide an OSGi bu...

2016-03-31 Thread tabish121 
Github user tabish121 commented on the pull request:

https://github.com/apache/qpid-jms/pull/2#issuecomment-204055703
  
I did add the BND plugin to proton-j recently in order to generate bundle 
information in the next release, a review from someone more versed in OSGi 
would be good.  

The client would work with any Netty version in the 4.0.x series given our 
past testing.  


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

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

[jira] [Commented] (QPIDJMS-164) Provide an OSGi bundle for the Qpid JMS client

2016-03-31 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on QPIDJMS-164:


Github user tabish121 commented on the pull request:

https://github.com/apache/qpid-jms/pull/2#issuecomment-204055703
  
I did add the BND plugin to proton-j recently in order to generate bundle 
information in the next release, a review from someone more versed in OSGi 
would be good.  

The client would work with any Netty version in the 4.0.x series given our 
past testing.  


> Provide an OSGi bundle for the Qpid JMS client
> --
>
> Key: QPIDJMS-164
> URL: https://issues.apache.org/jira/browse/QPIDJMS-164
> Project: Qpid JMS
>  Issue Type: Improvement
>Reporter: Hiram Chirino
>




--
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-164) Provide an OSGi bundle for the Qpid JMS client

2016-03-31 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on QPIDJMS-164:


Github user chirino commented on the pull request:

https://github.com/apache/qpid-jms/pull/2#issuecomment-204042552
  
So some of the issues then you have to take on is make sure your internal 
dependencies work well add mixed versions.  For example will your lib work well 
with the Netty versions that are shipped with Fuse?  Have you guys made a 
proper OSGi bundle for proton-j?

This uber bundle just ubers protonj and netty since they are internal 
implementation details.  It imports the logging and and JMS libs since they 
need to be shared.


> Provide an OSGi bundle for the Qpid JMS client
> --
>
> Key: QPIDJMS-164
> URL: https://issues.apache.org/jira/browse/QPIDJMS-164
> Project: Qpid JMS
>  Issue Type: Improvement
>Reporter: Hiram Chirino
>




--
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-jms pull request: Implements QPIDJMS-164 - Provide an OSGi bu...

2016-03-31 Thread chirino 
Github user chirino commented on the pull request:

https://github.com/apache/qpid-jms/pull/2#issuecomment-204042552
  
So some of the issues then you have to take on is make sure your internal 
dependencies work well add mixed versions.  For example will your lib work well 
with the Netty versions that are shipped with Fuse?  Have you guys made a 
proper OSGi bundle for proton-j?

This uber bundle just ubers protonj and netty since they are internal 
implementation details.  It imports the logging and and JMS libs since they 
need to be shared.


---
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] [Closed] (DISPATCH-249) Policy AMQP Open processing checks too late that policy is disabled

2016-03-31 Thread Chuck Rolke (JIRA) 

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

Chuck Rolke closed DISPATCH-249.

Resolution: Later

The current scheme is required to keep proton events serialized properly.

> Policy AMQP Open processing checks too late that policy is disabled
> ---
>
> Key: DISPATCH-249
> URL: https://issues.apache.org/jira/browse/DISPATCH-249
> Project: Qpid Dispatch
>  Issue Type: Bug
>Reporter: Chuck Rolke
>Assignee: Chuck Rolke
>
> Policy processing checks that policy is disabled after scheduling a deferred 
> Open process. This check should be done before executing the deferral so that 
> Opens with no policy are done synchronously.



--
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-127) Messages from waypoints to remote routers are not delivered

2016-03-31 Thread Ted Ross (JIRA) 

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

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

> Messages from waypoints to remote routers are not delivered
> ---
>
> Key: DISPATCH-127
> URL: https://issues.apache.org/jira/browse/DISPATCH-127
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 0.3
>Reporter: Ted Ross
>Assignee: Ted Ross
> Fix For: 0.6
>
>
> When messages from a waypoint to a remote consumer (one on a router other 
> than the one connected to the waypoint), messages are not delivered but are 
> RELEASED as unroutable.
> This occurs because the to_override field in the message annotations is not 
> properly set during ingress from the waypoint.



--
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-127) Messages from waypoints to remote routers are not delivered

2016-03-31 Thread ASF subversion and git services (JIRA) 

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

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

Commit 9d08d0a678d71c275ab0c05d4f28b1549630e132 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=9d08d0a ]

DISPATCH-127 - Carry the ingress address phase across inter-router links so 
waypoints can be
accessed from remote routers.


> Messages from waypoints to remote routers are not delivered
> ---
>
> Key: DISPATCH-127
> URL: https://issues.apache.org/jira/browse/DISPATCH-127
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 0.3
>Reporter: Ted Ross
>Assignee: Ted Ross
> Fix For: 0.6
>
>
> When messages from a waypoint to a remote consumer (one on a router other 
> than the one connected to the waypoint), messages are not delivered but are 
> RELEASED as unroutable.
> This occurs because the to_override field in the message annotations is not 
> properly set during ingress from the waypoint.



--
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-163) support populating the user-id field on produced messages

2016-03-31 Thread Timothy Bish (JIRA) 

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

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

> 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
>Affects Versions: 0.8.0
>Reporter: Robbie Gemmell
>Assignee: Timothy Bish
> Fix For: 0.9.0
>
>
> 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] [Updated] (QPIDJMS-163) support populating the user-id field on produced messages

2016-03-31 Thread Timothy Bish (JIRA) 

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

Timothy Bish updated QPIDJMS-163:
-
Fix Version/s: 0.9.0

> 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
>Affects Versions: 0.8.0
>Reporter: Robbie Gemmell
>Assignee: Timothy Bish
> Fix For: 0.9.0
>
>
> 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] [Updated] (QPIDJMS-163) support populating the user-id field on produced messages

2016-03-31 Thread Timothy Bish (JIRA) 

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

Timothy Bish updated QPIDJMS-163:
-
Affects Version/s: 0.8.0

> 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
>Affects Versions: 0.8.0
>Reporter: Robbie Gemmell
>Assignee: Timothy Bish
> Fix For: 0.9.0
>
>
> 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

2016-03-31 Thread Robbie Gemmell 

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



Looks good other than the couple of tiny issues noted.


proton-j/src/main/java/org/apache/qpid/proton/engine/Connection.java (lines 126 
- 127)


Does this need to be added to the interface?

The only use of it seems to cast to impl anyway, and it is asymmetric given 
there isn't an equivalent setter being added.

I'd make it impl-only for now at least if possible to avoid more 
reactor-specific leakage into the general API (ugly, but so is the lack of a 
'ReactorConnection' equivalent to match the C stuff).



proton-j/src/main/java/org/apache/qpid/proton/reactor/Reactor.java (line 265)


The url param goes before the handler in the C variant, which might be more 
natural, but I think consistency either way would be good.


- Robbie Gemmell


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] (QPID-7086) [Java Broker, Web Management Console] Add ability to set context variables

2016-03-31 Thread Alex Rudyy (JIRA) 

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

Alex Rudyy updated QPID-7086:
-
Attachment: WIP-Add-context-editor-to-auth-provider-ui.diff

> [Java Broker, Web Management Console] Add ability to set context variables
> --
>
> Key: QPID-7086
> URL: https://issues.apache.org/jira/browse/QPID-7086
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Lorenz Quack
>Assignee: Keith Wall
> Fix For: qpid-java-6.1
>
> Attachments: WIP-Add-context-editor-to-auth-provider-ui.diff
>
>
> Currently the Web Management Console support viewing/setting context 
> variables on a few selected objects (e.g., broker and VH).
> It should be possible to view/set the context variables of all 
> ConfiguredObjects.
> One place where this is currently an issue is Port where the UI does not 
> support context variables but we might want to selectively enable/disable TLS 
> protocols.



--
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-7149) [HA] active HA broker memory leak when ring queue discards overflow messages

2016-03-31 Thread Alan Conway (JIRA) 

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

Alan Conway commented on QPID-7149:
---

I have a fix under test, see 
https://bugzilla.redhat.com/show_bug.cgi?id=1318180. Will commit to trunk as 
soon as verified.

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

[jira] [Commented] (QPIDJMS-164) Provide an OSGi bundle for the Qpid JMS client

2016-03-31 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on QPIDJMS-164:


Github user gemmellr commented on the pull request:

https://github.com/apache/qpid-jms/pull/2#issuecomment-203999771
  
I rather dislike the uber bundle approach. Tim already did a little 
groundwork previously on updating our various dependencies to ensure they 
do/will provide osgi metadata, I think I'd rather see that work taken forward 
than to add a separate osgi uber module if at all avoidable.


> Provide an OSGi bundle for the Qpid JMS client
> --
>
> Key: QPIDJMS-164
> URL: https://issues.apache.org/jira/browse/QPIDJMS-164
> Project: Qpid JMS
>  Issue Type: Improvement
>Reporter: Hiram Chirino
>




--
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-jms pull request: Implements QPIDJMS-164 - Provide an OSGi bu...

2016-03-31 Thread gemmellr 
Github user gemmellr commented on the pull request:

https://github.com/apache/qpid-jms/pull/2#issuecomment-203999771
  
I rather dislike the uber bundle approach. Tim already did a little 
groundwork previously on updating our various dependencies to ensure they 
do/will provide osgi metadata, I think I'd rather see that work taken forward 
than to add a separate osgi uber module if at all avoidable.


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

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

[jira] [Created] (QPID-7177) Add support for where clauses including now(), currentUser()

2016-03-31 Thread Keith Wall (JIRA) 
Keith Wall created QPID-7177:


 Summary: Add support for where clauses including now(), 
currentUser()
 Key: QPID-7177
 URL: https://issues.apache.org/jira/browse/QPID-7177
 Project: Qpid
  Issue Type: Improvement
  Components: Java Broker
Reporter: Keith Wall
 Fix For: qpid-java-6.1


Allow a query's where clause to include now() and currentUser().   This will 
allow the Operator to more easily re-use queries over time, or share queries 
amongst his team.



--
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-7165) Allow query results to be sorted and paginated

2016-03-31 Thread Keith Wall (JIRA) 

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

Keith Wall commented on QPID-7165:
--

We want to check the relevant SQL standards concerning the syntax for the 
sorting of a column that results from function/expressions and follow it if 
possible.

For limit/offset, it seems there is not a broad consensus in the REST 
implementing community regarding the correctness of the use of Range headers to 
implement pagination.  We said we would go we limit and offset query parameters 
for now, and revisit the decision. Also when limit is returned the number of 
records that would be returned if pagination were not in use must be returned 
as part of the response.



> 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 
> e.g. {{orderBy='x ASC,y DESC,z'}}
> 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] [Updated] (QPID-7165) Allow query results to be sorted and paginated

2016-03-31 Thread 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:
-
Description: 
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 e.g. 
{{orderBy='x ASC,y DESC,z'}}

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.



  was:
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.




> 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 
> e.g. {{orderBy='x ASC,y DESC,z'}}
> 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] [Commented] (QPID-7176) Support valid values that are context sensitive

2016-03-31 Thread Rob Godfrey (JIRA) 

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

Rob Godfrey commented on QPID-7176:
---

So there's actually two cases here... 

# on creation of the new object where the only context available is the 
parent(s) of the object to be created 
# updating an existing object where the context is the object itself.

I suppose these two cases could be generalise to a single case of a path to a 
configured object which might be a parent or the object itself... but that is 
also potentially tricky.

As an aside I think from the examples given in the description 
"{{#clientCertRecorder}} should be restricted to the 
ManagedPeerCertificateTrustStores that are defined at that moment" you could 
actually solve that with a valid values function using the existing 
infrastructure (presuming you aren't caching valid values).  

> Support valid values that are context sensitive
> ---
>
> Key: QPID-7176
> URL: https://issues.apache.org/jira/browse/QPID-7176
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
>
> The model already has the ability to publish valid value information for the  
> attributes of a category.  This information is static.
> We need an analogous mechanism for instances or instances that are about to 
> be. For example, when creating or updating a Queue, the choice for 
> {{#alternateExchange}} should be restricted to Exchanges belonging to the 
> enclosing virtualhost, or when creating or editing a AMQPPort, 
> {{#clientCertRecorder}} should be restricted to the 
> ManagedPeerCertificateTrustStores that are defined at that moment.



--
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-6983) [Web Management Console] Add UI support for queries

2016-03-31 Thread Keith Wall (JIRA) 

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

Keith Wall commented on QPID-6983:
--

Comments following a review today:

1)  Tick a field within the Field popup and then click Cancel.   Expected: 
tick forgotten, actual: tick retained.
2)  Remove the pagination options within Field/Condition popups.  Keep the 
count.
3)  Remove the ‘not; from the list of options on the clause’s dropdown.
4)  Removing a clause from a Condition closed the Condition popup. 
Expected: clause removed.
5)  Categories should have a default set of fields (LATER)
6)  Rename Fields to Columns
7)  Conditions for attributes that have valid values should allow the user 
to choose multiple items (Requires QPID-7157)
8)  Conditions for attributes that are Dates should use date/time picker 
(Requires QPID-7158)
9)  Select and where text fields are too short.
10)   An advance search where the select part contained an expression failed
11)   Ability to re-order columns (LATER)
12)   Columns were not properly reset when switching between standard/advanced
13)   Add support for queries involving attributes that are not basic types 
(e.g Queue.alternativeExchange)  (LATER)
14)   Add support for queries involving attributes that are collections. (LATER)
15)   User should be able to specify the page size (LATER)


> [Web Management Console] Add UI support for queries
> ---
>
> Key: QPID-6983
> URL: https://issues.apache.org/jira/browse/QPID-6983
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
>Assignee: Alex Rudyy
> Attachments: query-ui-prototype.tar.gz
>
>
> Add the ability to the Web Management Console to submit queries (using the 
> feature added by QPID-6969) and view the results.  The results may need to be 
> paginated for display.



--
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-7176) Support valid values that are context sensitive

2016-03-31 Thread Keith Wall (JIRA) 
Keith Wall created QPID-7176:


 Summary: Support valid values that are context sensitive
 Key: QPID-7176
 URL: https://issues.apache.org/jira/browse/QPID-7176
 Project: Qpid
  Issue Type: Improvement
  Components: Java Broker
Reporter: Keith Wall


The model already has the ability to publish valid value information for the  
attributes of a category.  This information is static.

We need an analogous mechanism for instances or instances that are about to be. 
For example, when creating or updating a Queue, the choice for 
{{#alternateExchange}} should be restricted to Exchanges belonging to the 
enclosing virtualhost, or when creating or editing a AMQPPort, 
{{#clientCertRecorder}} should be restricted to the 
ManagedPeerCertificateTrustStores that are defined at that moment.





--
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-7172) HTTP Management threads are blocked by potentially long running operations

2016-03-31 Thread Lorenz Quack (JIRA) 

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

Lorenz Quack updated QPID-7172:
---
Description: 
As an operator of the Broker using the Web Management Console, I can initiate 
operations such as purge queue.  These operations may be long running.

When issuing a long running operation the user ought to get visual feedback 
that it is in progress.  Later the user should be able to return and find out 
if the task is finished and get the result.

Currently the operator may believe that the operation is 'stuck', and try the 
operation again, or get a colleague to do the same.

Internally within the Java Broker, the web thread is blocked awaiting the 
operation on the configuration thread.  If many such operations are in flight 
(or the operator retries an operation in belief it is stuck), the web tier may 
become slow or unresponsive.


  was:
As an operator of the Broker using the Web Management Console, I can initiate 
operations such as purge queue.  These operations may be long running.  
Currently the browser hangs whilst the operation is in progress.  If the 
operation takes a very long time the browser or an intermediate proxy may 
timeout the connection.

The user ought to be able to initiate a long running operation than continue to 
work on other tasks.  Later the user should be able to return and find out if 
the task is finished and get the result.

Currently the operator may believe that the operation is 'stuck', and try the 
operation again, or get a colleague to do the same.

Internally within the Java Broker, the web thread is blocked awaiting the 
operation on the configuration thread.  If many such operations are in flight 
(or the operator retries an operation in belief it is stuck), the web tier may 
become slow or unresponsive.



> HTTP Management threads are blocked by potentially long running operations
> --
>
> Key: QPID-7172
> URL: https://issues.apache.org/jira/browse/QPID-7172
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Reporter: Keith Wall
>
> As an operator of the Broker using the Web Management Console, I can initiate 
> operations such as purge queue.  These operations may be long running.
> When issuing a long running operation the user ought to get visual feedback 
> that it is in progress.  Later the user should be able to return and find out 
> if the task is finished and get the result.
> Currently the operator may believe that the operation is 'stuck', and try the 
> operation again, or get a colleague to do the same.
> Internally within the Java Broker, the web thread is blocked awaiting the 
> operation on the configuration thread.  If many such operations are in flight 
> (or the operator retries an operation in belief it is stuck), the web tier 
> may become slow or unresponsive.



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

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

[jira] [Created] (DISPATCH-249) Policy AMQP Open processing checks too late that policy is disabled

2016-03-31 Thread Chuck Rolke (JIRA) 
Chuck Rolke created DISPATCH-249:


 Summary: Policy AMQP Open processing checks too late that policy 
is disabled
 Key: DISPATCH-249
 URL: https://issues.apache.org/jira/browse/DISPATCH-249
 Project: Qpid Dispatch
  Issue Type: Bug
Reporter: Chuck Rolke
Assignee: Chuck Rolke


Policy processing checks that policy is disabled after scheduling a deferred 
Open process. This check should be done before executing the deferral so that 
Opens with no policy are done synchronously.



--
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-242) Add options to qdstat to display autoLinks and linkRoutes

2016-03-31 Thread ASF subversion and git services (JIRA) 

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

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

Commit 2a03648c8b1e6072f4a220fbf5abcf952853202c 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=2a03648 ]

DISPATCH-242 - Followed suggestions from Justin Ross: Removed some short-form 
args, made long-form args plural.


> 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