[jira] [Commented] (PROTON-1138) Assorted C++ API cleanups

[ASF subversion and git services (JIRA)]

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

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

Commit 278916a237aa025d3ae776904ccc526b3c82e21c in qpid-proton's branch 
refs/heads/master from Clifford Jansen
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=278916a ]

PROTON-1138: connection.release, heartbeat, link_prefix gone, max_channels -> 
max_sessions


> Assorted C++ API cleanups
> -
>
> Key: PROTON-1138
> URL: https://issues.apache.org/jira/browse/PROTON-1138
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: cpp-binding
>Affects Versions: 0.13.0
>Reporter: Justin Ross
>Assignee: Justin Ross
> Fix For: 0.13.0
>
>




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

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

[jira] [Resolved] (DISPATCH-300) Deprecate the ContainerEntity and move its attributes to RouterEntity

[Ted Ross (JIRA)]

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

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

> Deprecate the ContainerEntity and move its attributes to RouterEntity
> -
>
> Key: DISPATCH-300
> URL: https://issues.apache.org/jira/browse/DISPATCH-300
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Container
>Affects Versions: 0.6
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
> Fix For: 0.6
>
>
> Move the attributes of ContainerEntity to RouterEntity thus deprecating 
> ContainerEntity so we will have reduced complexity. This change should be 
> backward compatible meaning configs currently using ContainerEntity must not 
> be affected by this change.



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

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

[jira] [Commented] (DISPATCH-300) Deprecate the ContainerEntity and move its attributes to RouterEntity

[ASF subversion and git services (JIRA)]

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

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

Commit 7e5a04330f6b44a8e4db3fc4af052b1add2e1e3a 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=7e5a043 ]

DISPATCH-300 - (From Ganesh Murthy) Deprecated "container" in the configuration.


> Deprecate the ContainerEntity and move its attributes to RouterEntity
> -
>
> Key: DISPATCH-300
> URL: https://issues.apache.org/jira/browse/DISPATCH-300
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Container
>Affects Versions: 0.6
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
> Fix For: 0.6
>
>
> Move the attributes of ContainerEntity to RouterEntity thus deprecating 
> ContainerEntity so we will have reduced complexity. This change should be 
> backward compatible meaning configs currently using ContainerEntity must not 
> be affected by this change.



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

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

[jira] [Updated] (DISPATCH-300) Deprecate the ContainerEntity and move its attributes to RouterEntity

[Ted Ross (JIRA)]

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

Ted Ross updated DISPATCH-300:
--
Fix Version/s: 0.6

> Deprecate the ContainerEntity and move its attributes to RouterEntity
> -
>
> Key: DISPATCH-300
> URL: https://issues.apache.org/jira/browse/DISPATCH-300
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Container
>Affects Versions: 0.6
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
> Fix For: 0.6
>
>
> Move the attributes of ContainerEntity to RouterEntity thus deprecating 
> ContainerEntity so we will have reduced complexity. This change should be 
> backward compatible meaning configs currently using ContainerEntity must not 
> be affected by this change.



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

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

[jira] [Assigned] (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 reassigned DISPATCH-194:
-

Assignee: Ted Ross  (was: 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: Ted Ross
>Priority: Blocker
> 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] [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&focusedCommentId=15270015#comment-15270015
 ] 

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

Commit 8fa9635252abac997266f2388ba5a5844f34e88b 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=8fa9635 ]

DISPATCH-57 - Fixed balanced forwarding so it a) wont involve "full" links, and 
b) will honor
the valid-origin for messages when choosing a path to the destination, and c) 
uses the router
cost as a threshold for using inter-router links.


> 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 feature makes use of the route-cost to remove router nodes.  The 
> cost-to-remote-consumer is used as a threshold for forwarding deliveries to 
> that node.  For example, if the cost to a remote consumer is 100, then the 
> local router that takes in deliveries to the address will only start 
> forwarding messages to the remote node once local consumers have a backlog of 
> at least 100 outstanding (unsettled) deliveries.



--
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-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 updated DISPATCH-57:
-
Description: 
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 feature makes use of the route-cost to remove router nodes.  The 
cost-to-remote-consumer is used as a threshold for forwarding deliveries to 
that node.  For example, if the cost to a remote consumer is 100, then the 
local router that takes in deliveries to the address will only start forwarding 
messages to the remote node once local consumers have a backlog of at least 100 
outstanding (unsettled) deliveries.

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


> 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 feature makes use of the route-cost to remove router nodes.  The 
> cost-to-remote-consumer is used as a threshold for forwarding deliveries to 
> that node.  For example, if the cost to a remote consumer is 100, then the 
> local router that takes in deliveries to the address will only start 
> forwarding messages to the remote node once local consumers have a backlog of 
> at least 100 outstanding (unsettled) deliveries.



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

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

[jira] [Commented] (PROTON-1138) Assorted C++ API cleanups

[ASF subversion and git services (JIRA)]

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

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

Commit 24dd60385b52b471120a227bcb8ed8225e199a8a in qpid-proton's branch 
refs/heads/master from Clifford Jansen
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=24dd603 ]

PROTON-1138: connection host becomes virtual_host


> Assorted C++ API cleanups
> -
>
> Key: PROTON-1138
> URL: https://issues.apache.org/jira/browse/PROTON-1138
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: cpp-binding
>Affects Versions: 0.13.0
>Reporter: Justin Ross
>Assignee: Justin Ross
> Fix For: 0.13.0
>
>




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

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

[jira] [Commented] (DISPATCH-304) Console PNG images not showing up in documentation

[Ganesh Murthy (JIRA)]

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

Ganesh Murthy commented on DISPATCH-304:


The images show up now but are too big to fit into the center div - 
https://qpid.apache.org/releases/qpid-dispatch-master/book/console_operation.html#topology-page

> Console PNG images not showing up in documentation
> --
>
> Key: DISPATCH-304
> URL: https://issues.apache.org/jira/browse/DISPATCH-304
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 0.6
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>
> If you go to 
> http://qpid.apache.org/releases/qpid-dispatch-master/book/console_operation.html#logging-in-to-a-router-network
>  you will see that the images to console_overview.png, console_topology.png 
> etc are missing.



--
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-131) Provide for finer grained control over sending of messages as presettled.

[Timothy Bish (JIRA)]

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

Timothy Bish resolved QPIDJMS-131.
--
   Resolution: Fixed
 Assignee: Timothy Bish
Fix Version/s: 0.10.0

> Provide for finer grained control over sending of messages as presettled.
> -
>
> Key: QPIDJMS-131
> URL: https://issues.apache.org/jira/browse/QPIDJMS-131
> Project: Qpid JMS
>  Issue Type: Improvement
>  Components: qpid-jms-client
>Affects Versions: 0.6.0
>Reporter: Timothy Bish
>Assignee: Timothy Bish
> Fix For: 0.10.0
>
>
> Provide more options for when a message can be sent presettled or not.  
> Cases where it makes sense to allow for presettle sends are messages sent as 
> non-persistent or messages sent inside a transaction where the transaction 
> boundary can provide the sync point for batch send success or failure.  



--
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-173) Provide for finer grained control over automatic presettling of received messages

[Timothy Bish (JIRA)]

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

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

> Provide for finer grained control over automatic presettling of received 
> messages
> -
>
> Key: QPIDJMS-173
> URL: https://issues.apache.org/jira/browse/QPIDJMS-173
> Project: Qpid JMS
>  Issue Type: Improvement
>Affects Versions: 0.9.0
>Reporter: Timothy Bish
>Assignee: Timothy Bish
> Fix For: 0.10.0
>
>
> Allow for configuration on a policy level for controlling automatic settling 
> of incoming messages.  This make sense in cases such as Topic receivers etc 
> where the message loss is non-critical. 



--
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-173) Provide for finer grained control over automatic presettling of received messages

[ASF subversion and git services (JIRA)]

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

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

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

QPIDJMS-173 Add options to control consumer presettle state.

> Provide for finer grained control over automatic presettling of received 
> messages
> -
>
> Key: QPIDJMS-173
> URL: https://issues.apache.org/jira/browse/QPIDJMS-173
> Project: Qpid JMS
>  Issue Type: Improvement
>Affects Versions: 0.9.0
>Reporter: Timothy Bish
>Assignee: Timothy Bish
> Fix For: 0.10.0
>
>
> Allow for configuration on a policy level for controlling automatic settling 
> of incoming messages.  This make sense in cases such as Topic receivers etc 
> where the message loss is non-critical. 



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

