date:20190917



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

Ganesh Murthy resolved DISPATCH-1355.
-
Resolution: Duplicate

> Add ability to hide/show connection direction arrows on console's topology 
> page
> ---
>
> Key: DISPATCH-1355
> URL: https://issues.apache.org/jira/browse/DISPATCH-1355
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Console
>Affects Versions: 1.7.0
>Reporter: Ernest Allen
>Priority: Major
>
> Connection arrows for inter-router connections indicate which router is the 
> connector and which is the listener.
> Connection arrows for endpoint connections indicate link direction(s)
> The connection arrows can be misinterpreted as indicating which direction 
> message traffic is allowed to flow.
> Add a control to hide/show connection arrows. Default the state to hide.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

[jira] [Closed] (DISPATCH-1355) Add ability to hide/show connection direction arrows on console's topology page



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

Ganesh Murthy closed DISPATCH-1355.
---
Resolution: Duplicate

> Add ability to hide/show connection direction arrows on console's topology 
> page
> ---
>
> Key: DISPATCH-1355
> URL: https://issues.apache.org/jira/browse/DISPATCH-1355
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Console
>Affects Versions: 1.7.0
>Reporter: Ernest Allen
>Priority: Major
>
> Connection arrows for inter-router connections indicate which router is the 
> connector and which is the listener.
> Connection arrows for endpoint connections indicate link direction(s)
> The connection arrows can be misinterpreted as indicating which direction 
> message traffic is allowed to flow.
> Add a control to hide/show connection arrows. Default the state to hide.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

[jira] [Reopened] (DISPATCH-1355) Add ability to hide/show connection direction arrows on console's topology page



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

Ganesh Murthy reopened DISPATCH-1355:
-

> Add ability to hide/show connection direction arrows on console's topology 
> page
> ---
>
> Key: DISPATCH-1355
> URL: https://issues.apache.org/jira/browse/DISPATCH-1355
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Console
>Affects Versions: 1.7.0
>Reporter: Ernest Allen
>Priority: Major
>
> Connection arrows for inter-router connections indicate which router is the 
> connector and which is the listener.
> Connection arrows for endpoint connections indicate link direction(s)
> The connection arrows can be misinterpreted as indicating which direction 
> message traffic is allowed to flow.
> Add a control to hide/show connection arrows. Default the state to hide.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

[jira] [Updated] (DISPATCH-1393) Router link logging on interQDR connection is skipped on connecting router



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

Ganesh Murthy updated DISPATCH-1393:

Labels: troubleshooting  (was: )

> Router link logging on interQDR connection is skipped on connecting router
> --
>
> Key: DISPATCH-1393
> URL: https://issues.apache.org/jira/browse/DISPATCH-1393
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 1.8.0
> Environment: In test directory 
> build/tests/system_test.dir/system_tests_edge_router/EdgeRouterTest/setUpClass
>  
> grep "Link attached" INT*.log
>  
> and see that the log lines are only in INT.A.log
>Reporter: Chuck Rolke
>Priority: Major
>  Labels: troubleshooting
>
> A useful ROUTER info log message describing interrouter links is emitted at 
> the end of function qdr_link_inbound_first_attach_CT. Thus the link messages 
> are logged only on the router that is listening.
> The connecting router should log the same link details so that connection and 
> link pairs are more easily correlated.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

[jira] [Updated] (DISPATCH-1375) qdr_general_work_t could be shrinked to increase cache localty



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

Ganesh Murthy updated DISPATCH-1375:

Labels: performance  (was: )

> qdr_general_work_t could be shrinked to increase cache localty
> --
>
> Key: DISPATCH-1375
> URL: https://issues.apache.org/jira/browse/DISPATCH-1375
> Project: Qpid Dispatch
>  Issue Type: Improvement
>Affects Versions: 1.8.0
>Reporter: Francesco Nigro
>Priority: Minor
>  Labels: performance
>
> qdr_general_work_t fields are not used altogether and could be packed into 
> different groups to reduce size: on an 64 bit machine I'm getting 112 -> 80 
> bytes size



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

[jira] [Updated] (DISPATCH-1405) Display local ip addresses at startup



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

Ganesh Murthy updated DISPATCH-1405:

Summary: Display local ip addresses at startup  (was: Display local 
addresses at startup)

> Display local ip addresses at startup
> -
>
> Key: DISPATCH-1405
> URL: https://issues.apache.org/jira/browse/DISPATCH-1405
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Management Agent
>Affects Versions: 1.8.0
>Reporter: Chuck Rolke
>Priority: Minor
>  Labels: usability
>
> At boot time the router could display its local addresses. This would help 
> debugging certain issues.
> An example of the information is from hawtio:
> ```
> [io.hawt.system.ProxyWhitelist] Probing local addresses ...
> [io.hawt.system.ProxyWhitelist] Initial proxy whitelist: [localhost, 
> 127.0.0.1, 
>  10.10.111.222, ovpn-111-222.gw.example.com, 192.168.100.100, unused]
> ```



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

[jira] [Updated] (DISPATCH-1403) Consolidate chained qd_buffer_t field handling code



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

Ganesh Murthy updated DISPATCH-1403:

Labels: refactor  (was: )

