[jira] [Resolved] (DISPATCH-545) Allow the routers to draw under the legend on the topology page
[ https://issues.apache.org/jira/browse/DISPATCH-545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Allen resolved DISPATCH-545. --- Resolution: Won't Fix Now that you can hide the properties panel on the left of the topology page, this enhancement is no longer a priority. > Allow the routers to draw under the legend on the topology page > --- > > Key: DISPATCH-545 > URL: https://issues.apache.org/jira/browse/DISPATCH-545 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Console >Reporter: Ernest Allen >Assignee: Ernest Allen >Priority: Minor > > Widen the topology graph so that it goes from the info panel to the right > side of the page. Prevent the routers/clients from going behind the legend, > but allow them to go below the legend. > -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-793) Edge between nodes in Topology diagram missing on IE11
[ https://issues.apache.org/jira/browse/DISPATCH-793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Allen resolved DISPATCH-793. --- Resolution: Cannot Reproduce Assignee: Ernest Allen I can no longer reproduce on IE 11 on Windows 10 for either the hawtio or stand-alone console. It's possible this inadvertently got fixed with a different checkin. Please re-open if you can reproduce with latest code. > Edge between nodes in Topology diagram missing on IE11 > -- > > Key: DISPATCH-793 > URL: https://issues.apache.org/jira/browse/DISPATCH-793 > Project: Qpid Dispatch > Issue Type: Bug > Components: Console >Affects Versions: 1.0.0 > Environment: Dispatch and Dispatch plugin at commit e22091b3 >Reporter: Jiri Danek >Assignee: Ernest Allen >Priority: Minor > Attachments: no_edge_between_nodes.png > > > !no_edge_between_nodes.png! -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-748) Error message shown when rapidly clicking treeview on left side of hawtio console: Uncaught TypeError: Cannot read property 'height' of null
[
https://issues.apache.org/jira/browse/DISPATCH-748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ernest Allen resolved DISPATCH-748.
---
Resolution: Fixed
Assignee: Ernest Allen
Fix Version/s: 1.0.0
> Error message shown when rapidly clicking treeview on left side of hawtio
> console: Uncaught TypeError: Cannot read property 'height' of null
>
>
> Key: DISPATCH-748
> URL: https://issues.apache.org/jira/browse/DISPATCH-748
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Console
>Affects Versions: 0.8.0
>Reporter: Jiri Danek
>Assignee: Ernest Allen
>Priority: Minor
> Fix For: 1.0.0
>
>
> Rapidly close and open branches in the left side treeview on the Overview
> page in hawtio, see https://www.youtube.com/watch?v=-sxfXOvX2d8
> Red popup appears, eventually.
> {noformat}
> app.js:4 Synchronous XMLHttpRequest on the main thread is deprecated because
> of its detrimental effects to the end user's experience. For more help, check
> https://xhr.spec.whatwg.org/.
> send @ app.js:4
> app.js:16 [Themes] unknown theme name, using default theme
> app.js:16 [QDR] *creating Dispatch Console
> app.js:16 [QDR] curPath is /
> app.js:16 [RBAC] Using mbean
> hawtio:type=security,area=jmx,rank=0,name=HawtioDummyJMXSecurity for
> client-side role based access control
> app.js:16 [Core] hawtio started
> app.js:16 [QDR] okay to start
> app.js:16 [QDR] [
> "amqp:/_topo/0/Router.A/$management"
> ]
> app.js:16 [QDR] {
> "amqp:/_topo/0/Router.A/$management": {}
> }
> app.js:16 [QDR] saving page changed to /dispatch_hawtio_console/overview
> app.js:16 [Window] Uncaught TypeError: Cannot read property 'height' of null
> ( href="http://127.0.0.1:8080/hawtio/dispatch_hawtio_console/overview:1097";>http://127.0.0.1:8080/hawtio/dispatch_hawtio_console/overview:1097:50)
> consoleLogger @ app.js:16
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-748) Error message shown when rapidly clicking treeview on left side of hawtio console: Uncaught TypeError: Cannot read property 'height' of null
[
https://issues.apache.org/jira/browse/DISPATCH-748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16070952#comment-16070952
]
ASF subversion and git services commented on DISPATCH-748:
--
Commit 41fc94588ae90761c6ff34f2e337a58f429f4dde in qpid-dispatch's branch
refs/heads/master from [~eallen]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=41fc945 ]
DISPATCH-748 Check for null in table height to avoid possible error message
> Error message shown when rapidly clicking treeview on left side of hawtio
> console: Uncaught TypeError: Cannot read property 'height' of null
>
>
> Key: DISPATCH-748
> URL: https://issues.apache.org/jira/browse/DISPATCH-748
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Console
>Affects Versions: 0.8.0
>Reporter: Jiri Danek
>Priority: Minor
>
> Rapidly close and open branches in the left side treeview on the Overview
> page in hawtio, see https://www.youtube.com/watch?v=-sxfXOvX2d8
> Red popup appears, eventually.
> {noformat}
> app.js:4 Synchronous XMLHttpRequest on the main thread is deprecated because
> of its detrimental effects to the end user's experience. For more help, check
> https://xhr.spec.whatwg.org/.
> send @ app.js:4
> app.js:16 [Themes] unknown theme name, using default theme
> app.js:16 [QDR] *creating Dispatch Console
> app.js:16 [QDR] curPath is /
> app.js:16 [RBAC] Using mbean
> hawtio:type=security,area=jmx,rank=0,name=HawtioDummyJMXSecurity for
> client-side role based access control
> app.js:16 [Core] hawtio started
> app.js:16 [QDR] okay to start
> app.js:16 [QDR] [
> "amqp:/_topo/0/Router.A/$management"
> ]
> app.js:16 [QDR] {
> "amqp:/_topo/0/Router.A/$management": {}
> }
> app.js:16 [QDR] saving page changed to /dispatch_hawtio_console/overview
> app.js:16 [Window] Uncaught TypeError: Cannot read property 'height' of null
> ( href="http://127.0.0.1:8080/hawtio/dispatch_hawtio_console/overview:1097";>http://127.0.0.1:8080/hawtio/dispatch_hawtio_console/overview:1097:50)
> consoleLogger @ app.js:16
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-792) Freezing and moving nodes is somewhat broken (in either version of console)
[
https://issues.apache.org/jira/browse/DISPATCH-792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ernest Allen resolved DISPATCH-792.
---
Resolution: Fixed
Assignee: Ernest Allen
Fix Version/s: 1.0.0
This should fix all three issues described.
> Freezing and moving nodes is somewhat broken (in either version of console)
> ---
>
> Key: DISPATCH-792
> URL: https://issues.apache.org/jira/browse/DISPATCH-792
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Console
>Affects Versions: 1.0.0
> Environment: Dispatch and Dispatch plugin at commit e22091b3
> Built without libwebsocket, used the old websockify way to connect console
> Firefox 51.0.1, Chrome 56.0.2924.87 (64-bit) on Linux
>Reporter: Jiri Danek
>Assignee: Ernest Allen
>Priority: Minor
> Fix For: 1.0.0
>
>
> If I freeze a node using the right-click menu, then
> 1) The label in the popup menu randomly switches Freeze/Unfreeze and it is
> tricky to click the Unfreeze option: https://youtu.be/DwczdnMnnkc
> if I am dragging a frozen router node on top of console node, then
> 2) The legend switches to the other node. I would expect it not to change.
> https://www.youtube.com/watch?v=HSCxFvFnfTs
> 3) If I put the nodes exactly on top of each other, I get the following
> exception in browser log.
> {noformat}
> Error: attribute d: Expected number, "MNaN,NaNLNaN,NaN".
> a @ d3.min.js?_=1497955959439:1
> (anonymous) @ d3.min.js?_=1497955959439:3
> Y @ d3.min.js?_=1497955959439:1
> Aa.each @ d3.min.js?_=1497955959439:3
> Aa.attr @ d3.min.js?_=1497955959439:3
> tick @ VM79:1125
> t @ d3.min.js?_=1497955959439:1
> l.tick@ d3.min.js?_=1497955959439:4
> Rn@ d3.min.js?_=1497955959439:1
> Tn@ d3.min.js?_=1497955959439:1
> {noformat}
> Issue 3 is very hard to reproduce, I was able to trigger it two times in
> hawtio version of console, and then never. Unless it can be figured out from
> code what could went wrong, it is probably not worth the time to investigate
> further.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-792) Freezing and moving nodes is somewhat broken (in either version of console)
[
https://issues.apache.org/jira/browse/DISPATCH-792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16070939#comment-16070939
]
ASF subversion and git services commented on DISPATCH-792:
--
Commit a5bb8051b96da65832c58311841f28835afd71e6 in qpid-dispatch's branch
refs/heads/master from [~eallen]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=a5bb805 ]
DISPATCH-792 Fix freezing/unfreezing nodes and moving nodes on top of each other
> Freezing and moving nodes is somewhat broken (in either version of console)
> ---
>
> Key: DISPATCH-792
> URL: https://issues.apache.org/jira/browse/DISPATCH-792
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Console
>Affects Versions: 1.0.0
> Environment: Dispatch and Dispatch plugin at commit e22091b3
> Built without libwebsocket, used the old websockify way to connect console
> Firefox 51.0.1, Chrome 56.0.2924.87 (64-bit) on Linux
>Reporter: Jiri Danek
>Priority: Minor
>
> If I freeze a node using the right-click menu, then
> 1) The label in the popup menu randomly switches Freeze/Unfreeze and it is
> tricky to click the Unfreeze option: https://youtu.be/DwczdnMnnkc
> if I am dragging a frozen router node on top of console node, then
> 2) The legend switches to the other node. I would expect it not to change.
> https://www.youtube.com/watch?v=HSCxFvFnfTs
> 3) If I put the nodes exactly on top of each other, I get the following
> exception in browser log.
> {noformat}
> Error: attribute d: Expected number, "MNaN,NaNLNaN,NaN".
> a @ d3.min.js?_=1497955959439:1
> (anonymous) @ d3.min.js?_=1497955959439:3
> Y @ d3.min.js?_=1497955959439:1
> Aa.each @ d3.min.js?_=1497955959439:3
> Aa.attr @ d3.min.js?_=1497955959439:3
> tick @ VM79:1125
> t @ d3.min.js?_=1497955959439:1
> l.tick@ d3.min.js?_=1497955959439:4
> Rn@ d3.min.js?_=1497955959439:1
> Tn@ d3.min.js?_=1497955959439:1
> {noformat}
> Issue 3 is very hard to reproduce, I was able to trigger it two times in
> hawtio version of console, and then never. Unless it can be figured out from
> code what could went wrong, it is probably not worth the time to investigate
> further.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-421) Toasts messages are not logged in the rolldown "logging console"
[ https://issues.apache.org/jira/browse/DISPATCH-421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16070936#comment-16070936 ] ASF subversion and git services commented on DISPATCH-421: -- Commit b5acca6df81d4d3224f9dae4381ed9a89016f24e in qpid-dispatch's branch refs/heads/master from [~eallen] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=b5acca6 ] DISPATCH-421 Fix syntax error > Toasts messages are not logged in the rolldown "logging console" > > > Key: DISPATCH-421 > URL: https://issues.apache.org/jira/browse/DISPATCH-421 > Project: Qpid Dispatch > Issue Type: Bug > Components: Console >Affects Versions: 0.6.1 >Reporter: Jiri Danek >Assignee: Ernest Allen > Fix For: 1.0.0 > > > Do something that emits an error or confirmation toast. For example, delete > an address as in DISPATCH-418. Then click the icon to open the logging > console in the upper right corner. The error message from toast won't be > logged in the logging console. > I'd expect the toasts to be logged in the logging console. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1349) C "proactor" implementation on windows
[ https://issues.apache.org/jira/browse/PROTON-1349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16070920#comment-16070920 ] ASF subversion and git services commented on PROTON-1349: - Commit e1c3cd0315513f5a58d1aefbc9878cead62a7441 in qpid-proton's branch refs/heads/master from Clifford Jansen [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=e1c3cd0 ] PROTON-1349: partial implementation that compiles but does not yet pass tests. Added so that C++ proactor changes could be checked in. > C "proactor" implementation on windows > -- > > Key: PROTON-1349 > URL: https://issues.apache.org/jira/browse/PROTON-1349 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c > Environment: Windows >Reporter: Cliff Jansen >Assignee: Cliff Jansen > Fix For: 0.18.0 > > > Provide the Windows counterpart to the work in > https://issues.apache.org/jira/browse/PROTON-1344 > Including a thread safe inject. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (DISPATCH-575) The console should only pass 'amqp' in the list of protocols when connecting
[ https://issues.apache.org/jira/browse/DISPATCH-575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Allen closed DISPATCH-575. - Resolution: Won't Fix Only passing 'amqp' as the protocol would prevent the console from connecting through a websocket proxy. Leaving it as it is will allow the console to connect through the http interface of the router or through a proxy. > The console should only pass 'amqp' in the list of protocols when connecting > > > Key: DISPATCH-575 > URL: https://issues.apache.org/jira/browse/DISPATCH-575 > Project: Qpid Dispatch > Issue Type: Bug > Components: Console >Reporter: Ernest Allen >Assignee: Ernest Allen > > The console currently passes ["binary", "base64", "AMQWSB10"] as the list of > protocols that it supports when it connects to a proxy/router. > Once the router can directly handle the websockets protocol, the console > should pass 'amqp' as the protocol. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-430) Cursor snaps way above peaks in a rate chart
[ https://issues.apache.org/jira/browse/DISPATCH-430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Allen resolved DISPATCH-430. --- Resolution: Fixed Assignee: Ernest Allen Fix Version/s: 1.0.0 > Cursor snaps way above peaks in a rate chart > > > Key: DISPATCH-430 > URL: https://issues.apache.org/jira/browse/DISPATCH-430 > Project: Qpid Dispatch > Issue Type: Bug > Components: Console >Affects Versions: 0.6.1 >Reporter: Jiri Danek >Assignee: Ernest Allen > Fix For: 1.0.0 > > Attachments: chartPeeks.png > > > Add a chart. Delivery Count on a link is a good variable, because it changes > quickly. Click Configure button on the chart. Change chart type to Rate > chart. On the Duration tab set duration to something short, like 2 minutes. > Apply and close. > Position your mouse cursor under a peek in the chart. The circle that is > supposed to follow the mouse cursor and snap to the curve is placed way above > the peak. > If the chart rolls to the left under the mouse, which happens every time the > chart updates, the position of the snappy circle is not updated to match the > new height of the chart line. until I move my mouse. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-430) Cursor snaps way above peaks in a rate chart
[ https://issues.apache.org/jira/browse/DISPATCH-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16070880#comment-16070880 ] ASF subversion and git services commented on DISPATCH-430: -- Commit a8aecae5bd9459350ef7e50dd2d149d94af490fa in qpid-dispatch's branch refs/heads/master from [~eallen] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=a8aecae ] DISPATCH-430 Remove unused interpolation function for rate charts > Cursor snaps way above peaks in a rate chart > > > Key: DISPATCH-430 > URL: https://issues.apache.org/jira/browse/DISPATCH-430 > Project: Qpid Dispatch > Issue Type: Bug > Components: Console >Affects Versions: 0.6.1 >Reporter: Jiri Danek > Attachments: chartPeeks.png > > > Add a chart. Delivery Count on a link is a good variable, because it changes > quickly. Click Configure button on the chart. Change chart type to Rate > chart. On the Duration tab set duration to something short, like 2 minutes. > Apply and close. > Position your mouse cursor under a peek in the chart. The circle that is > supposed to follow the mouse cursor and snap to the curve is placed way above > the peak. > If the chart rolls to the left under the mouse, which happens every time the > chart updates, the position of the snappy circle is not updated to match the > new height of the chart line. until I move my mouse. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-430) Cursor snaps way above peaks in a rate chart
[ https://issues.apache.org/jira/browse/DISPATCH-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16070877#comment-16070877 ] ASF subversion and git services commented on DISPATCH-430: -- Commit 6f408b0726e0f9cc9ddf6920aa177af4b9d375d2 in qpid-dispatch's branch refs/heads/master from [~eallen] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=6f408b0 ] DISPATCH-430 Use linear interpolation on rate charts to prevent tooltip from drawing in the wrong y position > Cursor snaps way above peaks in a rate chart > > > Key: DISPATCH-430 > URL: https://issues.apache.org/jira/browse/DISPATCH-430 > Project: Qpid Dispatch > Issue Type: Bug > Components: Console >Affects Versions: 0.6.1 >Reporter: Jiri Danek > Attachments: chartPeeks.png > > > Add a chart. Delivery Count on a link is a good variable, because it changes > quickly. Click Configure button on the chart. Change chart type to Rate > chart. On the Duration tab set duration to something short, like 2 minutes. > Apply and close. > Position your mouse cursor under a peek in the chart. The circle that is > supposed to follow the mouse cursor and snap to the curve is placed way above > the peak. > If the chart rolls to the left under the mouse, which happens every time the > chart updates, the position of the snappy circle is not updated to match the > new height of the chart line. until I move my mouse. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-421) Toasts messages are not logged in the rolldown "logging console"
[ https://issues.apache.org/jira/browse/DISPATCH-421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Allen resolved DISPATCH-421. --- Resolution: Fixed Fix Version/s: 1.0.0 > Toasts messages are not logged in the rolldown "logging console" > > > Key: DISPATCH-421 > URL: https://issues.apache.org/jira/browse/DISPATCH-421 > Project: Qpid Dispatch > Issue Type: Bug > Components: Console >Affects Versions: 0.6.1 >Reporter: Jiri Danek >Assignee: Ernest Allen > Fix For: 1.0.0 > > > Do something that emits an error or confirmation toast. For example, delete > an address as in DISPATCH-418. Then click the icon to open the logging > console in the upper right corner. The error message from toast won't be > logged in the logging console. > I'd expect the toasts to be logged in the logging console. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-421) Toasts messages are not logged in the rolldown "logging console"
[ https://issues.apache.org/jira/browse/DISPATCH-421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16070726#comment-16070726 ] ASF subversion and git services commented on DISPATCH-421: -- Commit 2b15c8f5f91b2b2792045b4ad8882856e690fa45 in qpid-dispatch's branch refs/heads/master from [~eallen] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=2b15c8f ] DISPATCH-421 Mirror toast messages to debug console > Toasts messages are not logged in the rolldown "logging console" > > > Key: DISPATCH-421 > URL: https://issues.apache.org/jira/browse/DISPATCH-421 > Project: Qpid Dispatch > Issue Type: Bug > Components: Console >Affects Versions: 0.6.1 >Reporter: Jiri Danek >Assignee: Ernest Allen > > Do something that emits an error or confirmation toast. For example, delete > an address as in DISPATCH-418. Then click the icon to open the logging > console in the upper right corner. The error message from toast won't be > logged in the logging console. > I'd expect the toasts to be logged in the logging console. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (DISPATCH-421) Toasts messages are not logged in the rolldown "logging console"
[ https://issues.apache.org/jira/browse/DISPATCH-421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Allen reassigned DISPATCH-421: - Assignee: Ernest Allen > Toasts messages are not logged in the rolldown "logging console" > > > Key: DISPATCH-421 > URL: https://issues.apache.org/jira/browse/DISPATCH-421 > Project: Qpid Dispatch > Issue Type: Bug > Components: Console >Affects Versions: 0.6.1 >Reporter: Jiri Danek >Assignee: Ernest Allen > > Do something that emits an error or confirmation toast. For example, delete > an address as in DISPATCH-418. Then click the icon to open the logging > console in the upper right corner. The error message from toast won't be > logged in the logging console. > I'd expect the toasts to be logged in the logging console. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (PROTON-1511) BrokerAgent does not provide reconnect support
[ https://issues.apache.org/jira/browse/PROTON-1511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway closed PROTON-1511. --- Resolution: Not A Problem > BrokerAgent does not provide reconnect support > -- > > Key: PROTON-1511 > URL: https://issues.apache.org/jira/browse/PROTON-1511 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.17.0 >Reporter: Brian Bouterse >Assignee: Alan Conway > > The BrokerAgent is provided by this diff: > https://reviews.apache.org/r/52280/diff/3#0 Here is how to reproduce: > 1. Instantiate a BrokerAgent connecting to a qpidd broker > 2. Do something with the connected BrokerAgent object to show that it's > working > 3. kill qpidd with `pkill -9 -f qpidd` > 4. start qpidd up again > 5. Try to do step 2 again > 6. Receive a traceback indicating the BrokerAgent is disconnected > My code handles reconnect support for the connection, but it's not prepared > to also handle reconnect support for the BrokerAgent connection. I would like > that connection to have a reconnect support option added so I can call it > like: > BrokerAgent(**existing_options, reconnect=True) > Having reconnect default to True is also fine w/ me. I think users may still > want the option to set it also. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1511) BrokerAgent does not provide reconnect support
[ https://issues.apache.org/jira/browse/PROTON-1511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16070521#comment-16070521 ] Alan Conway commented on PROTON-1511: - This issue has been moved to the QPID project, the qmf.client package is part of Qpid, not proton. > BrokerAgent does not provide reconnect support > -- > > Key: PROTON-1511 > URL: https://issues.apache.org/jira/browse/PROTON-1511 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.17.0 >Reporter: Brian Bouterse >Assignee: Alan Conway > > The BrokerAgent is provided by this diff: > https://reviews.apache.org/r/52280/diff/3#0 Here is how to reproduce: > 1. Instantiate a BrokerAgent connecting to a qpidd broker > 2. Do something with the connected BrokerAgent object to show that it's > working > 3. kill qpidd with `pkill -9 -f qpidd` > 4. start qpidd up again > 5. Try to do step 2 again > 6. Receive a traceback indicating the BrokerAgent is disconnected > My code handles reconnect support for the connection, but it's not prepared > to also handle reconnect support for the BrokerAgent connection. I would like > that connection to have a reconnect support option added so I can call it > like: > BrokerAgent(**existing_options, reconnect=True) > Having reconnect default to True is also fine w/ me. I think users may still > want the option to set it also. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7847) qmf.client.BrokerAgent does not provide reconnect support
[ https://issues.apache.org/jira/browse/QPID-7847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway updated QPID-7847: -- Description: Moved from PROTON-1511 The BrokerAgent is provided by this diff: https://reviews.apache.org/r/52280/diff/3#0 Here is how to reproduce: 1. Instantiate a BrokerAgent connecting to a qpidd broker 2. Do something with the connected BrokerAgent object to show that it's working 3. kill qpidd with `pkill -9 -f qpidd` 4. start qpidd up again 5. Try to do step 2 again 6. Receive a traceback indicating the BrokerAgent is disconnected My code handles reconnect support for the connection, but it's not prepared to also handle reconnect support for the BrokerAgent connection. I would like that connection to have a reconnect support option added so I can call it like: BrokerAgent(**existing_options, reconnect=True) Having reconnect default to True is also fine w/ me. I think users may still want the option to set it also. was: [Moved from PROTON-1511] The BrokerAgent is provided by this diff: https://reviews.apache.org/r/52280/diff/3#0 Here is how to reproduce: 1. Instantiate a BrokerAgent connecting to a qpidd broker 2. Do something with the connected BrokerAgent object to show that it's working 3. kill qpidd with `pkill -9 -f qpidd` 4. start qpidd up again 5. Try to do step 2 again 6. Receive a traceback indicating the BrokerAgent is disconnected My code handles reconnect support for the connection, but it's not prepared to also handle reconnect support for the BrokerAgent connection. I would like that connection to have a reconnect support option added so I can call it like: BrokerAgent(**existing_options, reconnect=True) Having reconnect default to True is also fine w/ me. I think users may still want the option to set it also. > qmf.client.BrokerAgent does not provide reconnect support > - > > Key: QPID-7847 > URL: https://issues.apache.org/jira/browse/QPID-7847 > Project: Qpid > Issue Type: Bug > Components: QMF >Reporter: Alan Conway >Assignee: Alan Conway > > Moved from PROTON-1511 > The BrokerAgent is provided by this diff: > https://reviews.apache.org/r/52280/diff/3#0 Here is how to reproduce: > 1. Instantiate a BrokerAgent connecting to a qpidd broker > 2. Do something with the connected BrokerAgent object to show that it's > working > 3. kill qpidd with `pkill -9 -f qpidd` > 4. start qpidd up again > 5. Try to do step 2 again > 6. Receive a traceback indicating the BrokerAgent is disconnected > My code handles reconnect support for the connection, but it's not prepared > to also handle reconnect support for the BrokerAgent connection. I would like > that connection to have a reconnect support option added so I can call it > like: > BrokerAgent(**existing_options, reconnect=True) > Having reconnect default to True is also fine w/ me. I think users may still > want the option to set it also. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-7847) qmf.client.BrokerAgent does not provide reconnect support
Alan Conway created QPID-7847: - Summary: qmf.client.BrokerAgent does not provide reconnect support Key: QPID-7847 URL: https://issues.apache.org/jira/browse/QPID-7847 Project: Qpid Issue Type: Bug Components: QMF Reporter: Alan Conway Assignee: Alan Conway [Moved from PROTON-1511] The BrokerAgent is provided by this diff: https://reviews.apache.org/r/52280/diff/3#0 Here is how to reproduce: 1. Instantiate a BrokerAgent connecting to a qpidd broker 2. Do something with the connected BrokerAgent object to show that it's working 3. kill qpidd with `pkill -9 -f qpidd` 4. start qpidd up again 5. Try to do step 2 again 6. Receive a traceback indicating the BrokerAgent is disconnected My code handles reconnect support for the connection, but it's not prepared to also handle reconnect support for the BrokerAgent connection. I would like that connection to have a reconnect support option added so I can call it like: BrokerAgent(**existing_options, reconnect=True) Having reconnect default to True is also fine w/ me. I think users may still want the option to set it also. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (PROTON-1513) CLONE - BrokerAgent does not provide reconnect support
[ https://issues.apache.org/jira/browse/PROTON-1513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway closed PROTON-1513. --- Resolution: Duplicate > CLONE - BrokerAgent does not provide reconnect support > -- > > Key: PROTON-1513 > URL: https://issues.apache.org/jira/browse/PROTON-1513 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.17.0 >Reporter: Alan Conway >Assignee: Alan Conway > > The BrokerAgent is provided by this diff: > https://reviews.apache.org/r/52280/diff/3#0 Here is how to reproduce: > 1. Instantiate a BrokerAgent connecting to a qpidd broker > 2. Do something with the connected BrokerAgent object to show that it's > working > 3. kill qpidd with `pkill -9 -f qpidd` > 4. start qpidd up again > 5. Try to do step 2 again > 6. Receive a traceback indicating the BrokerAgent is disconnected > My code handles reconnect support for the connection, but it's not prepared > to also handle reconnect support for the BrokerAgent connection. I would like > that connection to have a reconnect support option added so I can call it > like: > BrokerAgent(**existing_options, reconnect=True) > Having reconnect default to True is also fine w/ me. I think users may still > want the option to set it also. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1513) CLONE - BrokerAgent does not provide reconnect support
Alan Conway created PROTON-1513: --- Summary: CLONE - BrokerAgent does not provide reconnect support Key: PROTON-1513 URL: https://issues.apache.org/jira/browse/PROTON-1513 Project: Qpid Proton Issue Type: Bug Components: python-binding Affects Versions: 0.17.0 Reporter: Alan Conway Assignee: Alan Conway The BrokerAgent is provided by this diff: https://reviews.apache.org/r/52280/diff/3#0 Here is how to reproduce: 1. Instantiate a BrokerAgent connecting to a qpidd broker 2. Do something with the connected BrokerAgent object to show that it's working 3. kill qpidd with `pkill -9 -f qpidd` 4. start qpidd up again 5. Try to do step 2 again 6. Receive a traceback indicating the BrokerAgent is disconnected My code handles reconnect support for the connection, but it's not prepared to also handle reconnect support for the BrokerAgent connection. I would like that connection to have a reconnect support option added so I can call it like: BrokerAgent(**existing_options, reconnect=True) Having reconnect default to True is also fine w/ me. I think users may still want the option to set it also. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-7846) [Java Broker] [AMQP 1.0] Transaction Coordinator Links are accumulated in LinkRegistry
Alex Rudyy created QPID-7846:
Summary: [Java Broker] [AMQP 1.0] Transaction Coordinator Links
are accumulated in LinkRegistry
Key: QPID-7846
URL: https://issues.apache.org/jira/browse/QPID-7846
Project: Qpid
Issue Type: Bug
Components: Java Broker
Affects Versions: qpid-java-broker-7.0.0
Reporter: Alex Rudyy
Transaction Coordinator links are not destroyed on detach. They are
accumulated in LinkRegistry which might cause eventually running out of memory.
As per section 4.2
"Declaring a Transaction" of AMQP spec: {quote}... the coordinator cannot be
resumed{quote}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-7842) [AMQP 1.0] Refactor link endpoint implementations
[ https://issues.apache.org/jira/browse/QPID-7842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall resolved QPID-7842. -- Resolution: Fixed > [AMQP 1.0] Refactor link endpoint implementations > - > > Key: QPID-7842 > URL: https://issues.apache.org/jira/browse/QPID-7842 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Keith Wall > Fix For: qpid-java-broker-7.0.0 > > > State is currently expressed by many maps scatter across the LinkEndPoint > hierarchy. This needs to be tidied up with supporting protocol tests added. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7815) Reject policy type
[
https://issues.apache.org/jira/browse/QPID-7815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16070375#comment-16070375
]
Keith Wall commented on QPID-7815:
--
In reply to Lorenz's point on the 21st, one possibility is to have the overflow
policy handlers consulted *before* the enqueue occurs. I am imagining a method
like {{OverflowPolicyHandler#preEnqueue(ServerMessage)}}. The method would
allow the routing to the queue(s) to be vetoed if necessary.
For the {{RejectOverflowPolicyHandler}}, its {{preEnqueue}} method would work
out if the message would be acceptable to the queue or not. It will do this by
maintaining {{pendingMessages}} and {{pendingBytes}} atomic counters. To
decide whether the message is acceptable or not, it would sum the pending
counters these with the queue's actual message/bytes statistics.The reject
policy's {{checkOverflow}} method would merely be tasked with reducing the
pending counters. It would not be able to veto the message's enqueue. To
ensure that the pending counters are decremented on rollback case, the reject
policy would need to register a on-delete listener with the message itself
(proposed: {{ServerMessage#addDeleteAction}}).
For the existing overview policies, the {{preEnqueue}} would simply accept the
message.
{{ServerMessage#isResourceAcceptable}} would be given the responsibility to
consult {{OverflowPolicyHandler#preEnqueue(ServerMessage)}}, if the queue has
an overflow policy.
I can see a disadvantage with this approach There is a race which would
manifest when a queue is approaching its limits: a newly arrive message could
be spuriously rejected if it's enqueue races 'unlucky' with another thread's
maintenance of the pending counters. I can't see how to avoid this without
single threading the some parts of the enqueue path (which I think would be
unacceptable). My hope is that this would not present problem in practice.
I also want to highlight another aspect of the proposal's behaviour. If a
message is routed to am exchange that is bound to many queues, if any queue
rejects, the message will be rejected globally and will go to none (see
RoutingResult.java:103). I don't see this is a problem, but wanted to call it
out for discussion.
> Reject policy type
> --
>
> Key: QPID-7815
> URL: https://issues.apache.org/jira/browse/QPID-7815
> Project: Qpid
> Issue Type: New Feature
> Components: Java Broker
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Tomas Vavricka
>Assignee: Lorenz Quack
> Labels: policy-type, queue, reject
> Fix For: qpid-java-broker-7.0.0
>
> Attachments:
> 0001-QPID-7815-Java-Broker-Enable-QueuePolicyTests-on-all.patch,
> 0001-QPID-7815-Reject-policy-type.patch
>
>
> It would be good if Java Broker will support reject policy.
> Reject policy - reject incoming message(s) when queue capacity is reached
> Queue capacity can be defined by maximum count of message and maximum size of
> messages (including header).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7845) [Java Broker] [AMQP 1.0] Functionality for resuming links is not fully implemented
[
https://issues.apache.org/jira/browse/QPID-7845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16070361#comment-16070361
]
Rob Godfrey commented on QPID-7845:
---
More fundamentally, since the broker does not store the link endpoint state
persistently, it doesn't really fulfil the contract for durable links.
> [Java Broker] [AMQP 1.0] Functionality for resuming links is not fully
> implemented
> --
>
> Key: QPID-7845
> URL: https://issues.apache.org/jira/browse/QPID-7845
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: qpid-java-6.0, qpid-java-6.0.1, qpid-java-6.0.2,
> qpid-java-6.0.3, qpid-java-6.0.4, qpid-java-6.0.5, qpid-java-6.0.6,
> qpid-java-6.0.7, qpid-java-6.1, qpid-java-6.1.1, qpid-java-6.1.2,
> qpid-java-broker-7.0.0, qpid-java-6.1.3, qpid-java-6.1.4, qpid-java-6.0.8
>Reporter: Alex Rudyy
>
> Existing broker implementation of resuming deliveries for sending and
> receiving links is incomplete. {{SendingLinkEndpoint}} only supports resuming
> of deliveries in terminal states {{Accepted}} and {{Released}}.
> {{StandardSendingLinkEndpoint}} can resume delivery in terminal states only.
> However, its current implementation only updates disposition and does not
> handle the case when delivery is not saved in the store.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7649) [Java Broker] Support the receipt of AMQP 1.0 Attach with incomplete-unsettled=true
[
https://issues.apache.org/jira/browse/QPID-7649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16070355#comment-16070355
]
ASF subversion and git services commented on QPID-7649:
---
Commit 737c52807080b2e54fa6f4b419c0086df375e2bc in qpid-broker-j's branch
refs/heads/master from [~alex.rufous]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=737c528 ]
QPID-7649: [Java Broker] [AMQP1.0] Add support for Attach with
incomplete-unsettled
> [Java Broker] Support the receipt of AMQP 1.0 Attach with
> incomplete-unsettled=true
> ---
>
> Key: QPID-7649
> URL: https://issues.apache.org/jira/browse/QPID-7649
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Reporter: Lorenz Quack
> Fix For: qpid-java-broker-7.0.0
>
>
> The AMQP 1.0 spec (2.7.3) allows to send an Attach with an incomplete
> {{unsettled}} map together with {{incomplete-unsettled=true}}. This is useful
> in cases where the unsettled map is too large to fit in a single frame.
> We currently do not respect this, violating the spec.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (PROTON-1511) BrokerAgent does not provide reconnect support
[ https://issues.apache.org/jira/browse/PROTON-1511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway reassigned PROTON-1511: --- Assignee: Alan Conway > BrokerAgent does not provide reconnect support > -- > > Key: PROTON-1511 > URL: https://issues.apache.org/jira/browse/PROTON-1511 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.17.0 >Reporter: Brian Bouterse >Assignee: Alan Conway > > The BrokerAgent is provided by this diff: > https://reviews.apache.org/r/52280/diff/3#0 Here is how to reproduce: > 1. Instantiate a BrokerAgent connecting to a qpidd broker > 2. Do something with the connected BrokerAgent object to show that it's > working > 3. kill qpidd with `pkill -9 -f qpidd` > 4. start qpidd up again > 5. Try to do step 2 again > 6. Receive a traceback indicating the BrokerAgent is disconnected > My code handles reconnect support for the connection, but it's not prepared > to also handle reconnect support for the BrokerAgent connection. I would like > that connection to have a reconnect support option added so I can call it > like: > BrokerAgent(**existing_options, reconnect=True) > Having reconnect default to True is also fine w/ me. I think users may still > want the option to set it also. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7845) [Java Broker] [AMQP 1.0] Functionality for resuming links is not fully implemented
[
https://issues.apache.org/jira/browse/QPID-7845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-7845:
-
Summary: [Java Broker] [AMQP 1.0] Functionality for resuming links is not
fully implemented (was: [Java Broker] [AMQP 1.0] Functionality to resuming
links is not fully implemented)
> [Java Broker] [AMQP 1.0] Functionality for resuming links is not fully
> implemented
> --
>
> Key: QPID-7845
> URL: https://issues.apache.org/jira/browse/QPID-7845
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: qpid-java-6.0, qpid-java-6.0.1, qpid-java-6.0.2,
> qpid-java-6.0.3, qpid-java-6.0.4, qpid-java-6.0.5, qpid-java-6.0.6,
> qpid-java-6.0.7, qpid-java-6.1, qpid-java-6.1.1, qpid-java-6.1.2,
> qpid-java-broker-7.0.0, qpid-java-6.1.3, qpid-java-6.1.4, qpid-java-6.0.8
>Reporter: Alex Rudyy
>
> Existing broker implementation of resuming deliveries for sending and
> receiving links is incomplete. {{SendingLinkEndpoint}} only supports resuming
> of deliveries in terminal states {{Accepted}} and {{Released}}.
> {{StandardSendingLinkEndpoint}} can resume delivery in terminal states only.
> However, its current implementation only updates disposition and does not
> handle the case when delivery is not saved in the store.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-7845) [Java Broker] [AMQP 1.0] Functionality to resuming links is not fully implemented
Alex Rudyy created QPID-7845:
Summary: [Java Broker] [AMQP 1.0] Functionality to resuming links
is not fully implemented
Key: QPID-7845
URL: https://issues.apache.org/jira/browse/QPID-7845
Project: Qpid
Issue Type: Bug
Components: Java Broker
Affects Versions: qpid-java-6.0.8, qpid-java-6.1.4, qpid-java-6.1.3,
qpid-java-6.1.2, qpid-java-6.1.1, qpid-java-6.1, qpid-java-6.0.7,
qpid-java-6.0.6, qpid-java-6.0.5, qpid-java-6.0.4, qpid-java-6.0.3,
qpid-java-6.0.2, qpid-java-6.0.1, qpid-java-6.0, qpid-java-broker-7.0.0
Reporter: Alex Rudyy
Existing broker implementation of resuming deliveries for sending and receiving
links is incomplete. {{SendingLinkEndpoint}} only supports resuming of
deliveries in terminal states {{Accepted}} and {{Released}}.
{{StandardSendingLinkEndpoint}} can resume delivery in terminal states only.
However, its current implementation only updates disposition and does not
handle the case when delivery is not saved in the store.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-7841) Remove RHEL 6 references from QPID site
[ https://issues.apache.org/jira/browse/QPID-7841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved QPID-7841. -- Resolution: Done > Remove RHEL 6 references from QPID site > --- > > Key: QPID-7841 > URL: https://issues.apache.org/jira/browse/QPID-7841 > Project: Qpid > Issue Type: Bug > Components: Packaging >Reporter: Irina Boverman >Priority: Minor > Attachments: 0001-Removed-RHEL-6-references.patch > > > RHEL 6 is no longer supported by QPID project. > We need to remove the Copr and EL6 parts from the Qpid website: > http://qpid.apache.org/packages.html > > https://git-wip-us.apache.org/repos/asf?p=qpid-site.git;a=tree > > https://git-wip-us.apache.org/repos/asf?p=qpid-site.git;a=blob_plain;f=README.md > > https://git-wip-us.apache.org/repos/asf?p=qpid-site.git;a=blob;f=input/packages.md -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-927) absolute-expiry-time and creation-time are encoded as 0 if not set
[ https://issues.apache.org/jira/browse/PROTON-927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16070208#comment-16070208 ] Andrew Stitcher commented on PROTON-927: [~jr...@redhat.com] Do you think we should block 0.18 for this problem? Considering that this issue and others related to default values keep on cropping up? If we don't prioritise it somehow it'll keep on getting pushed in to "the next" release. > absolute-expiry-time and creation-time are encoded as 0 if not set > -- > > Key: PROTON-927 > URL: https://issues.apache.org/jira/browse/PROTON-927 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.9.1 >Reporter: Gordon Sim > Fix For: 0.18.0 > > > They should instead be encoded as null (since there is no default). -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDIT-85) Tests don't limit the number of times it tries to connect to a broker
[
https://issues.apache.org/jira/browse/QPIDIT-85?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kim van der Riet updated QPIDIT-85:
---
Summary: Tests don't limit the number of times it tries to connect to a
broker (was: Tests dont limit the number of times it tries to connect to a
broker)
> Tests don't limit the number of times it tries to connect to a broker
> -
>
> Key: QPIDIT-85
> URL: https://issues.apache.org/jira/browse/QPIDIT-85
> Project: Apache QPID Interoperability Test Suite
> Issue Type: Bug
>Reporter: Kim van der Riet
>Assignee: Kim van der Riet
>
> When no broker is present, or when a misconfiguration prevents communication
> to the broker, then the test keeps attempting to connect without time or
> number limit:
> {noformat}
> ERROR:root:proton:io: recv: Connection refused
> ERROR:root:proton:io: recv: Connection refused
> ERROR:root:proton:io: recv: Connection refused
> ERROR:root:proton:io: recv: Connection refused
> ...
> {noformat}
> and will keep trying indefinitely, effectively hanging the test.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7844) Recover metadata into direct memory [6.0.x]
[ https://issues.apache.org/jira/browse/QPID-7844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16070122#comment-16070122 ] ASF subversion and git services commented on QPID-7844: --- Commit cf4987a3ea641c3d5a76e04c92fd3c6b57c65c6b in qpid-broker-j's branch refs/heads/6.0.x from [~k-wall] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=cf4987a ] QPID-7844: Recover metadata into direct memory [6.0.x] > Recover metadata into direct memory [6.0.x] > --- > > Key: QPID-7844 > URL: https://issues.apache.org/jira/browse/QPID-7844 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Keith Wall > Fix For: qpid-java-6.0.9 > > > The intention of QPID-7791 was to merge > https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=5293cc0 into > 6.0.x. There was an error and this was missed. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-927) absolute-expiry-time and creation-time are encoded as 0 if not set
[ https://issues.apache.org/jira/browse/PROTON-927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16070060#comment-16070060 ] Gordon Sim commented on PROTON-927: --- Original commit was https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;a=commit;h=57b0f34ab9904209fdc67aa066c72e0f80b3e966 (_ instead of - prevented JIRA picking it up). > absolute-expiry-time and creation-time are encoded as 0 if not set > -- > > Key: PROTON-927 > URL: https://issues.apache.org/jira/browse/PROTON-927 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.9.1 >Reporter: Gordon Sim > Fix For: 0.18.0 > > > They should instead be encoded as null (since there is no default). -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-7844) Recover metadata into direct memory [6.0.x]
Keith Wall created QPID-7844: Summary: Recover metadata into direct memory [6.0.x] Key: QPID-7844 URL: https://issues.apache.org/jira/browse/QPID-7844 Project: Qpid Issue Type: Improvement Components: Java Broker Reporter: Keith Wall Fix For: qpid-java-6.0.9 The intention of QPID-7791 was to merge https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=5293cc0 into 6.0.x. There was an error and this was missed. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Next Qpid JMS (0.24.0) / Proton-J (0.20.0) release dates?
On 30 June 2017 at 11:22, Keith W wrote: > Thanks Robbie. > > I'm planning for us to take a look at both the Proton-J change and > Qpid JMS Client next month (I was the original contributor if the Qpid > JMS Client SCRAM SHA module, after all) , so except to see some > patches from us on the reviewboard for comment. I don't think we'll > be able to take on corresponding changes for Proton-C (my C skills are > 17 years rusty), so we'll have to leave those to others. > I just meant establishing whether any matching changes are actually needed on other bits rather than actually doing them if there are (some tangential discussion suggests it might not be). We'd obviously want to avoid breaking things by only changing some bits at a particular time and not others if they do need it. > For the Proton-J change and Qpid JMS Client releases, we don't need > these changes urgently, so I was hoping to piggyback if there is a > release due in the next four to six weeks, otherwise we might push > things forward ourselves. > I'm happy to spin a release almost any time I'm actually around and not on holiday hehe. If theres demand for something and its considered ready then it can generally be released quickly. > > > On 30 June 2017 at 11:06, Robbie Gemmell wrote: >> On 29 June 2017 at 13:06, Keith W wrote: >>> Hello, >>> >>> Are there release dates in mind for Proton-J (0.20.0) and Qpid JMS >>> (0.24.0)? >> >> Nothing specific no, except not next week due to holidays etc (unless >> others feel like doing a release...). Essentially they are mostly >> released whenever theres something interesting enough ready or it >> seems too long otherwise. >> >>> >>> We are moving towards a Qpid Broker J major release next quarter. The >>> release backlog includes QPID-7787 [1] which will utilise the AMQP 1.0 >>> additional data field of the SASL outcome [2]. In order to be useful >>> end to end, this will need a corresponding change in the Qpid JMS >>> Client, QPIDJMS-294 [3], and a Proton J change to expose the data [4]. >>> >> >> Perhaps also including checking the interaction with Dispatch, the c++ >> broker, and proton-c plus bindings when using Cyrus, etc. >> >> I looked at Rob's patch on >> https://issues.apache.org/jira/browse/PROTON-1486 previously and >> mentioned to him it seems like it will work (tests might show :P) >> though I was hesitant whether it would be better to expose the value >> explicitly than feeding it though the same API+fields as the >> challenge/response. I did agree the things that might not work >> shouldnt really happen and are mostly already an issue regardless >> though. >> >> I haven't looked at the client side yet to see whats needed there. >> Perhaps folks that wrote those/related bits might have a better idea? >> :) >> >>> I want to understand the schedule so we can ensure the work on those >>> JIRAs is ready for consideration/inclusion. >>> >>> cheers, Keith. >>> >>> [1] https://issues.apache.org/jira/browse/QPID-7787 >>> [2] >>> http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-security-v1.0-os.html#type-sasl-outcome >>> [3] https://issues.apache.org/jira/browse/QPIDJMS-294 >>> [4] https://issues.apache.org/jira/browse/PROTON-1486 >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org >>> For additional commands, e-mail: dev-h...@qpid.apache.org >>> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org >> For additional commands, e-mail: dev-h...@qpid.apache.org >> > > - > To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org > For additional commands, e-mail: dev-h...@qpid.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Next Qpid JMS (0.24.0) / Proton-J (0.20.0) release dates?
Thanks Robbie. I'm planning for us to take a look at both the Proton-J change and Qpid JMS Client next month (I was the original contributor if the Qpid JMS Client SCRAM SHA module, after all) , so except to see some patches from us on the reviewboard for comment. I don't think we'll be able to take on corresponding changes for Proton-C (my C skills are 17 years rusty), so we'll have to leave those to others. For the Proton-J change and Qpid JMS Client releases, we don't need these changes urgently, so I was hoping to piggyback if there is a release due in the next four to six weeks, otherwise we might push things forward ourselves. On 30 June 2017 at 11:06, Robbie Gemmell wrote: > On 29 June 2017 at 13:06, Keith W wrote: >> Hello, >> >> Are there release dates in mind for Proton-J (0.20.0) and Qpid JMS (0.24.0)? > > Nothing specific no, except not next week due to holidays etc (unless > others feel like doing a release...). Essentially they are mostly > released whenever theres something interesting enough ready or it > seems too long otherwise. > >> >> We are moving towards a Qpid Broker J major release next quarter. The >> release backlog includes QPID-7787 [1] which will utilise the AMQP 1.0 >> additional data field of the SASL outcome [2]. In order to be useful >> end to end, this will need a corresponding change in the Qpid JMS >> Client, QPIDJMS-294 [3], and a Proton J change to expose the data [4]. >> > > Perhaps also including checking the interaction with Dispatch, the c++ > broker, and proton-c plus bindings when using Cyrus, etc. > > I looked at Rob's patch on > https://issues.apache.org/jira/browse/PROTON-1486 previously and > mentioned to him it seems like it will work (tests might show :P) > though I was hesitant whether it would be better to expose the value > explicitly than feeding it though the same API+fields as the > challenge/response. I did agree the things that might not work > shouldnt really happen and are mostly already an issue regardless > though. > > I haven't looked at the client side yet to see whats needed there. > Perhaps folks that wrote those/related bits might have a better idea? > :) > >> I want to understand the schedule so we can ensure the work on those >> JIRAs is ready for consideration/inclusion. >> >> cheers, Keith. >> >> [1] https://issues.apache.org/jira/browse/QPID-7787 >> [2] >> http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-security-v1.0-os.html#type-sasl-outcome >> [3] https://issues.apache.org/jira/browse/QPIDJMS-294 >> [4] https://issues.apache.org/jira/browse/PROTON-1486 >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org >> For additional commands, e-mail: dev-h...@qpid.apache.org >> > > - > To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org > For additional commands, e-mail: dev-h...@qpid.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Next Qpid JMS (0.24.0) / Proton-J (0.20.0) release dates?
On 29 June 2017 at 13:06, Keith W wrote: > Hello, > > Are there release dates in mind for Proton-J (0.20.0) and Qpid JMS (0.24.0)? Nothing specific no, except not next week due to holidays etc (unless others feel like doing a release...). Essentially they are mostly released whenever theres something interesting enough ready or it seems too long otherwise. > > We are moving towards a Qpid Broker J major release next quarter. The > release backlog includes QPID-7787 [1] which will utilise the AMQP 1.0 > additional data field of the SASL outcome [2]. In order to be useful > end to end, this will need a corresponding change in the Qpid JMS > Client, QPIDJMS-294 [3], and a Proton J change to expose the data [4]. > Perhaps also including checking the interaction with Dispatch, the c++ broker, and proton-c plus bindings when using Cyrus, etc. I looked at Rob's patch on https://issues.apache.org/jira/browse/PROTON-1486 previously and mentioned to him it seems like it will work (tests might show :P) though I was hesitant whether it would be better to expose the value explicitly than feeding it though the same API+fields as the challenge/response. I did agree the things that might not work shouldnt really happen and are mostly already an issue regardless though. I haven't looked at the client side yet to see whats needed there. Perhaps folks that wrote those/related bits might have a better idea? :) > I want to understand the schedule so we can ensure the work on those > JIRAs is ready for consideration/inclusion. > > cheers, Keith. > > [1] https://issues.apache.org/jira/browse/QPID-7787 > [2] > http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-security-v1.0-os.html#type-sasl-outcome > [3] https://issues.apache.org/jira/browse/QPIDJMS-294 > [4] https://issues.apache.org/jira/browse/PROTON-1486 > > - > To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org > For additional commands, e-mail: dev-h...@qpid.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7842) [AMQP 1.0] Refactor link endpoint implementations
[ https://issues.apache.org/jira/browse/QPID-7842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16069811#comment-16069811 ] ASF subversion and git services commented on QPID-7842: --- Commit 72ed1aa525272e70c696459d0f13e67781970258 in qpid-broker-j's branch refs/heads/master from [~alex.rufous] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=72ed1aa ] QPID-7842: Add protocol test ensuring that the same delivery tag can be re-used after delivery is settled > [AMQP 1.0] Refactor link endpoint implementations > - > > Key: QPID-7842 > URL: https://issues.apache.org/jira/browse/QPID-7842 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Keith Wall > Fix For: qpid-java-broker-7.0.0 > > > State is currently expressed by many maps scatter across the LinkEndPoint > hierarchy. This needs to be tidied up with supporting protocol tests added. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