[Ken Giusti (JIRA)]

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

Ken Giusti updated DISPATCH-194:

Priority: Blocker  (was: Major)

This JIRA blocks submitting this to debian, which enforces a 3 year ABI 
compatibility requirement.  Without this fix, the library will be considered 
public and that will make bug fixes difficult.

> 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
>Priority: Blocker
> 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] (PROTON-1189) remove the 'contrib/proton-hawtdispatch' module

[Robbie Gemmell (JIRA)]

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

Robbie Gemmell updated PROTON-1189:
---
Description: 
Remove the 'contrib/proton-hawtdispatch' module

As per discussion thread on the users list:
http://mail-archives.apache.org/mod_mbox/qpid-users/201604.mbox/%3CCAFitrpSKn%2BsyQLh8aj62%3DEVyvANMw4g0nj_wh4%2BGtFAfJ_Z0-Q%40mail.gmail.com%3E

  was:
Remove the 'proton/contrib/proton-hawtdispatch' module

As per discussion thread on the users list:
http://mail-archives.apache.org/mod_mbox/qpid-users/201604.mbox/%3CCAFitrpSKn%2BsyQLh8aj62%3DEVyvANMw4g0nj_wh4%2BGtFAfJ_Z0-Q%40mail.gmail.com%3E

Summary: remove the 'contrib/proton-hawtdispatch' module  (was: remove 
the 'proton/contrib/proton-hawtdispatch' module)

> remove the 'contrib/proton-hawtdispatch' module
> ---
>
> Key: PROTON-1189
> URL: https://issues.apache.org/jira/browse/PROTON-1189
> Project: Qpid Proton
>  Issue Type: Task
>Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
> Fix For: 0.13.0
>
>
> Remove the 'contrib/proton-hawtdispatch' module
> As per discussion thread on the users list:
> http://mail-archives.apache.org/mod_mbox/qpid-users/201604.mbox/%3CCAFitrpSKn%2BsyQLh8aj62%3DEVyvANMw4g0nj_wh4%2BGtFAfJ_Z0-Q%40mail.gmail.com%3E



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

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

[jira] [Updated] (PROTON-1188) remove the 'contrib/proton-jms' module

[Robbie Gemmell (JIRA)]

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

Robbie Gemmell updated PROTON-1188:
---
Description: 
Remove the 'contrib/proton-jms' module

As per discussion thread on the users list:
http://mail-archives.apache.org/mod_mbox/qpid-users/201604.mbox/%3CCAFitrpTGGi8ttT1v3fcQ-JdYJof2L%2BNRg-oGs8UHzRK9CGAnQA%40mail.gmail.com%3E

  was:
Remove the 'proton/contrib/proton-jms' module

As per discussion thread on the users list:
http://mail-archives.apache.org/mod_mbox/qpid-users/201604.mbox/%3CCAFitrpTGGi8ttT1v3fcQ-JdYJof2L%2BNRg-oGs8UHzRK9CGAnQA%40mail.gmail.com%3E

Summary: remove the 'contrib/proton-jms' module  (was: remove the 
'proton/contrib/proton-jms' module)

> remove the 'contrib/proton-jms' module
> --
>
> Key: PROTON-1188
> URL: https://issues.apache.org/jira/browse/PROTON-1188
> Project: Qpid Proton
>  Issue Type: Task
>Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
> Fix For: 0.13.0
>
>
> Remove the 'contrib/proton-jms' module
> As per discussion thread on the users list:
> http://mail-archives.apache.org/mod_mbox/qpid-users/201604.mbox/%3CCAFitrpTGGi8ttT1v3fcQ-JdYJof2L%2BNRg-oGs8UHzRK9CGAnQA%40mail.gmail.com%3E



--
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-304) Console PNG images not showing up in documentation

[ASF subversion and git services (JIRA)]

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

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

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

DISPATCH-304 - Additional fix to correct URL of console_login.png


> Console PNG images not showing up in documentation
> --
>
> Key: DISPATCH-304
> URL: https://issues.apache.org/jira/browse/DISPATCH-304
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 0.6
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>
> If you go to 
> http://qpid.apache.org/releases/qpid-dispatch-master/book/console_operation.html#logging-in-to-a-router-network
>  you will see that the images to console_overview.png, console_topology.png 
> etc are missing.



--
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-300) Deprecate the ContainerEntity and move its attributes to RouterEntity

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on DISPATCH-300:
-

Github user ganeshmurthy closed the pull request at:

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


> Deprecate the ContainerEntity and move its attributes to RouterEntity
> -
>
> Key: DISPATCH-300
> URL: https://issues.apache.org/jira/browse/DISPATCH-300
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Container
>Affects Versions: 0.6
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>
> Move the attributes of ContainerEntity to RouterEntity thus deprecating 
> ContainerEntity so we will have reduced complexity. This change should be 
> backward compatible meaning configs currently using ContainerEntity must not 
> be affected by this change.



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

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

[GitHub] qpid-dispatch pull request: DISPATCH-300 - Deprecate the Container...

[ganeshmurthy]

Github user ganeshmurthy closed the pull request at:

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


---
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] (PROTON-1189) remove the 'proton/contrib/proton-hawtdispatch' module

[ASF subversion and git services (JIRA)]

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

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

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

PROTON-1188, PROTON-1189: remove stale contrib/proton-jms and 
contrib/proton-hawtdispatch modules


> remove the 'proton/contrib/proton-hawtdispatch' module
> --
>
> Key: PROTON-1189
> URL: https://issues.apache.org/jira/browse/PROTON-1189
> Project: Qpid Proton
>  Issue Type: Task
>Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
> Fix For: 0.13.0
>
>
> Remove the 'proton/contrib/proton-hawtdispatch' module
> As per discussion thread on the users list:
> http://mail-archives.apache.org/mod_mbox/qpid-users/201604.mbox/%3CCAFitrpSKn%2BsyQLh8aj62%3DEVyvANMw4g0nj_wh4%2BGtFAfJ_Z0-Q%40mail.gmail.com%3E



--
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-300) Deprecate the ContainerEntity and move its attributes to RouterEntity

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on DISPATCH-300:
-

GitHub user ganeshmurthy opened a pull request:

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

DISPATCH-300 - Deprecate the ContainerEntity and move its attributes …

…to RouterEntity. Introduced backward compatible test for deprecated 
attributes

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

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

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

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


commit 68e291b8cae13e30b70cb16dd9f18619ea06b5a7
Author: Ganesh Murthy 
Date:   2016-05-02T21:49:17Z

DISPATCH-300 - Deprecate the ContainerEntity and move its attributes to 
RouterEntity. Introduced backward compatible test for deprecated attributes




> Deprecate the ContainerEntity and move its attributes to RouterEntity
> -
>
> Key: DISPATCH-300
> URL: https://issues.apache.org/jira/browse/DISPATCH-300
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Container
>Affects Versions: 0.6
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>
> Move the attributes of ContainerEntity to RouterEntity thus deprecating 
> ContainerEntity so we will have reduced complexity. This change should be 
> backward compatible meaning configs currently using ContainerEntity must not 
> be affected by this change.



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

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

[jira] [Resolved] (PROTON-1188) remove the 'proton/contrib/proton-jms' module

[Robbie Gemmell (JIRA)]

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

Robbie Gemmell resolved PROTON-1188.

Resolution: Fixed

> remove the 'proton/contrib/proton-jms' module
> -
>
> Key: PROTON-1188
> URL: https://issues.apache.org/jira/browse/PROTON-1188
> Project: Qpid Proton
>  Issue Type: Task
>Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
> Fix For: 0.13.0
>
>
> Remove the 'proton/contrib/proton-jms' module
> As per discussion thread on the users list:
> http://mail-archives.apache.org/mod_mbox/qpid-users/201604.mbox/%3CCAFitrpTGGi8ttT1v3fcQ-JdYJof2L%2BNRg-oGs8UHzRK9CGAnQA%40mail.gmail.com%3E



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

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

[jira] [Commented] (PROTON-1188) remove the 'proton/contrib/proton-jms' module

[ASF subversion and git services (JIRA)]

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

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

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

PROTON-1188, PROTON-1189: remove stale contrib/proton-jms and 
contrib/proton-hawtdispatch modules