> Consolidate chained qd_buffer_t field handling code
> ---
>
> Key: DISPATCH-1403
> URL: https://issues.apache.org/jira/browse/DISPATCH-1403
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Router Node
>Affects Versions: 1.8.0, 1.9.0
>Reporter: Ken Giusti
>Assignee: Ken Giusti
>Priority: Minor
>  Labels: refactor
> Fix For: Backlog
>
>
> There are many places in the router's C codebase where we need to work with 
> data spanning a chained qd_buffer_t list.   In particular the low level 
> operations such as:
> * advance N bytes
> * compare N bytes
> * copy N bytes
> are common throughout the code.
> Here are examples from the iterator.c library:
> [copy 
> bytes|https://github.com/apache/qpid-dispatch/blob/master/src/iterator.c#L378]
> [advance 
> cursor|https://github.com/apache/qpid-dispatch/blob/master/src/iterator.c#L424]
> [compare|https://github.com/apache/qpid-dispatch/blob/master/src/iterator.c#L467]
> Similar logic is implemented in message.c and parse.c.
> We should de-duplicate this code by providing a common implementation as part 
> of the buffer handling code.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

[jira] [Updated] (DISPATCH-1409) Update qdstat -l output to include the current credit



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

Ganesh Murthy updated DISPATCH-1409:

Labels: troubleshooting  (was: )

> Update qdstat -l output to include the current credit
> -
>
> Key: DISPATCH-1409
> URL: https://issues.apache.org/jira/browse/DISPATCH-1409
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Router Node, Tools
>Affects Versions: 1.8.0
>Reporter: Ken Giusti
>Priority: Major
>  Labels: troubleshooting
>
> The (cap) field in the output of qdstat -l shows the configured capacity for 
> the link, not the current credit available/outstanding.
> In order to easily detect credit stalls it would be useful to provide the 
> current credit for the link.  



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

[jira] [Updated] (DISPATCH-1405) Display local addresses at startup



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

Ganesh Murthy updated DISPATCH-1405:

Labels: usability  (was: )

> Display local addresses at startup
> --
>
> Key: DISPATCH-1405
> URL: https://issues.apache.org/jira/browse/DISPATCH-1405
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Management Agent
>Affects Versions: 1.8.0
>Reporter: Chuck Rolke
>Priority: Minor
>  Labels: usability
>
> At boot time the router could display its local addresses. This would help 
> debugging certain issues.
> An example of the information is from hawtio:
> ```
> [io.hawt.system.ProxyWhitelist] Probing local addresses ...
> [io.hawt.system.ProxyWhitelist] Initial proxy whitelist: [localhost, 
> 127.0.0.1, 
>  10.10.111.222, ovpn-111-222.gw.example.com, 192.168.100.100, unused]
> ```



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

[jira] [Updated] (DISPATCH-1411) Add timestamp and router name to header of qdstat output



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

Ganesh Murthy updated DISPATCH-1411:

Labels: troubleshooting  (was: )

> Add timestamp and router name to header of qdstat output
> 
>
> Key: DISPATCH-1411
> URL: https://issues.apache.org/jira/browse/DISPATCH-1411
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Tools
>Affects Versions: 1.8.0
>Reporter: Ken Giusti
>Priority: Major
>  Labels: troubleshooting
>
> Add a timestamp and the router's id to the header of the output of qdstat.
> This will allow us to correlate qdstat output with router log files.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

[jira] [Updated] (DISPATCH-1412) Policy C code performance issue: reload python module for each call



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

Ganesh Murthy updated DISPATCH-1412:

Labels: performance  (was: )

> Policy C code performance issue:  reload python module for each call
> 
>
> Key: DISPATCH-1412
> URL: https://issues.apache.org/jira/browse/DISPATCH-1412
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Policy Engine
>Affects Versions: 1.8.0
>Reporter: Chuck Rolke
>Assignee: Chuck Rolke
>Priority: Major
>  Labels: performance
>
> The module could be loaded once for the lifetime of the router instance.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

[jira] [Updated] (DISPATCH-1415) qdstat does not show process memory usage



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

Ganesh Murthy updated DISPATCH-1415:

Labels: troubleshooting  (was: )

> qdstat does not show process memory usage
> -
>
> Key: DISPATCH-1415
> URL: https://issues.apache.org/jira/browse/DISPATCH-1415
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Management Agent
>Affects Versions: 1.8.0
>Reporter: Chuck Rolke
>Priority: Major
>  Labels: troubleshooting
>
> *qdstat -m* shows managed memory usage but it does not show qdrouterd process 
> memory usage. An improvement would be to display process memory usage 
> somewhere via qdstat.
> Often a memory leak (DISPATCH-1407) will be in objects not held in managed 
> memory. In these cases memory usage may grow unbounded but not be visible by 
> qdstat.
> A new line or three could be added to qdstat -g or a new switch could be 
> added to qdstat. Good values to show are the standard columns from top: VIRT, 
> RES, and SHR.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

[jira] [Updated] (DISPATCH-1422) Add a global policy rejection count



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

Ganesh Murthy updated DISPATCH-1422:

Component/s: (was: Container)
 Policy Engine

> Add a global policy rejection count 
> 
>
> Key: DISPATCH-1422
> URL: https://issues.apache.org/jira/browse/DISPATCH-1422
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Policy Engine
>Affects Versions: 1.8.0
>Reporter: Ganesh Murthy
>Assignee: Chuck Rolke
>Priority: Major
>
> Add a new policyRejectionCount attribute to the router entity that counts 
> policy rejections across all connections. 



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

[jira] [Commented] (DISPATCH-1421) Attaching link to unavailable address sets source address to null in attach reply



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

Ganesh Murthy commented on DISPATCH-1421:
-

[~lulf] What is the user facing consequence of this ?

> Attaching link to unavailable address sets source address to null in attach 
> reply
> -
>
> Key: DISPATCH-1421
> URL: https://issues.apache.org/jira/browse/DISPATCH-1421
> Project: Qpid Dispatch
>  Issue Type: Bug
>Reporter: Ulf Lilleengen
>Priority: Major
>
> An AMQP client attaches to an address with source address set to 'bar' and 
> target address 'remote/foo1' (which the router does not know about):
>  
> {code:java}
> [425203913:0] -> Attach{name='space2.bar.fwd2.out', handle=0, role=SENDER, 
> sndSettleMode=MIXED, rcvSettleMode=FIRST, source=Source{address='bar', 
> durable=UNSETTLED_STATE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, 
> dynamicNodeProperties=null, distributionMode=null, filter=null, 
> defaultOutcome=null, outcomes=null, capabilities=null}, 
> target=Target{address='remote1/foo1', durable=NONE, expiryPolicy=SESSION_END, 
> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null}, 
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0, 
> maxMessageSize=null, offeredCapabilities=null, desiredCapabilities=null, 
> properties=null} {code}
>  
> As the router does not know about 'remote/foo1', it sets target=null, but 
> also source address to 'null' (this is actually null, not the string 'null', 
> proton-j is doing the formatting):
> {code:java}
> [425203913:0] <- Attach{name='space2.bar.fwd2.out', handle=0, role=RECEIVER, 
> sndSettleMode=MIXED, rcvSettleMode=FIRST, source=Source{address='null', 
> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false, 
> dynamicNodeProperties=null, distributionMode=null, filter=null, 
> defaultOutcome=null, outcomes=null, capabilities=null}, target=null, 
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0, 
> maxMessageSize=0, offeredCapabilities=null, desiredCapabilities=null, 
> properties=null}
> [425203913:0] <- Detach{handle=0, closed=true, 
> error=Error{condition=qd:no-route-to-dest, description='No route to the 
> destination node', info=null}} {code}
>  
> This can be handled in client code, but the question is if the router should 
> keep address='bar' in the replied attach or not.
>  
> Possibly related: https://issues.apache.org/jira/browse/DISPATCH-962 (CC 
> [~robbie])



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

[jira] [Updated] (DISPATCH-1420) Support server side filtering of entities



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

Ganesh Murthy updated DISPATCH-1420:

Affects Version/s: 1.8.0

> Support server side filtering of entities
> -
>
> Key: DISPATCH-1420
> URL: https://issues.apache.org/jira/browse/DISPATCH-1420
> Project: Qpid Dispatch
>  Issue Type: Improvement
>Affects Versions: 1.8.0
>Reporter: Ulf Lilleengen
>Priority: Major
>
> In order to inspect a specific connection or a specific link on a connection, 
> one has to query all connections and all links and do the filtering client 
> side. For deployments with a lot of entities, this consumes an unnecessary 
> amount of bandwith as well as complexity for clients.
>  
> This load could be reduced if the router management had the capability to 
> specify filters along with the query, and the ability to do the filtering in 
> the router before returning the result. Depending on the underlying 
> datastructure, it could be possible to query more efficiently doing lookup by 
> id for instance.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

[jira] [Updated] (DISPATCH-1425) Limit the maximum message size that a sender can send to the router



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

Ganesh Murthy updated DISPATCH-1425:

Component/s: (was: Container)
 Policy Engine

> Limit the maximum message size that a sender can send to the router
> ---
>
> Key: DISPATCH-1425
> URL: https://issues.apache.org/jira/browse/DISPATCH-1425
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Policy Engine
>Affects Versions: 1.8.0
>Reporter: Ganesh Murthy
>Priority: Major
>




--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

[jira] [Assigned] (DISPATCH-1425) Limit the maximum message size that a sender can send to the router



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

Ganesh Murthy reassigned DISPATCH-1425:
---

Assignee: Chuck Rolke

> Limit the maximum message size that a sender can send to the router
> ---
>
> Key: DISPATCH-1425
> URL: https://issues.apache.org/jira/browse/DISPATCH-1425
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Policy Engine
>Affects Versions: 1.8.0
>Reporter: Ganesh Murthy
>Assignee: Chuck Rolke
>Priority: Major
>




--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

[jira] [Updated] (DISPATCH-1173) Exceptions handling



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

Ganesh Murthy updated DISPATCH-1173:

Labels: usability  (was: )

> Exceptions handling
> ---
>
> Key: DISPATCH-1173
> URL: https://issues.apache.org/jira/browse/DISPATCH-1173
> Project: Qpid Dispatch
>  Issue Type: Improvement
>Affects Versions: 1.3.0, 1.8.0
>Reporter: Olivier VERMEULEN
>Priority: Major
>  Labels: usability
>
> We are using the Dispatch-Router 1.3.0, Broker-J 7.0.3 and Qpid JMS 0.11.1
> For the same use case, the exception we get from the dispatch-router is much 
> less explicit than the one we get when we connect to the broker directly.
>  
> +For example when sending a message to a topic that does not exist.+
>  * *Through the broker:*
> javax.jms.InvalidDestinationException: Could not find destination for target 
> 'Target 
> \{address=unknownDestination,durable=none,expiryPolicy=session-end,dynamic=false,capabilities=[topic]}
>  ' [condition = amqp:not-found]
>  * *Through the dispatch-router* (defaultDistribution set to unavailable):
> javax.jms.InvalidDestinationException: Node not found [condition = 
> amqp:not-found]
>  
> +Another example when sending a message bigger than the max_message_size set 
> on the broker:+
>  * *Through the broker*:
> javax.jms.JMSException: delivery '\x00' exceeds max-message-size 10240 
> [condition = amqp:link:message-size-exceeded]
>  * *Through the dispatch-router*:
> javax.jms.JMSException: Delivery failed: failure at remote
>  



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

[jira] [Assigned] (DISPATCH-1327) Router stops forwarding multicast deliveries (large messages) to connected receivers after a receiver closes its connection



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

Ganesh Murthy reassigned DISPATCH-1327:
---

Assignee: Ken Giusti

> Router stops forwarding multicast deliveries (large messages) to connected 
> receivers after a receiver closes its connection
> ---
>
> Key: DISPATCH-1327
> URL: https://issues.apache.org/jira/browse/DISPATCH-1327
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Routing Engine
>Affects Versions: 1.7.0
>Reporter: Fernando Giorgetti
>Assignee: Ken Giusti
>Priority: Major
>
> The problem can be observed running 
> *test_40_drop_rx_client_multicast_large_message*** from 
> *system_tests_edge_router*.
> It does not happen all the time, but after some attempts it will fail and we 
> can observe receivers won't get all sent messages and then test times out.
> Further info to be attached.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

[jira] [Updated] (DISPATCH-1336) Deliveries settled out of order in simple test case



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

Ganesh Murthy updated DISPATCH-1336:

Issue Type: Bug  (was: Improvement)

> Deliveries settled out of order in simple test case
> ---
>
> Key: DISPATCH-1336
> URL: https://issues.apache.org/jira/browse/DISPATCH-1336
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 1.7.0
> Environment: Fedora 29, Python 3
> Debug builds
> Proton git: branch master @ 0481a507c
> Dispatch git: branch master @ 7b3a8e25
>Reporter: Chuck Rolke
>Priority: Major
>
> 1. A router is started with a simple
> qdrouterd
> 2. A single qpid-proton-c sender sends 100,000 messages to port 5672
>  3. A simple qpid-proton-c receiver receives the messages and accepts them.
>  4. In the sender's on_accept method occasionally the message IDs appear out 
> of order.
> In this snippet the message id numbers are marching along in the correct 
> order. Then settlements 77441..77459 jump ahead of settlement 77430. After 
> that the streams get synchronized again and match for the remainder of the 
> run.
> This is not necessarily wrong from an AMQP standpoint. But one might expect 
> that the settlements would propagate from the receiver back to the sender in 
> order every time.
> Can anyone explain how this happens?
> {code:java}
> Fail to match message id 77430 with settlement id 77441
> Fail to match message id 77431 with settlement id 77442
> Fail to match message id 77432 with settlement id 77443
> Fail to match message id 77433 with settlement id 77444
> Fail to match message id 77434 with settlement id 77445
> Fail to match message id 77435 with settlement id 77446
> Fail to match message id 77436 with settlement id 77447
> Fail to match message id 77437 with settlement id 77448
> Fail to match message id 77438 with settlement id 77449
> Fail to match message id 77439 with settlement id 77450
> Fail to match message id 77440 with settlement id 77451
> Fail to match message id 77441 with settlement id 77452
> Fail to match message id 77442 with settlement id 77453
> Fail to match message id 77443 with settlement id 77454
> Fail to match message id 77444 with settlement id 77455
> Fail to match message id 77445 with settlement id 77456
> Fail to match message id 77446 with settlement id 77457
> Fail to match message id 77447 with settlement id 77458
> Fail to match message id 77448 with settlement id 77459
> Fail to match message id 77449 with settlement id 77430
> Fail to match message id 77450 with settlement id 77431
> Fail to match message id 77451 with settlement id 77432
> Fail to match message id 77452 with settlement id 77433
> Fail to match message id 77453 with settlement id 77434
> Fail to match message id 77454 with settlement id 77435
> Fail to match message id 77455 with settlement id 77436
> Fail to match message id 77456 with settlement id 77437
> Fail to match message id 77457 with settlement id 77438
> Fail to match message id 77458 with settlement id 77439
> Fail to match message id 77459 with settlement id 77440
> {code}



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

[jira] [Updated] (DISPATCH-1336) Deliveries settled out of order in simple test case



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

Ganesh Murthy updated DISPATCH-1336:

Priority: Major  (was: Minor)

> Deliveries settled out of order in simple test case
> ---
>
> Key: DISPATCH-1336
> URL: https://issues.apache.org/jira/browse/DISPATCH-1336
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Router Node
>Affects Versions: 1.7.0
> Environment: Fedora 29, Python 3
> Debug builds
> Proton git: branch master @ 0481a507c
> Dispatch git: branch master @ 7b3a8e25
>Reporter: Chuck Rolke
>Priority: Major
>
> 1. A router is started with a simple
> qdrouterd
> 2. A single qpid-proton-c sender sends 100,000 messages to port 5672
>  3. A simple qpid-proton-c receiver receives the messages and accepts them.
>  4. In the sender's on_accept method occasionally the message IDs appear out 
> of order.
> In this snippet the message id numbers are marching along in the correct 
> order. Then settlements 77441..77459 jump ahead of settlement 77430. After 
> that the streams get synchronized again and match for the remainder of the 
> run.
> This is not necessarily wrong from an AMQP standpoint. But one might expect 
> that the settlements would propagate from the receiver back to the sender in 
> order every time.
> Can anyone explain how this happens?
> {code:java}
> Fail to match message id 77430 with settlement id 77441
> Fail to match message id 77431 with settlement id 77442
> Fail to match message id 77432 with settlement id 77443
> Fail to match message id 77433 with settlement id 77444
> Fail to match message id 77434 with settlement id 77445
> Fail to match message id 77435 with settlement id 77446
> Fail to match message id 77436 with settlement id 77447
> Fail to match message id 77437 with settlement id 77448
> Fail to match message id 77438 with settlement id 77449
> Fail to match message id 77439 with settlement id 77450
> Fail to match message id 77440 with settlement id 77451
> Fail to match message id 77441 with settlement id 77452
> Fail to match message id 77442 with settlement id 77453
> Fail to match message id 77443 with settlement id 77454
> Fail to match message id 77444 with settlement id 77455
> Fail to match message id 77445 with settlement id 77456
> Fail to match message id 77446 with settlement id 77457
> Fail to match message id 77447 with settlement id 77458
> Fail to match message id 77448 with settlement id 77459
> Fail to match message id 77449 with settlement id 77430
> Fail to match message id 77450 with settlement id 77431
> Fail to match message id 77451 with settlement id 77432
> Fail to match message id 77452 with settlement id 77433
> Fail to match message id 77453 with settlement id 77434
> Fail to match message id 77454 with settlement id 77435
> Fail to match message id 77455 with settlement id 77436
> Fail to match message id 77456 with settlement id 77437
> Fail to match message id 77457 with settlement id 77438
> Fail to match message id 77458 with settlement id 77439
> Fail to match message id 77459 with settlement id 77440
> {code}



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

[jira] [Updated] (DISPATCH-1342) Replaced mutex with spin lock on qd_message content



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

Ganesh Murthy updated DISPATCH-1342:

Labels: performance  (was: )

> Replaced mutex with spin lock on qd_message content
> ---
>
> Key: DISPATCH-1342
> URL: https://issues.apache.org/jira/browse/DISPATCH-1342
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Routing Engine
>Affects Versions: 1.7.0
>Reporter: Francesco Nigro
>Priority: Minor
>  Labels: performance
>
> Given that qd_message creation and qd_message_free involves sys_mutex 
> allocation/free and they are OS resources too, using spin locks will reduce 
> the CPU/memory usage while performing such frequent operations.
> In addition it would make the router more reactive and resilient to OS thread 
> scheduling while message->content is being concurrently accessed too, given 
> that such accesses are meant to not last long and there is no need to involve 
> OS arbitration to park/awake threads,



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

[jira] [Updated] (DISPATCH-1344) Relaxing C11 sys_atomic_init and get



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

Ganesh Murthy updated DISPATCH-1344:

Labels: performance  (was: )

> Relaxing C11 sys_atomic_init and get
> 
>
> Key: DISPATCH-1344
> URL: https://issues.apache.org/jira/browse/DISPATCH-1344
> Project: Qpid Dispatch
>  Issue Type: Improvement
>Affects Versions: 1.7.0
>Reporter: Francesco Nigro
>Priority: Minor
>  Labels: performance
>
> GCC version of the same primitives are using plain loads/stores while C11 
> ones where using the default behavior of all atomic operations ie 
> sequentially consistent ordering.
> Sequential consistent ordering is heavy-weight and should be relaxed if not 
> necessary.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

[jira] [Updated] (DISPATCH-1351) qd_message_content_t could be inlined into qd_message_pvt_t



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

Ganesh Murthy updated DISPATCH-1351:

Labels: performance  (was: )

> qd_message_content_t could be inlined into qd_message_pvt_t
> ---
>
> Key: DISPATCH-1351
> URL: https://issues.apache.org/jira/browse/DISPATCH-1351
> Project: Qpid Dispatch
>  Issue Type: Improvement
>Affects Versions: 1.7.0
>Reporter: Francesco Nigro
>Priority: Minor
>  Labels: performance
>




--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

[jira] [Updated] (DISPATCH-1352) qd_buffer_list_clone cost is dominated by cache misses



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

Ganesh Murthy updated DISPATCH-1352:

Labels: performance  (was: )

> qd_buffer_list_clone cost is dominated by cache misses
> --
>
> Key: DISPATCH-1352
> URL: https://issues.apache.org/jira/browse/DISPATCH-1352
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Routing Engine
>Affects Versions: 1.7.0
>Reporter: Francesco Nigro
>Priority: Major
>  Labels: performance
> Attachments: screenshot-1.png, screenshot-2.png
>
>
> qd_buffer_list_clone on qd_message_copy for 
> qd_message_pvt_t.ma_to_override/ma_trace/ma_ingress is dominated by cache 
> misses costs:
> * to "allocate" new qd_buffer_t
> * to reference any qd_buffer_t from the source qd_buffer_list_t



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

[jira] [Updated] (DISPATCH-1363) Remove apache rat check from main travis build and move to a sub build



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

Ganesh Murthy updated DISPATCH-1363:

Labels: CI/CD  (was: )

> Remove apache rat check from main travis build and move to a sub build 
> ---
>
> Key: DISPATCH-1363
> URL: https://issues.apache.org/jira/browse/DISPATCH-1363
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Tests
>Affects Versions: 1.7.0
>Reporter: Ganesh Murthy
>Priority: Minor
>  Labels: CI/CD
>
> Currently, when a Travis build fails, we are unable to tell if the the 
> failure was due to the rat check failure or due to a system test failure. You 
> have to scroll all the way to the bottom of the build output page to find out 
> if the rat check failed.
> An improvement would be to move the rat check to a sub build so that it is 
> easy to visually identify if the build failure is due to the rat check or 
> system test failure.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

[jira] [Commented] (DISPATCH-1364) "make install" does not install qpid_dispatch[_site.py] files in the correct location



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

Ganesh Murthy commented on DISPATCH-1364:
-

Use the setuptools query function to determine where to install the 
distribution.

> "make install" does not install qpid_dispatch[_site.py] files in the correct 
> location
> -
>
> Key: DISPATCH-1364
> URL: https://issues.apache.org/jira/browse/DISPATCH-1364
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Tools
>Affects Versions: 1.8.0
>Reporter: Ken Giusti
>Priority: Major
> Fix For: Backlog
>
>
> Building and install qdr from source (cmake ; make install) ends up 
> putting qdr's python library modules in the wrong directory (not in the 
> default python search path).
> Specifically, these files are incorrectly installed in a "site-packages" 
> sub-directory:
> By default ubuntu's python does not use "site-packages" for installing 3rd 
> party python packages - it uses "dist-packages" instead. 
> The default python paths in ubuntu are:
> {quote}>>> import sys
>  >>> sys.path
>  ['', '/usr/lib/python36.zip', '/usr/lib/python3.6', 
> '/usr/lib/python3.6/lib-dynload', *'/usr/local/lib/python3.6/dist-packages'*, 
> '/usr/lib/python3/dist-packages']
> {quote}
>  
> For example, proton correctly puts its python files in
> /usr/local/lib/python3.6/dist-packages/
> on ubuntu, while dispatch drops its packages into
> /usr/local/lib/python3.6/site-packages/
>  



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

[jira] [Updated] (DISPATCH-1364) "make install" does not install qpid_dispatch[_site.py] files in the correct location



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

Ganesh Murthy updated DISPATCH-1364:

Fix Version/s: Backlog

> "make install" does not install qpid_dispatch[_site.py] files in the correct 
> location
> -
>
> Key: DISPATCH-1364
> URL: https://issues.apache.org/jira/browse/DISPATCH-1364
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Tools
>Affects Versions: 1.8.0
>Reporter: Ken Giusti
>Priority: Major
> Fix For: Backlog
>
>
> Building and install qdr from source (cmake ; make install) ends up 
> putting qdr's python library modules in the wrong directory (not in the 
> default python search path).
> Specifically, these files are incorrectly installed in a "site-packages" 
> sub-directory:
> By default ubuntu's python does not use "site-packages" for installing 3rd 
> party python packages - it uses "dist-packages" instead. 
> The default python paths in ubuntu are:
> {quote}>>> import sys
>  >>> sys.path
>  ['', '/usr/lib/python36.zip', '/usr/lib/python3.6', 
> '/usr/lib/python3.6/lib-dynload', *'/usr/local/lib/python3.6/dist-packages'*, 
> '/usr/lib/python3/dist-packages']
> {quote}
>  
> For example, proton correctly puts its python files in
> /usr/local/lib/python3.6/dist-packages/
> on ubuntu, while dispatch drops its packages into
> /usr/local/lib/python3.6/site-packages/
>  



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

[jira] [Updated] (DISPATCH-1366) Performance improvement in qd_parse_as functions



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

Ganesh Murthy updated DISPATCH-1366:

Labels: performance  (was: )

> Performance improvement in qd_parse_as functions
> 
>
> Key: DISPATCH-1366
> URL: https://issues.apache.org/jira/browse/DISPATCH-1366
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Router Node
>Affects Versions: 1.8.0
>Reporter: Chuck Rolke
>Priority: Major
>  Labels: performance
> Fix For: Backlog
>
>
> Most of the calls to qd_iterator_octet in file parse.c could be avoided when 
> enough of the field's data is in the current underlying buffer. The objective 
> is to use the same technques used in DISPATCH-1354



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

[jira] [Updated] (DISPATCH-1368) Link (address) priority is ignored by the second hop router



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

Ganesh Murthy updated DISPATCH-1368:

Priority: Minor  (was: Major)

> Link (address) priority is ignored by the second hop router
> ---
>
> Key: DISPATCH-1368
> URL: https://issues.apache.org/jira/browse/DISPATCH-1368
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 1.8.0, 1.9.0
>Reporter: Ken Giusti
>Assignee: michael goulish
>Priority: Minor
>
> Address-based priority is only enforced on the egress of the first hop router.
> In a 3 router linear network:
> Sender --> Router A --> Router B --> Router C --> Receiver
> Message delivery is properly sent via the inter-router links between Router A 
> and Router B.
> However, those messages are all forwarded on the default priority (4) between 
> router B and C.
> [C --> Receiver is fine - priority doesn't apply to egress endpoint links]
> The expectation is that the message priority is honored across all 
> inter-router links.
> [Reproducer|https://github.com/kgiusti/dispatch/tree/DISPATCH-1368-reproducer]
> Build the router, then run the priority test (ctest -VV -R priority).
> Then grep for "DELIVERIES" in the log files:
>  grep "DELIVERIES" 
> tests/system_test.dir/system_tests_priority/CongestionTests/setUpClass/*.log
> tests/system_test.dir/system_tests_priority/CongestionTests/setUpClass/A.log:2019-06-14
>  11:10:00.324389 -0400 ROUTER (error) DELIVERIES PER PRIORITY: 9=20 8=0 7=28 
> 6=0 5=0 4(default)=21 3=0 2=12 1=0 0=343 
> (/home/kgiusti/work/dispatch/qpid-dispatch/src/router_core/router_core_thread.c:188)
> tests/system_test.dir/system_tests_priority/CongestionTests/setUpClass/B.log:2019-06-14
>  11:10:00.302570 -0400 ROUTER (error) DELIVERIES PER PRIORITY: 9=0 8=0 7=0 
> 6=0 5=0 4(default)=172 3=0 2=0 1=0 0=286 
> (/home/kgiusti/work/dispatch/qpid-dispatch/src/router_core/router_core_thread.c:188)
> ...
> Notice the counts on A (tx to B) - these are correct.
> On B all msgs are sent priority 4 (default) to C - this is wrong.
>  
>  
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

[jira] [Updated] (DISPATCH-1369) Update console dependencies to avoid npm security warnings



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

Ganesh Murthy updated DISPATCH-1369:

Labels: security  (was: )

> Update console dependencies to avoid npm security warnings
> --
>
> Key: DISPATCH-1369
> URL: https://issues.apache.org/jira/browse/DISPATCH-1369
> Project: Qpid Dispatch
>  Issue Type: Task
>  Components: Console
>Affects Versions: 1.8.0
>Reporter: Ernest Allen
>Assignee: Ernest Allen
>Priority: Major
>  Labels: security
>
> Running npm audit in the stand-alone console directory results in 51 moderate 
> security warnings.
> The underlying npm package dependencies should be updated



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

[jira] [Updated] (DISPATCH-1371) qd_alloc can reuse instances in LIFO order



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

Ganesh Murthy updated DISPATCH-1371:

Labels: performance  (was: performence)

> qd_alloc can reuse instances in LIFO order
> --
>
> Key: DISPATCH-1371
> URL: https://issues.apache.org/jira/browse/DISPATCH-1371
> Project: Qpid Dispatch
>  Issue Type: Improvement
>Affects Versions: 1.8.0
>Reporter: Francesco Nigro
>Priority: Minor
>  Labels: performance
>
> qd_dealloc is inserting instances on the tail of the thread local free_list 
> while qd_alloc is reading from the head, always causing cache misses unless 
> free_list size is 1.
> qd_alloc could instead reuse the last inserted instance ie the tail, using 
> free_list as a stack (with LIFO accesses).



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

[jira] [Updated] (DISPATCH-1371) qd_alloc can reuse instances in LIFO order



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

Ganesh Murthy updated DISPATCH-1371:

Labels: performence  (was: )

> qd_alloc can reuse instances in LIFO order
> --
>
> Key: DISPATCH-1371
> URL: https://issues.apache.org/jira/browse/DISPATCH-1371
> Project: Qpid Dispatch
>  Issue Type: Improvement
>Affects Versions: 1.8.0
>Reporter: Francesco Nigro
>Priority: Minor
>  Labels: performence
>
> qd_dealloc is inserting instances on the tail of the thread local free_list 
> while qd_alloc is reading from the head, always causing cache misses unless 
> free_list size is 1.
> qd_alloc could instead reuse the last inserted instance ie the tail, using 
> free_list as a stack (with LIFO accesses).



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

[jira] [Commented] (DISPATCH-1371) qd_alloc can reuse instances in LIFO order



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

Ganesh Murthy commented on DISPATCH-1371:
-

[~nigro@gmail.com] can we close this ?

> qd_alloc can reuse instances in LIFO order
> --
>
> Key: DISPATCH-1371
> URL: https://issues.apache.org/jira/browse/DISPATCH-1371
> Project: Qpid Dispatch
>  Issue Type: Improvement
>Affects Versions: 1.8.0
>Reporter: Francesco Nigro
>Priority: Minor
>
> qd_dealloc is inserting instances on the tail of the thread local free_list 
> while qd_alloc is reading from the head, always causing cache misses unless 
> free_list size is 1.
> qd_alloc could instead reuse the last inserted instance ie the tail, using 
> free_list as a stack (with LIFO accesses).



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

[jira] [Updated] (DISPATCH-1373) the log system mutex is held far too long



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

Ganesh Murthy updated DISPATCH-1373:

Labels: performance  (was: )

> the log system mutex is held far too long
> -
>
> Key: DISPATCH-1373
> URL: https://issues.apache.org/jira/browse/DISPATCH-1373
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 1.8.0, 1.9.0
>Reporter: Ken Giusti
>Priority: Major
>  Labels: performance
>
> The log code holds the log mutex(s) too long.  Depending on the log level 
> (trace+ is worst) the lock has been observed being held for > 30 milliseconds.
> The log lock is a singleton that is acquired by all calls to qd_log (active 
> log level only) - which means it is a global lock.
> It appears as if the lock is held while doing I/O and alloc/dealloc'ing 
> memory - which may be expensive (in qd_vlog_impl() in log.c):
>  
> {{    // Bounded buffer of log entries, keep most recent.}}
> {{    *sys_mutex_lock(log_lock);*}}
> {{    qd_log_entry_t *entry = new_qd_log_entry_t();}}
> {{    DEQ_ITEM_INIT(entry);}}
> {{    entry->module = source->module;}}
> {{    entry->level  = level;}}
> {{    entry->file   = file ? strdup(file) : 0;}}
> {{    entry->line   = line;}}
> {{    gettimeofday(>time, NULL);}}
> {{    vsnprintf(entry->text, TEXT_MAX, fmt, ap);}}
> {{    write_log(source, entry);}}
> {{    DEQ_INSERT_TAIL(entries, entry);}}
> {{    if (DEQ_SIZE(entries) > LIST_MAX)}}
> {{    qd_log_entry_free_lh(DEQ_HEAD(entries));}}
> {{    *sys_mutex_unlock(log_lock);*}}{{}}
>  



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

[jira] [Commented] (DISPATCH-1399) Allow arrows on console's topology page to be disabled



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

Ganesh Murthy commented on DISPATCH-1399:
-

[~eallen] Is this bug fixed ?

> Allow arrows on console's topology page to be disabled
> --
>
> Key: DISPATCH-1399
> URL: https://issues.apache.org/jira/browse/DISPATCH-1399
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Console
>Affects Versions: 1.8.0
>Reporter: Ernest Allen
>Assignee: Ernest Allen
>Priority: Major
>
> The topology diagram shows the direction that connections are initiated. The 
> router with the listener has the arrow pointing to it.
> This can be confusing since there is actually bi-directional traffic going 
> over the connection's links.
> There should be an option to hide the arrows.
> The arrows should be hidden by default.
> The current state of the arrows (visible/hidden) should be remembered (per 
> browser) and restored.
>  



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

[jira] [Updated] (DISPATCH-1400) [tools] Scraper fails with log file BOM byte order marks



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

Ganesh Murthy updated DISPATCH-1400:

Priority: Minor  (was: Major)

> [tools] Scraper fails with log file BOM byte order marks
> 
>
> Key: DISPATCH-1400
> URL: https://issues.apache.org/jira/browse/DISPATCH-1400
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Tools
>Affects Versions: 1.8.0
>Reporter: Chuck Rolke
>Assignee: Chuck Rolke
>Priority: Minor
>
> Logs captured from downloading Openshift pod logs have BOMs. Scraper fails 
> right away.
> A workaround is to process the log with dos2unix:
> {{   dos2unix PVT.log}}
>  



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

[jira] [Updated] (DISPATCH-1418) sending a msg to a configured address w/o subscribers should RELEASE not REJECT



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

Ganesh Murthy updated DISPATCH-1418:

Priority: Major  (was: Minor)

> sending a msg to a configured address w/o subscribers should RELEASE not 
> REJECT
> ---
>
> Key: DISPATCH-1418
> URL: https://issues.apache.org/jira/browse/DISPATCH-1418
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Routing Engine
>Affects Versions: 1.8.0, 1.9.0
>Reporter: Ken Giusti
>Assignee: Ken Giusti
>Priority: Major
>
> Attach a sender to the router using an anonymous link.
> Send a message to an address that is pre-configured (say "closest/foo") while 
> there are no subscribers.
> Expect: the message be RELEASED by the router
> Actual: the message is REJECTED by the router
> See system_tests_router_mesh.py



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

[jira] [Commented] (DISPATCH-1422) Add a global policy rejection count



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

Ganesh Murthy commented on DISPATCH-1422:
-

Add this metric to prometheus 

> Add a global policy rejection count 
> 
>
> Key: DISPATCH-1422
> URL: https://issues.apache.org/jira/browse/DISPATCH-1422
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Container
>Affects Versions: 1.8.0
>Reporter: Ganesh Murthy
>Assignee: Chuck Rolke
>Priority: Major
>
> Add a new policyRejectionCount attribute to the router entity that counts 
> policy rejections across all connections. 



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

[jira] [Updated] (DISPATCH-1424) Long running tests that can identify router memory growth and other stability issues



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

Ganesh Murthy updated DISPATCH-1424:

Summary: Long running tests that can identify router memory growth and 
other stability issues   (was: Long running tests that can identify 
routermemory growth and other stability issues )

> Long running tests that can identify router memory growth and other stability 
> issues 
> -
>
> Key: DISPATCH-1424
> URL: https://issues.apache.org/jira/browse/DISPATCH-1424
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Tests
>Affects Versions: 1.8.0
>Reporter: Ganesh Murthy
>Assignee: michael goulish
>Priority: Major
>
> These tests will be run on CI



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

[jira] [Created] (DISPATCH-1425) Limit the maximum message size that a sender can send to the router

Ganesh Murthy created DISPATCH-1425:
---

 Summary: Limit the maximum message size that a sender can send to 
the router
 Key: DISPATCH-1425
 URL: https://issues.apache.org/jira/browse/DISPATCH-1425
 Project: Qpid Dispatch
  Issue Type: Improvement
  Components: Container
Affects Versions: 1.8.0
Reporter: Ganesh Murthy






--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

[jira] [Assigned] (DISPATCH-1423) Multicast sender with no receiver has first 250 messages released

2019-09-17 Thread Ken Giusti (Jira)



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

Ken Giusti reassigned DISPATCH-1423:


Assignee: Ken Giusti

> Multicast sender with no receiver has first 250 messages released
> -
>
> Key: DISPATCH-1423
> URL: https://issues.apache.org/jira/browse/DISPATCH-1423
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Routing Engine
>Affects Versions: 1.8.0
>Reporter: Chuck Rolke
>Assignee: Ken Giusti
>Priority: Major
> Attachments: INTB-250-released-1.8.0.html, INTB.conf
>
>
> When a sender starts and there's no receiver already attached then the first 
> 250 messages the sender sends get released. After that the router waits for 
> the a receiver to attach before issuing more credit to the sender. The proton 
> c++ simple_send and simple receive clients expose this problem.
> 1. Start router with attached config file
> 2. Start sender
> simple_send -a 127.0.0.1:5672/multicast/q1 -m 500
> 3. Start receiver
>simple_recv -a 127.0.0.1:5672/multicast/q1 -m 500
> The sender competes with 'all messages confirmed'.
> The receiver is waiting for the second 250 messages.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

[jira] [Created] (DISPATCH-1424) Long running tests that can identify routermemory growth and other stability issues

Ganesh Murthy created DISPATCH-1424:
---

 Summary: Long running tests that can identify routermemory growth 
and other stability issues 
 Key: DISPATCH-1424
 URL: https://issues.apache.org/jira/browse/DISPATCH-1424
 Project: Qpid Dispatch
  Issue Type: Improvement
  Components: Tests
Affects Versions: 1.8.0
Reporter: Ganesh Murthy
Assignee: michael goulish


These tests will be run on CI



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

[jira] [Updated] (DISPATCH-1423) Multicast sender with no receiver has first 250 messages released



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

Chuck Rolke updated DISPATCH-1423:
--
Attachment: INTB-250-released-1.8.0.html

> Multicast sender with no receiver has first 250 messages released
> -
>
> Key: DISPATCH-1423
> URL: https://issues.apache.org/jira/browse/DISPATCH-1423
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Routing Engine
>Affects Versions: 1.8.0
>Reporter: Chuck Rolke
>Priority: Major
> Attachments: INTB-250-released-1.8.0.html, INTB.conf
>
>
> When a sender starts and there's no receiver already attached then the first 
> 250 messages the sender sends get released. After that the router waits for 
> the a receiver to attach before issuing more credit to the sender. The proton 
> c++ simple_send and simple receive clients expose this problem.
> 1. Start router with attached config file
> 2. Start sender
> simple_send -a 127.0.0.1:5672/multicast/q1 -m 500
> 3. Start receiver
>simple_recv -a 127.0.0.1:5672/multicast/q1 -m 500
> The sender competes with 'all messages confirmed'.
> The receiver is waiting for the second 250 messages.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

Re: [VOTE] Release Qpid Dispatch Router 1.9.0 (RC2)

2019-09-17 Thread Chuck Rolke

+1

* Passes checksum verify
* Build and pass self tests
* Run local test environment stress test OK.

Note: observed issue described in DISPATCH-1423. 
That issue is also present in 1.8.0 and is not a regression

- Original Message -
> From: "Ganesh Murthy" 
> To: us...@qpid.apache.org, dev@qpid.apache.org
> Sent: Monday, September 16, 2019 2:17:05 PM
> Subject: [VOTE] Release Qpid Dispatch Router 1.9.0 (RC2)
> 
> Hello All,
> 
>  Please cast your vote on this thread to release RC2 as the
> official Qpid Dispatch Router version  1.9.0.
> 
> RC2 of Qpid Dispatch Router version 1.9.0 can be found here:
> 
> https://dist.apache.org/repos/dist/dev/qpid/dispatch/1.9.0-rc2/
> 
> The following improvements, and bug fixes are introduced in 1.9.0:
> 
> Improvements -
> DISPATCH-480 - Default tests timeout is too short for some machines
> DISPATCH-1266 - Improve router's handling of unsettled multicast
> deliveries
> DISPATCH-1338 - Improvements to edge router documentation
> DISPATCH-1345 - Reduce the number of QDR_LINK_FLOW events by
> coalescing credit grants
> DISPATCH-1346 - Create documentation for priority delivery
> DISPATCH-1347 - Update documentation for Dispatch Router console
> DISPATCH-1350 - Update logging/monitoring documentation
> DISPATCH-1353 - Document how to configure access policy control on
> router-initiated connections
> DISPATCH-1354 - Interrouter annotation processing uses slow methods
> DISPATCH-1370 - Move the schema, connect, and entities tabs to the
> right in the console
> DISPATCH-1372 - alloc_pool intrusive linked list can be replaced
> by a linked stack
> DISPATCH-1374 - Add qdstat options --all-routers and all-entities
> which display statistics of all routers and displays all entities
> DISPATCH-1376 - Make it easier to change the product name in the console
> DISPATCH-1379 - Message receive performance improvements
> DISPATCH-1381 - Create documentation for configuring fallback
> destinations
> DISPATCH-1382 - Document ability to force-close a connection from
> the web console
> DISPATCH-1385 - qd_message_list_t is dead code
> DISPATCH-1388 - Authorization doc fails to describe vhost
> abstraction clearly
> DISPATCH-1396 - Doc how to start the router
> 
> Bugs -
> DISPATCH-1359 - Set ctest timeout to 300 seconds.
> DISPATCH-1361 - system_tests_fallback_dest hanging in some cases
> DISPATCH-1362 - Shutdown crash when trying to clean up fallback addresses
> DISPATCH-1365 - Table of links with delayed deliveries is showing
> all endpoint links
> DISPATCH-1378 - missing lock of connection's links_with_work list
> DISPATCH-1380 - qdrouterd leaves dangling qd_link_t pointer
> DISPATCH-1383 - system_tests_policy is timing out
> DISPATCH-1387 - Coverity issues on master branch
> DISPATCH-1391 - Proton link reference not cleared on router link
> objects during session close
> DISPATCH-1394 - qd_check_message() incorrectly validates partially
> received messages
> DISPATCH-1398 - "Expression with no effect" warning for console web
> DISPATCH-1404 - message annotation parsing incorrectly uses
> ->remainder for current buffer capacity
> DISPATCH-1406 - Inter-router link stall on receive client failover
> DISPATCH-1407 - Memory leak on link policy denial
> DISPATCH-1408 - system_tests_distribution failing when running
> under valgrind
> DISPATCH-1410 - attach of auto-links not logged
> DISPATCH-1413 - system_tests_two_routers.py failing intermittently on
> Travis
> DISPATCH-1417 - Crash when connection_wake ctx points to freed memory
> 
> Thanks.
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
> 
> 

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

[jira] [Updated] (DISPATCH-1417) Crash when connection_wake ctx points to freed memory



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

Chuck Rolke updated DISPATCH-1417:
--
Attachment: (was: INTB.conf)

> Crash when connection_wake ctx points to freed memory
> -
>
> Key: DISPATCH-1417
> URL: https://issues.apache.org/jira/browse/DISPATCH-1417
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 1.8.0
>Reporter: Chuck Rolke
>Assignee: Ganesh Murthy
>Priority: Major
> Fix For: 1.9.0
>
>
> Test clients are streaming unsettled multicast messages to and from an edge 
> router. Another client repeats the cycle "connect, receive one message from 
> the stream, disconnect". Soon the edge router core dumps with:
> {{(gdb) bt
> #0 get_pconnection (c=0x) at 
> /home/chug/git/qpid-proton/c/src/proactor/epoll.c:578
> #1 0x7fc8c0582a1c in pn_connection_wake (c=0x) at 
> /home/chug/git/qpid-proton/c/src/proactor/epoll.c:1439
> #2 0x7fc8c0668472 in connection_wake (ctx=0x1a43658) at 
> /home/chug/Downloads/qpid-dispatch-1.9.0/src/server.c:505
> #3 0x7fc8c066b2af in qd_server_activate (ctx=0x1a43658) at 
> /home/chug/Downloads/qpid-dispatch-1.9.0/src/server.c:1304
> #4 0x7fc8c064f3dd in qdr_activate_connections_CT (core=0x19c8ce0) at 
> /home/chug/Downloads/qpid-dispatch-1.9.0/src/router_core/router_core_thread.c:65
> #5 0x7fc8c064fa1d in router_core_thread (arg=0x19c8ce0) at 
> /home/chug/Downloads/qpid-dispatch-1.9.0/src/router_core/router_core_thread.c:171
> #6 0x7fc8c056258e in start_thread () from /usr/lib64/libpthread.so.0
> #7 0x7fc8c0201713 in clone () from /usr/lib64/libc.so.6
> (gdb) info threads
>  Id Target Id Frame 
> * 1 Thread 0x7fc8b1e44700 (LWP 21706) get_pconnection (c=0x) 
> at /home/chug/git/qpid-proton/c/src/proactor/epoll.c:578
>  2 Thread 0x7fc8bf8ff240 (LWP 21696) 0x7fc8c0201a47 in epoll_wait () from 
> /usr/lib64/libc.so.6
>  3 Thread 0x7fc8b0e42700 (LWP 21708) 0x7fc8c0201a47 in epoll_wait () from 
> /usr/lib64/libc.so.6
>  4 Thread 0x7fc8abfff700 (LWP 21709) 0x7fc8c0201a47 in epoll_wait () from 
> /usr/lib64/libc.so.6
>  5 Thread 0x7fc8b1643700 (LWP 21707) 0x7fc8c01f6481 in poll () from 
> /usr/lib64/libc.so.6
>  6 Thread 0x7fc8ab7fe700 (LWP 21710) 0x7fc8c0201a47 in epoll_wait () from 
> /usr/lib64/libc.so.6}}



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

[jira] [Updated] (DISPATCH-1423) Multicast sender with no receiver has first 250 messages released



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

Chuck Rolke updated DISPATCH-1423:
--
Attachment: INTB.conf

> Multicast sender with no receiver has first 250 messages released
> -
>
> Key: DISPATCH-1423
> URL: https://issues.apache.org/jira/browse/DISPATCH-1423
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Routing Engine
>Affects Versions: 1.8.0
>Reporter: Chuck Rolke
>Priority: Major
> Attachments: INTB.conf
>
>
> When a sender starts and there's no receiver already attached then the first 
> 250 messages the sender sends get released. After that the router waits for 
> the a receiver to attach before issuing more credit to the sender. The proton 
> c++ simple_send and simple receive clients expose this problem.
> 1. Start router with attached config file
> 2. Start sender
> simple_send -a 127.0.0.1:5672/multicast/q1 -m 500
> 3. Start receiver
>simple_recv -a 127.0.0.1:5672/multicast/q1 -m 500
> The sender competes with 'all messages confirmed'.
> The receiver is waiting for the second 250 messages.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

[jira] [Updated] (DISPATCH-1417) Crash when connection_wake ctx points to freed memory



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

Chuck Rolke updated DISPATCH-1417:
--
Attachment: INTB.conf

> Crash when connection_wake ctx points to freed memory
> -
>
> Key: DISPATCH-1417
> URL: https://issues.apache.org/jira/browse/DISPATCH-1417
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 1.8.0
>Reporter: Chuck Rolke
>Assignee: Ganesh Murthy
>Priority: Major
> Fix For: 1.9.0
>
> Attachments: INTB.conf
>
>
> Test clients are streaming unsettled multicast messages to and from an edge 
> router. Another client repeats the cycle "connect, receive one message from 
> the stream, disconnect". Soon the edge router core dumps with:
> {{(gdb) bt
> #0 get_pconnection (c=0x) at 
> /home/chug/git/qpid-proton/c/src/proactor/epoll.c:578
> #1 0x7fc8c0582a1c in pn_connection_wake (c=0x) at 
> /home/chug/git/qpid-proton/c/src/proactor/epoll.c:1439
> #2 0x7fc8c0668472 in connection_wake (ctx=0x1a43658) at 
> /home/chug/Downloads/qpid-dispatch-1.9.0/src/server.c:505
> #3 0x7fc8c066b2af in qd_server_activate (ctx=0x1a43658) at 
> /home/chug/Downloads/qpid-dispatch-1.9.0/src/server.c:1304
> #4 0x7fc8c064f3dd in qdr_activate_connections_CT (core=0x19c8ce0) at 
> /home/chug/Downloads/qpid-dispatch-1.9.0/src/router_core/router_core_thread.c:65
> #5 0x7fc8c064fa1d in router_core_thread (arg=0x19c8ce0) at 
> /home/chug/Downloads/qpid-dispatch-1.9.0/src/router_core/router_core_thread.c:171
> #6 0x7fc8c056258e in start_thread () from /usr/lib64/libpthread.so.0
> #7 0x7fc8c0201713 in clone () from /usr/lib64/libc.so.6
> (gdb) info threads
>  Id Target Id Frame 
> * 1 Thread 0x7fc8b1e44700 (LWP 21706) get_pconnection (c=0x) 
> at /home/chug/git/qpid-proton/c/src/proactor/epoll.c:578
>  2 Thread 0x7fc8bf8ff240 (LWP 21696) 0x7fc8c0201a47 in epoll_wait () from 
> /usr/lib64/libc.so.6
>  3 Thread 0x7fc8b0e42700 (LWP 21708) 0x7fc8c0201a47 in epoll_wait () from 
> /usr/lib64/libc.so.6
>  4 Thread 0x7fc8abfff700 (LWP 21709) 0x7fc8c0201a47 in epoll_wait () from 
> /usr/lib64/libc.so.6
>  5 Thread 0x7fc8b1643700 (LWP 21707) 0x7fc8c01f6481 in poll () from 
> /usr/lib64/libc.so.6
>  6 Thread 0x7fc8ab7fe700 (LWP 21710) 0x7fc8c0201a47 in epoll_wait () from 
> /usr/lib64/libc.so.6}}



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

[jira] [Created] (DISPATCH-1423) Multicast sender with no receiver has first 250 messages released

Chuck Rolke created DISPATCH-1423:
-

 Summary: Multicast sender with no receiver has first 250 messages 
released
 Key: DISPATCH-1423
 URL: https://issues.apache.org/jira/browse/DISPATCH-1423
 Project: Qpid Dispatch
  Issue Type: Bug
  Components: Routing Engine
Affects Versions: 1.8.0
Reporter: Chuck Rolke


When a sender starts and there's no receiver already attached then the first 
250 messages the sender sends get released. After that the router waits for the 
a receiver to attach before issuing more credit to the sender. The proton c++ 
simple_send and simple receive clients expose this problem.

1. Start router with attached config file
2. Start sender
simple_send -a 127.0.0.1:5672/multicast/q1 -m 500
3. Start receiver
   simple_recv -a 127.0.0.1:5672/multicast/q1 -m 500

The sender competes with 'all messages confirmed'.
The receiver is waiting for the second 250 messages.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

Re: [VOTE] Release Qpid Dispatch Router 1.9.0 (RC2)

2019-09-17 Thread Michael Goulish

+1

Two large-scale tests done, with no trouble.

Test 1

5 routers linear network (A...E)
500 senders on router A, 500 receivers on router E
1 unique address per client-pair
distribution : closest
senders throttled to 10 messages per second
non-pre-settled, 100 byte payload messages.
1e4 messages per sender.


Test 2
-
5 router linear network
500 receivers on E
each 50 receivers share 1 multicast address
10 senders on A, each with a unique multicast address
each sender will be sending to 50 receivers
100 byte payload msgs non-pre-settled
senders throttled to 10 messages per second
1e4 messages per sender

On Mon, Sep 16, 2019 at 2:17 PM Ganesh Murthy  wrote:

> Hello All,
>
>  Please cast your vote on this thread to release RC2 as the
> official Qpid Dispatch Router version  1.9.0.
>
> RC2 of Qpid Dispatch Router version 1.9.0 can be found here:
>
> https://dist.apache.org/repos/dist/dev/qpid/dispatch/1.9.0-rc2/
>
> The following improvements, and bug fixes are introduced in 1.9.0:
>
> Improvements -
> DISPATCH-480 - Default tests timeout is too short for some machines
> DISPATCH-1266 - Improve router's handling of unsettled multicast
> deliveries
> DISPATCH-1338 - Improvements to edge router documentation
> DISPATCH-1345 - Reduce the number of QDR_LINK_FLOW events by
> coalescing credit grants
> DISPATCH-1346 - Create documentation for priority delivery
> DISPATCH-1347 - Update documentation for Dispatch Router console
> DISPATCH-1350 - Update logging/monitoring documentation
> DISPATCH-1353 - Document how to configure access policy control on
> router-initiated connections
> DISPATCH-1354 - Interrouter annotation processing uses slow methods
> DISPATCH-1370 - Move the schema, connect, and entities tabs to the
> right in the console
> DISPATCH-1372 - alloc_pool intrusive linked list can be replaced
> by a linked stack
> DISPATCH-1374 - Add qdstat options --all-routers and all-entities
> which display statistics of all routers and displays all entities
> DISPATCH-1376 - Make it easier to change the product name in the
> console
> DISPATCH-1379 - Message receive performance improvements
> DISPATCH-1381 - Create documentation for configuring fallback
> destinations
> DISPATCH-1382 - Document ability to force-close a connection from
> the web console
> DISPATCH-1385 - qd_message_list_t is dead code
> DISPATCH-1388 - Authorization doc fails to describe vhost
> abstraction clearly
> DISPATCH-1396 - Doc how to start the router
>
> Bugs -
> DISPATCH-1359 - Set ctest timeout to 300 seconds.
> DISPATCH-1361 - system_tests_fallback_dest hanging in some cases
> DISPATCH-1362 - Shutdown crash when trying to clean up fallback
> addresses
> DISPATCH-1365 - Table of links with delayed deliveries is showing
> all endpoint links
> DISPATCH-1378 - missing lock of connection's links_with_work list
> DISPATCH-1380 - qdrouterd leaves dangling qd_link_t pointer
> DISPATCH-1383 - system_tests_policy is timing out
> DISPATCH-1387 - Coverity issues on master branch
> DISPATCH-1391 - Proton link reference not cleared on router link
> objects during session close
> DISPATCH-1394 - qd_check_message() incorrectly validates partially
> received messages
> DISPATCH-1398 - "Expression with no effect" warning for console web
> DISPATCH-1404 - message annotation parsing incorrectly uses
> ->remainder for current buffer capacity
> DISPATCH-1406 - Inter-router link stall on receive client failover
> DISPATCH-1407 - Memory leak on link policy denial
> DISPATCH-1408 - system_tests_distribution failing when running
> under valgrind
> DISPATCH-1410 - attach of auto-links not logged
> DISPATCH-1413 - system_tests_two_routers.py failing intermittently on
> Travis
> DISPATCH-1417 - Crash when connection_wake ctx points to freed memory
>
> Thanks.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
> For additional commands, e-mail: dev-h...@qpid.apache.org
>
>

[jira] [Created] (DISPATCH-1422) Add a global policy rejection count

Ganesh Murthy created DISPATCH-1422:
---

 Summary: Add a global policy rejection count 
 Key: DISPATCH-1422
 URL: https://issues.apache.org/jira/browse/DISPATCH-1422
 Project: Qpid Dispatch
  Issue Type: Improvement
  Components: Container
Affects Versions: 1.8.0
Reporter: Ganesh Murthy
Assignee: Chuck Rolke


Add a new policyRejectionCount attribute to the router entity that counts 
policy rejections across all connections. 



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

[GitHub] [qpid-dispatch] franz1981 closed pull request #528: DISPATCH-1375 qdr_general_work_t could be shrinked to increase cache localty

franz1981 closed pull request #528: DISPATCH-1375 qdr_general_work_t could be 
shrinked to increase cache localty
URL: https://github.com/apache/qpid-dispatch/pull/528
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[jira] [Commented] (DISPATCH-1375) qdr_general_work_t could be shrinked to increase cache localty



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

ASF GitHub Bot commented on DISPATCH-1375:
--

franz1981 commented on pull request #528: DISPATCH-1375 qdr_general_work_t 
could be shrinked to increase cache localty
URL: https://github.com/apache/qpid-dispatch/pull/528
 
 
   
 

This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> qdr_general_work_t could be shrinked to increase cache localty
> --
>
> Key: DISPATCH-1375
> URL: https://issues.apache.org/jira/browse/DISPATCH-1375
> Project: Qpid Dispatch
>  Issue Type: Improvement
>Affects Versions: 1.8.0
>Reporter: Francesco Nigro
>Priority: Minor
>
> qdr_general_work_t fields are not used altogether and could be packed into 
> different groups to reduce size: on an 64 bit machine I'm getting 112 -> 80 
> bytes size



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

[jira] [Created] (PROTON-2101) local-idle-timeout is detected but on_transport_error callback is not called

2019-09-17 Thread Bajan Fella (Jira)

Bajan Fella created PROTON-2101:
---

 Summary:  local-idle-timeout is detected but on_transport_error 
callback is not called
 Key: PROTON-2101
 URL: https://issues.apache.org/jira/browse/PROTON-2101
 Project: Qpid Proton
  Issue Type: Bug
  Components: cpp-binding, proton-c
Affects Versions: proton-c-0.29.0, proton-c-0.28.0, proton-c-0.27.1, 
proton-c-0.27.0, proton-c-0.26.0, proton-c-0.25.0
 Environment: Windows, 64-bit, TLS, Visual Studio 17 C++
Reporter: Bajan Fella
 Attachments: simple_recv.cpp

I am running 0.25 and I see an issue where the local-dle-timeout is being 
detected but the on_transport_error callback is not being called. As a result 
sometimes when my application experience temporary network issues it cannot 
recover. This is a release blocker for me. 

I have all my TRACE flags enabled and I am seeing

->[01661BD6BDF0]:ERROR amqp:resource-limit-exceeded local-idle-timeout 
expired

 ->[01661BD6BDF0]:0 -> @close(24) [error=@error(29) 
[condition=:"amqp:resource-limit-exceeded", description="local-idle-timeout 
expired"]]

When I caught this issue in the debugger I can see the PN_TRANSPORT_TAIL_CLOSED 
event but never receive the PN_TRANSPORT_CLOSED event.

To reproduce, I took the \qpid-proton-master\cpp\examples\simple_recv.cpp from 
the 0.29.0 repo and modified it so I can connect to my server which is setup 
for TLS.  Please see attached sample code.

Once I connect I then use Clumsy ([https://jagt.github.io/clumsy/index.html]) 
to slow down/throttle/drop some packets on the port. For example, if my server 
is listening on port pxxx at ipx.ipx.ipx.ipx. I use 

(((ip.DstAddr=ipx.ipx.ipx.ipx) and (tcp.DstPort=pxxx)) or 
((ip.SrcAddr=ipx.ipx.ipx.ipx) and (tcp.SrcPort=pxxx))) as a filter in Clumsy 
After a minute our so I get the expected output in the trace and netstat -ano | 
finsstr /c:pxxx shows that the TCP connection is closed but I did not receive a 
transport_error or transport_close

[018B6B046210]:0 -> (EMPTY FRAME)
[018B6B046210]:RAW: "\x00\x00\x00\x08\x02\x00\x00\x00"
[018B6B046210]:0 <- (EMPTY FRAME)
[018B6B046210]:0 <- (EMPTY FRAME)
[018B6B046210]:0 -> (EMPTY FRAME)
[018B6B046210]:RAW: "\x00\x00\x00\x08\x02\x00\x00\x00"
[018B6B046210]:0 -> (EMPTY FRAME)
[018B6B046210]:RAW: "\x00\x00\x00\x08\x02\x00\x00\x00"
[018B6B046210]:ERROR amqp:resource-limit-exceeded local-idle-timeout expired
[018B6B046210]:0 -> @close(24) [error=@error(29) 
[condition=:"amqp:resource-limit-exceeded", description="local-idle-timeout 
expired"]]
[018B6B046210]:RAW: 
"\x00\x00\x00Z\x02\x00\x00\x00\x00S\x18\xd0\x00\x00\x00J\x00\x00\x00\x01\x00S\x1d\xd0\x00\x00\x00>\x00\x00\x00\x02\xa3\x1camqp:resource-limit-exceeded\xa1\x1alocal-idle-timeout
 expired"

 



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

[GitHub] [qpid-broker-j] alex-rufous commented on issue #36: QPID-8361: [Broker-J] Create a developer guide for Qpid Broker-J

alex-rufous commented on issue #36: QPID-8361: [Broker-J] Create a developer 
guide for Qpid Broker-J
URL: https://github.com/apache/qpid-broker-j/pull/36#issuecomment-532226526
 
 
   Tomas,
   Thanks a lot for the review comments. I committed a second patch for the 
pull request addressing majority of your comments.
   
   > Reading would be easier if there will be table of contents for larger 
documents like High Level Architecture. Unfortunately MD format does not 
support TOC naturally, so maintaining would be more difficult. I think it is 
worth it, because chapters do not change too much.
   > 
   
   I generated TOC using markdown-toc utility. The TOCs can be regenerated with 
the script "toc-generator.sh" if required. I think it should be OK for now.
   
   > I suggest to improve High Level Architecture with
   > 
   > * exchange architecture
   
   I added some basic exchange overview. I am not sure that it will be useful. 
I think that every section in architecture document requires writing an extra 
chapter with details.
  
   > * transaction architecture
   I will add this separately.
   > 
   > * AMQP protocol error handling architecture
   AMQP protocol error handling requires improvements. I think writing it right 
now will generate more work for future.
   
   > 
   > I submitted review comments mostly for typos I noticed during reading the 
guide.
   I hope I addressed the majority of them.
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[jira] [Commented] (QPID-8361) [Broker-J] Create a developer guide for Qpid Broker-J



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

ASF GitHub Bot commented on QPID-8361:
--

alex-rufous commented on issue #36: QPID-8361: [Broker-J] Create a developer 
guide for Qpid Broker-J
URL: https://github.com/apache/qpid-broker-j/pull/36#issuecomment-532226526
 
 
   Tomas,
   Thanks a lot for the review comments. I committed a second patch for the 
pull request addressing majority of your comments.
   
   > Reading would be easier if there will be table of contents for larger 
documents like High Level Architecture. Unfortunately MD format does not 
support TOC naturally, so maintaining would be more difficult. I think it is 
worth it, because chapters do not change too much.
   > 
   
   I generated TOC using markdown-toc utility. The TOCs can be regenerated with 
the script "toc-generator.sh" if required. I think it should be OK for now.
   
   > I suggest to improve High Level Architecture with
   > 
   > * exchange architecture
   
   I added some basic exchange overview. I am not sure that it will be useful. 
I think that every section in architecture document requires writing an extra 
chapter with details.
  
   > * transaction architecture
   I will add this separately.
   > 
   > * AMQP protocol error handling architecture
   AMQP protocol error handling requires improvements. I think writing it right 
now will generate more work for future.
   
   > 
   > I submitted review comments mostly for typos I noticed during reading the 
guide.
   I hope I addressed the majority of them.
   
 

This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> [Broker-J] Create a developer guide for Qpid Broker-J
> -
>
> Key: QPID-8361
> URL: https://issues.apache.org/jira/browse/QPID-8361
> Project: Qpid
>  Issue Type: Task
>  Components: Broker-J
>Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-8.0.0
>
>
> The developer documentation is currently scattered over various Qpid 
> confluence pages. It could be challenging for people interested in 
> contributing to the project to find that documentation. A developer guide 
> could be added to cover such aspects as
> * Environment Setup
> * Building project
> * Running tests
> * Releasing
> * Architecture overview
> The following wiki pages are good candidates for inclusion into a developer 
> guide:
> [High Level 
> Architecture|https://cwiki.apache.org/confluence/display/qpid/High+Level+Architecture]
> [How To Build Qpid 
> Broker-J|https://cwiki.apache.org/confluence/display/qpid/How+To+Build+Qpid+Broker-J]
> [Releasing Qpid 
> Broker-J|https://cwiki.apache.org/confluence/display/qpid/Releasing+Qpid+Broker-J]
> The wiki pages below might be included as well
> [Java Coding 
> Standards|https://cwiki.apache.org/confluence/display/qpid/Java+Coding+Standards]
> [Qpid Java Run 
> Scripts|https://cwiki.apache.org/confluence/display/qpid/Qpid+Java+Run+Scripts]
> The developer documentation should be easy to modify, maintain and preview. 
> Thus, it can be written in  markdown or 
> [asciidoc|https://asciidoctor.org/docs/asciidoc-syntax-quick-reference/]. The 
> latter is also supported on github. 
> Potentially, it can be published on Qpid  project site as part of release 
> process.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

[jira] [Commented] (QPID-8361) [Broker-J] Create a developer guide for Qpid Broker-J

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

ASF GitHub Bot commented on QPID-8361:
--

alex-rufous commented on pull request #36: QPID-8361: [Broker-J] Create a
developer guide for Qpid Broker-J
URL: https://github.com/apache/qpid-broker-j/pull/36#discussion_r325167594

##
File path: doc/developer-guide/src/main/markdown/consumer-queue-interactions.md
##
@@ -0,0 +1,144 @@
+# Consumer-Queue Interactions
+
+This article overviews implementation behind interactions between consumers
and queue.
+
+The main players are
+
+ * Queue - model object providing the messaging queue functionality.
+* QueueConsumerManager - queue entity responsible for managing queue
consumers
+ * Consumers - queue consumers
+
+The `ConsumerTarget` is the broker-side representation of a consuming client.
Due to multi-queue consumers
+a `ConsumerTarget` has one or more `Consumers` associated with one `Queue`
each. It is this `Consumer` that
+interacts with the `Queue`.
+
+## Responsibilities
+
+A `Queue` is responsible for notification of at least one interested
`Consumer` when there is work to be done
+(message to consume).
+
+A `Consumer` is responsible for notification of its `Queue` when it is ready
to do some work (for example, consume messages).
+When notified by a `Queue` of available work, a `Consumer` MUST try to pull
messages of said `Queue` until either
+it notifies the `Queue` that it is no longer interested OR there are no more
messages available on the `Queue`
+(i.e., the Queue does not return a message).
+
+### Simple Example
+
+ 1. `Message` arrives on the `Queue`
+ 2. The `Queue` notifies some interested `Consumers` that there is work to be
done
+ 3. The `Consumers` notify their `ConsumerTarget` that they would like to do
work
+ 4. The `ConsumerTargets` notify their `Sessions` that they would like to do
work
+ 5. The `Sessions` notify their `Connections` that they would like to do work
+ 6. The `Connections` schedule themselves. This is the switch from the
incoming `Thread` to the `IO-Thread`.
+ 7. The `Scheduler` kicks off a IO-Thread to process the work of a `Connection`
+ 8. The `Connection` iterates over its `Sessions` that want to do work
+ 9. The `Sessions` iterate over its `ConsumerTargets` that want to do work
+ 10. The `ConsumerTargets` iterate over its `Consumers` that want to do work
+ 11. The Consumer tries to pulls a message from the `Queue`
+ 12. If successful the message is put on the IO-buffer to be sent down the wire
+
+### Threading Model
+
+The consuming part is always invoked from the consuming connection's IO-Thread
+whereas the publishing part might be invoked from different threads (producing
connection's IO-Thread,
+Housekeeping thread for held or TTLed messages, a consuming connection's
IO-Thread in case for message reject).
+
+Therefore, the interfaces between `Consumers` and the `Queue` MUST be
thread-safe and SHOULD be lock free.
+
+### Interfaces Between Consumers and Queues
+
+These are the interfaces between `Consumers` and `Queues` and the scenarios
when they are called.
+
+ * `AbstractQueue#setNotifyWorkDesired`
+Called by the `Consumer` to notify the `Queue` whether it is interested in
doing work or not.
+* FlowControl
+* Credit
+* TCP backpressure
+ * `QueueConsumer#notifyWork`
+Called by the `Queue` to notify the `Consumer` that there is potentially
work available.
+* Consumer becomes Interested
+* A new message arrives
+* A previously unavailable (acquired, held, blocked by message grouping)
message becomes available
+* A notified consumer did not do the work we expected it to do we need to
notify someone else
+* A high priority consumer becomes uninterested and thus allows a low
priority consumer to consume messages
+ * `AbstractQueue#deliverSingleMessage`
+Called by the `Consumer` to get a message from the Queue.
+* A consumer was notified and now tries to pull a message of a queue
+
+### QueueConsumerManager internals
+
+The `QueueConsumerManager` (QCM for short) keeps track of the state of
`Consumers` from the perspective of the `Queue`.
+It shares and decides which `Consumer` to notify of work with the `Queue`. To
do this in a performant way it maintains
+a number of lists and moves `Consumers` between those lists to indicate state
change. The lists it maintains are:
+
+ * All (all queue consumers)
+ * NonAcquiring
+ * NotInterested
+ * Interested
+ * Notified
+
+Typically we want these lists to be thread-safe and give us O(1)
access/deletion if we know the element and O(1) size information.
+Unfortunately there is no data structure in the Java standard library with
those characteristics
+which is why they are based on our own data structure `QueueConsumerNodeList`.
+
+ QueueConsumerNodeList
+
+The

[GitHub] [qpid-broker-j] alex-rufous commented on a change in pull request #36: QPID-8361: [Broker-J] Create a developer guide for Qpid Broker-J

alex-rufous commented on a change in pull request #36: QPID-8361: [Broker-J] 
Create a developer guide for Qpid Broker-J
URL: https://github.com/apache/qpid-broker-j/pull/36#discussion_r325167594
 
 

 ##
 File path: doc/developer-guide/src/main/markdown/consumer-queue-interactions.md
 ##
 @@ -0,0 +1,144 @@
+# Consumer-Queue Interactions
+
+This article overviews implementation behind interactions between consumers 
and queue.
+
+The main players are
+
+ * Queue - model object providing the messaging queue functionality.
+* QueueConsumerManager - queue entity responsible for managing queue 
consumers
+ * Consumers - queue consumers
+
+The `ConsumerTarget` is the broker-side representation of a consuming client. 
Due to multi-queue consumers
+a `ConsumerTarget` has one or more `Consumers` associated with one `Queue` 
each. It is this `Consumer` that
+interacts with the `Queue`.
+
+## Responsibilities
+
+A `Queue` is responsible for notification of at least one interested 
`Consumer` when there is work to be done
+(message to consume).
+
+A `Consumer` is responsible for notification of its `Queue` when it is ready 
to do some work (for example, consume messages).
+When notified by a `Queue` of available work, a `Consumer` MUST try to pull 
messages of said `Queue` until either
+it notifies the `Queue` that it is no longer interested OR there are no more 
messages available on the `Queue`
+(i.e., the Queue does not return a message).
+
+### Simple Example
+
+ 1. `Message` arrives on the `Queue`
+ 2. The `Queue` notifies some interested `Consumers` that there is work to be 
done
+ 3. The `Consumers` notify their `ConsumerTarget` that they would like to do 
work
+ 4. The `ConsumerTargets` notify their `Sessions` that they would like to do 
work
+ 5. The `Sessions` notify their `Connections` that they would like to do work
+ 6. The `Connections` schedule themselves. This is the switch from the 
incoming `Thread` to the `IO-Thread`.
+ 7. The `Scheduler` kicks off a IO-Thread to process the work of a `Connection`
+ 8. The `Connection` iterates over its `Sessions` that want to do work
+ 9. The `Sessions` iterate over its `ConsumerTargets` that want to do work
+ 10. The `ConsumerTargets` iterate over its `Consumers` that want to do work
+ 11. The Consumer tries to pulls a message from the `Queue`
+ 12. If successful the message is put on the IO-buffer to be sent down the wire
+
+### Threading Model
+
+The consuming part is always invoked from the consuming connection's IO-Thread
+whereas the publishing part might be invoked from different threads (producing 
connection's IO-Thread,
+Housekeeping thread for held or TTLed messages, a consuming connection's 
IO-Thread in case for message reject).
+
+Therefore, the interfaces between `Consumers` and the `Queue` MUST be 
thread-safe and SHOULD be lock free.
+
+### Interfaces Between Consumers and Queues
+
+These are the interfaces between `Consumers` and `Queues` and the scenarios 
when they are called.
+
+  * `AbstractQueue#setNotifyWorkDesired`
+Called by the `Consumer` to notify the `Queue` whether it is interested in 
doing work or not.
+* FlowControl
+* Credit
+* TCP backpressure
+  * `QueueConsumer#notifyWork`
+Called by the `Queue` to notify the `Consumer` that there is potentially 
work available.
+* Consumer becomes Interested
+* A new message arrives
+* A previously unavailable (acquired, held, blocked by message grouping) 
message becomes available
+* A notified consumer did not do the work we expected it to do we need to 
notify someone else
+* A high priority consumer becomes uninterested and thus allows a low 
priority consumer to consume messages
+  * `AbstractQueue#deliverSingleMessage`
+Called by the `Consumer` to get a message from the Queue.
+* A consumer was notified and now tries to pull a message of a queue
+
+### QueueConsumerManager internals
+
+The `QueueConsumerManager` (QCM for short) keeps track of the state of 
`Consumers` from the perspective of the `Queue`.
+It shares and decides which `Consumer` to notify of work with the `Queue`. To 
do this in a performant way it maintains
+a number of lists and moves `Consumers` between those lists to indicate state 
change. The lists it maintains are:
+
+  *  All (all queue consumers)
+  *  NonAcquiring
+  *  NotInterested
+  *  Interested
+  *  Notified
+
+Typically we want these lists to be thread-safe and give us O(1) 
access/deletion if we know the element and O(1) size information.
+Unfortunately there is no data structure in the Java standard library with 
those characteristics
+which is why they are based on our own data structure `QueueConsumerNodeList`.
+
+ QueueConsumerNodeList
+
+The `QueueConsumerNodeList` is the underlying data structure of all of QCM's 
lists.
+It is thread-safe and allows O(1) appending and given you have a pointer to an 
entry O(1) deletion.
+It is essentially a singly linked list. To achieve O(1)

[jira] [Commented] (QPID-8361) [Broker-J] Create a developer guide for Qpid Broker-J



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

ASF GitHub Bot commented on QPID-8361:
--

alex-rufous commented on pull request #36: QPID-8361: [Broker-J] Create a 
developer guide for Qpid Broker-J
URL: https://github.com/apache/qpid-broker-j/pull/36#discussion_r325164352
 
 

 ##
 File path: doc/developer-guide/src/main/markdown/index.md
 ##
 @@ -0,0 +1,26 @@
+# Qpid Broker-J Developer Guide
+
+This guide is intended for developers and contributors of Qpid Broker-J 
project to provide guidance and
+reference materials to aid them in development, building and releasing Qpid 
Broker-J.
+
+Each chapter in this guide is intended to be self-contained, so, the reader 
can jump to an interesting topic.
 
 Review comment:
   Done
 

This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> [Broker-J] Create a developer guide for Qpid Broker-J
> -
>
> Key: QPID-8361
> URL: https://issues.apache.org/jira/browse/QPID-8361
> Project: Qpid
>  Issue Type: Task
>  Components: Broker-J
>Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-8.0.0
>
>
> The developer documentation is currently scattered over various Qpid 
> confluence pages. It could be challenging for people interested in 
> contributing to the project to find that documentation. A developer guide 
> could be added to cover such aspects as
> * Environment Setup
> * Building project
> * Running tests
> * Releasing
> * Architecture overview
> The following wiki pages are good candidates for inclusion into a developer 
> guide:
> [High Level 
> Architecture|https://cwiki.apache.org/confluence/display/qpid/High+Level+Architecture]
> [How To Build Qpid 
> Broker-J|https://cwiki.apache.org/confluence/display/qpid/How+To+Build+Qpid+Broker-J]
> [Releasing Qpid 
> Broker-J|https://cwiki.apache.org/confluence/display/qpid/Releasing+Qpid+Broker-J]
> The wiki pages below might be included as well
> [Java Coding 
> Standards|https://cwiki.apache.org/confluence/display/qpid/Java+Coding+Standards]
> [Qpid Java Run 
> Scripts|https://cwiki.apache.org/confluence/display/qpid/Qpid+Java+Run+Scripts]
> The developer documentation should be easy to modify, maintain and preview. 
> Thus, it can be written in  markdown or 
> [asciidoc|https://asciidoctor.org/docs/asciidoc-syntax-quick-reference/]. The 
> latter is also supported on github. 
> Potentially, it can be published on Qpid  project site as part of release 
> process.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

[jira] [Commented] (QPID-8361) [Broker-J] Create a developer guide for Qpid Broker-J



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

ASF GitHub Bot commented on QPID-8361:
--

alex-rufous commented on pull request #36: QPID-8361: [Broker-J] Create a 
developer guide for Qpid Broker-J
URL: https://github.com/apache/qpid-broker-j/pull/36#discussion_r325164285
 
 

 ##
 File path: doc/developer-guide/src/main/markdown/index.md
 ##
 @@ -0,0 +1,26 @@
+# Qpid Broker-J Developer Guide
+
+This guide is intended for developers and contributors of Qpid Broker-J 
project to provide guidance and
+reference materials to aid them in development, building and releasing Qpid 
Broker-J.
 
 Review comment:
   Done
 

This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> [Broker-J] Create a developer guide for Qpid Broker-J
> -
>
> Key: QPID-8361
> URL: https://issues.apache.org/jira/browse/QPID-8361
> Project: Qpid
>  Issue Type: Task
>  Components: Broker-J
>Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-8.0.0
>
>
> The developer documentation is currently scattered over various Qpid 
> confluence pages. It could be challenging for people interested in 
> contributing to the project to find that documentation. A developer guide 
> could be added to cover such aspects as
> * Environment Setup
> * Building project
> * Running tests
> * Releasing
> * Architecture overview
> The following wiki pages are good candidates for inclusion into a developer 
> guide:
> [High Level 
> Architecture|https://cwiki.apache.org/confluence/display/qpid/High+Level+Architecture]
> [How To Build Qpid 
> Broker-J|https://cwiki.apache.org/confluence/display/qpid/How+To+Build+Qpid+Broker-J]
> [Releasing Qpid 
> Broker-J|https://cwiki.apache.org/confluence/display/qpid/Releasing+Qpid+Broker-J]
> The wiki pages below might be included as well
> [Java Coding 
> Standards|https://cwiki.apache.org/confluence/display/qpid/Java+Coding+Standards]
> [Qpid Java Run 
> Scripts|https://cwiki.apache.org/confluence/display/qpid/Qpid+Java+Run+Scripts]
> The developer documentation should be easy to modify, maintain and preview. 
> Thus, it can be written in  markdown or 
> [asciidoc|https://asciidoctor.org/docs/asciidoc-syntax-quick-reference/]. The 
> latter is also supported on github. 
> Potentially, it can be published on Qpid  project site as part of release 
> process.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

[jira] [Commented] (QPID-8361) [Broker-J] Create a developer guide for Qpid Broker-J



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

ASF GitHub Bot commented on QPID-8361:
--

alex-rufous commented on pull request #36: QPID-8361: [Broker-J] Create a 
developer guide for Qpid Broker-J
URL: https://github.com/apache/qpid-broker-j/pull/36#discussion_r325164143
 
 

 ##
 File path: doc/developer-guide/src/main/markdown/consumer-queue-interactions.md
 ##
 @@ -0,0 +1,144 @@
+# Consumer-Queue Interactions
+
+This article overviews implementation behind interactions between consumers 
and queue.
+
+The main players are
+
+ * Queue - model object providing the messaging queue functionality.
+* QueueConsumerManager - queue entity responsible for managing queue 
consumers
+ * Consumers - queue consumers
+
+The `ConsumerTarget` is the broker-side representation of a consuming client. 
Due to multi-queue consumers
+a `ConsumerTarget` has one or more `Consumers` associated with one `Queue` 
each. It is this `Consumer` that
+interacts with the `Queue`.
+
+## Responsibilities
+
+A `Queue` is responsible for notification of at least one interested 
`Consumer` when there is work to be done
+(message to consume).
+
+A `Consumer` is responsible for notification of its `Queue` when it is ready 
to do some work (for example, consume messages).
+When notified by a `Queue` of available work, a `Consumer` MUST try to pull 
messages of said `Queue` until either
+it notifies the `Queue` that it is no longer interested OR there are no more 
messages available on the `Queue`
+(i.e., the Queue does not return a message).
+
+### Simple Example
+
+ 1. `Message` arrives on the `Queue`
+ 2. The `Queue` notifies some interested `Consumers` that there is work to be 
done
 
 Review comment:
   Actually, the message could be delivered to only some of the queue 
consumers, especially,  in situations, where consumers with priorities are 
used. Thus, the message can go to  consumer with the higher priority.
 

This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> [Broker-J] Create a developer guide for Qpid Broker-J
> -
>
> Key: QPID-8361
> URL: https://issues.apache.org/jira/browse/QPID-8361
> Project: Qpid
>  Issue Type: Task
>  Components: Broker-J
>Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-8.0.0
>
>
> The developer documentation is currently scattered over various Qpid 
> confluence pages. It could be challenging for people interested in 
> contributing to the project to find that documentation. A developer guide 
> could be added to cover such aspects as
> * Environment Setup
> * Building project
> * Running tests
> * Releasing
> * Architecture overview
> The following wiki pages are good candidates for inclusion into a developer 
> guide:
> [High Level 
> Architecture|https://cwiki.apache.org/confluence/display/qpid/High+Level+Architecture]
> [How To Build Qpid 
> Broker-J|https://cwiki.apache.org/confluence/display/qpid/How+To+Build+Qpid+Broker-J]
> [Releasing Qpid 
> Broker-J|https://cwiki.apache.org/confluence/display/qpid/Releasing+Qpid+Broker-J]
> The wiki pages below might be included as well
> [Java Coding 
> Standards|https://cwiki.apache.org/confluence/display/qpid/Java+Coding+Standards]
> [Qpid Java Run 
> Scripts|https://cwiki.apache.org/confluence/display/qpid/Qpid+Java+Run+Scripts]
> The developer documentation should be easy to modify, maintain and preview. 
> Thus, it can be written in  markdown or 
> [asciidoc|https://asciidoctor.org/docs/asciidoc-syntax-quick-reference/]. The 
> latter is also supported on github. 
> Potentially, it can be published on Qpid  project site as part of release 
> process.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

[GitHub] [qpid-broker-j] alex-rufous commented on a change in pull request #36: QPID-8361: [Broker-J] Create a developer guide for Qpid Broker-J

alex-rufous commented on a change in pull request #36: QPID-8361: [Broker-J] 
Create a developer guide for Qpid Broker-J
URL: https://github.com/apache/qpid-broker-j/pull/36#discussion_r325164352
 
 

 ##
 File path: doc/developer-guide/src/main/markdown/index.md
 ##
 @@ -0,0 +1,26 @@
+# Qpid Broker-J Developer Guide
+
+This guide is intended for developers and contributors of Qpid Broker-J 
project to provide guidance and
+reference materials to aid them in development, building and releasing Qpid 
Broker-J.
+
+Each chapter in this guide is intended to be self-contained, so, the reader 
can jump to an interesting topic.
 
 Review comment:
   Done


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[GitHub] [qpid-broker-j] alex-rufous commented on a change in pull request #36: QPID-8361: [Broker-J] Create a developer guide for Qpid Broker-J

alex-rufous commented on a change in pull request #36: QPID-8361: [Broker-J] 
Create a developer guide for Qpid Broker-J
URL: https://github.com/apache/qpid-broker-j/pull/36#discussion_r325164285
 
 

 ##
 File path: doc/developer-guide/src/main/markdown/index.md
 ##
 @@ -0,0 +1,26 @@
+# Qpid Broker-J Developer Guide
+
+This guide is intended for developers and contributors of Qpid Broker-J 
project to provide guidance and
+reference materials to aid them in development, building and releasing Qpid 
Broker-J.
 
 Review comment:
   Done


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[GitHub] [qpid-broker-j] alex-rufous commented on a change in pull request #36: QPID-8361: [Broker-J] Create a developer guide for Qpid Broker-J

alex-rufous commented on a change in pull request #36: QPID-8361: [Broker-J] 
Create a developer guide for Qpid Broker-J
URL: https://github.com/apache/qpid-broker-j/pull/36#discussion_r325164143
 
 

 ##
 File path: doc/developer-guide/src/main/markdown/consumer-queue-interactions.md
 ##
 @@ -0,0 +1,144 @@
+# Consumer-Queue Interactions
+
+This article overviews implementation behind interactions between consumers 
and queue.
+
+The main players are
+
+ * Queue - model object providing the messaging queue functionality.
+* QueueConsumerManager - queue entity responsible for managing queue 
consumers
+ * Consumers - queue consumers
+
+The `ConsumerTarget` is the broker-side representation of a consuming client. 
Due to multi-queue consumers
+a `ConsumerTarget` has one or more `Consumers` associated with one `Queue` 
each. It is this `Consumer` that
+interacts with the `Queue`.
+
+## Responsibilities
+
+A `Queue` is responsible for notification of at least one interested 
`Consumer` when there is work to be done
+(message to consume).
+
+A `Consumer` is responsible for notification of its `Queue` when it is ready 
to do some work (for example, consume messages).
+When notified by a `Queue` of available work, a `Consumer` MUST try to pull 
messages of said `Queue` until either
+it notifies the `Queue` that it is no longer interested OR there are no more 
messages available on the `Queue`
+(i.e., the Queue does not return a message).
+
+### Simple Example
+
+ 1. `Message` arrives on the `Queue`
+ 2. The `Queue` notifies some interested `Consumers` that there is work to be 
done
 
 Review comment:
   Actually, the message could be delivered to only some of the queue 
consumers, especially,  in situations, where consumers with priorities are 
used. Thus, the message can go to  consumer with the higher priority.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[jira] [Commented] (QPID-8361) [Broker-J] Create a developer guide for Qpid Broker-J

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

ASF GitHub Bot commented on QPID-8361:
--

alex-rufous commented on pull request #36: QPID-8361: [Broker-J] Create a
developer guide for Qpid Broker-J
URL: https://github.com/apache/qpid-broker-j/pull/36#discussion_r325163203

##
File path: doc/developer-guide/src/main/markdown/architecture.md
##
@@ -0,0 +1,399 @@
+# High Level Architecture
+
+This article provides a high level description of the architecture of Qpid
Broker-J.
+
+Broker-J is messaging broker that implements the AMQP protocols (version 0-8,
0-9, 0-91, 0-10 and 1.0).
+Any AMQP compliant messaging library can be used with the Broker. The Broker
supports on the fly message translation
+from one AMQP protocol to another, meaning it is possible to use the Broker to
allow clients that use different
+AMQP protocol version to exchange messages. It can be managed over a built in
HTTP interface
+(that presents a REST API and a Web Management Console), or by AMQP Management
(early draft implementation).
+
+The Broker has a highly pluggable architecture that allows alternative
implementations to be substituted for any concern.
+For instance, you can simply build a module delegating to your own storage or
own authentication provider linking
+to your enterprise authentication backend.
+
+Broker-J is 100% pure Java. It can be run standalone or embedded within
another Java applications.
+
+## Model
+
+A tree of manageable categories, all of which extend of the interface
`ConfiguredObject`, underpin the `Broker`.
+A `ConfiguredObject` has zero or more attributes, zero or more children and
zero or more context variable name/value pairs.
+A `ConfiguredObject` may be persisted to a configuration store so its state
can be restored when the Broker is restarted.
+The manageable categories are arranged into a tree structure. `SystemConfig`
is at the root and has a single descendent
+`Broker`. The `Broker` itself has children: `Port`, `AuthenticationProvider`,
`VirtualHostNode` amongst others.
+`VirtualHostNode` has a child `VirtualHost`. The children of the
`VirtualHost` are categories that directly involved
+in messaging such as `Queue`. The diagram below illustrates the category
hierarchy but many categories are elided for brevity.
+The model tree structure is codified in the `BrokerModel` class.
+
+![Broker Model](images/model.png)
+
+## Category Specializations
+
+Some categories have specialisations. An example is the category `Queue`. It
has specialisations corresponding to
+the queue types supported by the `Broker` e.g. `StandardQueue`,
`PrirorityQueue` etc.
+
+### Attributes
+
+Each `ConfiguredObject` instance has zero or more attributes. Attributes
have a name and a value which can be
+a Java primitive value or an instance of any class for which an
`AttributeValueConverter` exist. This mechanism allows
+ attribute values to be `Lists`, `Sets`, `Maps`, or arbitrary structured types
`ManagedAttributeValues`.
+
+Attributes are marked up in the code with method annotations
`@ManagedAttribute` which defines things
+whether the attribute is mandatory or mutable. Attributes can also be marked
a secure which indicates restrictions
+ no how the attribute is used (used for attributes that that store passwords
or private-keys).
+
+Attributes can have default values. The default value applies if the user
omits to supply a value when the object
+is created. Defaults themselves can be defined in terms of `context variable`
references.
+
+### Context Variables
+
+Each `ConfiguredObject` instance has zero or more context variable
assignments. These are simply name/value pairs
+where both name and value are strings.
+
+When resolving an attribute's value, if the attribute's value (or attribute's
default) contains a context variable
+reference (e.g. `${foo}`), the variable is first resolved using the
`ConfiguredObject`'s own context variables.
+If the `ConfiguedObject` has no definition for the context variable, the
entity's parent is tried,
+then its grandparent and so forth, all the way until the `SystemContext` is
reached.
+If the `SystemContext` provides no value, the JVM's system properties are
consulted.
+
+A context variable's value can be defined in terms of other context variables.
+
+Context variables are useful for extracting environment specific information
from configuration for instance path stems
+or port numbers.
+
+## Lifecycle
+
+`ConfiguredObjects` have a lifecycle.
+
+A `ConfiguredObject` is created exactly once by a call its parent's
`#createChild()` method.
+This brings the object into existence. It goes through a number of phases
during creation (`ConfiguredObject#create`)
+
+ * resolution (where the attribute values are resolved and assigned to the
object)
+ * creation validation

[jira] [Commented] (QPID-8361) [Broker-J] Create a developer guide for Qpid Broker-J

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

ASF GitHub Bot commented on QPID-8361:
--

alex-rufous commented on pull request #36: QPID-8361: [Broker-J] Create a
developer guide for Qpid Broker-J
URL: https://github.com/apache/qpid-broker-j/pull/36#discussion_r325163108

[jira] [Commented] (QPID-8361) [Broker-J] Create a developer guide for Qpid Broker-J

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

ASF GitHub Bot commented on QPID-8361:
--

alex-rufous commented on pull request #36: QPID-8361: [Broker-J] Create a
developer guide for Qpid Broker-J
URL: https://github.com/apache/qpid-broker-j/pull/36#discussion_r325162693

[GitHub] [qpid-broker-j] alex-rufous commented on a change in pull request #36: QPID-8361: [Broker-J] Create a developer guide for Qpid Broker-J

alex-rufous commented on a change in pull request #36: QPID-8361: [Broker-J] 
Create a developer guide for Qpid Broker-J
URL: https://github.com/apache/qpid-broker-j/pull/36#discussion_r325163108
 
 

 ##
 File path: doc/developer-guide/src/main/markdown/architecture.md
 ##
 @@ -0,0 +1,399 @@
+# High Level Architecture
+
+This article provides a high level description of the architecture of Qpid 
Broker-J.
+
+Broker-J is messaging broker that implements the AMQP protocols (version 0-8, 
0-9, 0-91, 0-10 and 1.0).
+Any AMQP compliant messaging library can be used with the Broker. The Broker 
supports on the fly message translation
+from one AMQP protocol to another, meaning it is possible to use the Broker to 
allow clients that use different
+AMQP protocol version to exchange messages. It can be managed over a built in 
HTTP interface
+(that presents a REST API and a Web Management Console), or by AMQP Management 
(early draft implementation).
+
+The Broker has a highly pluggable architecture that allows alternative 
implementations to be substituted for any concern.
+For instance, you can simply build a module delegating to your own storage or 
own authentication provider linking
+to your enterprise authentication backend.
+
+Broker-J is 100% pure Java.  It can be run standalone or embedded within 
another Java applications.
+
+## Model
+
+A tree of manageable categories, all of which extend of the interface 
`ConfiguredObject`, underpin the `Broker`.
+A `ConfiguredObject` has zero or more attributes, zero or more children and 
zero or more context variable name/value pairs.
+A `ConfiguredObject` may be persisted to a configuration store so its state 
can be restored when the Broker is restarted.
+The manageable categories are arranged into a tree structure.  `SystemConfig` 
is at the root and has a single descendent
+`Broker`.  The `Broker` itself has children: `Port`, `AuthenticationProvider`, 
`VirtualHostNode` amongst others.
+`VirtualHostNode` has a child `VirtualHost`.  The children of the 
`VirtualHost` are categories that directly involved
+in messaging such as `Queue`. The diagram below illustrates the category 
hierarchy but many categories are elided for brevity.
+The model tree structure is codified in the `BrokerModel` class.
+
+![Broker Model](images/model.png)
+
+## Category Specializations
+
+Some categories have specialisations.  An example is the category `Queue`.  It 
has specialisations corresponding to
+the queue types supported by the `Broker` e.g. `StandardQueue`, 
`PrirorityQueue` etc.
+
+### Attributes
+
+Each `ConfiguredObject` instance has zero or more attributes.   Attributes 
have a name and a value which can be
+a Java primitive value or an instance of any class for which an 
`AttributeValueConverter` exist.  This mechanism allows
+ attribute values to be `Lists`, `Sets`, `Maps`, or arbitrary structured types 
`ManagedAttributeValues`.
+
+Attributes are marked up in the code with method annotations 
`@ManagedAttribute` which defines things
+whether the attribute is mandatory or mutable.  Attributes can also be marked 
a secure which indicates restrictions
+ no how the attribute is used (used for attributes that that store passwords 
or private-keys).
+
+Attributes can have default values. The default value applies if the user 
omits to supply a value when the object
+is created.  Defaults themselves can be defined in terms of `context variable` 
references.
+
+### Context Variables
+
+Each `ConfiguredObject` instance has zero or more context variable 
assignments. These are simply name/value pairs
+where both name and value are strings.
+
+When resolving an attribute's value, if the attribute's value (or attribute's 
default) contains a context variable
+reference (e.g. `${foo}`), the variable is first resolved using the 
`ConfiguredObject`'s own context variables.
+If the `ConfiguedObject` has no definition for the context variable, the 
entity's parent is tried,
+then its grandparent and so forth, all the way until the `SystemContext` is 
reached.
+If the `SystemContext` provides no value, the JVM's system properties are 
consulted.
+
+A context variable's value can be defined in terms of other context variables.
+
+Context variables are useful for extracting environment specific information 
from configuration for instance path stems
+or port numbers.
+
+## Lifecycle
+
+`ConfiguredObjects` have a lifecycle.
+
+A `ConfiguredObject` is created exactly once by a call its parent's 
`#createChild()` method.
+This brings the object into existence.  It goes through a number of phases 
during creation (`ConfiguredObject#create`)
+
+ * resolution (where the attribute values are resolved and assigned to the 
object)
+ * creation validation (ensuring business rules are adhered to)
+ * registration with parents
+ * implementation specific creation (`#onCreate`)
+ * implementation specific opening (`#onOpen`)
+
+When the `Broker` is restarted objects that exist in the

[GitHub] [qpid-broker-j] alex-rufous commented on a change in pull request #36: QPID-8361: [Broker-J] Create a developer guide for Qpid Broker-J

alex-rufous commented on a change in pull request #36: QPID-8361: [Broker-J] 
Create a developer guide for Qpid Broker-J
URL: https://github.com/apache/qpid-broker-j/pull/36#discussion_r325163203
 
 

 ##
 File path: doc/developer-guide/src/main/markdown/architecture.md
 ##
 @@ -0,0 +1,399 @@
+# High Level Architecture
+
+This article provides a high level description of the architecture of Qpid 
Broker-J.
+
+Broker-J is messaging broker that implements the AMQP protocols (version 0-8, 
0-9, 0-91, 0-10 and 1.0).
+Any AMQP compliant messaging library can be used with the Broker. The Broker 
supports on the fly message translation
+from one AMQP protocol to another, meaning it is possible to use the Broker to 
allow clients that use different
+AMQP protocol version to exchange messages. It can be managed over a built in 
HTTP interface
+(that presents a REST API and a Web Management Console), or by AMQP Management 
(early draft implementation).
+
+The Broker has a highly pluggable architecture that allows alternative 
implementations to be substituted for any concern.
+For instance, you can simply build a module delegating to your own storage or 
own authentication provider linking
+to your enterprise authentication backend.
+
+Broker-J is 100% pure Java.  It can be run standalone or embedded within 
another Java applications.
+
+## Model
+
+A tree of manageable categories, all of which extend of the interface 
`ConfiguredObject`, underpin the `Broker`.
+A `ConfiguredObject` has zero or more attributes, zero or more children and 
zero or more context variable name/value pairs.
+A `ConfiguredObject` may be persisted to a configuration store so its state 
can be restored when the Broker is restarted.
+The manageable categories are arranged into a tree structure.  `SystemConfig` 
is at the root and has a single descendent
+`Broker`.  The `Broker` itself has children: `Port`, `AuthenticationProvider`, 
`VirtualHostNode` amongst others.
+`VirtualHostNode` has a child `VirtualHost`.  The children of the 
`VirtualHost` are categories that directly involved
+in messaging such as `Queue`. The diagram below illustrates the category 
hierarchy but many categories are elided for brevity.
+The model tree structure is codified in the `BrokerModel` class.
+
+![Broker Model](images/model.png)
+
+## Category Specializations
+
+Some categories have specialisations.  An example is the category `Queue`.  It 
has specialisations corresponding to
+the queue types supported by the `Broker` e.g. `StandardQueue`, 
`PrirorityQueue` etc.
+
+### Attributes
+
+Each `ConfiguredObject` instance has zero or more attributes.   Attributes 
have a name and a value which can be
+a Java primitive value or an instance of any class for which an 
`AttributeValueConverter` exist.  This mechanism allows
+ attribute values to be `Lists`, `Sets`, `Maps`, or arbitrary structured types 
`ManagedAttributeValues`.
+
+Attributes are marked up in the code with method annotations 
`@ManagedAttribute` which defines things
+whether the attribute is mandatory or mutable.  Attributes can also be marked 
a secure which indicates restrictions
+ no how the attribute is used (used for attributes that that store passwords 
or private-keys).
+
+Attributes can have default values. The default value applies if the user 
omits to supply a value when the object
+is created.  Defaults themselves can be defined in terms of `context variable` 
references.
+
+### Context Variables
+
+Each `ConfiguredObject` instance has zero or more context variable 
assignments. These are simply name/value pairs
+where both name and value are strings.
+
+When resolving an attribute's value, if the attribute's value (or attribute's 
default) contains a context variable
+reference (e.g. `${foo}`), the variable is first resolved using the 
`ConfiguredObject`'s own context variables.
+If the `ConfiguedObject` has no definition for the context variable, the 
entity's parent is tried,
+then its grandparent and so forth, all the way until the `SystemContext` is 
reached.
+If the `SystemContext` provides no value, the JVM's system properties are 
consulted.
+
+A context variable's value can be defined in terms of other context variables.
+
+Context variables are useful for extracting environment specific information 
from configuration for instance path stems
+or port numbers.
+
+## Lifecycle
+
+`ConfiguredObjects` have a lifecycle.
+
+A `ConfiguredObject` is created exactly once by a call its parent's 
`#createChild()` method.
+This brings the object into existence.  It goes through a number of phases 
during creation (`ConfiguredObject#create`)
+
+ * resolution (where the attribute values are resolved and assigned to the 
object)
+ * creation validation (ensuring business rules are adhered to)
+ * registration with parents
+ * implementation specific creation (`#onCreate`)
+ * implementation specific opening (`#onOpen`)
+
+When the `Broker` is restarted objects that exist in the

[jira] [Commented] (QPID-8361) [Broker-J] Create a developer guide for Qpid Broker-J

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

ASF GitHub Bot commented on QPID-8361:
--

alex-rufous commented on pull request #36: QPID-8361: [Broker-J] Create a
developer guide for Qpid Broker-J
URL: https://github.com/apache/qpid-broker-j/pull/36#discussion_r325162130

[jira] [Commented] (QPID-8361) [Broker-J] Create a developer guide for Qpid Broker-J

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

ASF GitHub Bot commented on QPID-8361:
--

alex-rufous commented on pull request #36: QPID-8361: [Broker-J] Create a
developer guide for Qpid Broker-J
URL: https://github.com/apache/qpid-broker-j/pull/36#discussion_r325161989

[jira] [Commented] (QPID-8361) [Broker-J] Create a developer guide for Qpid Broker-J

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

ASF GitHub Bot commented on QPID-8361:
--

alex-rufous commented on pull request #36: QPID-8361: [Broker-J] Create a
developer guide for Qpid Broker-J
URL: https://github.com/apache/qpid-broker-j/pull/36#discussion_r325162489

[jira] [Commented] (QPID-8361) [Broker-J] Create a developer guide for Qpid Broker-J

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

ASF GitHub Bot commented on QPID-8361:
--

alex-rufous commented on pull request #36: QPID-8361: [Broker-J] Create a
developer guide for Qpid Broker-J
URL: https://github.com/apache/qpid-broker-j/pull/36#discussion_r325162048

[jira] [Commented] (QPID-8361) [Broker-J] Create a developer guide for Qpid Broker-J

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

ASF GitHub Bot commented on QPID-8361:
--

alex-rufous commented on pull request #36: QPID-8361: [Broker-J] Create a
developer guide for Qpid Broker-J
URL: https://github.com/apache/qpid-broker-j/pull/36#discussion_r325162398

[GitHub] [qpid-broker-j] alex-rufous commented on a change in pull request #36: QPID-8361: [Broker-J] Create a developer guide for Qpid Broker-J

alex-rufous commented on a change in pull request #36: QPID-8361: [Broker-J] 
Create a developer guide for Qpid Broker-J
URL: https://github.com/apache/qpid-broker-j/pull/36#discussion_r325162693
 
 

 ##
 File path: doc/developer-guide/src/main/markdown/architecture.md
 ##
 @@ -0,0 +1,399 @@
+# High Level Architecture
+
+This article provides a high level description of the architecture of Qpid 
Broker-J.
+
+Broker-J is messaging broker that implements the AMQP protocols (version 0-8, 
0-9, 0-91, 0-10 and 1.0).
+Any AMQP compliant messaging library can be used with the Broker. The Broker 
supports on the fly message translation
+from one AMQP protocol to another, meaning it is possible to use the Broker to 
allow clients that use different
+AMQP protocol version to exchange messages. It can be managed over a built in 
HTTP interface
+(that presents a REST API and a Web Management Console), or by AMQP Management 
(early draft implementation).
+
+The Broker has a highly pluggable architecture that allows alternative 
implementations to be substituted for any concern.
+For instance, you can simply build a module delegating to your own storage or 
own authentication provider linking
+to your enterprise authentication backend.
+
+Broker-J is 100% pure Java.  It can be run standalone or embedded within 
another Java applications.
+
+## Model
+
+A tree of manageable categories, all of which extend of the interface 
`ConfiguredObject`, underpin the `Broker`.
+A `ConfiguredObject` has zero or more attributes, zero or more children and 
zero or more context variable name/value pairs.
+A `ConfiguredObject` may be persisted to a configuration store so its state 
can be restored when the Broker is restarted.
+The manageable categories are arranged into a tree structure.  `SystemConfig` 
is at the root and has a single descendent
+`Broker`.  The `Broker` itself has children: `Port`, `AuthenticationProvider`, 
`VirtualHostNode` amongst others.
+`VirtualHostNode` has a child `VirtualHost`.  The children of the 
`VirtualHost` are categories that directly involved
+in messaging such as `Queue`. The diagram below illustrates the category 
hierarchy but many categories are elided for brevity.
+The model tree structure is codified in the `BrokerModel` class.
+
+![Broker Model](images/model.png)
+
+## Category Specializations
+
+Some categories have specialisations.  An example is the category `Queue`.  It 
has specialisations corresponding to
+the queue types supported by the `Broker` e.g. `StandardQueue`, 
`PrirorityQueue` etc.
+
+### Attributes
+
+Each `ConfiguredObject` instance has zero or more attributes.   Attributes 
have a name and a value which can be
+a Java primitive value or an instance of any class for which an 
`AttributeValueConverter` exist.  This mechanism allows
+ attribute values to be `Lists`, `Sets`, `Maps`, or arbitrary structured types 
`ManagedAttributeValues`.
+
+Attributes are marked up in the code with method annotations 
`@ManagedAttribute` which defines things
+whether the attribute is mandatory or mutable.  Attributes can also be marked 
a secure which indicates restrictions
+ no how the attribute is used (used for attributes that that store passwords 
or private-keys).
+
+Attributes can have default values. The default value applies if the user 
omits to supply a value when the object
+is created.  Defaults themselves can be defined in terms of `context variable` 
references.
+
+### Context Variables
+
+Each `ConfiguredObject` instance has zero or more context variable 
assignments. These are simply name/value pairs
+where both name and value are strings.
+
+When resolving an attribute's value, if the attribute's value (or attribute's 
default) contains a context variable
+reference (e.g. `${foo}`), the variable is first resolved using the 
`ConfiguredObject`'s own context variables.
+If the `ConfiguedObject` has no definition for the context variable, the 
entity's parent is tried,
+then its grandparent and so forth, all the way until the `SystemContext` is 
reached.
+If the `SystemContext` provides no value, the JVM's system properties are 
consulted.
+
+A context variable's value can be defined in terms of other context variables.
+
+Context variables are useful for extracting environment specific information 
from configuration for instance path stems
+or port numbers.
+
+## Lifecycle
+
+`ConfiguredObjects` have a lifecycle.
+
+A `ConfiguredObject` is created exactly once by a call its parent's 
`#createChild()` method.
+This brings the object into existence.  It goes through a number of phases 
during creation (`ConfiguredObject#create`)
+
+ * resolution (where the attribute values are resolved and assigned to the 
object)
+ * creation validation (ensuring business rules are adhered to)
+ * registration with parents
+ * implementation specific creation (`#onCreate`)
+ * implementation specific opening (`#onOpen`)
+
+When the `Broker` is restarted objects that exist in the

[jira] [Commented] (QPID-8361) [Broker-J] Create a developer guide for Qpid Broker-J

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

ASF GitHub Bot commented on QPID-8361:
--

alex-rufous commented on pull request #36: QPID-8361: [Broker-J] Create a
developer guide for Qpid Broker-J
URL: https://github.com/apache/qpid-broker-j/pull/36#discussion_r325162223

[GitHub] [qpid-broker-j] alex-rufous commented on a change in pull request #36: QPID-8361: [Broker-J] Create a developer guide for Qpid Broker-J

alex-rufous commented on a change in pull request #36: QPID-8361: [Broker-J] 
Create a developer guide for Qpid Broker-J
URL: https://github.com/apache/qpid-broker-j/pull/36#discussion_r325162489
 
 

 ##
 File path: doc/developer-guide/src/main/markdown/architecture.md
 ##
 @@ -0,0 +1,399 @@
+# High Level Architecture
+
+This article provides a high level description of the architecture of Qpid 
Broker-J.
+
+Broker-J is messaging broker that implements the AMQP protocols (version 0-8, 
0-9, 0-91, 0-10 and 1.0).
+Any AMQP compliant messaging library can be used with the Broker. The Broker 
supports on the fly message translation
+from one AMQP protocol to another, meaning it is possible to use the Broker to 
allow clients that use different
+AMQP protocol version to exchange messages. It can be managed over a built in 
HTTP interface
+(that presents a REST API and a Web Management Console), or by AMQP Management 
(early draft implementation).
+
+The Broker has a highly pluggable architecture that allows alternative 
implementations to be substituted for any concern.
+For instance, you can simply build a module delegating to your own storage or 
own authentication provider linking
+to your enterprise authentication backend.
+
+Broker-J is 100% pure Java.  It can be run standalone or embedded within 
another Java applications.
+
+## Model
+
+A tree of manageable categories, all of which extend of the interface 
`ConfiguredObject`, underpin the `Broker`.
+A `ConfiguredObject` has zero or more attributes, zero or more children and 
zero or more context variable name/value pairs.
+A `ConfiguredObject` may be persisted to a configuration store so its state 
can be restored when the Broker is restarted.
+The manageable categories are arranged into a tree structure.  `SystemConfig` 
is at the root and has a single descendent
+`Broker`.  The `Broker` itself has children: `Port`, `AuthenticationProvider`, 
`VirtualHostNode` amongst others.
+`VirtualHostNode` has a child `VirtualHost`.  The children of the 
`VirtualHost` are categories that directly involved
+in messaging such as `Queue`. The diagram below illustrates the category 
hierarchy but many categories are elided for brevity.
+The model tree structure is codified in the `BrokerModel` class.
+
+![Broker Model](images/model.png)
+
+## Category Specializations
+
+Some categories have specialisations.  An example is the category `Queue`.  It 
has specialisations corresponding to
+the queue types supported by the `Broker` e.g. `StandardQueue`, 
`PrirorityQueue` etc.
+
+### Attributes
+
+Each `ConfiguredObject` instance has zero or more attributes.   Attributes 
have a name and a value which can be
+a Java primitive value or an instance of any class for which an 
`AttributeValueConverter` exist.  This mechanism allows
+ attribute values to be `Lists`, `Sets`, `Maps`, or arbitrary structured types 
`ManagedAttributeValues`.
+
+Attributes are marked up in the code with method annotations 
`@ManagedAttribute` which defines things
+whether the attribute is mandatory or mutable.  Attributes can also be marked 
a secure which indicates restrictions
+ no how the attribute is used (used for attributes that that store passwords 
or private-keys).
+
+Attributes can have default values. The default value applies if the user 
omits to supply a value when the object
+is created.  Defaults themselves can be defined in terms of `context variable` 
references.
+
+### Context Variables
+
+Each `ConfiguredObject` instance has zero or more context variable 
assignments. These are simply name/value pairs
+where both name and value are strings.
+
+When resolving an attribute's value, if the attribute's value (or attribute's 
default) contains a context variable
+reference (e.g. `${foo}`), the variable is first resolved using the 
`ConfiguredObject`'s own context variables.
+If the `ConfiguedObject` has no definition for the context variable, the 
entity's parent is tried,
+then its grandparent and so forth, all the way until the `SystemContext` is 
reached.
+If the `SystemContext` provides no value, the JVM's system properties are 
consulted.
+
+A context variable's value can be defined in terms of other context variables.
+
+Context variables are useful for extracting environment specific information 
from configuration for instance path stems
+or port numbers.
+
+## Lifecycle
+
+`ConfiguredObjects` have a lifecycle.
+
+A `ConfiguredObject` is created exactly once by a call its parent's 
`#createChild()` method.
+This brings the object into existence.  It goes through a number of phases 
during creation (`ConfiguredObject#create`)
+
+ * resolution (where the attribute values are resolved and assigned to the 
object)
+ * creation validation (ensuring business rules are adhered to)
+ * registration with parents
+ * implementation specific creation (`#onCreate`)
+ * implementation specific opening (`#onOpen`)
+
+When the `Broker` is restarted objects that exist in the

[jira] [Commented] (QPID-8361) [Broker-J] Create a developer guide for Qpid Broker-J



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

ASF GitHub Bot commented on QPID-8361:
--

alex-rufous commented on pull request #36: QPID-8361: [Broker-J] Create a 
developer guide for Qpid Broker-J
URL: https://github.com/apache/qpid-broker-j/pull/36#discussion_r325161741
 
 

 ##
 File path: doc/developer-guide/src/main/markdown/build-instructions.md
 ##
 @@ -0,0 +1,290 @@
+# Build Instructions
+
+[Quick Start Guide](quick-start.md) only gives a minimum set of instructions 
to start quickly building and developing
+Qpid Broker-J code. The materials provided here intend to give a dipper 
understanding of various options for building,
+and testing Qpid Broker-J.
+
+## Prerequisites
+
+### Sources
+
+The Qpid project employs [Git distributed version-control 
system](https://git-scm.com) for tracking changes in source code.
+
+The Git repository can be found at 
.
+
+The mirror of Git repository exists on GitHub at 
.
+
+Changes need to be committed into Apache Git repository. They immediately get 
propagated into GitHub mirror.
+Only members of Qpid project with commit rights can commit the changes. The 
contributors without commit rights need
+to raise [Pull 
Request](https://help.github.com/en/articles/creating-a-pull-request) on GitHub 
in order to have
+their changes be committed by Qpid project committers.
+
+Git client is required to checkout sources from Git repo
+
+git clone https://gitbox.apache.org/repos/asf/qpid-broker-j.git 
qpid-broker-j
+
+For complete reference and documentation on Git please check [Git 
Book](https://git-scm.com/book/en/v2)
+
+### Maven
+
+Qpid Broker-J project uses [Maven](http://maven.apache.org/) as its build and 
management tool. Maven version 3 or above
+is required for building the project.
+
+You should set the `M2_HOME` environment variable and include its bin 
directory in your `PATH`.
+
+Check that maven is installed on your system by executing the following at 
your command prompt.
+
+mvn --version
+
+For full maven install instructions visit [Maven Installation 
Instructions](http://maven.apache.org/download.cgi#Installation).
+
+For complete reference and documentation on Maven please visit the following 
online resources.
+
+* [Apache Maven Project](http://maven.apache.org/)
+* [Maven: The Complete Reference by 
Sonatype](http://books.sonatype.com/mvnref-book/reference/public-book.html)
+
+
+### Java
+
+The build requires a Java 8 or later. You should set the `JAVA_HOME` 
environment variable and include its bin directory
+in your `PATH`.
+
+Check java version by executing the following at your command prompt.
+
+java -version
+
+## Project structure
+
+Qpid Broker-J consists of a number of modules and sub-modules located in their 
own directories. Each Qpid Broker-J module
+has its own POM file (pom.xml) located in its root directory. This file 
defines the modules version, dependencies and
+project inheritance as well as the configuration of the relative maven plugins 
specific to this module.
+The Qpid Broker-J parent pom.xml is located in the root of the project and 
declares all qpid modules, dependencies,
+plugins, etc.
+
+## Building
+
+The project is built by executing maven command in conjunction with 
pre-defined profiles. For example, the command below
+cleans previous build output and install all modules to local repository 
without running the tests:
+
+mvn clean install -DskipTests
+
+The following command installs all modules to the local repository after 
running all the tests:
+
+mvn clean install
+
+### Maven Commands
+
+Here is a quick reference guide outlining some of the maven commands you can 
run and what the outcome will be.
+
+Please visit [Introduction To The Maven 
Lifecycle](https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html)
+reference guide for full details on all the maven lifecycle phases.
+
+|  Command  | Description  | Notes 
 |
+|---|:-|:---|
+| mvn clean | removes all the files created by the previous build  
|Usually means it deletes the contents of the modules `*/target/` directory.|
+| mvn validate  | validates that the maven poms are all correct and that no 
config is missing | Useful to run when making build modifications to ensure 
consistency.|
+| mvn compile   | compiles the source code of the project | This will verify 
that project dependencies are correct.|
+| mvn test  | executes the unit tests | Should not rely on code being 
packaged or deployed, only unit tests.|
+| mvn package   | packages the code into the its distributable

[GitHub] [qpid-broker-j] alex-rufous commented on a change in pull request #36: QPID-8361: [Broker-J] Create a developer guide for Qpid Broker-J

alex-rufous commented on a change in pull request #36: QPID-8361: [Broker-J] 
Create a developer guide for Qpid Broker-J
URL: https://github.com/apache/qpid-broker-j/pull/36#discussion_r325162048
 
 

 ##
 File path: doc/developer-guide/src/main/markdown/architecture.md
 ##
 @@ -0,0 +1,399 @@
+# High Level Architecture
+
+This article provides a high level description of the architecture of Qpid 
Broker-J.
+
+Broker-J is messaging broker that implements the AMQP protocols (version 0-8, 
0-9, 0-91, 0-10 and 1.0).
+Any AMQP compliant messaging library can be used with the Broker. The Broker 
supports on the fly message translation
+from one AMQP protocol to another, meaning it is possible to use the Broker to 
allow clients that use different
+AMQP protocol version to exchange messages. It can be managed over a built in 
HTTP interface
+(that presents a REST API and a Web Management Console), or by AMQP Management 
(early draft implementation).
+
+The Broker has a highly pluggable architecture that allows alternative 
implementations to be substituted for any concern.
+For instance, you can simply build a module delegating to your own storage or 
own authentication provider linking
+to your enterprise authentication backend.
+
+Broker-J is 100% pure Java.  It can be run standalone or embedded within 
another Java applications.
+
+## Model
+
+A tree of manageable categories, all of which extend of the interface 
`ConfiguredObject`, underpin the `Broker`.
+A `ConfiguredObject` has zero or more attributes, zero or more children and 
zero or more context variable name/value pairs.
+A `ConfiguredObject` may be persisted to a configuration store so its state 
can be restored when the Broker is restarted.
+The manageable categories are arranged into a tree structure.  `SystemConfig` 
is at the root and has a single descendent
+`Broker`.  The `Broker` itself has children: `Port`, `AuthenticationProvider`, 
`VirtualHostNode` amongst others.
+`VirtualHostNode` has a child `VirtualHost`.  The children of the 
`VirtualHost` are categories that directly involved
+in messaging such as `Queue`. The diagram below illustrates the category 
hierarchy but many categories are elided for brevity.
+The model tree structure is codified in the `BrokerModel` class.
+
+![Broker Model](images/model.png)
+
+## Category Specializations
+
+Some categories have specialisations.  An example is the category `Queue`.  It 
has specialisations corresponding to
+the queue types supported by the `Broker` e.g. `StandardQueue`, 
`PrirorityQueue` etc.
+
+### Attributes
+
+Each `ConfiguredObject` instance has zero or more attributes.   Attributes 
have a name and a value which can be
+a Java primitive value or an instance of any class for which an 
`AttributeValueConverter` exist.  This mechanism allows
+ attribute values to be `Lists`, `Sets`, `Maps`, or arbitrary structured types 
`ManagedAttributeValues`.
+
+Attributes are marked up in the code with method annotations 
`@ManagedAttribute` which defines things
+whether the attribute is mandatory or mutable.  Attributes can also be marked 
a secure which indicates restrictions
+ no how the attribute is used (used for attributes that that store passwords 
or private-keys).
+
+Attributes can have default values. The default value applies if the user 
omits to supply a value when the object
+is created.  Defaults themselves can be defined in terms of `context variable` 
references.
+
+### Context Variables
+
+Each `ConfiguredObject` instance has zero or more context variable 
assignments. These are simply name/value pairs
+where both name and value are strings.
+
+When resolving an attribute's value, if the attribute's value (or attribute's 
default) contains a context variable
+reference (e.g. `${foo}`), the variable is first resolved using the 
`ConfiguredObject`'s own context variables.
+If the `ConfiguedObject` has no definition for the context variable, the 
entity's parent is tried,
+then its grandparent and so forth, all the way until the `SystemContext` is 
reached.
+If the `SystemContext` provides no value, the JVM's system properties are 
consulted.
+
+A context variable's value can be defined in terms of other context variables.
+
+Context variables are useful for extracting environment specific information 
from configuration for instance path stems
+or port numbers.
+
+## Lifecycle
+
+`ConfiguredObjects` have a lifecycle.
+
+A `ConfiguredObject` is created exactly once by a call its parent's 
`#createChild()` method.
+This brings the object into existence.  It goes through a number of phases 
during creation (`ConfiguredObject#create`)
+
+ * resolution (where the attribute values are resolved and assigned to the 
object)
+ * creation validation (ensuring business rules are adhered to)
+ * registration with parents
+ * implementation specific creation (`#onCreate`)
+ * implementation specific opening (`#onOpen`)
+
+When the `Broker` is restarted objects that exist in the

[GitHub] [qpid-broker-j] alex-rufous commented on a change in pull request #36: QPID-8361: [Broker-J] Create a developer guide for Qpid Broker-J

alex-rufous commented on a change in pull request #36: QPID-8361: [Broker-J] 
Create a developer guide for Qpid Broker-J
URL: https://github.com/apache/qpid-broker-j/pull/36#discussion_r325162223
 
 

 ##
 File path: doc/developer-guide/src/main/markdown/architecture.md
 ##
 @@ -0,0 +1,399 @@
+# High Level Architecture
+
+This article provides a high level description of the architecture of Qpid 
Broker-J.
+
+Broker-J is messaging broker that implements the AMQP protocols (version 0-8, 
0-9, 0-91, 0-10 and 1.0).
+Any AMQP compliant messaging library can be used with the Broker. The Broker 
supports on the fly message translation
+from one AMQP protocol to another, meaning it is possible to use the Broker to 
allow clients that use different
+AMQP protocol version to exchange messages. It can be managed over a built in 
HTTP interface
+(that presents a REST API and a Web Management Console), or by AMQP Management 
(early draft implementation).
+
+The Broker has a highly pluggable architecture that allows alternative 
implementations to be substituted for any concern.
+For instance, you can simply build a module delegating to your own storage or 
own authentication provider linking
+to your enterprise authentication backend.
+
+Broker-J is 100% pure Java.  It can be run standalone or embedded within 
another Java applications.
+
+## Model
+
+A tree of manageable categories, all of which extend of the interface 
`ConfiguredObject`, underpin the `Broker`.
+A `ConfiguredObject` has zero or more attributes, zero or more children and 
zero or more context variable name/value pairs.
+A `ConfiguredObject` may be persisted to a configuration store so its state 
can be restored when the Broker is restarted.
+The manageable categories are arranged into a tree structure.  `SystemConfig` 
is at the root and has a single descendent
+`Broker`.  The `Broker` itself has children: `Port`, `AuthenticationProvider`, 
`VirtualHostNode` amongst others.
+`VirtualHostNode` has a child `VirtualHost`.  The children of the 
`VirtualHost` are categories that directly involved
+in messaging such as `Queue`. The diagram below illustrates the category 
hierarchy but many categories are elided for brevity.
+The model tree structure is codified in the `BrokerModel` class.
+
+![Broker Model](images/model.png)
+
+## Category Specializations
+
+Some categories have specialisations.  An example is the category `Queue`.  It 
has specialisations corresponding to
+the queue types supported by the `Broker` e.g. `StandardQueue`, 
`PrirorityQueue` etc.
+
+### Attributes
+
+Each `ConfiguredObject` instance has zero or more attributes.   Attributes 
have a name and a value which can be
+a Java primitive value or an instance of any class for which an 
`AttributeValueConverter` exist.  This mechanism allows
+ attribute values to be `Lists`, `Sets`, `Maps`, or arbitrary structured types 
`ManagedAttributeValues`.
+
+Attributes are marked up in the code with method annotations 
`@ManagedAttribute` which defines things
+whether the attribute is mandatory or mutable.  Attributes can also be marked 
a secure which indicates restrictions
+ no how the attribute is used (used for attributes that that store passwords 
or private-keys).
+
+Attributes can have default values. The default value applies if the user 
omits to supply a value when the object
+is created.  Defaults themselves can be defined in terms of `context variable` 
references.
+
+### Context Variables
+
+Each `ConfiguredObject` instance has zero or more context variable 
assignments. These are simply name/value pairs
+where both name and value are strings.
+
+When resolving an attribute's value, if the attribute's value (or attribute's 
default) contains a context variable
+reference (e.g. `${foo}`), the variable is first resolved using the 
`ConfiguredObject`'s own context variables.
+If the `ConfiguedObject` has no definition for the context variable, the 
entity's parent is tried,
+then its grandparent and so forth, all the way until the `SystemContext` is 
reached.
+If the `SystemContext` provides no value, the JVM's system properties are 
consulted.
+
+A context variable's value can be defined in terms of other context variables.
+
+Context variables are useful for extracting environment specific information 
from configuration for instance path stems
+or port numbers.
+
+## Lifecycle
+
+`ConfiguredObjects` have a lifecycle.
+
+A `ConfiguredObject` is created exactly once by a call its parent's 
`#createChild()` method.
+This brings the object into existence.  It goes through a number of phases 
during creation (`ConfiguredObject#create`)
+
+ * resolution (where the attribute values are resolved and assigned to the 
object)
+ * creation validation (ensuring business rules are adhered to)
+ * registration with parents
+ * implementation specific creation (`#onCreate`)
+ * implementation specific opening (`#onOpen`)
+
+When the `Broker` is restarted objects that exist in the

[GitHub] [qpid-broker-j] alex-rufous commented on a change in pull request #36: QPID-8361: [Broker-J] Create a developer guide for Qpid Broker-J

alex-rufous commented on a change in pull request #36: QPID-8361: [Broker-J] 
Create a developer guide for Qpid Broker-J
URL: https://github.com/apache/qpid-broker-j/pull/36#discussion_r325162398
 
 

 ##
 File path: doc/developer-guide/src/main/markdown/architecture.md
 ##
 @@ -0,0 +1,399 @@
+# High Level Architecture
+
+This article provides a high level description of the architecture of Qpid 
Broker-J.
+
+Broker-J is messaging broker that implements the AMQP protocols (version 0-8, 
0-9, 0-91, 0-10 and 1.0).
+Any AMQP compliant messaging library can be used with the Broker. The Broker 
supports on the fly message translation
+from one AMQP protocol to another, meaning it is possible to use the Broker to 
allow clients that use different
+AMQP protocol version to exchange messages. It can be managed over a built in 
HTTP interface
+(that presents a REST API and a Web Management Console), or by AMQP Management 
(early draft implementation).
+
+The Broker has a highly pluggable architecture that allows alternative 
implementations to be substituted for any concern.
+For instance, you can simply build a module delegating to your own storage or 
own authentication provider linking
+to your enterprise authentication backend.
+
+Broker-J is 100% pure Java.  It can be run standalone or embedded within 
another Java applications.
+
+## Model
+
+A tree of manageable categories, all of which extend of the interface 
`ConfiguredObject`, underpin the `Broker`.
+A `ConfiguredObject` has zero or more attributes, zero or more children and 
zero or more context variable name/value pairs.
+A `ConfiguredObject` may be persisted to a configuration store so its state 
can be restored when the Broker is restarted.
+The manageable categories are arranged into a tree structure.  `SystemConfig` 
is at the root and has a single descendent
+`Broker`.  The `Broker` itself has children: `Port`, `AuthenticationProvider`, 
`VirtualHostNode` amongst others.
+`VirtualHostNode` has a child `VirtualHost`.  The children of the 
`VirtualHost` are categories that directly involved
+in messaging such as `Queue`. The diagram below illustrates the category 
hierarchy but many categories are elided for brevity.
+The model tree structure is codified in the `BrokerModel` class.
+
+![Broker Model](images/model.png)
+
+## Category Specializations
+
+Some categories have specialisations.  An example is the category `Queue`.  It 
has specialisations corresponding to
+the queue types supported by the `Broker` e.g. `StandardQueue`, 
`PrirorityQueue` etc.
+
+### Attributes
+
+Each `ConfiguredObject` instance has zero or more attributes.   Attributes 
have a name and a value which can be
+a Java primitive value or an instance of any class for which an 
`AttributeValueConverter` exist.  This mechanism allows
+ attribute values to be `Lists`, `Sets`, `Maps`, or arbitrary structured types 
`ManagedAttributeValues`.
+
+Attributes are marked up in the code with method annotations 
`@ManagedAttribute` which defines things
+whether the attribute is mandatory or mutable.  Attributes can also be marked 
a secure which indicates restrictions
+ no how the attribute is used (used for attributes that that store passwords 
or private-keys).
+
+Attributes can have default values. The default value applies if the user 
omits to supply a value when the object
+is created.  Defaults themselves can be defined in terms of `context variable` 
references.
+
+### Context Variables
+
+Each `ConfiguredObject` instance has zero or more context variable 
assignments. These are simply name/value pairs
+where both name and value are strings.
+
+When resolving an attribute's value, if the attribute's value (or attribute's 
default) contains a context variable
+reference (e.g. `${foo}`), the variable is first resolved using the 
`ConfiguredObject`'s own context variables.
+If the `ConfiguedObject` has no definition for the context variable, the 
entity's parent is tried,
+then its grandparent and so forth, all the way until the `SystemContext` is 
reached.
+If the `SystemContext` provides no value, the JVM's system properties are 
consulted.
+
+A context variable's value can be defined in terms of other context variables.
+
+Context variables are useful for extracting environment specific information 
from configuration for instance path stems
+or port numbers.
+
+## Lifecycle
+
+`ConfiguredObjects` have a lifecycle.
+
+A `ConfiguredObject` is created exactly once by a call its parent's 
`#createChild()` method.
+This brings the object into existence.  It goes through a number of phases 
during creation (`ConfiguredObject#create`)
+
+ * resolution (where the attribute values are resolved and assigned to the 
object)
+ * creation validation (ensuring business rules are adhered to)
+ * registration with parents
+ * implementation specific creation (`#onCreate`)
+ * implementation specific opening (`#onOpen`)
+
+When the `Broker` is restarted objects that exist in the

[GitHub] [qpid-broker-j] alex-rufous commented on a change in pull request #36: QPID-8361: [Broker-J] Create a developer guide for Qpid Broker-J

alex-rufous commented on a change in pull request #36: QPID-8361: [Broker-J] 
Create a developer guide for Qpid Broker-J
URL: https://github.com/apache/qpid-broker-j/pull/36#discussion_r325161989
 
 

 ##
 File path: doc/developer-guide/src/main/markdown/architecture.md
 ##
 @@ -0,0 +1,399 @@
+# High Level Architecture
+
+This article provides a high level description of the architecture of Qpid 
Broker-J.
+
+Broker-J is messaging broker that implements the AMQP protocols (version 0-8, 
0-9, 0-91, 0-10 and 1.0).
+Any AMQP compliant messaging library can be used with the Broker. The Broker 
supports on the fly message translation
+from one AMQP protocol to another, meaning it is possible to use the Broker to 
allow clients that use different
+AMQP protocol version to exchange messages. It can be managed over a built in 
HTTP interface
+(that presents a REST API and a Web Management Console), or by AMQP Management 
(early draft implementation).
+
+The Broker has a highly pluggable architecture that allows alternative 
implementations to be substituted for any concern.
+For instance, you can simply build a module delegating to your own storage or 
own authentication provider linking
+to your enterprise authentication backend.
+
+Broker-J is 100% pure Java.  It can be run standalone or embedded within 
another Java applications.
+
+## Model
+
+A tree of manageable categories, all of which extend of the interface 
`ConfiguredObject`, underpin the `Broker`.
+A `ConfiguredObject` has zero or more attributes, zero or more children and 
zero or more context variable name/value pairs.
+A `ConfiguredObject` may be persisted to a configuration store so its state 
can be restored when the Broker is restarted.
+The manageable categories are arranged into a tree structure.  `SystemConfig` 
is at the root and has a single descendent
+`Broker`.  The `Broker` itself has children: `Port`, `AuthenticationProvider`, 
`VirtualHostNode` amongst others.
+`VirtualHostNode` has a child `VirtualHost`.  The children of the 
`VirtualHost` are categories that directly involved
+in messaging such as `Queue`. The diagram below illustrates the category 
hierarchy but many categories are elided for brevity.
+The model tree structure is codified in the `BrokerModel` class.
+
+![Broker Model](images/model.png)
+
+## Category Specializations
+
+Some categories have specialisations.  An example is the category `Queue`.  It 
has specialisations corresponding to
+the queue types supported by the `Broker` e.g. `StandardQueue`, 
`PrirorityQueue` etc.
+
+### Attributes
+
+Each `ConfiguredObject` instance has zero or more attributes.   Attributes 
have a name and a value which can be
+a Java primitive value or an instance of any class for which an 
`AttributeValueConverter` exist.  This mechanism allows
+ attribute values to be `Lists`, `Sets`, `Maps`, or arbitrary structured types 
`ManagedAttributeValues`.
+
+Attributes are marked up in the code with method annotations 
`@ManagedAttribute` which defines things
+whether the attribute is mandatory or mutable.  Attributes can also be marked 
a secure which indicates restrictions
+ no how the attribute is used (used for attributes that that store passwords 
or private-keys).
+
+Attributes can have default values. The default value applies if the user 
omits to supply a value when the object
+is created.  Defaults themselves can be defined in terms of `context variable` 
references.
+
+### Context Variables
+
+Each `ConfiguredObject` instance has zero or more context variable 
assignments. These are simply name/value pairs
+where both name and value are strings.
+
+When resolving an attribute's value, if the attribute's value (or attribute's 
default) contains a context variable
+reference (e.g. `${foo}`), the variable is first resolved using the 
`ConfiguredObject`'s own context variables.
+If the `ConfiguedObject` has no definition for the context variable, the 
entity's parent is tried,
+then its grandparent and so forth, all the way until the `SystemContext` is 
reached.
+If the `SystemContext` provides no value, the JVM's system properties are 
consulted.
+
+A context variable's value can be defined in terms of other context variables.
+
+Context variables are useful for extracting environment specific information 
from configuration for instance path stems
+or port numbers.
+
+## Lifecycle
+
+`ConfiguredObjects` have a lifecycle.
+
+A `ConfiguredObject` is created exactly once by a call its parent's 
`#createChild()` method.
+This brings the object into existence.  It goes through a number of phases 
during creation (`ConfiguredObject#create`)
+
+ * resolution (where the attribute values are resolved and assigned to the 
object)
+ * creation validation (ensuring business rules are adhered to)
+ * registration with parents
+ * implementation specific creation (`#onCreate`)
+ * implementation specific opening (`#onOpen`)
+
+When the `Broker` is restarted objects that exist in the

[jira] [Commented] (QPID-8361) [Broker-J] Create a developer guide for Qpid Broker-J



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

ASF GitHub Bot commented on QPID-8361:
--

alex-rufous commented on pull request #36: QPID-8361: [Broker-J] Create a 
developer guide for Qpid Broker-J
URL: https://github.com/apache/qpid-broker-j/pull/36#discussion_r325161816
 
 

 ##
 File path: doc/developer-guide/src/main/markdown/architecture.md
 ##
 @@ -0,0 +1,399 @@
+# High Level Architecture
+
+This article provides a high level description of the architecture of Qpid 
Broker-J.
+
+Broker-J is messaging broker that implements the AMQP protocols (version 0-8, 
0-9, 0-91, 0-10 and 1.0).
+Any AMQP compliant messaging library can be used with the Broker. The Broker 
supports on the fly message translation
+from one AMQP protocol to another, meaning it is possible to use the Broker to 
allow clients that use different
+AMQP protocol version to exchange messages. It can be managed over a built in 
HTTP interface
+(that presents a REST API and a Web Management Console), or by AMQP Management 
(early draft implementation).
 
 Review comment:
   Fixed
 

This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> [Broker-J] Create a developer guide for Qpid Broker-J
> -
>
> Key: QPID-8361
> URL: https://issues.apache.org/jira/browse/QPID-8361
> Project: Qpid
>  Issue Type: Task
>  Components: Broker-J
>Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-8.0.0
>
>
> The developer documentation is currently scattered over various Qpid 
> confluence pages. It could be challenging for people interested in 
> contributing to the project to find that documentation. A developer guide 
> could be added to cover such aspects as
> * Environment Setup
> * Building project
> * Running tests
> * Releasing
> * Architecture overview
> The following wiki pages are good candidates for inclusion into a developer 
> guide:
> [High Level 
> Architecture|https://cwiki.apache.org/confluence/display/qpid/High+Level+Architecture]
> [How To Build Qpid 
> Broker-J|https://cwiki.apache.org/confluence/display/qpid/How+To+Build+Qpid+Broker-J]
> [Releasing Qpid 
> Broker-J|https://cwiki.apache.org/confluence/display/qpid/Releasing+Qpid+Broker-J]
> The wiki pages below might be included as well
> [Java Coding 
> Standards|https://cwiki.apache.org/confluence/display/qpid/Java+Coding+Standards]
> [Qpid Java Run 
> Scripts|https://cwiki.apache.org/confluence/display/qpid/Qpid+Java+Run+Scripts]
> The developer documentation should be easy to modify, maintain and preview. 
> Thus, it can be written in  markdown or 
> [asciidoc|https://asciidoctor.org/docs/asciidoc-syntax-quick-reference/]. The 
> latter is also supported on github. 
> Potentially, it can be published on Qpid  project site as part of release 
> process.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

[GitHub] [qpid-broker-j] alex-rufous commented on a change in pull request #36: QPID-8361: [Broker-J] Create a developer guide for Qpid Broker-J

alex-rufous commented on a change in pull request #36: QPID-8361: [Broker-J] 
Create a developer guide for Qpid Broker-J
URL: https://github.com/apache/qpid-broker-j/pull/36#discussion_r325162130
 
 

 ##
 File path: doc/developer-guide/src/main/markdown/architecture.md
 ##
 @@ -0,0 +1,399 @@
+# High Level Architecture
+
+This article provides a high level description of the architecture of Qpid 
Broker-J.
+
+Broker-J is messaging broker that implements the AMQP protocols (version 0-8, 
0-9, 0-91, 0-10 and 1.0).
+Any AMQP compliant messaging library can be used with the Broker. The Broker 
supports on the fly message translation
+from one AMQP protocol to another, meaning it is possible to use the Broker to 
allow clients that use different
+AMQP protocol version to exchange messages. It can be managed over a built in 
HTTP interface
+(that presents a REST API and a Web Management Console), or by AMQP Management 
(early draft implementation).
+
+The Broker has a highly pluggable architecture that allows alternative 
implementations to be substituted for any concern.
+For instance, you can simply build a module delegating to your own storage or 
own authentication provider linking
+to your enterprise authentication backend.
+
+Broker-J is 100% pure Java.  It can be run standalone or embedded within 
another Java applications.
+
+## Model
+
+A tree of manageable categories, all of which extend of the interface 
`ConfiguredObject`, underpin the `Broker`.
+A `ConfiguredObject` has zero or more attributes, zero or more children and 
zero or more context variable name/value pairs.
+A `ConfiguredObject` may be persisted to a configuration store so its state 
can be restored when the Broker is restarted.
+The manageable categories are arranged into a tree structure.  `SystemConfig` 
is at the root and has a single descendent
+`Broker`.  The `Broker` itself has children: `Port`, `AuthenticationProvider`, 
`VirtualHostNode` amongst others.
+`VirtualHostNode` has a child `VirtualHost`.  The children of the 
`VirtualHost` are categories that directly involved
+in messaging such as `Queue`. The diagram below illustrates the category 
hierarchy but many categories are elided for brevity.
+The model tree structure is codified in the `BrokerModel` class.
+
+![Broker Model](images/model.png)
+
+## Category Specializations
+
+Some categories have specialisations.  An example is the category `Queue`.  It 
has specialisations corresponding to
+the queue types supported by the `Broker` e.g. `StandardQueue`, 
`PrirorityQueue` etc.
+
+### Attributes
+
+Each `ConfiguredObject` instance has zero or more attributes.   Attributes 
have a name and a value which can be
+a Java primitive value or an instance of any class for which an 
`AttributeValueConverter` exist.  This mechanism allows
+ attribute values to be `Lists`, `Sets`, `Maps`, or arbitrary structured types 
`ManagedAttributeValues`.
+
+Attributes are marked up in the code with method annotations 
`@ManagedAttribute` which defines things
+whether the attribute is mandatory or mutable.  Attributes can also be marked 
a secure which indicates restrictions
+ no how the attribute is used (used for attributes that that store passwords 
or private-keys).
+
+Attributes can have default values. The default value applies if the user 
omits to supply a value when the object
+is created.  Defaults themselves can be defined in terms of `context variable` 
references.
+
+### Context Variables
+
+Each `ConfiguredObject` instance has zero or more context variable 
assignments. These are simply name/value pairs
+where both name and value are strings.
+
+When resolving an attribute's value, if the attribute's value (or attribute's 
default) contains a context variable
+reference (e.g. `${foo}`), the variable is first resolved using the 
`ConfiguredObject`'s own context variables.
+If the `ConfiguedObject` has no definition for the context variable, the 
entity's parent is tried,
+then its grandparent and so forth, all the way until the `SystemContext` is 
reached.
+If the `SystemContext` provides no value, the JVM's system properties are 
consulted.
+
+A context variable's value can be defined in terms of other context variables.
+
+Context variables are useful for extracting environment specific information 
from configuration for instance path stems
+or port numbers.
+
+## Lifecycle
+
+`ConfiguredObjects` have a lifecycle.
+
+A `ConfiguredObject` is created exactly once by a call its parent's 
`#createChild()` method.
+This brings the object into existence.  It goes through a number of phases 
during creation (`ConfiguredObject#create`)
+
+ * resolution (where the attribute values are resolved and assigned to the 
object)
+ * creation validation (ensuring business rules are adhered to)
+ * registration with parents
+ * implementation specific creation (`#onCreate`)
+ * implementation specific opening (`#onOpen`)
+
+When the `Broker` is restarted objects that exist in the

[jira] [Commented] (QPID-8361) [Broker-J] Create a developer guide for Qpid Broker-J



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

ASF GitHub Bot commented on QPID-8361:
--

alex-rufous commented on pull request #36: QPID-8361: [Broker-J] Create a 
developer guide for Qpid Broker-J
URL: https://github.com/apache/qpid-broker-j/pull/36#discussion_r325161218
 
 

 ##
 File path: doc/developer-guide/src/main/markdown/code-guide.md
 ##
 @@ -0,0 +1,446 @@
+# Qpid Broker-J Coding Standards
+
+This article documents the standard adopted for Java code in the Qpid project.
+All committers are expected to follow this standard.
+
+## Executive Summary
+
+The main things for layout purposes in the standard are:
+
+ * Indent using four spaces. No tabs.
+ * braces always go on new lines, e.g.
+```java
+if (x == 5)
+{
+System.out.println("Hello");
+}
+```
+
+rather than
+
+```java
+if (x == 5} {
+System.out.println("Hello");
+}
+```
+
+Always add braces, e.g.
+
+```java
+if (x == 5)
+{
+System.out.println("Hello");
+}
+```
+rather than
+
+```java
+if (x == 5}
+System.out.println("Hello");
+```
+
+Fields prefixed with underscores, e.g. `_messageCount`
+
+Spaces after keywords but no spaces either before or after parentheses in 
method calls, e.g.
+
+```java
+if (x == 5)
+```
+
+rather than
+
+```java
+if(x==5)
+```
+
+but
+
+```java
+foo.bar(4, 5)
+```
+
+rather than
+
+```java
+foo.bar( 4, 5 )
+```
+
+## Details
+
+### Introduction
+
+This document describes two types of coding standard:
+
+1. **Mandatory** standards must be followed at all times.
+2. **Recommended** standards should in general be followed but in particular 
cases may be omitted
+   where the programmer feels that there is a good reason to do so.
+
+Code that does not adhere to mandatory standards will not pass the automated 
checks
+(or a code review if the guideline is not stylistic).
+
+### Source files
+
+This section defines the general rules associated with the contents of a Java 
source file and the order
+in which the each part should be presented. No rules on programming style, 
naming conventions or indentation are given here.
+
+1. Java source files must have a ".java" suffix (this will be enforced by the 
compiler) [mandatory].
+2. The basename of a Java source file must be the same as the public class 
defined therein
+   (this will be enforced by the compiler) [mandatory].
+3. Only one class should be defined per source file (except for inner classes 
and one-shot uses
+   where the non-public class cannot conceivably be used outside of its 
context) [mandatory].
+4. Source files should not exceed 1500 lines [recommended].
+5. No line in a source file should exceed 120 characters [mandatory].
+6. The sections of a source file should be presented in the following order 
[mandatory]:
+   * File information comment (see rule 7 below).
+   * Package name (see rules 1 to 3 in the section 2.1 above and rule 8 below).
+   * Imports (see rules 9 to 10 below).
+   * Other class definitions.
+   * Public class definition.
+7. Do not use automatically expanded log or revision number provided by your 
source code management system
+   unless it provides a facility to avoid "false conflicts" when doing merges 
due simply to revision number changes
+   (which happens, for example, with cvs when branches are used). [mandatory]
+8. Every class that is to be released must be a member of a package 
[mandatory].
+Rationale: classes that are not explicitly put in a package are placed in 
the unnamed package by the compiler.
+Therefore as the classes from many developers will be being placed in the 
same package the likelihood of a name
+clash is greatly increased.
+9. All class imports from the same package should be grouped together. A 
single blank line should separate imports
+   from different packages [recommended].
+10. Use javadoc tags and use HTML mark-up to enhance the readability of the 
output files [mandatory].
+
+### Java Elements
+
+This section gives advice on coding the various elements of the Java 
programming language.
+
+ Class definitions
+
+This section gives guidelines for class and interface definitions in Java.
+The term class in this section is used more broadly to mean class and 
interface:
+
+1. Class names should start with a capital letter with every subsequent word 
capitalised,
+   for example: `DataProcessor` [mandatory].
+2. All classes should be preceded by a javadoc comment describing the purpose 
of the class [recommended].
+3. Class-level javadoc comments should specify the thread-safety of the class 
[recommended].
+4. The name of exception classes should end in the word exception, for 
example: UnknownMungeException [mandatory].
+5. Class names should in general not be overloaded. For example, defining a 
class "com.foo.bar.String"
+should be avoided as there is already a class

[jira] [Commented] (QPID-8361) [Broker-J] Create a developer guide for Qpid Broker-J



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

ASF GitHub Bot commented on QPID-8361:
--

alex-rufous commented on pull request #36: QPID-8361: [Broker-J] Create a 
developer guide for Qpid Broker-J
URL: https://github.com/apache/qpid-broker-j/pull/36#discussion_r325160955
 
 

 ##
 File path: doc/developer-guide/src/main/markdown/code-guide.md
 ##
 @@ -0,0 +1,446 @@
+# Qpid Broker-J Coding Standards
+
+This article documents the standard adopted for Java code in the Qpid project.
+All committers are expected to follow this standard.
+
+## Executive Summary
+
+The main things for layout purposes in the standard are:
+
+ * Indent using four spaces. No tabs.
+ * braces always go on new lines, e.g.
+```java
+if (x == 5)
+{
+System.out.println("Hello");
+}
+```
+
+rather than
+
+```java
+if (x == 5} {
+System.out.println("Hello");
+}
+```
+
+Always add braces, e.g.
+
+```java
+if (x == 5)
+{
+System.out.println("Hello");
+}
+```
+rather than
+
+```java
+if (x == 5}
+System.out.println("Hello");
+```
+
+Fields prefixed with underscores, e.g. `_messageCount`
+
+Spaces after keywords but no spaces either before or after parentheses in 
method calls, e.g.
+
+```java
+if (x == 5)
+```
+
+rather than
+
+```java
+if(x==5)
+```
+
+but
+
+```java
+foo.bar(4, 5)
+```
+
+rather than
+
+```java
+foo.bar( 4, 5 )
+```
+
+## Details
+
+### Introduction
+
+This document describes two types of coding standard:
+
+1. **Mandatory** standards must be followed at all times.
+2. **Recommended** standards should in general be followed but in particular 
cases may be omitted
+   where the programmer feels that there is a good reason to do so.
+
+Code that does not adhere to mandatory standards will not pass the automated 
checks
+(or a code review if the guideline is not stylistic).
+
+### Source files
+
+This section defines the general rules associated with the contents of a Java 
source file and the order
+in which the each part should be presented. No rules on programming style, 
naming conventions or indentation are given here.
+
+1. Java source files must have a ".java" suffix (this will be enforced by the 
compiler) [mandatory].
+2. The basename of a Java source file must be the same as the public class 
defined therein
+   (this will be enforced by the compiler) [mandatory].
+3. Only one class should be defined per source file (except for inner classes 
and one-shot uses
+   where the non-public class cannot conceivably be used outside of its 
context) [mandatory].
+4. Source files should not exceed 1500 lines [recommended].
+5. No line in a source file should exceed 120 characters [mandatory].
+6. The sections of a source file should be presented in the following order 
[mandatory]:
+   * File information comment (see rule 7 below).
+   * Package name (see rules 1 to 3 in the section 2.1 above and rule 8 below).
+   * Imports (see rules 9 to 10 below).
+   * Other class definitions.
+   * Public class definition.
+7. Do not use automatically expanded log or revision number provided by your 
source code management system
+   unless it provides a facility to avoid "false conflicts" when doing merges 
due simply to revision number changes
+   (which happens, for example, with cvs when branches are used). [mandatory]
+8. Every class that is to be released must be a member of a package 
[mandatory].
+Rationale: classes that are not explicitly put in a package are placed in 
the unnamed package by the compiler.
+Therefore as the classes from many developers will be being placed in the 
same package the likelihood of a name
+clash is greatly increased.
+9. All class imports from the same package should be grouped together. A 
single blank line should separate imports
+   from different packages [recommended].
+10. Use javadoc tags and use HTML mark-up to enhance the readability of the 
output files [mandatory].
+
+### Java Elements
+
+This section gives advice on coding the various elements of the Java 
programming language.
+
+ Class definitions
+
+This section gives guidelines for class and interface definitions in Java.
+The term class in this section is used more broadly to mean class and 
interface:
+
+1. Class names should start with a capital letter with every subsequent word 
capitalised,
+   for example: `DataProcessor` [mandatory].
+2. All classes should be preceded by a javadoc comment describing the purpose 
of the class [recommended].
+3. Class-level javadoc comments should specify the thread-safety of the class 
[recommended].
+4. The name of exception classes should end in the word exception, for 
example: UnknownMungeException [mandatory].
+5. Class names should in general not be overloaded. For example, defining a 
class "com.foo.bar.String"
+should be avoided as there is already a class

[GitHub] [qpid-broker-j] alex-rufous commented on a change in pull request #36: QPID-8361: [Broker-J] Create a developer guide for Qpid Broker-J

alex-rufous commented on a change in pull request #36: QPID-8361: [Broker-J] 
Create a developer guide for Qpid Broker-J
URL: https://github.com/apache/qpid-broker-j/pull/36#discussion_r325161741
 
 

 ##
 File path: doc/developer-guide/src/main/markdown/build-instructions.md
 ##
 @@ -0,0 +1,290 @@
+# Build Instructions
+
+[Quick Start Guide](quick-start.md) only gives a minimum set of instructions 
to start quickly building and developing
+Qpid Broker-J code. The materials provided here intend to give a dipper 
understanding of various options for building,
+and testing Qpid Broker-J.
+
+## Prerequisites
+
+### Sources
+
+The Qpid project employs [Git distributed version-control 
system](https://git-scm.com) for tracking changes in source code.
+
+The Git repository can be found at 
.
+
+The mirror of Git repository exists on GitHub at 
.
+
+Changes need to be committed into Apache Git repository. They immediately get 
propagated into GitHub mirror.
+Only members of Qpid project with commit rights can commit the changes. The 
contributors without commit rights need
+to raise [Pull 
Request](https://help.github.com/en/articles/creating-a-pull-request) on GitHub 
in order to have
+their changes be committed by Qpid project committers.
+
+Git client is required to checkout sources from Git repo
+
+git clone https://gitbox.apache.org/repos/asf/qpid-broker-j.git 
qpid-broker-j
+
+For complete reference and documentation on Git please check [Git 
Book](https://git-scm.com/book/en/v2)
+
+### Maven
+
+Qpid Broker-J project uses [Maven](http://maven.apache.org/) as its build and 
management tool. Maven version 3 or above
+is required for building the project.
+
+You should set the `M2_HOME` environment variable and include its bin 
directory in your `PATH`.
+
+Check that maven is installed on your system by executing the following at 
your command prompt.
+
+mvn --version
+
+For full maven install instructions visit [Maven Installation 
Instructions](http://maven.apache.org/download.cgi#Installation).
+
+For complete reference and documentation on Maven please visit the following 
online resources.
+
+* [Apache Maven Project](http://maven.apache.org/)
+* [Maven: The Complete Reference by 
Sonatype](http://books.sonatype.com/mvnref-book/reference/public-book.html)
+
+
+### Java
+
+The build requires a Java 8 or later. You should set the `JAVA_HOME` 
environment variable and include its bin directory
+in your `PATH`.
+
+Check java version by executing the following at your command prompt.
+
+java -version
+
+## Project structure
+
+Qpid Broker-J consists of a number of modules and sub-modules located in their 
own directories. Each Qpid Broker-J module
+has its own POM file (pom.xml) located in its root directory. This file 
defines the modules version, dependencies and
+project inheritance as well as the configuration of the relative maven plugins 
specific to this module.
+The Qpid Broker-J parent pom.xml is located in the root of the project and 
declares all qpid modules, dependencies,
+plugins, etc.
+
+## Building
+
+The project is built by executing maven command in conjunction with 
pre-defined profiles. For example, the command below
+cleans previous build output and install all modules to local repository 
without running the tests:
+
+mvn clean install -DskipTests
+
+The following command installs all modules to the local repository after 
running all the tests:
+
+mvn clean install
+
+### Maven Commands
+
+Here is a quick reference guide outlining some of the maven commands you can 
run and what the outcome will be.
+
+Please visit [Introduction To The Maven 
Lifecycle](https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html)
+reference guide for full details on all the maven lifecycle phases.
+
+|  Command  | Description  | Notes 
 |
+|---|:-|:---|
+| mvn clean | removes all the files created by the previous build  
|Usually means it deletes the contents of the modules `*/target/` directory.|
+| mvn validate  | validates that the maven poms are all correct and that no 
config is missing | Useful to run when making build modifications to ensure 
consistency.|
+| mvn compile   | compiles the source code of the project | This will verify 
that project dependencies are correct.|
+| mvn test  | executes the unit tests | Should not rely on code being 
packaged or deployed, only unit tests.|
+| mvn package   | packages the code into the its distributable formats (jar, 
zip etc)| Each pom specifies what the distribution format is, default is POM.|
+| mvn verify| verifies that the packaged code is valid| This will run the 
integration and system tests.|
+| mvn install   |

[jira] [Commented] (QPID-8361) [Broker-J] Create a developer guide for Qpid Broker-J



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

ASF GitHub Bot commented on QPID-8361:
--

alex-rufous commented on pull request #36: QPID-8361: [Broker-J] Create a 
developer guide for Qpid Broker-J
URL: https://github.com/apache/qpid-broker-j/pull/36#discussion_r325161177
 
 

 ##
 File path: doc/developer-guide/src/main/markdown/code-guide.md
 ##
 @@ -0,0 +1,446 @@
+# Qpid Broker-J Coding Standards
+
+This article documents the standard adopted for Java code in the Qpid project.
+All committers are expected to follow this standard.
+
+## Executive Summary
+
+The main things for layout purposes in the standard are:
+
+ * Indent using four spaces. No tabs.
+ * braces always go on new lines, e.g.
+```java
+if (x == 5)
+{
+System.out.println("Hello");
+}
+```
+
+rather than
+
+```java
+if (x == 5} {
+System.out.println("Hello");
+}
+```
+
+Always add braces, e.g.
+
+```java
+if (x == 5)
+{
+System.out.println("Hello");
+}
+```
+rather than
+
+```java
+if (x == 5}
+System.out.println("Hello");
+```
+
+Fields prefixed with underscores, e.g. `_messageCount`
+
+Spaces after keywords but no spaces either before or after parentheses in 
method calls, e.g.
+
+```java
+if (x == 5)
+```
+
+rather than
+
+```java
+if(x==5)
+```
+
+but
+
+```java
+foo.bar(4, 5)
+```
+
+rather than
+
+```java
+foo.bar( 4, 5 )
+```
+
+## Details
+
+### Introduction
+
+This document describes two types of coding standard:
+
+1. **Mandatory** standards must be followed at all times.
+2. **Recommended** standards should in general be followed but in particular 
cases may be omitted
+   where the programmer feels that there is a good reason to do so.
+
+Code that does not adhere to mandatory standards will not pass the automated 
checks
+(or a code review if the guideline is not stylistic).
+
+### Source files
+
+This section defines the general rules associated with the contents of a Java 
source file and the order
+in which the each part should be presented. No rules on programming style, 
naming conventions or indentation are given here.
+
+1. Java source files must have a ".java" suffix (this will be enforced by the 
compiler) [mandatory].
+2. The basename of a Java source file must be the same as the public class 
defined therein
+   (this will be enforced by the compiler) [mandatory].
+3. Only one class should be defined per source file (except for inner classes 
and one-shot uses
+   where the non-public class cannot conceivably be used outside of its 
context) [mandatory].
+4. Source files should not exceed 1500 lines [recommended].
+5. No line in a source file should exceed 120 characters [mandatory].
+6. The sections of a source file should be presented in the following order 
[mandatory]:
+   * File information comment (see rule 7 below).
+   * Package name (see rules 1 to 3 in the section 2.1 above and rule 8 below).
+   * Imports (see rules 9 to 10 below).
+   * Other class definitions.
+   * Public class definition.
+7. Do not use automatically expanded log or revision number provided by your 
source code management system
+   unless it provides a facility to avoid "false conflicts" when doing merges 
due simply to revision number changes
+   (which happens, for example, with cvs when branches are used). [mandatory]
+8. Every class that is to be released must be a member of a package 
[mandatory].
+Rationale: classes that are not explicitly put in a package are placed in 
the unnamed package by the compiler.
+Therefore as the classes from many developers will be being placed in the 
same package the likelihood of a name
+clash is greatly increased.
+9. All class imports from the same package should be grouped together. A 
single blank line should separate imports
+   from different packages [recommended].
+10. Use javadoc tags and use HTML mark-up to enhance the readability of the 
output files [mandatory].
+
+### Java Elements
+
+This section gives advice on coding the various elements of the Java 
programming language.
+
+ Class definitions
+
+This section gives guidelines for class and interface definitions in Java.
+The term class in this section is used more broadly to mean class and 
interface:
+
+1. Class names should start with a capital letter with every subsequent word 
capitalised,
+   for example: `DataProcessor` [mandatory].
+2. All classes should be preceded by a javadoc comment describing the purpose 
of the class [recommended].
+3. Class-level javadoc comments should specify the thread-safety of the class 
[recommended].
+4. The name of exception classes should end in the word exception, for 
example: UnknownMungeException [mandatory].
+5. Class names should in general not be overloaded. For example, defining a 
class "com.foo.bar.String"
+should be avoided as there is already a class

[jira] [Commented] (QPID-8361) [Broker-J] Create a developer guide for Qpid Broker-J



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

ASF GitHub Bot commented on QPID-8361:
--

alex-rufous commented on pull request #36: QPID-8361: [Broker-J] Create a 
developer guide for Qpid Broker-J
URL: https://github.com/apache/qpid-broker-j/pull/36#discussion_r325161064
 
 

 ##
 File path: doc/developer-guide/src/main/markdown/code-guide.md
 ##
 @@ -0,0 +1,446 @@
+# Qpid Broker-J Coding Standards
+
+This article documents the standard adopted for Java code in the Qpid project.
+All committers are expected to follow this standard.
+
+## Executive Summary
+
+The main things for layout purposes in the standard are:
+
+ * Indent using four spaces. No tabs.
+ * braces always go on new lines, e.g.
+```java
+if (x == 5)
+{
+System.out.println("Hello");
+}
+```
+
+rather than
+
+```java
+if (x == 5} {
+System.out.println("Hello");
+}
+```
+
+Always add braces, e.g.
+
+```java
+if (x == 5)
+{
+System.out.println("Hello");
+}
+```
+rather than
+
+```java
+if (x == 5}
+System.out.println("Hello");
+```
+
+Fields prefixed with underscores, e.g. `_messageCount`
+
+Spaces after keywords but no spaces either before or after parentheses in 
method calls, e.g.
+
+```java
+if (x == 5)
+```
+
+rather than
+
+```java
+if(x==5)
+```
+
+but
+
+```java
+foo.bar(4, 5)
+```
+
+rather than
+
+```java
+foo.bar( 4, 5 )
+```
+
+## Details
+
+### Introduction
+
+This document describes two types of coding standard:
+
+1. **Mandatory** standards must be followed at all times.
+2. **Recommended** standards should in general be followed but in particular 
cases may be omitted
+   where the programmer feels that there is a good reason to do so.
+
+Code that does not adhere to mandatory standards will not pass the automated 
checks
+(or a code review if the guideline is not stylistic).
+
+### Source files
+
+This section defines the general rules associated with the contents of a Java 
source file and the order
+in which the each part should be presented. No rules on programming style, 
naming conventions or indentation are given here.
+
+1. Java source files must have a ".java" suffix (this will be enforced by the 
compiler) [mandatory].
+2. The basename of a Java source file must be the same as the public class 
defined therein
+   (this will be enforced by the compiler) [mandatory].
+3. Only one class should be defined per source file (except for inner classes 
and one-shot uses
+   where the non-public class cannot conceivably be used outside of its 
context) [mandatory].
+4. Source files should not exceed 1500 lines [recommended].
+5. No line in a source file should exceed 120 characters [mandatory].
+6. The sections of a source file should be presented in the following order 
[mandatory]:
+   * File information comment (see rule 7 below).
+   * Package name (see rules 1 to 3 in the section 2.1 above and rule 8 below).
+   * Imports (see rules 9 to 10 below).
+   * Other class definitions.
+   * Public class definition.
+7. Do not use automatically expanded log or revision number provided by your 
source code management system
+   unless it provides a facility to avoid "false conflicts" when doing merges 
due simply to revision number changes
+   (which happens, for example, with cvs when branches are used). [mandatory]
+8. Every class that is to be released must be a member of a package 
[mandatory].
+Rationale: classes that are not explicitly put in a package are placed in 
the unnamed package by the compiler.
+Therefore as the classes from many developers will be being placed in the 
same package the likelihood of a name
+clash is greatly increased.
+9. All class imports from the same package should be grouped together. A 
single blank line should separate imports
+   from different packages [recommended].
+10. Use javadoc tags and use HTML mark-up to enhance the readability of the 
output files [mandatory].
+
+### Java Elements
+
+This section gives advice on coding the various elements of the Java 
programming language.
+
+ Class definitions
+
+This section gives guidelines for class and interface definitions in Java.
+The term class in this section is used more broadly to mean class and 
interface:
+
+1. Class names should start with a capital letter with every subsequent word 
capitalised,
+   for example: `DataProcessor` [mandatory].
+2. All classes should be preceded by a javadoc comment describing the purpose 
of the class [recommended].
+3. Class-level javadoc comments should specify the thread-safety of the class 
[recommended].
+4. The name of exception classes should end in the word exception, for 
example: UnknownMungeException [mandatory].
+5. Class names should in general not be overloaded. For example, defining a 
class "com.foo.bar.String"
+should be avoided as there is already a class

[GitHub] [qpid-broker-j] alex-rufous commented on a change in pull request #36: QPID-8361: [Broker-J] Create a developer guide for Qpid Broker-J

alex-rufous commented on a change in pull request #36: QPID-8361: [Broker-J] 
Create a developer guide for Qpid Broker-J
URL: https://github.com/apache/qpid-broker-j/pull/36#discussion_r325161816
 
 

 ##
 File path: doc/developer-guide/src/main/markdown/architecture.md
 ##
 @@ -0,0 +1,399 @@
+# High Level Architecture
+
+This article provides a high level description of the architecture of Qpid 
Broker-J.
+
+Broker-J is messaging broker that implements the AMQP protocols (version 0-8, 
0-9, 0-91, 0-10 and 1.0).
+Any AMQP compliant messaging library can be used with the Broker. The Broker 
supports on the fly message translation
+from one AMQP protocol to another, meaning it is possible to use the Broker to 
allow clients that use different
+AMQP protocol version to exchange messages. It can be managed over a built in 
HTTP interface
+(that presents a REST API and a Web Management Console), or by AMQP Management 
(early draft implementation).
 
 Review comment:
   Fixed


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[GitHub] [qpid-broker-j] alex-rufous commented on a change in pull request #36: QPID-8361: [Broker-J] Create a developer guide for Qpid Broker-J

alex-rufous commented on a change in pull request #36: QPID-8361: [Broker-J] 
Create a developer guide for Qpid Broker-J
URL: https://github.com/apache/qpid-broker-j/pull/36#discussion_r325161364
 
 

 ##
 File path: doc/developer-guide/src/main/markdown/build-instructions.md
 ##
 @@ -0,0 +1,290 @@
+# Build Instructions
+
+[Quick Start Guide](quick-start.md) only gives a minimum set of instructions 
to start quickly building and developing
+Qpid Broker-J code. The materials provided here intend to give a dipper 
understanding of various options for building,
+and testing Qpid Broker-J.
+
+## Prerequisites
+
+### Sources
+
+The Qpid project employs [Git distributed version-control 
system](https://git-scm.com) for tracking changes in source code.
+
+The Git repository can be found at 
.
+
+The mirror of Git repository exists on GitHub at 
.
+
+Changes need to be committed into Apache Git repository. They immediately get 
propagated into GitHub mirror.
+Only members of Qpid project with commit rights can commit the changes. The 
contributors without commit rights need
+to raise [Pull 
Request](https://help.github.com/en/articles/creating-a-pull-request) on GitHub 
in order to have
+their changes be committed by Qpid project committers.
+
+Git client is required to checkout sources from Git repo
+
+git clone https://gitbox.apache.org/repos/asf/qpid-broker-j.git 
qpid-broker-j
+
+For complete reference and documentation on Git please check [Git 
Book](https://git-scm.com/book/en/v2)
+
+### Maven
+
+Qpid Broker-J project uses [Maven](http://maven.apache.org/) as its build and 
management tool. Maven version 3 or above
+is required for building the project.
+
+You should set the `M2_HOME` environment variable and include its bin 
directory in your `PATH`.
+
+Check that maven is installed on your system by executing the following at 
your command prompt.
+
+mvn --version
+
+For full maven install instructions visit [Maven Installation 
Instructions](http://maven.apache.org/download.cgi#Installation).
+
+For complete reference and documentation on Maven please visit the following 
online resources.
+
+* [Apache Maven Project](http://maven.apache.org/)
+* [Maven: The Complete Reference by 
Sonatype](http://books.sonatype.com/mvnref-book/reference/public-book.html)
+
+
+### Java
+
+The build requires a Java 8 or later. You should set the `JAVA_HOME` 
environment variable and include its bin directory
+in your `PATH`.
+
+Check java version by executing the following at your command prompt.
+
+java -version
+
+## Project structure
+
+Qpid Broker-J consists of a number of modules and sub-modules located in their 
own directories. Each Qpid Broker-J module
+has its own POM file (pom.xml) located in its root directory. This file 
defines the modules version, dependencies and
+project inheritance as well as the configuration of the relative maven plugins 
specific to this module.
+The Qpid Broker-J parent pom.xml is located in the root of the project and 
declares all qpid modules, dependencies,
+plugins, etc.
+
+## Building
+
+The project is built by executing maven command in conjunction with 
pre-defined profiles. For example, the command below
+cleans previous build output and install all modules to local repository 
without running the tests:
+
+mvn clean install -DskipTests
+
+The following command installs all modules to the local repository after 
running all the tests:
+
+mvn clean install
+
+### Maven Commands
+
+Here is a quick reference guide outlining some of the maven commands you can 
run and what the outcome will be.
+
+Please visit [Introduction To The Maven 
Lifecycle](https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html)
+reference guide for full details on all the maven lifecycle phases.
+
+|  Command  | Description  | Notes 
 |
+|---|:-|:---|
+| mvn clean | removes all the files created by the previous build  
|Usually means it deletes the contents of the modules `*/target/` directory.|
+| mvn validate  | validates that the maven poms are all correct and that no 
config is missing | Useful to run when making build modifications to ensure 
consistency.|
+| mvn compile   | compiles the source code of the project | This will verify 
that project dependencies are correct.|
+| mvn test  | executes the unit tests | Should not rely on code being 
packaged or deployed, only unit tests.|
+| mvn package   | packages the code into the its distributable formats (jar, 
zip etc)| Each pom specifies what the distribution format is, default is POM.|
+| mvn verify| verifies that the packaged code is valid| This will run the 
integration and system tests.|
+| mvn install   |

[jira] [Commented] (QPID-8361) [Broker-J] Create a developer guide for Qpid Broker-J



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

ASF GitHub Bot commented on QPID-8361:
--

alex-rufous commented on pull request #36: QPID-8361: [Broker-J] Create a 
developer guide for Qpid Broker-J
URL: https://github.com/apache/qpid-broker-j/pull/36#discussion_r325161364
 
 

 ##
 File path: doc/developer-guide/src/main/markdown/build-instructions.md
 ##
 @@ -0,0 +1,290 @@
+# Build Instructions
+
+[Quick Start Guide](quick-start.md) only gives a minimum set of instructions 
to start quickly building and developing
+Qpid Broker-J code. The materials provided here intend to give a dipper 
understanding of various options for building,
+and testing Qpid Broker-J.
+
+## Prerequisites
+
+### Sources
+
+The Qpid project employs [Git distributed version-control 
system](https://git-scm.com) for tracking changes in source code.
+
+The Git repository can be found at 
.
+
+The mirror of Git repository exists on GitHub at 
.
+
+Changes need to be committed into Apache Git repository. They immediately get 
propagated into GitHub mirror.
+Only members of Qpid project with commit rights can commit the changes. The 
contributors without commit rights need
+to raise [Pull 
Request](https://help.github.com/en/articles/creating-a-pull-request) on GitHub 
in order to have
+their changes be committed by Qpid project committers.
+
+Git client is required to checkout sources from Git repo
+
+git clone https://gitbox.apache.org/repos/asf/qpid-broker-j.git 
qpid-broker-j
+
+For complete reference and documentation on Git please check [Git 
Book](https://git-scm.com/book/en/v2)
+
+### Maven
+
+Qpid Broker-J project uses [Maven](http://maven.apache.org/) as its build and 
management tool. Maven version 3 or above
+is required for building the project.
+
+You should set the `M2_HOME` environment variable and include its bin 
directory in your `PATH`.
+
+Check that maven is installed on your system by executing the following at 
your command prompt.
+
+mvn --version
+
+For full maven install instructions visit [Maven Installation 
Instructions](http://maven.apache.org/download.cgi#Installation).
+
+For complete reference and documentation on Maven please visit the following 
online resources.
+
+* [Apache Maven Project](http://maven.apache.org/)
+* [Maven: The Complete Reference by 
Sonatype](http://books.sonatype.com/mvnref-book/reference/public-book.html)
+
+
+### Java
+
+The build requires a Java 8 or later. You should set the `JAVA_HOME` 
environment variable and include its bin directory
+in your `PATH`.
+
+Check java version by executing the following at your command prompt.
+
+java -version
+
+## Project structure
+
+Qpid Broker-J consists of a number of modules and sub-modules located in their 
own directories. Each Qpid Broker-J module
+has its own POM file (pom.xml) located in its root directory. This file 
defines the modules version, dependencies and
+project inheritance as well as the configuration of the relative maven plugins 
specific to this module.
+The Qpid Broker-J parent pom.xml is located in the root of the project and 
declares all qpid modules, dependencies,
+plugins, etc.
+
+## Building
+
+The project is built by executing maven command in conjunction with 
pre-defined profiles. For example, the command below
+cleans previous build output and install all modules to local repository 
without running the tests:
+
+mvn clean install -DskipTests
+
+The following command installs all modules to the local repository after 
running all the tests:
+
+mvn clean install
+
+### Maven Commands
+
+Here is a quick reference guide outlining some of the maven commands you can 
run and what the outcome will be.
+
+Please visit [Introduction To The Maven 
Lifecycle](https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html)
+reference guide for full details on all the maven lifecycle phases.
+
+|  Command  | Description  | Notes 
 |
+|---|:-|:---|
+| mvn clean | removes all the files created by the previous build  
|Usually means it deletes the contents of the modules `*/target/` directory.|
+| mvn validate  | validates that the maven poms are all correct and that no 
config is missing | Useful to run when making build modifications to ensure 
consistency.|
+| mvn compile   | compiles the source code of the project | This will verify 
that project dependencies are correct.|
+| mvn test  | executes the unit tests | Should not rely on code being 
packaged or deployed, only unit tests.|
+| mvn package   | packages the code into the its distributable

[jira] [Commented] (QPID-8361) [Broker-J] Create a developer guide for Qpid Broker-J



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

ASF GitHub Bot commented on QPID-8361:
--

alex-rufous commented on pull request #36: QPID-8361: [Broker-J] Create a 
developer guide for Qpid Broker-J
URL: https://github.com/apache/qpid-broker-j/pull/36#discussion_r325161274
 
 

 ##
 File path: doc/developer-guide/src/main/markdown/build-instructions.md
 ##
 @@ -0,0 +1,290 @@
+# Build Instructions
+
+[Quick Start Guide](quick-start.md) only gives a minimum set of instructions 
to start quickly building and developing
+Qpid Broker-J code. The materials provided here intend to give a dipper 
understanding of various options for building,
 
 Review comment:
   Addressed
 

This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> [Broker-J] Create a developer guide for Qpid Broker-J
> -
>
> Key: QPID-8361
> URL: https://issues.apache.org/jira/browse/QPID-8361
> Project: Qpid
>  Issue Type: Task
>  Components: Broker-J
>Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-8.0.0
>
>
> The developer documentation is currently scattered over various Qpid 
> confluence pages. It could be challenging for people interested in 
> contributing to the project to find that documentation. A developer guide 
> could be added to cover such aspects as
> * Environment Setup
> * Building project
> * Running tests
> * Releasing
> * Architecture overview
> The following wiki pages are good candidates for inclusion into a developer 
> guide:
> [High Level 
> Architecture|https://cwiki.apache.org/confluence/display/qpid/High+Level+Architecture]
> [How To Build Qpid 
> Broker-J|https://cwiki.apache.org/confluence/display/qpid/How+To+Build+Qpid+Broker-J]
> [Releasing Qpid 
> Broker-J|https://cwiki.apache.org/confluence/display/qpid/Releasing+Qpid+Broker-J]
> The wiki pages below might be included as well
> [Java Coding 
> Standards|https://cwiki.apache.org/confluence/display/qpid/Java+Coding+Standards]
> [Qpid Java Run 
> Scripts|https://cwiki.apache.org/confluence/display/qpid/Qpid+Java+Run+Scripts]
> The developer documentation should be easy to modify, maintain and preview. 
> Thus, it can be written in  markdown or 
> [asciidoc|https://asciidoctor.org/docs/asciidoc-syntax-quick-reference/]. The 
> latter is also supported on github. 
> Potentially, it can be published on Qpid  project site as part of release 
> process.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

[GitHub] [qpid-broker-j] alex-rufous commented on a change in pull request #36: QPID-8361: [Broker-J] Create a developer guide for Qpid Broker-J

alex-rufous commented on a change in pull request #36: QPID-8361: [Broker-J] 
Create a developer guide for Qpid Broker-J
URL: https://github.com/apache/qpid-broker-j/pull/36#discussion_r325161177
 
 

 ##
 File path: doc/developer-guide/src/main/markdown/code-guide.md
 ##
 @@ -0,0 +1,446 @@
+# Qpid Broker-J Coding Standards
+
+This article documents the standard adopted for Java code in the Qpid project.
+All committers are expected to follow this standard.
+
+## Executive Summary
+
+The main things for layout purposes in the standard are:
+
+ * Indent using four spaces. No tabs.
+ * braces always go on new lines, e.g.
+```java
+if (x == 5)
+{
+System.out.println("Hello");
+}
+```
+
+rather than
+
+```java
+if (x == 5} {
+System.out.println("Hello");
+}
+```
+
+Always add braces, e.g.
+
+```java
+if (x == 5)
+{
+System.out.println("Hello");
+}
+```
+rather than
+
+```java
+if (x == 5}
+System.out.println("Hello");
+```
+
+Fields prefixed with underscores, e.g. `_messageCount`
+
+Spaces after keywords but no spaces either before or after parentheses in 
method calls, e.g.
+
+```java
+if (x == 5)
+```
+
+rather than
+
+```java
+if(x==5)
+```
+
+but
+
+```java
+foo.bar(4, 5)
+```
+
+rather than
+
+```java
+foo.bar( 4, 5 )
+```
+
+## Details
+
+### Introduction
+
+This document describes two types of coding standard:
+
+1. **Mandatory** standards must be followed at all times.
+2. **Recommended** standards should in general be followed but in particular 
cases may be omitted
+   where the programmer feels that there is a good reason to do so.
+
+Code that does not adhere to mandatory standards will not pass the automated 
checks
+(or a code review if the guideline is not stylistic).
+
+### Source files
+
+This section defines the general rules associated with the contents of a Java 
source file and the order
+in which the each part should be presented. No rules on programming style, 
naming conventions or indentation are given here.
+
+1. Java source files must have a ".java" suffix (this will be enforced by the 
compiler) [mandatory].
+2. The basename of a Java source file must be the same as the public class 
defined therein
+   (this will be enforced by the compiler) [mandatory].
+3. Only one class should be defined per source file (except for inner classes 
and one-shot uses
+   where the non-public class cannot conceivably be used outside of its 
context) [mandatory].
+4. Source files should not exceed 1500 lines [recommended].
+5. No line in a source file should exceed 120 characters [mandatory].
+6. The sections of a source file should be presented in the following order 
[mandatory]:
+   * File information comment (see rule 7 below).
+   * Package name (see rules 1 to 3 in the section 2.1 above and rule 8 below).
+   * Imports (see rules 9 to 10 below).
+   * Other class definitions.
+   * Public class definition.
+7. Do not use automatically expanded log or revision number provided by your 
source code management system
+   unless it provides a facility to avoid "false conflicts" when doing merges 
due simply to revision number changes
+   (which happens, for example, with cvs when branches are used). [mandatory]
+8. Every class that is to be released must be a member of a package 
[mandatory].
+Rationale: classes that are not explicitly put in a package are placed in 
the unnamed package by the compiler.
+Therefore as the classes from many developers will be being placed in the 
same package the likelihood of a name
+clash is greatly increased.
+9. All class imports from the same package should be grouped together. A 
single blank line should separate imports
+   from different packages [recommended].
+10. Use javadoc tags and use HTML mark-up to enhance the readability of the 
output files [mandatory].
+
+### Java Elements
+
+This section gives advice on coding the various elements of the Java 
programming language.
+
+ Class definitions
+
+This section gives guidelines for class and interface definitions in Java.
+The term class in this section is used more broadly to mean class and 
interface:
+
+1. Class names should start with a capital letter with every subsequent word 
capitalised,
+   for example: `DataProcessor` [mandatory].
+2. All classes should be preceded by a javadoc comment describing the purpose 
of the class [recommended].
+3. Class-level javadoc comments should specify the thread-safety of the class 
[recommended].
+4. The name of exception classes should end in the word exception, for 
example: UnknownMungeException [mandatory].
+5. Class names should in general not be overloaded. For example, defining a 
class "com.foo.bar.String"
+should be avoided as there is already a class "java.lang.String" 
[recommended].
+Rationale: adhering to this rule reduces the likelihood of confusion and 
means that the use of fully qualified
+class names should not be required.
+6. The definition of the

[GitHub] [qpid-broker-j] alex-rufous commented on a change in pull request #36: QPID-8361: [Broker-J] Create a developer guide for Qpid Broker-J

alex-rufous commented on a change in pull request #36: QPID-8361: [Broker-J] 
Create a developer guide for Qpid Broker-J
URL: https://github.com/apache/qpid-broker-j/pull/36#discussion_r325161218
 
 

 ##
 File path: doc/developer-guide/src/main/markdown/code-guide.md
 ##
 @@ -0,0 +1,446 @@
+# Qpid Broker-J Coding Standards
+
+This article documents the standard adopted for Java code in the Qpid project.
+All committers are expected to follow this standard.
+
+## Executive Summary
+
+The main things for layout purposes in the standard are:
+
+ * Indent using four spaces. No tabs.
+ * braces always go on new lines, e.g.
+```java
+if (x == 5)
+{
+System.out.println("Hello");
+}
+```
+
+rather than
+
+```java
+if (x == 5} {
+System.out.println("Hello");
+}
+```
+
+Always add braces, e.g.
+
+```java
+if (x == 5)
+{
+System.out.println("Hello");
+}
+```
+rather than
+
+```java
+if (x == 5}
+System.out.println("Hello");
+```
+
+Fields prefixed with underscores, e.g. `_messageCount`
+
+Spaces after keywords but no spaces either before or after parentheses in 
method calls, e.g.
+
+```java
+if (x == 5)
+```
+
+rather than
+
+```java
+if(x==5)
+```
+
+but
+
+```java
+foo.bar(4, 5)
+```
+
+rather than
+
+```java
+foo.bar( 4, 5 )
+```
+
+## Details
+
+### Introduction
+
+This document describes two types of coding standard:
+
+1. **Mandatory** standards must be followed at all times.
+2. **Recommended** standards should in general be followed but in particular 
cases may be omitted
+   where the programmer feels that there is a good reason to do so.
+
+Code that does not adhere to mandatory standards will not pass the automated 
checks
+(or a code review if the guideline is not stylistic).
+
+### Source files
+
+This section defines the general rules associated with the contents of a Java 
source file and the order
+in which the each part should be presented. No rules on programming style, 
naming conventions or indentation are given here.
+
+1. Java source files must have a ".java" suffix (this will be enforced by the 
compiler) [mandatory].
+2. The basename of a Java source file must be the same as the public class 
defined therein
+   (this will be enforced by the compiler) [mandatory].
+3. Only one class should be defined per source file (except for inner classes 
and one-shot uses
+   where the non-public class cannot conceivably be used outside of its 
context) [mandatory].
+4. Source files should not exceed 1500 lines [recommended].
+5. No line in a source file should exceed 120 characters [mandatory].
+6. The sections of a source file should be presented in the following order 
[mandatory]:
+   * File information comment (see rule 7 below).
+   * Package name (see rules 1 to 3 in the section 2.1 above and rule 8 below).
+   * Imports (see rules 9 to 10 below).
+   * Other class definitions.
+   * Public class definition.
+7. Do not use automatically expanded log or revision number provided by your 
source code management system
+   unless it provides a facility to avoid "false conflicts" when doing merges 
due simply to revision number changes
+   (which happens, for example, with cvs when branches are used). [mandatory]
+8. Every class that is to be released must be a member of a package 
[mandatory].
+Rationale: classes that are not explicitly put in a package are placed in 
the unnamed package by the compiler.
+Therefore as the classes from many developers will be being placed in the 
same package the likelihood of a name
+clash is greatly increased.
+9. All class imports from the same package should be grouped together. A 
single blank line should separate imports
+   from different packages [recommended].
+10. Use javadoc tags and use HTML mark-up to enhance the readability of the 
output files [mandatory].
+
+### Java Elements
+
+This section gives advice on coding the various elements of the Java 
programming language.
+
+ Class definitions
+
+This section gives guidelines for class and interface definitions in Java.
+The term class in this section is used more broadly to mean class and 
interface:
+
+1. Class names should start with a capital letter with every subsequent word 
capitalised,
+   for example: `DataProcessor` [mandatory].
+2. All classes should be preceded by a javadoc comment describing the purpose 
of the class [recommended].
+3. Class-level javadoc comments should specify the thread-safety of the class 
[recommended].
+4. The name of exception classes should end in the word exception, for 
example: UnknownMungeException [mandatory].
+5. Class names should in general not be overloaded. For example, defining a 
class "com.foo.bar.String"
+should be avoided as there is already a class "java.lang.String" 
[recommended].
+Rationale: adhering to this rule reduces the likelihood of confusion and 
means that the use of fully qualified
+class names should not be required.
+6. The definition of the

[GitHub] [qpid-broker-j] alex-rufous commented on a change in pull request #36: QPID-8361: [Broker-J] Create a developer guide for Qpid Broker-J

alex-rufous commented on a change in pull request #36: QPID-8361: [Broker-J] 
Create a developer guide for Qpid Broker-J
URL: https://github.com/apache/qpid-broker-j/pull/36#discussion_r325161274
 
 

 ##
 File path: doc/developer-guide/src/main/markdown/build-instructions.md
 ##
 @@ -0,0 +1,290 @@
+# Build Instructions
+
+[Quick Start Guide](quick-start.md) only gives a minimum set of instructions 
to start quickly building and developing
+Qpid Broker-J code. The materials provided here intend to give a dipper 
understanding of various options for building,
 
 Review comment:
   Addressed


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[GitHub] [qpid-broker-j] alex-rufous commented on a change in pull request #36: QPID-8361: [Broker-J] Create a developer guide for Qpid Broker-J

alex-rufous commented on a change in pull request #36: QPID-8361: [Broker-J] 
Create a developer guide for Qpid Broker-J
URL: https://github.com/apache/qpid-broker-j/pull/36#discussion_r325160955
 
 

 ##
 File path: doc/developer-guide/src/main/markdown/code-guide.md
 ##
 @@ -0,0 +1,446 @@
+# Qpid Broker-J Coding Standards
+
+This article documents the standard adopted for Java code in the Qpid project.
+All committers are expected to follow this standard.
+
+## Executive Summary
+
+The main things for layout purposes in the standard are:
+
+ * Indent using four spaces. No tabs.
+ * braces always go on new lines, e.g.
+```java
+if (x == 5)
+{
+System.out.println("Hello");
+}
+```
+
+rather than
+
+```java
+if (x == 5} {
+System.out.println("Hello");
+}
+```
+
+Always add braces, e.g.
+
+```java
+if (x == 5)
+{
+System.out.println("Hello");
+}
+```
+rather than
+
+```java
+if (x == 5}
+System.out.println("Hello");
+```
+
+Fields prefixed with underscores, e.g. `_messageCount`
+
+Spaces after keywords but no spaces either before or after parentheses in 
method calls, e.g.
+
+```java
+if (x == 5)
+```
+
+rather than
+
+```java
+if(x==5)
+```
+
+but
+
+```java
+foo.bar(4, 5)
+```
+
+rather than
+
+```java
+foo.bar( 4, 5 )
+```
+
+## Details
+
+### Introduction
+
+This document describes two types of coding standard:
+
+1. **Mandatory** standards must be followed at all times.
+2. **Recommended** standards should in general be followed but in particular 
cases may be omitted
+   where the programmer feels that there is a good reason to do so.
+
+Code that does not adhere to mandatory standards will not pass the automated 
checks
+(or a code review if the guideline is not stylistic).
+
+### Source files
+
+This section defines the general rules associated with the contents of a Java 
source file and the order
+in which the each part should be presented. No rules on programming style, 
naming conventions or indentation are given here.
+
+1. Java source files must have a ".java" suffix (this will be enforced by the 
compiler) [mandatory].
+2. The basename of a Java source file must be the same as the public class 
defined therein
+   (this will be enforced by the compiler) [mandatory].
+3. Only one class should be defined per source file (except for inner classes 
and one-shot uses
+   where the non-public class cannot conceivably be used outside of its 
context) [mandatory].
+4. Source files should not exceed 1500 lines [recommended].
+5. No line in a source file should exceed 120 characters [mandatory].
+6. The sections of a source file should be presented in the following order 
[mandatory]:
+   * File information comment (see rule 7 below).
+   * Package name (see rules 1 to 3 in the section 2.1 above and rule 8 below).
+   * Imports (see rules 9 to 10 below).
+   * Other class definitions.
+   * Public class definition.
+7. Do not use automatically expanded log or revision number provided by your 
source code management system
+   unless it provides a facility to avoid "false conflicts" when doing merges 
due simply to revision number changes
+   (which happens, for example, with cvs when branches are used). [mandatory]
+8. Every class that is to be released must be a member of a package 
[mandatory].
+Rationale: classes that are not explicitly put in a package are placed in 
the unnamed package by the compiler.
+Therefore as the classes from many developers will be being placed in the 
same package the likelihood of a name
+clash is greatly increased.
+9. All class imports from the same package should be grouped together. A 
single blank line should separate imports
+   from different packages [recommended].
+10. Use javadoc tags and use HTML mark-up to enhance the readability of the 
output files [mandatory].
+
+### Java Elements
+
+This section gives advice on coding the various elements of the Java 
programming language.
+
+ Class definitions
+
+This section gives guidelines for class and interface definitions in Java.
+The term class in this section is used more broadly to mean class and 
interface:
+
+1. Class names should start with a capital letter with every subsequent word 
capitalised,
+   for example: `DataProcessor` [mandatory].
+2. All classes should be preceded by a javadoc comment describing the purpose 
of the class [recommended].
+3. Class-level javadoc comments should specify the thread-safety of the class 
[recommended].
+4. The name of exception classes should end in the word exception, for 
example: UnknownMungeException [mandatory].
+5. Class names should in general not be overloaded. For example, defining a 
class "com.foo.bar.String"
+should be avoided as there is already a class "java.lang.String" 
[recommended].
+Rationale: adhering to this rule reduces the likelihood of confusion and 
means that the use of fully qualified
+class names should not be required.
+6. The definition of the

[GitHub] [qpid-broker-j] alex-rufous commented on a change in pull request #36: QPID-8361: [Broker-J] Create a developer guide for Qpid Broker-J

alex-rufous commented on a change in pull request #36: QPID-8361: [Broker-J] 
Create a developer guide for Qpid Broker-J
URL: https://github.com/apache/qpid-broker-j/pull/36#discussion_r325161064
 
 

 ##
 File path: doc/developer-guide/src/main/markdown/code-guide.md
 ##
 @@ -0,0 +1,446 @@
+# Qpid Broker-J Coding Standards
+
+This article documents the standard adopted for Java code in the Qpid project.
+All committers are expected to follow this standard.
+
+## Executive Summary
+
+The main things for layout purposes in the standard are:
+
+ * Indent using four spaces. No tabs.
+ * braces always go on new lines, e.g.
+```java
+if (x == 5)
+{
+System.out.println("Hello");
+}
+```
+
+rather than
+
+```java
+if (x == 5} {
+System.out.println("Hello");
+}
+```
+
+Always add braces, e.g.
+
+```java
+if (x == 5)
+{
+System.out.println("Hello");
+}
+```
+rather than
+
+```java
+if (x == 5}
+System.out.println("Hello");
+```
+
+Fields prefixed with underscores, e.g. `_messageCount`
+
+Spaces after keywords but no spaces either before or after parentheses in 
method calls, e.g.
+
+```java
+if (x == 5)
+```
+
+rather than
+
+```java
+if(x==5)
+```
+
+but
+
+```java
+foo.bar(4, 5)
+```
+
+rather than
+
+```java
+foo.bar( 4, 5 )
+```
+
+## Details
+
+### Introduction
+
+This document describes two types of coding standard:
+
+1. **Mandatory** standards must be followed at all times.
+2. **Recommended** standards should in general be followed but in particular 
cases may be omitted
+   where the programmer feels that there is a good reason to do so.
+
+Code that does not adhere to mandatory standards will not pass the automated 
checks
+(or a code review if the guideline is not stylistic).
+
+### Source files
+
+This section defines the general rules associated with the contents of a Java 
source file and the order
+in which the each part should be presented. No rules on programming style, 
naming conventions or indentation are given here.
+
+1. Java source files must have a ".java" suffix (this will be enforced by the 
compiler) [mandatory].
+2. The basename of a Java source file must be the same as the public class 
defined therein
+   (this will be enforced by the compiler) [mandatory].
+3. Only one class should be defined per source file (except for inner classes 
and one-shot uses
+   where the non-public class cannot conceivably be used outside of its 
context) [mandatory].
+4. Source files should not exceed 1500 lines [recommended].
+5. No line in a source file should exceed 120 characters [mandatory].
+6. The sections of a source file should be presented in the following order 
[mandatory]:
+   * File information comment (see rule 7 below).
+   * Package name (see rules 1 to 3 in the section 2.1 above and rule 8 below).
+   * Imports (see rules 9 to 10 below).
+   * Other class definitions.
+   * Public class definition.
+7. Do not use automatically expanded log or revision number provided by your 
source code management system
+   unless it provides a facility to avoid "false conflicts" when doing merges 
due simply to revision number changes
+   (which happens, for example, with cvs when branches are used). [mandatory]
+8. Every class that is to be released must be a member of a package 
[mandatory].
+Rationale: classes that are not explicitly put in a package are placed in 
the unnamed package by the compiler.
+Therefore as the classes from many developers will be being placed in the 
same package the likelihood of a name
+clash is greatly increased.
+9. All class imports from the same package should be grouped together. A 
single blank line should separate imports
+   from different packages [recommended].
+10. Use javadoc tags and use HTML mark-up to enhance the readability of the 
output files [mandatory].
+
+### Java Elements
+
+This section gives advice on coding the various elements of the Java 
programming language.
+
+ Class definitions
+
+This section gives guidelines for class and interface definitions in Java.
+The term class in this section is used more broadly to mean class and 
interface:
+
+1. Class names should start with a capital letter with every subsequent word 
capitalised,
+   for example: `DataProcessor` [mandatory].
+2. All classes should be preceded by a javadoc comment describing the purpose 
of the class [recommended].
+3. Class-level javadoc comments should specify the thread-safety of the class 
[recommended].
+4. The name of exception classes should end in the word exception, for 
example: UnknownMungeException [mandatory].
+5. Class names should in general not be overloaded. For example, defining a 
class "com.foo.bar.String"
+should be avoided as there is already a class "java.lang.String" 
[recommended].
+Rationale: adhering to this rule reduces the likelihood of confusion and 
means that the use of fully qualified
+class names should not be required.
+6. The definition of the

[jira] [Commented] (PROTON-1890) [c++] implement idle_timeout and heartbeats

2019-09-17 Thread Bajan Fella (Jira)



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

Bajan Fella commented on PROTON-1890:
-

[~aconway] Thanks for you comments. I will submit an issue.

> [c++] implement idle_timeout and heartbeats
> ---
>
> Key: PROTON-1890
> URL: https://issues.apache.org/jira/browse/PROTON-1890
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
>Affects Versions: proton-0.16.0
>Reporter: Praveen Bodke
>Assignee: Alan Conway
>Priority: Major
> Attachments: PROTON-1890.zip, examples.diff
>
>
> This is similar issue reported in PROTON-1782 for ruby. 
> We are facing this issue in cpp binding and i am able to reproduce the issue 
> with scheduled_send_03.cpp example. The test scenario is to drop all the 
> packets from both the interfaces after the successful connection. The only 
> change i made to this example is to send messages continuously inside the 
> send() method. The other end is detecting the error as it is sending the 
> empty frames and no response is heard.
> The proton is not sending the heartbeat messages (empty frames) as the sender 
> is busy in sending the data frames. Is it not necessary to send empty frames 
> even if the data frames are sent?
>  



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

[jira] [Commented] (QPID-8361) [Broker-J] Create a developer guide for Qpid Broker-J