> remove the 'proton/contrib/proton-jms' module
> -
>
> Key: PROTON-1188
> URL: https://issues.apache.org/jira/browse/PROTON-1188
> Project: Qpid Proton
>  Issue Type: Task
>Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
> Fix For: 0.13.0
>
>
> Remove the 'proton/contrib/proton-jms' module
> As per discussion thread on the users list:
> http://mail-archives.apache.org/mod_mbox/qpid-users/201604.mbox/%3CCAFitrpTGGi8ttT1v3fcQ-JdYJof2L%2BNRg-oGs8UHzRK9CGAnQA%40mail.gmail.com%3E



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

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

[jira] [Resolved] (PROTON-1189) remove the 'proton/contrib/proton-hawtdispatch' module

[Robbie Gemmell (JIRA)]

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

Robbie Gemmell resolved PROTON-1189.

Resolution: Fixed

> remove the 'proton/contrib/proton-hawtdispatch' module
> --
>
> Key: PROTON-1189
> URL: https://issues.apache.org/jira/browse/PROTON-1189
> Project: Qpid Proton
>  Issue Type: Task
>Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
> Fix For: 0.13.0
>
>
> Remove the 'proton/contrib/proton-hawtdispatch' module
> As per discussion thread on the users list:
> http://mail-archives.apache.org/mod_mbox/qpid-users/201604.mbox/%3CCAFitrpSKn%2BsyQLh8aj62%3DEVyvANMw4g0nj_wh4%2BGtFAfJ_Z0-Q%40mail.gmail.com%3E



--
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-300 - Deprecate the Container...

[ganeshmurthy]

GitHub user ganeshmurthy opened a pull request:

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

DISPATCH-300 - Deprecate the ContainerEntity and move its attributes …

…to RouterEntity. Introduced backward compatible test for deprecated 
attributes

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

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

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

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


commit 68e291b8cae13e30b70cb16dd9f18619ea06b5a7
Author: Ganesh Murthy 
Date:   2016-05-02T21:49:17Z

DISPATCH-300 - Deprecate the ContainerEntity and move its attributes to 
RouterEntity. Introduced backward compatible test for deprecated attributes




---
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] (PROTON-1187) consistent options for endpoints

[ASF subversion and git services (JIRA)]

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

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

Commit 99a90561524fc0a3fe0c37833b7c3d97e4bc84d3 in qpid-proton's branch 
refs/heads/master from Clifford Jansen
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=99a9056 ]

PROTON-1187: session_options, connection.open() with connection_options


> consistent options for endpoints
> 
>
> Key: PROTON-1187
> URL: https://issues.apache.org/jira/browse/PROTON-1187
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: cpp-binding
>Affects Versions: 0.12.2
>Reporter: Cliff Jansen
>Assignee: Cliff Jansen
> Fix For: 0.13.0
>
>
> Make use of endpoint options consistent by adding session options.   Also 
> update connection.open to accept connection_options to configure inbound 
> connections.



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

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

[jira] [Created] (PROTON-1189) remove the 'proton/contrib/proton-hawtdispatch' module

[Robbie Gemmell (JIRA)]

Robbie Gemmell created PROTON-1189:
--

 Summary: remove the 'proton/contrib/proton-hawtdispatch' module
 Key: PROTON-1189
 URL: https://issues.apache.org/jira/browse/PROTON-1189
 Project: Qpid Proton
  Issue Type: Task
Reporter: Robbie Gemmell
Assignee: Robbie Gemmell
 Fix For: 0.13.0


Remove the 'proton/contrib/proton-hawtdispatch' module

As per discussion thread on the users list:
http://mail-archives.apache.org/mod_mbox/qpid-users/201604.mbox/%3CCAFitrpSKn%2BsyQLh8aj62%3DEVyvANMw4g0nj_wh4%2BGtFAfJ_Z0-Q%40mail.gmail.com%3E



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

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

[jira] [Created] (PROTON-1188) remove the 'proton/contrib/proton-jms' module

[Robbie Gemmell (JIRA)]

Robbie Gemmell created PROTON-1188:
--

 Summary: remove the 'proton/contrib/proton-jms' module
 Key: PROTON-1188
 URL: https://issues.apache.org/jira/browse/PROTON-1188
 Project: Qpid Proton
  Issue Type: Task
Reporter: Robbie Gemmell
Assignee: Robbie Gemmell
 Fix For: 0.13.0


Remove the 'proton/contrib/proton-jms' module

As per discussion thread on the users list:
http://mail-archives.apache.org/mod_mbox/qpid-users/201604.mbox/%3CCAFitrpTGGi8ttT1v3fcQ-JdYJof2L%2BNRg-oGs8UHzRK9CGAnQA%40mail.gmail.com%3E



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

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

[jira] [Created] (PROTON-1187) consistent options for endpoints

[Cliff Jansen (JIRA)]

Cliff Jansen created PROTON-1187:


 Summary: consistent options for endpoints
 Key: PROTON-1187
 URL: https://issues.apache.org/jira/browse/PROTON-1187
 Project: Qpid Proton
  Issue Type: Improvement
  Components: cpp-binding
Affects Versions: 0.12.2
Reporter: Cliff Jansen
Assignee: Cliff Jansen
 Fix For: 0.13.0


Make use of endpoint options consistent by adding session options.   Also 
update connection.open to accept connection_options to configure inbound 
connections.



--
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-7230) Broker terminates the connection to JMS Client

[Robbie Gemmell (JIRA)]

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

Robbie Gemmell resolved QPID-7230.
--
Resolution: Information Provided

As per comment at \[1\], resolving this JIRA at least for now, QPID-7241 can be 
used for further discussion as that seems to be the underlying issue.

\[1\] 
https://issues.apache.org/jira/browse/QPID-7230?focusedCommentId=15268963&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15268963

> Broker terminates the connection to JMS Client
> --
>
> Key: QPID-7230
> URL: https://issues.apache.org/jira/browse/QPID-7230
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker, Java Client
>Affects Versions: 0.32
> Environment: Fedora21 and C++ Broker installed by package manager
>Reporter: Ben
> Attachments: 200-a.log, 300-a.log, ben-trace.log
>
>
> Following scenario: 
> One Producer and one Consumer created by a Java JMS-Client. The Producer is 
> sending 200x15mb non persistent messages to a queue. This queue is located on 
> a local running c++ broker. After few messages my broker terminates the 
> connection with the following exception.
> javax.jms.JMSException: send not allowed after the sender is closed.
> The really astonishing is, that this behavior only occurs with non persistent 
> messages. If I change the delivery mode to persistent, my broker won't close 
> the connection.



--
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-7230) Broker terminates the connection to JMS Client

[Robbie Gemmell (JIRA)]

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

Robbie Gemmell commented on QPID-7230:
--

Ok so it seems like the underlying issue is throughput with large messages, as 
Gordon raised QPID-7241 for already, leading to the queue size being hit, with 
broker and client seeming to act approprialtey given that.

I'm going to close this JIRA out and suggest tracking further progress on 
QPID-7241, as this one has become a bit scattered and the only apparent issue 
looks to be what precisely what QPID-7241 covers. We can always reopen if 
needed.

> Broker terminates the connection to JMS Client
> --
>
> Key: QPID-7230
> URL: https://issues.apache.org/jira/browse/QPID-7230
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker, Java Client
>Affects Versions: 0.32
> Environment: Fedora21 and C++ Broker installed by package manager
>Reporter: Ben
> Attachments: 200-a.log, 300-a.log, ben-trace.log
>
>
> Following scenario: 
> One Producer and one Consumer created by a Java JMS-Client. The Producer is 
> sending 200x15mb non persistent messages to a queue. This queue is located on 
> a local running c++ broker. After few messages my broker terminates the 
> connection with the following exception.
> javax.jms.JMSException: send not allowed after the sender is closed.
> The really astonishing is, that this behavior only occurs with non persistent 
> messages. If I change the delivery mode to persistent, my broker won't close 
> the connection.



--
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-7211) [Java Broker, WMC] Do not transfer inherited context variables

[Lorenz Quack (JIRA)]

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

Lorenz Quack updated QPID-7211:
---
Attachment: 0001-QPID-7211-Java-Broker-Introduce-request-parameter-to.patch

> [Java Broker, WMC] Do not transfer inherited context variables
> --
>
> Key: QPID-7211
> URL: https://issues.apache.org/jira/browse/QPID-7211
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Lorenz Quack
> Fix For: qpid-java-6.0.3, qpid-java-6.1
>
> Attachments: 
> 0001-QPID-7211-Java-Broker-Introduce-request-parameter-to.patch, 
> 0004-QPID-7211-Java-Broker-Introduce-request-parameter-to.patch
>
>
> currently for all configured objects we transfer the complete inherited 
> context.
> We should only send the values that have been set on the object.
> Of course, there must remain a way to get the inherited context as well.
> For compatibility we transmit effective values but in the future (v7?) we 
> want to send actual 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] [Issue Comment Deleted] (QPID-7230) Broker terminates the connection to JMS Client

[Ben (JIRA)]

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

Ben updated QPID-7230:
--
Comment: was deleted

(was: Log4J Trace that shows the problem.)

> Broker terminates the connection to JMS Client
> --
>
> Key: QPID-7230
> URL: https://issues.apache.org/jira/browse/QPID-7230
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker, Java Client
>Affects Versions: 0.32
> Environment: Fedora21 and C++ Broker installed by package manager
>Reporter: Ben
> Attachments: 200-a.log, 300-a.log, ben-trace.log
>
>
> Following scenario: 
> One Producer and one Consumer created by a Java JMS-Client. The Producer is 
> sending 200x15mb non persistent messages to a queue. This queue is located on 
> a local running c++ broker. After few messages my broker terminates the 
> connection with the following exception.
> javax.jms.JMSException: send not allowed after the sender is closed.
> The really astonishing is, that this behavior only occurs with non persistent 
> messages. If I change the delivery mode to persistent, my broker won't close 
> the connection.



--
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-7230) Broker terminates the connection to JMS Client

[Ben (JIRA)]

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

Ben edited comment on QPID-7230 at 5/3/16 3:39 PM:
---

It seems the queue size is the problem. Already added the size of 1GB but this 
is not enough.
The broker is too slow to deliver all incoming messages fast enough before the 
queues size is reached. With a queue size of 10gb it is working. If I choose 
the delivery mode 2 to persist all messages, the broker is slowing down the 
producer to wait for the persist process and my queue will not reach it's 
maximum size.

I've attached my trace, so you can understand what's going on. 

For me it seems really odd that 15MB messages are so slow that the broker will 
reach the maximum size of 1GB in nearly 5 seconds.


was (Author: ben_):
It seems the queue size is the problem. Already added the size of 1GB but this 
is not enough.
The broker is too slow to deliver all incoming messages fast enough before the 
queues size is reached. With a queue size of 10gb it is working. If I choose 
the delivery mode 2 to persist all messages, the broker is slowing down the 
producer to wait for the persist process and my queue will not reach it's 
maximum size.

I've attached my trace, so you can understand what's going on. 

For me it seems really odd that 15MB messages are so slow. 

> Broker terminates the connection to JMS Client
> --
>
> Key: QPID-7230
> URL: https://issues.apache.org/jira/browse/QPID-7230
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker, Java Client
>Affects Versions: 0.32
> Environment: Fedora21 and C++ Broker installed by package manager
>Reporter: Ben
> Attachments: 200-a.log, 300-a.log, ben-trace.log
>
>
> Following scenario: 
> One Producer and one Consumer created by a Java JMS-Client. The Producer is 
> sending 200x15mb non persistent messages to a queue. This queue is located on 
> a local running c++ broker. After few messages my broker terminates the 
> connection with the following exception.
> javax.jms.JMSException: send not allowed after the sender is closed.
> The really astonishing is, that this behavior only occurs with non persistent 
> messages. If I change the delivery mode to persistent, my broker won't close 
> the connection.



--
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-7230) Broker terminates the connection to JMS Client

[Ben (JIRA)]

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

Ben updated QPID-7230:
--
Attachment: ben-trace.log

Log4J Trace that shows the problem.

> Broker terminates the connection to JMS Client
> --
>
> Key: QPID-7230
> URL: https://issues.apache.org/jira/browse/QPID-7230
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker, Java Client
>Affects Versions: 0.32
> Environment: Fedora21 and C++ Broker installed by package manager
>Reporter: Ben
> Attachments: 200-a.log, 300-a.log, ben-trace.log
>
>
> Following scenario: 
> One Producer and one Consumer created by a Java JMS-Client. The Producer is 
> sending 200x15mb non persistent messages to a queue. This queue is located on 
> a local running c++ broker. After few messages my broker terminates the 
> connection with the following exception.
> javax.jms.JMSException: send not allowed after the sender is closed.
> The really astonishing is, that this behavior only occurs with non persistent 
> messages. If I change the delivery mode to persistent, my broker won't close 
> the connection.



--
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-7230) Broker terminates the connection to JMS Client

[Ben (JIRA)]

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

Ben commented on QPID-7230:
---

It seems the queue size is the problem. Already added the size of 1GB but this 
is not enough.
The broker is too slow to deliver all incoming messages fast enough before the 
queues size is reached. With a queue size of 10gb it is working. If I choose 
the delivery mode 2 to persist all messages, the broker is slowing down the 
producer to wait for the persist process and my queue will not reach it's 
maximum size.

I've attached my trace, so you can understand what's going on. 

For me it seems really odd that 15MB messages are so slow. 

> Broker terminates the connection to JMS Client
> --
>
> Key: QPID-7230
> URL: https://issues.apache.org/jira/browse/QPID-7230
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker, Java Client
>Affects Versions: 0.32
> Environment: Fedora21 and C++ Broker installed by package manager
>Reporter: Ben
> Attachments: 200-a.log, 300-a.log
>
>
> Following scenario: 
> One Producer and one Consumer created by a Java JMS-Client. The Producer is 
> sending 200x15mb non persistent messages to a queue. This queue is located on 
> a local running c++ broker. After few messages my broker terminates the 
> connection with the following exception.
> javax.jms.JMSException: send not allowed after the sender is closed.
> The really astonishing is, that this behavior only occurs with non persistent 
> messages. If I change the delivery mode to persistent, my broker won't close 
> the connection.



--
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-7230) Broker terminates the connection to JMS Client

[Robbie Gemmell (JIRA)]

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

Robbie Gemmell commented on QPID-7230:
--

How to configure it depends on what logging framework youa re using. As the doc 
(http://qpid.apache.org/releases/qpid-jms-0.9.0/docs/index.html#logging) 
mentions, the client uses the SLF4J logging framework, with you then picking an 
actual logging implementation that suits your needs, e.g log4j, logback, jul, 
etc.

The examples (https://github.com/apache/qpid-jms/tree/master/qpid-jms-examples) 
use log4j, with the slf4j-log4j binding listed in the pom, and log4j itself 
then configured via log4j.properties on the classpath.

> Broker terminates the connection to JMS Client
> --
>
> Key: QPID-7230
> URL: https://issues.apache.org/jira/browse/QPID-7230
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker, Java Client
>Affects Versions: 0.32
> Environment: Fedora21 and C++ Broker installed by package manager
>Reporter: Ben
> Attachments: 200-a.log, 300-a.log
>
>
> Following scenario: 
> One Producer and one Consumer created by a Java JMS-Client. The Producer is 
> sending 200x15mb non persistent messages to a queue. This queue is located on 
> a local running c++ broker. After few messages my broker terminates the 
> connection with the following exception.
> javax.jms.JMSException: send not allowed after the sender is closed.
> The really astonishing is, that this behavior only occurs with non persistent 
> messages. If I change the delivery mode to persistent, my broker won't close 
> the connection.



--
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-304) Console PNG images not showing up in documentation

[ASF subversion and git services (JIRA)]

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

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

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

DISPATCH-304 - Fix the location to which the PNG images are copied


> Console PNG images not showing up in documentation
> --
>
> Key: DISPATCH-304
> URL: https://issues.apache.org/jira/browse/DISPATCH-304
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 0.6
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>
> If you go to 
> http://qpid.apache.org/releases/qpid-dispatch-master/book/console_operation.html#logging-in-to-a-router-network
>  you will see that the images to console_overview.png, console_topology.png 
> etc are missing.



--
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-304) Console PNG images not showing up in documentation

[Ganesh Murthy (JIRA)]

Ganesh Murthy created DISPATCH-304:
--

 Summary: Console PNG images not showing up in documentation
 Key: DISPATCH-304
 URL: https://issues.apache.org/jira/browse/DISPATCH-304
 Project: Qpid Dispatch
  Issue Type: Bug
Affects Versions: 0.6
Reporter: Ganesh Murthy
Assignee: Ganesh Murthy


If you go to 
http://qpid.apache.org/releases/qpid-dispatch-master/book/console_operation.html#logging-in-to-a-router-network
 you will see that the images to console_overview.png, console_topology.png etc 
are missing.



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

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

[jira] [Commented] (PROTON-1186) [C++ binding] Remove proton::url from core API

[ASF subversion and git services (JIRA)]

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

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

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

PROTON-1186: [C++ binding] Stop using proton::url in the core API
- Leave the proton::url class available as a user convenience
- Tidy up proton::url to be more value like.


> [C++ binding] Remove proton::url from core API
> --
>
> Key: PROTON-1186
> URL: https://issues.apache.org/jira/browse/PROTON-1186
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: cpp-binding
>Reporter: Andrew Stitcher
>Assignee: Andrew Stitcher
> Fix For: 0.13.0
>
>
> - Replace uses of proton::url in the core C++ API with plain std::string.
> - Keep proton::url in the user API as a convenience, but make it more value 
> like.



--
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-7230) Broker terminates the connection to JMS Client

[Ben (JIRA)]

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

Ben commented on QPID-7230:
---

mh the question is, how can I configure the 
org.apache.qpid.jms.provider.amqp.FRAMES Logger? It seems this file is placed 
inside the jms client library and I retrieve it via maven. Would it be enough 
to add this option in qpids log file?

> Broker terminates the connection to JMS Client
> --
>
> Key: QPID-7230
> URL: https://issues.apache.org/jira/browse/QPID-7230
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker, Java Client
>Affects Versions: 0.32
> Environment: Fedora21 and C++ Broker installed by package manager
>Reporter: Ben
> Attachments: 200-a.log, 300-a.log
>
>
> Following scenario: 
> One Producer and one Consumer created by a Java JMS-Client. The Producer is 
> sending 200x15mb non persistent messages to a queue. This queue is located on 
> a local running c++ broker. After few messages my broker terminates the 
> connection with the following exception.
> javax.jms.JMSException: send not allowed after the sender is closed.
> The really astonishing is, that this behavior only occurs with non persistent 
> messages. If I change the delivery mode to persistent, my broker won't close 
> the connection.



--
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-7230) Broker terminates the connection to JMS Client

[Ben (JIRA)]

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

Ben edited comment on QPID-7230 at 5/3/16 1:55 PM:
---

mh the question is, how can I configure the 
org.apache.qpid.jms.provider.amqp.FRAMES Logger? It seems this logging 
configuration file is placed inside the jms client library and I retrieve it 
via maven. Would it be enough to add this option in qpids log file?


was (Author: ben_):
mh the question is, how can I configure the 
org.apache.qpid.jms.provider.amqp.FRAMES Logger? It seems this file is placed 
inside the jms client library and I retrieve it via maven. Would it be enough 
to add this option in qpids log file?

> Broker terminates the connection to JMS Client
> --
>
> Key: QPID-7230
> URL: https://issues.apache.org/jira/browse/QPID-7230
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker, Java Client
>Affects Versions: 0.32
> Environment: Fedora21 and C++ Broker installed by package manager
>Reporter: Ben
> Attachments: 200-a.log, 300-a.log
>
>
> Following scenario: 
> One Producer and one Consumer created by a Java JMS-Client. The Producer is 
> sending 200x15mb non persistent messages to a queue. This queue is located on 
> a local running c++ broker. After few messages my broker terminates the 
> connection with the following exception.
> javax.jms.JMSException: send not allowed after the sender is closed.
> The really astonishing is, that this behavior only occurs with non persistent 
> messages. If I change the delivery mode to persistent, my broker won't close 
> the connection.



--
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-7207) Reorganize Qpid source for independent releases

[ASF subversion and git services (JIRA)]

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

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

Commit 1742115 from [~justi9] in branch 'qpid/trunk'
[ https://svn.apache.org/r1742115 ]

QPID-7207: Found another variant of this leak

> Reorganize Qpid source for independent releases
> ---
>
> Key: QPID-7207
> URL: https://issues.apache.org/jira/browse/QPID-7207
> Project: Qpid
>  Issue Type: Task
>Reporter: Justin Ross
>Assignee: Justin Ross
>
> An effort to achieve the source tree layout proposed here\[1\]. It allows the 
> Qpid project to produce independent releases of Qpid C++ and Python as well 
> as other modules that have heretofore been bundled into one large Qpid 
> release.  More detail in the proposal\[2\].
> \[1\] 
> https://cwiki.apache.org/confluence/display/qpid/Source+tree+layout+proposal
> \[2\] https://github.com/ssorj/qpid-svn-reorg



--
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] (QPID-7232) Sending too big message into paged queue blocks the broker from starting again

[Jakub Scholz (JIRA)]

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

Jakub Scholz closed QPID-7232.
--
Resolution: Duplicate

> Sending too big message into paged queue blocks the broker from starting again
> --
>
> Key: QPID-7232
> URL: https://issues.apache.org/jira/browse/QPID-7232
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker
>Affects Versions: qpid-cpp-0.34
>Reporter: Jakub Scholz
>
> When user attempts to send a message into paged queue which is bigger than 
> the page size, it receives an error message that the message is too big and 
> the message doesn't seem to be enqueued in the queue. So far is all ok. But 
> when you stop the broker and try to start it again, the broker fails to start 
> because it seems to have the too big message still in its queue.
> Steps to reproduce:
> 1. Start the broker (with linearstore)
> 2. Create durable paged queue with small page factor
> {code}qpid-config -a localhost:32770 add queue testQueue 
> --argument=qpid.paging=true --argument=qpid.page_factor=1 
> --argument=qpid.max_pages_loaded=1 --durable{code}
> 3. Send a message bigger than the page size into the queue
> {code}qpid-config -a localhost:32770 add queue testQueue 
> --argument=qpid.paging=true --argument=qpid.page_factor=1 
> --argument=qpid.max_pages_loaded=1 --durable{code}
> This fails as expected with following error:
> {code}2016-04-28 10:29:58 [Client] warning Exception received from broker: 
> precondition-failed: Message is larger than page size for queue testQueue 
> (/root/rpmbuild/BUILD/qpid-cpp-0.36/src/qpid/broker/PagedQueue.cpp:137) 
> [caused by 2 \x00:\x00]{code}
> 4. Stop the broker
> 5. Start the broker - it doesn't start with following error:
> {code}
> 2016-04-28 08:30:03 [Store] notice Linear Store: Store module initialized; 
> store-dir=/var/lib/qpidd/.qpidd
> 2016-04-28 08:30:03 [Broker] error Message is larger than page size for queue 
> testQueue
> 2016-04-28 08:30:03 [Broker] critical Broker (pid=41) start-up failed: 
> precondition-failed: Message is larger than page size for queue testQueue 
> (/root/rpmbuild/BUILD/qpid-cpp-0.36/src/qpid/broker/PagedQueue.cpp:137)
> 2016-04-28 08:30:03 [Broker] notice Broker (pid=41) shut-down
> 2016-04-28 08:30:03 [Broker] critical Unexpected error: precondition-failed: 
> Message is larger than page size for queue testQueue 
> (/root/rpmbuild/BUILD/qpid-cpp-0.36/src/qpid/broker/PagedQueue.cpp:137)
> {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] [Commented] (QPID-7232) Sending too big message into paged queue blocks the broker from starting again

[Jakub Scholz (JIRA)]

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

Jakub Scholz commented on QPID-7232:


This bug was fixed by QPID-7250 and should be closed.

> Sending too big message into paged queue blocks the broker from starting again
> --
>
> Key: QPID-7232
> URL: https://issues.apache.org/jira/browse/QPID-7232
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker
>Affects Versions: qpid-cpp-0.34
>Reporter: Jakub Scholz
>
> When user attempts to send a message into paged queue which is bigger than 
> the page size, it receives an error message that the message is too big and 
> the message doesn't seem to be enqueued in the queue. So far is all ok. But 
> when you stop the broker and try to start it again, the broker fails to start 
> because it seems to have the too big message still in its queue.
> Steps to reproduce:
> 1. Start the broker (with linearstore)
> 2. Create durable paged queue with small page factor
> {code}qpid-config -a localhost:32770 add queue testQueue 
> --argument=qpid.paging=true --argument=qpid.page_factor=1 
> --argument=qpid.max_pages_loaded=1 --durable{code}
> 3. Send a message bigger than the page size into the queue
> {code}qpid-config -a localhost:32770 add queue testQueue 
> --argument=qpid.paging=true --argument=qpid.page_factor=1 
> --argument=qpid.max_pages_loaded=1 --durable{code}
> This fails as expected with following error:
> {code}2016-04-28 10:29:58 [Client] warning Exception received from broker: 
> precondition-failed: Message is larger than page size for queue testQueue 
> (/root/rpmbuild/BUILD/qpid-cpp-0.36/src/qpid/broker/PagedQueue.cpp:137) 
> [caused by 2 \x00:\x00]{code}
> 4. Stop the broker
> 5. Start the broker - it doesn't start with following error:
> {code}
> 2016-04-28 08:30:03 [Store] notice Linear Store: Store module initialized; 
> store-dir=/var/lib/qpidd/.qpidd
> 2016-04-28 08:30:03 [Broker] error Message is larger than page size for queue 
> testQueue
> 2016-04-28 08:30:03 [Broker] critical Broker (pid=41) start-up failed: 
> precondition-failed: Message is larger than page size for queue testQueue 
> (/root/rpmbuild/BUILD/qpid-cpp-0.36/src/qpid/broker/PagedQueue.cpp:137)
> 2016-04-28 08:30:03 [Broker] notice Broker (pid=41) shut-down
> 2016-04-28 08:30:03 [Broker] critical Unexpected error: precondition-failed: 
> Message is larger than page size for queue testQueue 
> (/root/rpmbuild/BUILD/qpid-cpp-0.36/src/qpid/broker/PagedQueue.cpp:137)
> {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] [Reopened] (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 reopened QPID-7165:
--

There is a defect in the order-by (and select) parsing when the input is in the 
form {{a + b}}.  It seems the parser fails, but the exception is not reported.

> 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
>
> Attachments: 
> 0001-QPID-7165-Java-Broker-Allow-query-results-to-be-sort.patch, 
> 0001-QPID-7165-Java-Broker-Allow-query-results-to-be-sort.patch, 
> 0002-QPID-7165-Java-Broker-Allow-query-results-to-be-sort.patch, 
> 0002-QPID-7165-Java-Broker-Allow-query-results-to-be-sort.patch, 
> 0004-WIP.patch
>
>
> 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-7238) [Java Broker, WMC] Share data from structure service amongst UI elements

[Keith Wall (JIRA)]

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

Keith Wall commented on QPID-7238:
--

We said we desire to put a façade over the structure service, and stop the 
remainder of the code implementing a structure service call in their own right.

> [Java Broker, WMC] Share data from structure service amongst UI elements
> 
>
> Key: QPID-7238
> URL: https://issues.apache.org/jira/browse/QPID-7238
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Lorenz Quack
> Fix For: qpid-java-6.1
>
>
> Currently the TreeView in the WMC polls the structure service every 5 
> seconds. Other UI components (e.g. QueryBuilder) also occasionally need this 
> information.
> We should share the information instead of making multiple requests.
> One possible way is to store this information in management.



--
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-7238) [Java Broker, WMC] Share data from structure service amongst UI elements

[Keith Wall (JIRA)]

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

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

> [Java Broker, WMC] Share data from structure service amongst UI elements
> 
>
> Key: QPID-7238
> URL: https://issues.apache.org/jira/browse/QPID-7238
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Lorenz Quack
> Fix For: qpid-java-6.1
>
>
> Currently the TreeView in the WMC polls the structure service every 5 
> seconds. Other UI components (e.g. QueryBuilder) also occasionally need this 
> information.
> We should share the information instead of making multiple requests.
> One possible way is to store this information in management.



--
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-300) Deprecate the ContainerEntity and move its attributes to RouterEntity

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on DISPATCH-300:
-

GitHub user ganeshmurthy opened a pull request:

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

DISPATCH-300 - Deprecate the ContainerEntity and move its attributes …

…to RouterEntity. Introduced backward compatible test for deprecated 
attributes

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

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

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

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


commit 03e469cfcfe56c278aa30e0cff7bd0725fa8e737
Author: Ganesh Murthy 
Date:   2016-05-02T21:49:17Z

DISPATCH-300 - Deprecate the ContainerEntity and move its attributes to 
RouterEntity. Introduced backward compatible test for deprecated attributes




> Deprecate the ContainerEntity and move its attributes to RouterEntity
> -
>
> Key: DISPATCH-300
> URL: https://issues.apache.org/jira/browse/DISPATCH-300
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Container
>Affects Versions: 0.6
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>
> Move the attributes of ContainerEntity to RouterEntity thus deprecating 
> ContainerEntity so we will have reduced complexity. This change should be 
> backward compatible meaning configs currently using ContainerEntity must not 
> be affected by this change.



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

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

[GitHub] qpid-dispatch pull request: DISPATCH-300 - Deprecate the Container...

[ganeshmurthy]

GitHub user ganeshmurthy opened a pull request:

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

DISPATCH-300 - Deprecate the ContainerEntity and move its attributes …

…to RouterEntity. Introduced backward compatible test for deprecated 
attributes

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

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

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

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


commit 03e469cfcfe56c278aa30e0cff7bd0725fa8e737
Author: Ganesh Murthy 
Date:   2016-05-02T21:49:17Z

DISPATCH-300 - Deprecate the ContainerEntity and move its attributes to 
RouterEntity. Introduced backward compatible test for deprecated attributes




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

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

[jira] [Commented] (QPID-7230) Broker terminates the connection to JMS Client

[Robbie Gemmell (JIRA)]

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

Robbie Gemmell commented on QPID-7230:
--

I realise your C++ broker is normally a daemon service. Gordon advised for you 
to stop the daemon C++ broker, and instead start the C++ broker on the command 
line with the logging options. That failed because something is already 
listening on 5672, with the netstat output seeming to confirm that, albeit it 
isn't saying precisely which process it is (likely because of user privilage 
restrictions). Just using the client logging seems easier at this point.

> Broker terminates the connection to JMS Client
> --
>
> Key: QPID-7230
> URL: https://issues.apache.org/jira/browse/QPID-7230
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker, Java Client
>Affects Versions: 0.32
> Environment: Fedora21 and C++ Broker installed by package manager
>Reporter: Ben
> Attachments: 200-a.log, 300-a.log
>
>
> Following scenario: 
> One Producer and one Consumer created by a Java JMS-Client. The Producer is 
> sending 200x15mb non persistent messages to a queue. This queue is located on 
> a local running c++ broker. After few messages my broker terminates the 
> connection with the following exception.
> javax.jms.JMSException: send not allowed after the sender is closed.
> The really astonishing is, that this behavior only occurs with non persistent 
> messages. If I change the delivery mode to persistent, my broker won't close 
> the connection.



--
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-7230) Broker terminates the connection to JMS Client

[Ben (JIRA)]

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

Ben edited comment on QPID-7230 at 5/3/16 12:53 PM:


I already said several times that there is no other broker running on that 
port. Netstat showed that there is no pid listening on that port. I also 
mentioned that the c++ broker works. I can send millions of small messages 
without any problem. Just sending big messages will cause the described 
problem. So I don't know why this error occurs in log because the server is 
running and does not terminate. 

by the way, my c++ broker is not command line, it is running as a linux daemon. 
I said that I have to start all other brokers via command line. But as gordon 
recommended, I will activate the protocol trace on the client side and repeat 
my test with the daemon.

My queue is not durable and before adding the queue with configured size, I 
restart the broker daemon. That also means the queue is empty when I start a 
test.


was (Author: ben_):
I already said several times that there is no other broker running on that 
port. Netstat showed that there is nor pid listening on that port. I also 
mentioned that the c++ broker works. I can send millions of small messages 
without any problem. Just sending big messages will cause the described 
problem. So I don't know why this error occurs in log because the server is 
running and does not terminate. 

by the way, my c++ broker is not command line, it is running as a linux daemon. 
I said that I have to start all other brokers via command line. But as gordon 
recommended, I will activate the protocol trace on the client side and repeat 
my test with the daemon.

My queue is not durable and before adding the queue with configured size, I 
restart the broker daemon. That also means the queue is empty when I start a 
test.

> Broker terminates the connection to JMS Client
> --
>
> Key: QPID-7230
> URL: https://issues.apache.org/jira/browse/QPID-7230
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker, Java Client
>Affects Versions: 0.32
> Environment: Fedora21 and C++ Broker installed by package manager
>Reporter: Ben
> Attachments: 200-a.log, 300-a.log
>
>
> Following scenario: 
> One Producer and one Consumer created by a Java JMS-Client. The Producer is 
> sending 200x15mb non persistent messages to a queue. This queue is located on 
> a local running c++ broker. After few messages my broker terminates the 
> connection with the following exception.
> javax.jms.JMSException: send not allowed after the sender is closed.
> The really astonishing is, that this behavior only occurs with non persistent 
> messages. If I change the delivery mode to persistent, my broker won't close 
> the connection.



--
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-300) Deprecate the ContainerEntity and move its attributes to RouterEntity

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on DISPATCH-300:
-

Github user ganeshmurthy closed the pull request at:

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


> Deprecate the ContainerEntity and move its attributes to RouterEntity
> -
>
> Key: DISPATCH-300
> URL: https://issues.apache.org/jira/browse/DISPATCH-300
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Container
>Affects Versions: 0.6
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>
> Move the attributes of ContainerEntity to RouterEntity thus deprecating 
> ContainerEntity so we will have reduced complexity. This change should be 
> backward compatible meaning configs currently using ContainerEntity must not 
> be affected by this change.



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

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

[jira] [Comment Edited] (QPID-7230) Broker terminates the connection to JMS Client

[Ben (JIRA)]

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

Ben edited comment on QPID-7230 at 5/3/16 12:39 PM:


I already said several times that there is no other broker running on that 
port. Netstat showed that there is nor pid listening on that port. I also 
mentioned that the c++ broker works. I can send millions of small messages 
without any problem. Just sending big messages will cause the described 
problem. So I don't know why this error occurs in log because the server is 
running and does not terminate. 

by the way, my c++ broker is not command line, it is running as a linux daemon. 
I said that I have to start all other brokers via command line. But as gordon 
recommended, I will activate the protocol trace on the client side and repeat 
my test with the daemon.

My queue is not durable and before adding the queue with configured size, I 
restart the broker daemon. That also means the queue is empty when I start a 
test.


was (Author: ben_):
I already said several times that there is no other broker running on that 
port. Netstat showed that there is nor pid listening on that port. I also 
mentioned that the c++ broker WORKS. I can send millions of small messages 
without any problem. Just sending big messages will cause the described 
problem. So I don't know why this error occurs in log because the server is 
running and does not terminate. 

by the way, my c++ broker is not command line, it is running as a linux daemon. 
I said that I have to start all other brokers via command line. But as gordon 
recommended, I will activate the protocol trace on the client side and repeat 
my test with the daemon.

My queue is not durable and before adding the queue with configured size, I 
restart the broker daemon. That also means the queue is empty when I start a 
test.

> Broker terminates the connection to JMS Client
> --
>
> Key: QPID-7230
> URL: https://issues.apache.org/jira/browse/QPID-7230
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker, Java Client
>Affects Versions: 0.32
> Environment: Fedora21 and C++ Broker installed by package manager
>Reporter: Ben
> Attachments: 200-a.log, 300-a.log
>
>
> Following scenario: 
> One Producer and one Consumer created by a Java JMS-Client. The Producer is 
> sending 200x15mb non persistent messages to a queue. This queue is located on 
> a local running c++ broker. After few messages my broker terminates the 
> connection with the following exception.
> javax.jms.JMSException: send not allowed after the sender is closed.
> The really astonishing is, that this behavior only occurs with non persistent 
> messages. If I change the delivery mode to persistent, my broker won't close 
> the connection.



--
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-300 - Deprecate the Container...

[ganeshmurthy]

Github user ganeshmurthy closed the pull request at:

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


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

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

[jira] [Comment Edited] (QPID-7230) Broker terminates the connection to JMS Client

[Ben (JIRA)]

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

Ben edited comment on QPID-7230 at 5/3/16 12:38 PM:


I already said several times that there is no other broker running on that 
port. Netstat showed that there is nor pid listening on that port. I also 
mentioned that the c++ broker WORKS. I can send millions of small messages 
without any problem. Just sending big messages will cause the described 
problem. So I don't know why this error occurs in log because the server is 
running and does not terminate. 

by the way, my c++ broker is not command line, it is running as a linux daemon. 
I said that I have to start all other brokers via command line. But as gordon 
recommended, I will activate the protocol trace on the client side and repeat 
my test with the daemon.

My queue is not durable and before adding the queue with configured size, I 
restart the broker daemon. That also means the queue is empty when I start a 
test.


was (Author: ben_):
I already said several times that there is no other broker running on that 
port. Netstat showed that there is nor pid listening on that port. I also 
mentioned that the c++ broker WORKS. I can send millions of small messages 
without any problem. Just sending big messages will cause the described 
problem. So I don't know why this error occurs in log because the server is 
running and does not terminate. 

by the way, my c++ broker is not command line, it is running as a linux daemon. 
I said that I have to start all other brokers via command line. But as gordon 
recommended, I will activate the protocol trace on the client side and repeat 
my test.

My queue is not durable and before adding the queue with configured size, I 
restart the broker daemon. That also means the queue is empty when I start a 
test.

> Broker terminates the connection to JMS Client
> --
>
> Key: QPID-7230
> URL: https://issues.apache.org/jira/browse/QPID-7230
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker, Java Client
>Affects Versions: 0.32
> Environment: Fedora21 and C++ Broker installed by package manager
>Reporter: Ben
> Attachments: 200-a.log, 300-a.log
>
>
> Following scenario: 
> One Producer and one Consumer created by a Java JMS-Client. The Producer is 
> sending 200x15mb non persistent messages to a queue. This queue is located on 
> a local running c++ broker. After few messages my broker terminates the 
> connection with the following exception.
> javax.jms.JMSException: send not allowed after the sender is closed.
> The really astonishing is, that this behavior only occurs with non persistent 
> messages. If I change the delivery mode to persistent, my broker won't close 
> the connection.



--
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-7230) Broker terminates the connection to JMS Client

[Ben (JIRA)]

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

Ben edited comment on QPID-7230 at 5/3/16 12:38 PM:


I already said several times that there is no other broker running on that 
port. Netstat showed that there is nor pid listening on that port. I also 
mentioned that the c++ broker WORKS. I can send millions of small messages 
without any problem. Just sending big messages will cause the described 
problem. So I don't know why this error occurs in log because the server is 
running and does not terminate. 

by the way, my c++ broker is not command line, it is running as a linux daemon. 
I said that I have to start all other brokers via command line. But as gordon 
recommended, I will activate the protocol trace on the client side and repeat 
my test.

My queue is not durable and before adding the queue with configured size, I 
restart the broker daemon. That also means the queue is empty when I start a 
test.


was (Author: ben_):
I already said several times that there is no other broker running on that 
port. Netstat showed that there is nor pid listening on that port. And also 
mentioned that the c++ broker WORKS. I can send millions of small messages 
without any problem. Just sending bis messages will cause the described 
problem. So I don't know why this error occurs in log because the server is 
running and does not terminate. 

by the way, my c++ broker is not command line, it is running as a linux daemon. 
I said that I have to start all other brokers via command line. But as gordon 
recommended, I will activate the protocol trace on the client side and repeat 
my test.

My queue is not durable and before adding the queue with configured size, I 
restart the broker daemon. That also means the queue is empty when I start a 
test.

> Broker terminates the connection to JMS Client
> --
>
> Key: QPID-7230
> URL: https://issues.apache.org/jira/browse/QPID-7230
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker, Java Client
>Affects Versions: 0.32
> Environment: Fedora21 and C++ Broker installed by package manager
>Reporter: Ben
> Attachments: 200-a.log, 300-a.log
>
>
> Following scenario: 
> One Producer and one Consumer created by a Java JMS-Client. The Producer is 
> sending 200x15mb non persistent messages to a queue. This queue is located on 
> a local running c++ broker. After few messages my broker terminates the 
> connection with the following exception.
> javax.jms.JMSException: send not allowed after the sender is closed.
> The really astonishing is, that this behavior only occurs with non persistent 
> messages. If I change the delivery mode to persistent, my broker won't close 
> the connection.



--
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-7230) Broker terminates the connection to JMS Client

[Ben (JIRA)]

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

Ben commented on QPID-7230:
---

I already said several times that there is no other broker running on that 
port. Netstat showed that there is nor pid listening on that port. And also 
mentioned that the c++ broker WORKS. I can send millions of small messages 
without any problem. Just sending bis messages will cause the described 
problem. So I don't know why this error occurs in log because the server is 
running and does not terminate. 

by the way, my c++ broker is not command line, it is running as a linux daemon. 
I said that I have to start all other brokers via command line. But as gordon 
recommended, I will activate the protocol trace on the client side and repeat 
my test.

My queue is not durable and before adding the queue with configured size, I 
restart the broker daemon. That also means the queue is empty when I start a 
test.

> Broker terminates the connection to JMS Client
> --
>
> Key: QPID-7230
> URL: https://issues.apache.org/jira/browse/QPID-7230
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker, Java Client
>Affects Versions: 0.32
> Environment: Fedora21 and C++ Broker installed by package manager
>Reporter: Ben
> Attachments: 200-a.log, 300-a.log
>
>
> Following scenario: 
> One Producer and one Consumer created by a Java JMS-Client. The Producer is 
> sending 200x15mb non persistent messages to a queue. This queue is located on 
> a local running c++ broker. After few messages my broker terminates the 
> connection with the following exception.
> javax.jms.JMSException: send not allowed after the sender is closed.
> The really astonishing is, that this behavior only occurs with non persistent 
> messages. If I change the delivery mode to persistent, my broker won't close 
> the connection.



--
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-7230) Broker terminates the connection to JMS Client

[Robbie Gemmell (JIRA)]

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

Robbie Gemmell commented on QPID-7230:
--

As Gordon has mentioned a couple times, the fact the logging indicates the port 
(5672) is in use when you try to start the C++ broker on the command line, 
means you have something else running on port 5672, and so the command line 
initiated C++ broker does not start up. It would seem your other broker tests 
should have the same issue if started at similar point, though not all brokers 
necessarily shut down in error when their port is already in use at startup, so 
you need to be careful that you are actually connecting to what you think you 
are (a useful check: connection attempts should fail immediately before you 
start the intended broker).

If you are connecting to port 5672 during your testing (if not, please say 
so..) and that testing is working at all immediately following the 'in-use' 
error, then the something on 5672 is obviously speaking AMQP 1.0. You'd need to 
stop the thing on port 5672 (which could well be one of the other brokers you 
mention testing..) before starting the C++ broker on the command line with the 
trace logging options Gordon suggested. Alternatively, go for his subsequent 
suggestion of enabling the protocol trace on the client side, and repeating 
your test to get the protocol trace logging.

I can't say I have tried setting/adjusting the 'queue size' on the C++ broker, 
but can I enquire if you had deleted the queue before adding it again with the 
new config? If not, that seems worth a try (I'm not sure if that config affects 
existing queues, or even whether you can issue the 'add' without error in such 
cases when the queue already exists). Also, are you clearing the queue out 
between runs? Adjusting the config may not help [enough] if the queue is still 
largely full of stuff from prior runs.

> Broker terminates the connection to JMS Client
> --
>
> Key: QPID-7230
> URL: https://issues.apache.org/jira/browse/QPID-7230
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker, Java Client
>Affects Versions: 0.32
> Environment: Fedora21 and C++ Broker installed by package manager
>Reporter: Ben
> Attachments: 200-a.log, 300-a.log
>
>
> Following scenario: 
> One Producer and one Consumer created by a Java JMS-Client. The Producer is 
> sending 200x15mb non persistent messages to a queue. This queue is located on 
> a local running c++ broker. After few messages my broker terminates the 
> connection with the following exception.
> javax.jms.JMSException: send not allowed after the sender is closed.
> The really astonishing is, that this behavior only occurs with non persistent 
> messages. If I change the delivery mode to persistent, my broker won't close 
> the connection.



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

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

[jira] [Commented] (PROTON-1181) [reactor] Use the host passed to pn_reactor_connection_to_host as default hostname for open frame

[Ken Giusti (JIRA)]

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

Ken Giusti commented on PROTON-1181:


Link to reviewboard:

https://reviews.apache.org/r/46879/

> [reactor] Use the host passed to pn_reactor_connection_to_host as default 
> hostname for open frame
> -
>
> Key: PROTON-1181
> URL: https://issues.apache.org/jira/browse/PROTON-1181
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c, proton-j, python-binding
>Affects Versions: 0.13.0
>Reporter: Ken Giusti
>Assignee: Ken Giusti
> Fix For: 0.13.0
>
>
> Modify the 'connection_to_host' reactor interface to use the passed host 
> parameter as the default for the connection's hostname sent in the open frame.
> This should only be done if the host parameter is NOT a numerical IP address 
> (do it for DNS-like names).
> Modify the pn_connection_set_hostname() to take a NULL argument so the 
> default can be reset (e.g. no hostname in open frame).  
> The default can be overridden by setting the desired hostname via the 
> connection's set_hostname method.



--
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-7198) LDAP and OAUTH2 Authentication Providers should cache authentication results for a short period

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7198:
-
Description: 
The OAUTH2 and LDAP authentication providers should be changed to cache 
authentication results for a short (configurable) period.  If the same 
authentication provider receives the same credentials again (i.e. matching 
username and password in the case of LDAP), it should reuse the cached 
authentication result.   The cached authentication result should expire 
automatically.  Negative authentication results should be cached too.

This will serve to reduce load on authentication backends (such as 
Directories).  It will be especially useful when the REST API to used for 
programmatically monitoring the Broker which otherwise may create an excessive 
load on the backend.

The authentication provider must not retain the user passwords in clear.  The 
size of the cache should be constrained.



  was:
The OAUTTH2 and LDAP authentication providers should be changed to cache 
authentication results for a short (configurable period).  If the same 
authentication provider receives the same credentials again (i.e. matching 
username and password), it should reuse the cached authentication result.   The 
cached authentication result should expire automatically.

This would serve to reduce load on authentication backends (such as 
Directories).  It will be especially useful when the REST API to used for 
programmatically monitoring the Broker which otherwise may create an excessive 
load on the backend.

The authentication provider must not retain the user passwords in clear.


> LDAP and OAUTH2 Authentication Providers should cache authentication results 
> for a short period
> ---
>
> Key: QPID-7198
> URL: https://issues.apache.org/jira/browse/QPID-7198
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
>
> The OAUTH2 and LDAP authentication providers should be changed to cache 
> authentication results for a short (configurable) period.  If the same 
> authentication provider receives the same credentials again (i.e. matching 
> username and password in the case of LDAP), it should reuse the cached 
> authentication result.   The cached authentication result should expire 
> automatically.  Negative authentication results should be cached too.
> This will serve to reduce load on authentication backends (such as 
> Directories).  It will be especially useful when the REST API to used for 
> programmatically monitoring the Broker which otherwise may create an 
> excessive load on the backend.
> The authentication provider must not retain the user passwords in clear.  The 
> size of the cache should be constrained.



--
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 46879: Use host passed to Reactor's connection_to_host call as the default hostname sent in the open frame

[Robbie Gemmell]

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




proton-j/src/main/java/org/apache/qpid/proton/reactor/impl/ReactorImpl.java 
(line 468)


There should be a null check on the hostname before the test of whether it 
isEmpty().

If this isn't throwing a NullPointerException then that suggests it is the 
actually empty string, which I'd say this change needs to address in order to 
be complete.

An equivalent of the new tests that are being added for the C reactor would 
highlight if thats the case.


- Robbie Gemmell


On May 1, 2016, 11:54 p.m., Kenneth Giusti wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46879/
> ---
> 
> (Updated May 1, 2016, 11:54 p.m.)
> 
> 
> Review request for qpid, Chug Rolke, Justin Ross, and Robbie Gemmell.
> 
> 
> Bugs: PROTON-1181
> https://issues.apache.org/jira/browse/PROTON-1181
> 
> 
> Repository: qpid-proton-git
> 
> 
> Description
> ---
> 
> See linked JIRA
> 
> 
> Diffs
> -
> 
>   proton-c/src/engine/engine.c c620101 
>   proton-c/src/reactor/connection.c 336d1f1 
>   proton-c/src/tests/reactor.c 9564569 
>   proton-j/src/main/java/org/apache/qpid/proton/reactor/impl/ReactorImpl.java 
> d13cfbe 
>   tests/python/proton_tests/reactor.py 6ee107d 
> 
> Diff: https://reviews.apache.org/r/46879/diff/
> 
> 
> Testing
> ---
> 
> New unit tests added.
> 
> 
> Thanks,
> 
> Kenneth Giusti
> 
>