[jira] [Comment Edited] (DISPATCH-1496) router can grant extra credit during drain of a link-routed receiver
[
https://issues.apache.org/jira/browse/DISPATCH-1496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16981941#comment-16981941
]
Ganesh Murthy edited comment on DISPATCH-1496 at 11/25/19 10:13 PM:
To reproduce this problem -
# Start broker and add a queue called examples. The broker should listen for
AMQP requests on port amqp
# Start the router with the attached config file (qdrouterd.conf). The config
sets up link routes with prefix "examples"
# Send a single message via the router to the broker queue - python
simple_send.py -m1 --address 0.0.0.0:23456/examples
# Run the attached reproducer - python simple_recv_drain.py --address
0.0.0.0:23456/examples
# You will see that the router incorrectly grants additional credit.
was (Author: ganeshmurthy):
To reproduce this problem -
# Start broker and add a queue called examples. The broker should listen for
AMQP requests on port amqp
# Start the router with the attached config file. The config has link routes
# Send a single message via the router to the broker queue - python
simple_send.py -m1 --address 0.0.0.0:23456/examples
# Run the attached reproducer - python simple_recv_drain.py --address
0.0.0.0:23456/examples
# You will see that the router incorrectly grants additional credit.
> router can grant extra credit during drain of a link-routed receiver
>
>
> Key: DISPATCH-1496
> URL: https://issues.apache.org/jira/browse/DISPATCH-1496
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 1.10.0
>Reporter: Robbie Gemmell
>Assignee: Ganesh Murthy
>Priority: Major
> Attachments: qdrouterd.conf, simple_recv_drain.py
>
>
> The router can grant extra credit during drain of a link-routed receiver,
> leading to the router having more outstanding credit to the peer than the
> receiver has actually granted.
> The following shows a link-routed receiver draining credit from the link,
> after a single message having been received from the broker it was
> link-routed to. The router relays the flow from client to broker as expected,
> with "delivery-count=1, link-credit=999, drain=true", and relays the brokers
> response with "delivery-count=1000, link-credit=0, drain=true":
> {noformat}
> [0x27bb800]:1 <- @flow(19) [next-incoming-id=1, incoming-window=2047,
> next-outgoing-id=5, outgoing-window=2147483647, handle=2, delivery-count=1,
> link-credit=999, drain=true]
> [0x2763c90]:0 -> @flow(19) [next-incoming-id=2, incoming-window=2147483647,
> next-outgoing-id=4, outgoing-window=2147483647, handle=2, delivery-count=1,
> link-credit=999, drain=true]
> [0x2763c90]:0 <- @flow(19) [next-incoming-id=4, incoming-window=2147483647,
> next-outgoing-id=2, outgoing-window=2147483647, handle=2,
> delivery-count=1000, link-credit=0, drain=true]
> [0x27bb800]:1 -> @flow(19) [next-incoming-id=5, incoming-window=2147483647,
> next-outgoing-id=1, outgoing-window=2147483647, handle=2,
> delivery-count=1000, link-credit=0, drain=true]
> {noformat}
> The receiver then supplies more credit, which the router again relays as
> expected:
> {noformat}
> [0x27bb800]:1 <- @flow(19) [next-incoming-id=1, incoming-window=2047,
> next-outgoing-id=5, outgoing-window=2147483647, handle=2,
> delivery-count=1000, link-credit=1000]
> [0x2763c90]:0 -> @flow(19) [next-incoming-id=2, incoming-window=2147483647,
> next-outgoing-id=4, outgoing-window=2147483647, handle=2,
> delivery-count=1000, link-credit=1000, drain=false]
> {noformat}
> The receiver then drained this credit without having received any messages.
> The router relays the drain, but _incorrectly grants additional credit to the
> broker at the same time_, despite the receiver not having done so itself. The
> credit is drained, and the router updates the receiver to note it is also
> drained. Note however that the delivery counts have now diverged between
> client->router and router->broker, which seems unexpected for a link route.
> {noformat}
> [0x27bb800]:1 <- @flow(19) [next-incoming-id=1, incoming-window=2047,
> next-outgoing-id=7, outgoing-window=2147483647, handle=2,
> delivery-count=1000, link-credit=1000, drain=true]
> [0x2763c90]:0 -> @flow(19) [next-incoming-id=2, incoming-window=2147483647,
> next-outgoing-id=6, outgoing-window=2147483647, handle=2,
> delivery-count=1000, link-credit=2000, drain=true]
> [0x2763c90]:0 <- @flow(19) [next-incoming-id=6, incoming-window=2147483647,
> next-outgoing-id=2, outgoing-window=2147483647, handle=2,
> delivery-count=3000, link-credit=0, drain=true]
> [0x27bb800]:1 -> @flow(19) [next-incoming-id=7, incoming-window=2147483647,
> next-outgoing-id=1, outgoing-window=2147483647, handle=2,
> delivery-count=2000, link-credit=0, drain=true]
> {noformat}
> Had the
[jira] [Updated] (DISPATCH-1496) router can grant extra credit during drain of a link-routed receiver
[
https://issues.apache.org/jira/browse/DISPATCH-1496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ganesh Murthy updated DISPATCH-1496:
Attachment: simple_recv_drain.py
> router can grant extra credit during drain of a link-routed receiver
>
>
> Key: DISPATCH-1496
> URL: https://issues.apache.org/jira/browse/DISPATCH-1496
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 1.10.0
>Reporter: Robbie Gemmell
>Assignee: Ganesh Murthy
>Priority: Major
> Attachments: qdrouterd.conf, simple_recv_drain.py
>
>
> The router can grant extra credit during drain of a link-routed receiver,
> leading to the router having more outstanding credit to the peer than the
> receiver has actually granted.
> The following shows a link-routed receiver draining credit from the link,
> after a single message having been received from the broker it was
> link-routed to. The router relays the flow from client to broker as expected,
> with "delivery-count=1, link-credit=999, drain=true", and relays the brokers
> response with "delivery-count=1000, link-credit=0, drain=true":
> {noformat}
> [0x27bb800]:1 <- @flow(19) [next-incoming-id=1, incoming-window=2047,
> next-outgoing-id=5, outgoing-window=2147483647, handle=2, delivery-count=1,
> link-credit=999, drain=true]
> [0x2763c90]:0 -> @flow(19) [next-incoming-id=2, incoming-window=2147483647,
> next-outgoing-id=4, outgoing-window=2147483647, handle=2, delivery-count=1,
> link-credit=999, drain=true]
> [0x2763c90]:0 <- @flow(19) [next-incoming-id=4, incoming-window=2147483647,
> next-outgoing-id=2, outgoing-window=2147483647, handle=2,
> delivery-count=1000, link-credit=0, drain=true]
> [0x27bb800]:1 -> @flow(19) [next-incoming-id=5, incoming-window=2147483647,
> next-outgoing-id=1, outgoing-window=2147483647, handle=2,
> delivery-count=1000, link-credit=0, drain=true]
> {noformat}
> The receiver then supplies more credit, which the router again relays as
> expected:
> {noformat}
> [0x27bb800]:1 <- @flow(19) [next-incoming-id=1, incoming-window=2047,
> next-outgoing-id=5, outgoing-window=2147483647, handle=2,
> delivery-count=1000, link-credit=1000]
> [0x2763c90]:0 -> @flow(19) [next-incoming-id=2, incoming-window=2147483647,
> next-outgoing-id=4, outgoing-window=2147483647, handle=2,
> delivery-count=1000, link-credit=1000, drain=false]
> {noformat}
> The receiver then drained this credit without having received any messages.
> The router relays the drain, but _incorrectly grants additional credit to the
> broker at the same time_, despite the receiver not having done so itself. The
> credit is drained, and the router updates the receiver to note it is also
> drained. Note however that the delivery counts have now diverged between
> client->router and router->broker, which seems unexpected for a link route.
> {noformat}
> [0x27bb800]:1 <- @flow(19) [next-incoming-id=1, incoming-window=2047,
> next-outgoing-id=7, outgoing-window=2147483647, handle=2,
> delivery-count=1000, link-credit=1000, drain=true]
> [0x2763c90]:0 -> @flow(19) [next-incoming-id=2, incoming-window=2147483647,
> next-outgoing-id=6, outgoing-window=2147483647, handle=2,
> delivery-count=1000, link-credit=2000, drain=true]
> [0x2763c90]:0 <- @flow(19) [next-incoming-id=6, incoming-window=2147483647,
> next-outgoing-id=2, outgoing-window=2147483647, handle=2,
> delivery-count=3000, link-credit=0, drain=true]
> [0x27bb800]:1 -> @flow(19) [next-incoming-id=7, incoming-window=2147483647,
> next-outgoing-id=1, outgoing-window=2147483647, handle=2,
> delivery-count=2000, link-credit=0, drain=true]
> {noformat}
> Had the broker been able to send messages using the mistakenly granted extra
> credit, the router would not be able to pass these all on to the client until
> it granted more credit. It isnt clear what would happen to them, but it seems
> like they could get stuck in the router until more credit is granted by the
> receiver, or the receiver detaches, etc. Again, unexpected for a link-route.
> The system continued on in this case since since this receiver grants (and
> drains) new credit:
> {noformat}
> [0x27bb800]:1 <- @flow(19) [next-incoming-id=1, incoming-window=2047,
> next-outgoing-id=7, outgoing-window=2147483647, handle=2,
> delivery-count=2000, link-credit=1000]
> [0x2763c90]:0 -> @flow(19) [next-incoming-id=2, incoming-window=2147483647,
> next-outgoing-id=6, outgoing-window=2147483647, handle=2,
> delivery-count=3000, link-credit=1000, drain=false]
> etc etc
> {noformat}
> however the delivery-count divergence grows over time as the situation
> repeats.
>
> Noticed while trying out changes for DISPATCH-1488.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
[jira] [Updated] (DISPATCH-1496) router can grant extra credit during drain of a link-routed receiver
[
https://issues.apache.org/jira/browse/DISPATCH-1496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ganesh Murthy updated DISPATCH-1496:
Attachment: qdrouterd.conf
> router can grant extra credit during drain of a link-routed receiver
>
>
> Key: DISPATCH-1496
> URL: https://issues.apache.org/jira/browse/DISPATCH-1496
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 1.10.0
>Reporter: Robbie Gemmell
>Assignee: Ganesh Murthy
>Priority: Major
> Attachments: qdrouterd.conf
>
>
> The router can grant extra credit during drain of a link-routed receiver,
> leading to the router having more outstanding credit to the peer than the
> receiver has actually granted.
> The following shows a link-routed receiver draining credit from the link,
> after a single message having been received from the broker it was
> link-routed to. The router relays the flow from client to broker as expected,
> with "delivery-count=1, link-credit=999, drain=true", and relays the brokers
> response with "delivery-count=1000, link-credit=0, drain=true":
> {noformat}
> [0x27bb800]:1 <- @flow(19) [next-incoming-id=1, incoming-window=2047,
> next-outgoing-id=5, outgoing-window=2147483647, handle=2, delivery-count=1,
> link-credit=999, drain=true]
> [0x2763c90]:0 -> @flow(19) [next-incoming-id=2, incoming-window=2147483647,
> next-outgoing-id=4, outgoing-window=2147483647, handle=2, delivery-count=1,
> link-credit=999, drain=true]
> [0x2763c90]:0 <- @flow(19) [next-incoming-id=4, incoming-window=2147483647,
> next-outgoing-id=2, outgoing-window=2147483647, handle=2,
> delivery-count=1000, link-credit=0, drain=true]
> [0x27bb800]:1 -> @flow(19) [next-incoming-id=5, incoming-window=2147483647,
> next-outgoing-id=1, outgoing-window=2147483647, handle=2,
> delivery-count=1000, link-credit=0, drain=true]
> {noformat}
> The receiver then supplies more credit, which the router again relays as
> expected:
> {noformat}
> [0x27bb800]:1 <- @flow(19) [next-incoming-id=1, incoming-window=2047,
> next-outgoing-id=5, outgoing-window=2147483647, handle=2,
> delivery-count=1000, link-credit=1000]
> [0x2763c90]:0 -> @flow(19) [next-incoming-id=2, incoming-window=2147483647,
> next-outgoing-id=4, outgoing-window=2147483647, handle=2,
> delivery-count=1000, link-credit=1000, drain=false]
> {noformat}
> The receiver then drained this credit without having received any messages.
> The router relays the drain, but _incorrectly grants additional credit to the
> broker at the same time_, despite the receiver not having done so itself. The
> credit is drained, and the router updates the receiver to note it is also
> drained. Note however that the delivery counts have now diverged between
> client->router and router->broker, which seems unexpected for a link route.
> {noformat}
> [0x27bb800]:1 <- @flow(19) [next-incoming-id=1, incoming-window=2047,
> next-outgoing-id=7, outgoing-window=2147483647, handle=2,
> delivery-count=1000, link-credit=1000, drain=true]
> [0x2763c90]:0 -> @flow(19) [next-incoming-id=2, incoming-window=2147483647,
> next-outgoing-id=6, outgoing-window=2147483647, handle=2,
> delivery-count=1000, link-credit=2000, drain=true]
> [0x2763c90]:0 <- @flow(19) [next-incoming-id=6, incoming-window=2147483647,
> next-outgoing-id=2, outgoing-window=2147483647, handle=2,
> delivery-count=3000, link-credit=0, drain=true]
> [0x27bb800]:1 -> @flow(19) [next-incoming-id=7, incoming-window=2147483647,
> next-outgoing-id=1, outgoing-window=2147483647, handle=2,
> delivery-count=2000, link-credit=0, drain=true]
> {noformat}
> Had the broker been able to send messages using the mistakenly granted extra
> credit, the router would not be able to pass these all on to the client until
> it granted more credit. It isnt clear what would happen to them, but it seems
> like they could get stuck in the router until more credit is granted by the
> receiver, or the receiver detaches, etc. Again, unexpected for a link-route.
> The system continued on in this case since since this receiver grants (and
> drains) new credit:
> {noformat}
> [0x27bb800]:1 <- @flow(19) [next-incoming-id=1, incoming-window=2047,
> next-outgoing-id=7, outgoing-window=2147483647, handle=2,
> delivery-count=2000, link-credit=1000]
> [0x2763c90]:0 -> @flow(19) [next-incoming-id=2, incoming-window=2147483647,
> next-outgoing-id=6, outgoing-window=2147483647, handle=2,
> delivery-count=3000, link-credit=1000, drain=false]
> etc etc
> {noformat}
> however the delivery-count divergence grows over time as the situation
> repeats.
>
> Noticed while trying out changes for DISPATCH-1488.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To
[jira] [Commented] (DISPATCH-1496) router can grant extra credit during drain of a link-routed receiver
[
https://issues.apache.org/jira/browse/DISPATCH-1496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16981941#comment-16981941
]
Ganesh Murthy commented on DISPATCH-1496:
-
To reproduce this problem -
# Start broker and add a queue called examples. The broker should listen for
AMQP requests on port amqp
# Start the router with the attached config file. The config has link routes
# Send a single message via the router to the broker queue - python
simple_send.py -m1 --address 0.0.0.0:23456/examples
# Run the attached reproducer - python simple_recv_drain.py --address
0.0.0.0:23456/examples
# You will see that the router incorrectly grants additional credit.
> router can grant extra credit during drain of a link-routed receiver
>
>
> Key: DISPATCH-1496
> URL: https://issues.apache.org/jira/browse/DISPATCH-1496
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 1.10.0
>Reporter: Robbie Gemmell
>Assignee: Ganesh Murthy
>Priority: Major
>
> The router can grant extra credit during drain of a link-routed receiver,
> leading to the router having more outstanding credit to the peer than the
> receiver has actually granted.
> The following shows a link-routed receiver draining credit from the link,
> after a single message having been received from the broker it was
> link-routed to. The router relays the flow from client to broker as expected,
> with "delivery-count=1, link-credit=999, drain=true", and relays the brokers
> response with "delivery-count=1000, link-credit=0, drain=true":
> {noformat}
> [0x27bb800]:1 <- @flow(19) [next-incoming-id=1, incoming-window=2047,
> next-outgoing-id=5, outgoing-window=2147483647, handle=2, delivery-count=1,
> link-credit=999, drain=true]
> [0x2763c90]:0 -> @flow(19) [next-incoming-id=2, incoming-window=2147483647,
> next-outgoing-id=4, outgoing-window=2147483647, handle=2, delivery-count=1,
> link-credit=999, drain=true]
> [0x2763c90]:0 <- @flow(19) [next-incoming-id=4, incoming-window=2147483647,
> next-outgoing-id=2, outgoing-window=2147483647, handle=2,
> delivery-count=1000, link-credit=0, drain=true]
> [0x27bb800]:1 -> @flow(19) [next-incoming-id=5, incoming-window=2147483647,
> next-outgoing-id=1, outgoing-window=2147483647, handle=2,
> delivery-count=1000, link-credit=0, drain=true]
> {noformat}
> The receiver then supplies more credit, which the router again relays as
> expected:
> {noformat}
> [0x27bb800]:1 <- @flow(19) [next-incoming-id=1, incoming-window=2047,
> next-outgoing-id=5, outgoing-window=2147483647, handle=2,
> delivery-count=1000, link-credit=1000]
> [0x2763c90]:0 -> @flow(19) [next-incoming-id=2, incoming-window=2147483647,
> next-outgoing-id=4, outgoing-window=2147483647, handle=2,
> delivery-count=1000, link-credit=1000, drain=false]
> {noformat}
> The receiver then drained this credit without having received any messages.
> The router relays the drain, but _incorrectly grants additional credit to the
> broker at the same time_, despite the receiver not having done so itself. The
> credit is drained, and the router updates the receiver to note it is also
> drained. Note however that the delivery counts have now diverged between
> client->router and router->broker, which seems unexpected for a link route.
> {noformat}
> [0x27bb800]:1 <- @flow(19) [next-incoming-id=1, incoming-window=2047,
> next-outgoing-id=7, outgoing-window=2147483647, handle=2,
> delivery-count=1000, link-credit=1000, drain=true]
> [0x2763c90]:0 -> @flow(19) [next-incoming-id=2, incoming-window=2147483647,
> next-outgoing-id=6, outgoing-window=2147483647, handle=2,
> delivery-count=1000, link-credit=2000, drain=true]
> [0x2763c90]:0 <- @flow(19) [next-incoming-id=6, incoming-window=2147483647,
> next-outgoing-id=2, outgoing-window=2147483647, handle=2,
> delivery-count=3000, link-credit=0, drain=true]
> [0x27bb800]:1 -> @flow(19) [next-incoming-id=7, incoming-window=2147483647,
> next-outgoing-id=1, outgoing-window=2147483647, handle=2,
> delivery-count=2000, link-credit=0, drain=true]
> {noformat}
> Had the broker been able to send messages using the mistakenly granted extra
> credit, the router would not be able to pass these all on to the client until
> it granted more credit. It isnt clear what would happen to them, but it seems
> like they could get stuck in the router until more credit is granted by the
> receiver, or the receiver detaches, etc. Again, unexpected for a link-route.
> The system continued on in this case since since this receiver grants (and
> drains) new credit:
> {noformat}
> [0x27bb800]:1 <- @flow(19) [next-incoming-id=1, incoming-window=2047,
> next-outgoing-id=7, outgoing-window=2147483647, handle=2,
> delivery-count=2000, link-credit=1000]
> [0x2763c
[jira] [Resolved] (DISPATCH-1476) [tools] New proton logging breaks Scraper
[ https://issues.apache.org/jira/browse/DISPATCH-1476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charles E. Rolke resolved DISPATCH-1476. Fix Version/s: 1.10.0 Resolution: Fixed Fixed at commit e805072 > [tools] New proton logging breaks Scraper > - > > Key: DISPATCH-1476 > URL: https://issues.apache.org/jira/browse/DISPATCH-1476 > Project: Qpid Dispatch > Issue Type: Bug > Components: Tools >Affects Versions: 1.9.0 > Environment: all >Reporter: Charles E. Rolke >Assignee: Charles E. Rolke >Priority: Major > Fix For: 1.10.0 > > > For starters the new logging injects *FRAME:* into log text. Scraper needs to > accommodate that. It will take some time to discover all the changes and > agree that what proton is doing is correct. > Until then this issue tracks disabling the scraper self test and re-enabling > it when the log formats have settled. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1497) [test] system tests fallback_dest test times out occasionally
Charles E. Rolke created DISPATCH-1497:
--
Summary: [test] system tests fallback_dest test times out
occasionally
Key: DISPATCH-1497
URL: https://issues.apache.org/jira/browse/DISPATCH-1497
Project: Qpid Dispatch
Issue Type: Bug
Components: Router Node, Tools
Affects Versions: 1.9.0
Environment: Fedora 29. Proton 0.29.0
Reporter: Charles E. Rolke
The fallback_dest typically completes in 40-45 seconds on my machine.
Occasionally, the test times out with:
{noformat}
61: File "/home/chug/git/qpid-dispatch/tests/system_tests_fallback_dest.py",
line 350, in test_35_switchover_mix_1
61: self.assertEqual(None, test.error)
61: AssertionError: None != 'Timeout Expired - n_tx=0, n_rx=0, n_rel=2799,
phase=1'
61: Ran 50 tests in 100.831s
{noformat}
Increasing the test timeout from 60 to 240 seconds produces the same result but
it takes a total of 280 seconds.
In all recorded failures the counters n_tx=0 and n_rx=0 are the same. The n_rel
varies around 2800 (2799, 2816).
The most successful loops before a failure was 120. Usually it fails in around
10 loops.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (PROTON-2146) Reduce memory per connection
[ https://issues.apache.org/jira/browse/PROTON-2146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clifford Jansen resolved PROTON-2146. - Fix Version/s: proton-c-0.30.0 Resolution: Fixed > Reduce memory per connection > > > Key: PROTON-2146 > URL: https://issues.apache.org/jira/browse/PROTON-2146 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: proton-c-0.29.0 >Reporter: Clifford Jansen >Assignee: Clifford Jansen >Priority: Major > Fix For: proton-c-0.30.0 > > > The transport currently starts with 2 16K buffers: one for input and one for > output, and they grow from there depending on load. > Instrumenting with Quiver and Qpid dispatch router shows that these starting > buffer sizes can be reduced to 8K without detectable performance degradation. > This can reduce memory load by close to 16K per connection for processes with > large numbers of lightly loaded connections. Connections with heavier load > will still grow as large as before, but with one extra 8K->16K growth step in > buffer size. > Reducing to 4K does lead to a degradation of several percent and further > reductions to 2K leads to a degradation closer to 20%. So smaller starting > sizes are not considered for now, but reworking the transport growth strategy > might make it possible in future. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2146) Reduce memory per connection
[ https://issues.apache.org/jira/browse/PROTON-2146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16981867#comment-16981867 ] ASF subversion and git services commented on PROTON-2146: - Commit b53246cacf63f60745fa0a6fa7b50e5545fd23ec in qpid-proton's branch refs/heads/master from Clifford Jansen [ https://gitbox.apache.org/repos/asf?p=qpid-proton.git;h=b53246c ] PROTON-2146: reduce memory per connection for lightly loaded connections > Reduce memory per connection > > > Key: PROTON-2146 > URL: https://issues.apache.org/jira/browse/PROTON-2146 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: proton-c-0.29.0 >Reporter: Clifford Jansen >Assignee: Clifford Jansen >Priority: Major > > The transport currently starts with 2 16K buffers: one for input and one for > output, and they grow from there depending on load. > Instrumenting with Quiver and Qpid dispatch router shows that these starting > buffer sizes can be reduced to 8K without detectable performance degradation. > This can reduce memory load by close to 16K per connection for processes with > large numbers of lightly loaded connections. Connections with heavier load > will still grow as large as before, but with one extra 8K->16K growth step in > buffer size. > Reducing to 4K does lead to a degradation of several percent and further > reductions to 2K leads to a degradation closer to 20%. So smaller starting > sizes are not considered for now, but reworking the transport growth strategy > might make it possible in future. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-2146) Reduce memory per connection
Clifford Jansen created PROTON-2146: --- Summary: Reduce memory per connection Key: PROTON-2146 URL: https://issues.apache.org/jira/browse/PROTON-2146 Project: Qpid Proton Issue Type: Improvement Components: proton-c Affects Versions: proton-c-0.29.0 Reporter: Clifford Jansen Assignee: Clifford Jansen The transport currently starts with 2 16K buffers: one for input and one for output, and they grow from there depending on load. Instrumenting with Quiver and Qpid dispatch router shows that these starting buffer sizes can be reduced to 8K without detectable performance degradation. This can reduce memory load by close to 16K per connection for processes with large numbers of lightly loaded connections. Connections with heavier load will still grow as large as before, but with one extra 8K->16K growth step in buffer size. Reducing to 4K does lead to a degradation of several percent and further reductions to 2K leads to a degradation closer to 20%. So smaller starting sizes are not considered for now, but reworking the transport growth strategy might make it possible in future. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (DISPATCH-1496) router can grant extra credit during drain of a link-routed receiver
[
https://issues.apache.org/jira/browse/DISPATCH-1496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ganesh Murthy reassigned DISPATCH-1496:
---
Assignee: Ganesh Murthy
> router can grant extra credit during drain of a link-routed receiver
>
>
> Key: DISPATCH-1496
> URL: https://issues.apache.org/jira/browse/DISPATCH-1496
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 1.10.0
>Reporter: Robbie Gemmell
>Assignee: Ganesh Murthy
>Priority: Major
>
> The router can grant extra credit during drain of a link-routed receiver,
> leading to the router having more outstanding credit to the peer than the
> receiver has actually granted.
> The following shows a link-routed receiver draining credit from the link,
> after a single message having been received from the broker it was
> link-routed to. The router relays the flow from client to broker as expected,
> with "delivery-count=1, link-credit=999, drain=true", and relays the brokers
> response with "delivery-count=1000, link-credit=0, drain=true":
> {noformat}
> [0x27bb800]:1 <- @flow(19) [next-incoming-id=1, incoming-window=2047,
> next-outgoing-id=5, outgoing-window=2147483647, handle=2, delivery-count=1,
> link-credit=999, drain=true]
> [0x2763c90]:0 -> @flow(19) [next-incoming-id=2, incoming-window=2147483647,
> next-outgoing-id=4, outgoing-window=2147483647, handle=2, delivery-count=1,
> link-credit=999, drain=true]
> [0x2763c90]:0 <- @flow(19) [next-incoming-id=4, incoming-window=2147483647,
> next-outgoing-id=2, outgoing-window=2147483647, handle=2,
> delivery-count=1000, link-credit=0, drain=true]
> [0x27bb800]:1 -> @flow(19) [next-incoming-id=5, incoming-window=2147483647,
> next-outgoing-id=1, outgoing-window=2147483647, handle=2,
> delivery-count=1000, link-credit=0, drain=true]
> {noformat}
> The receiver then supplies more credit, which the router again relays as
> expected:
> {noformat}
> [0x27bb800]:1 <- @flow(19) [next-incoming-id=1, incoming-window=2047,
> next-outgoing-id=5, outgoing-window=2147483647, handle=2,
> delivery-count=1000, link-credit=1000]
> [0x2763c90]:0 -> @flow(19) [next-incoming-id=2, incoming-window=2147483647,
> next-outgoing-id=4, outgoing-window=2147483647, handle=2,
> delivery-count=1000, link-credit=1000, drain=false]
> {noformat}
> The receiver then drained this credit without having received any messages.
> The router relays the drain, but _incorrectly grants additional credit to the
> broker at the same time_, despite the receiver not having done so itself. The
> credit is drained, and the router updates the receiver to note it is also
> drained. Note however that the delivery counts have now diverged between
> client->router and router->broker, which seems unexpected for a link route.
> {noformat}
> [0x27bb800]:1 <- @flow(19) [next-incoming-id=1, incoming-window=2047,
> next-outgoing-id=7, outgoing-window=2147483647, handle=2,
> delivery-count=1000, link-credit=1000, drain=true]
> [0x2763c90]:0 -> @flow(19) [next-incoming-id=2, incoming-window=2147483647,
> next-outgoing-id=6, outgoing-window=2147483647, handle=2,
> delivery-count=1000, link-credit=2000, drain=true]
> [0x2763c90]:0 <- @flow(19) [next-incoming-id=6, incoming-window=2147483647,
> next-outgoing-id=2, outgoing-window=2147483647, handle=2,
> delivery-count=3000, link-credit=0, drain=true]
> [0x27bb800]:1 -> @flow(19) [next-incoming-id=7, incoming-window=2147483647,
> next-outgoing-id=1, outgoing-window=2147483647, handle=2,
> delivery-count=2000, link-credit=0, drain=true]
> {noformat}
> Had the broker been able to send messages using the mistakenly granted extra
> credit, the router would not be able to pass these all on to the client until
> it granted more credit. It isnt clear what would happen to them, but it seems
> like they could get stuck in the router until more credit is granted by the
> receiver, or the receiver detaches, etc. Again, unexpected for a link-route.
> The system continued on in this case since since this receiver grants (and
> drains) new credit:
> {noformat}
> [0x27bb800]:1 <- @flow(19) [next-incoming-id=1, incoming-window=2047,
> next-outgoing-id=7, outgoing-window=2147483647, handle=2,
> delivery-count=2000, link-credit=1000]
> [0x2763c90]:0 -> @flow(19) [next-incoming-id=2, incoming-window=2147483647,
> next-outgoing-id=6, outgoing-window=2147483647, handle=2,
> delivery-count=3000, link-credit=1000, drain=false]
> etc etc
> {noformat}
> however the delivery-count divergence grows over time as the situation
> repeats.
>
> Noticed while trying out changes for DISPATCH-1488.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...
[jira] [Commented] (DISPATCH-1492) Router asserts when client connects to edge listener
[
https://issues.apache.org/jira/browse/DISPATCH-1492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16981809#comment-16981809
]
ASF GitHub Bot commented on DISPATCH-1492:
--
ChugR commented on issue #629: DISPATCH-1492 - Prevent router crash when
senders connect to edge lis…
URL: https://github.com/apache/qpid-dispatch/pull/629#issuecomment-558295275
+!
I can connect to the edge listener as a client and the system does not
crash. The edge listener behaves well as a normal client listener
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
> Router asserts when client connects to edge listener
>
>
> Key: DISPATCH-1492
> URL: https://issues.apache.org/jira/browse/DISPATCH-1492
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Router Node
>Affects Versions: 1.9.0
>Reporter: Charles E. Rolke
>Assignee: Ganesh Murthy
>Priority: Major
> Attachments: INTA.conf
>
>
> Start a router with attached INTA.conf configuration
> Open a proton cpp example simple_send to send one message to the edge listener
> {noformat}
> qpid-proton/build/cpp/examples/simple_send -a 127.0.0.1:21003/multicast/q1
> -m 1
> {noformat}
> Router asserts with
> {noformat}
> Core was generated by `qdrouterd -c INTA.conf'.
> Program terminated with signal SIGABRT, Aborted.
> #0 0x7f870e54257f in raise () from /lib64/libc.so.6
> [Current thread is 1 (Thread 0x7f870053d700 (LWP 6221))]
> Missing separate debuginfos, use: dnf debuginfo-install
> glibc-2.28-33.fc29.x86_64 libuv-1.30.1-1.fc29.x86_64
> libwebsockets-3.0.1-2.fc29.x86_64 libxcrypt-4.4.6-2.fc29.x86_64
> pcre2-10.33-9.fc29.x86_64
> (gdb)
> (gdb) bt
> #0 0x7f870e54257f in raise () from /lib64/libc.so.6
> #1 0x7f870e52c895 in abort () from /lib64/libc.so.6
> #2 0x7f870e52c769 in __assert_fail_base.cold.0 () from /lib64/libc.so.6
> #3 0x7f870e53aa26 in __assert_fail () from /lib64/libc.so.6
> #4 0x7f870ebc0254 in on_link_event (context=0x7f86f804ef30, event=4096,
> link=0x7f86ec08c6d8)
> at
> /home/chug/git/qpid-dispatch/src/router_core/modules/edge_addr_tracking/edge_addr_tracking.c:337
> #5 0x7f870eb9c5eb in qdrc_event_link_raise (core=0x22a1640, event=4096,
> link=0x7f86ec08c6d8) at
> /home/chug/git/qpid-dispatch/src/router_core/core_events.c:102
> #6 0x7f870ebc279f in qdr_link_react_to_first_attach_CT (core=0x22a1640,
> conn=0x7f86ec079fd8, addr=0x7f86f8032398, link=0x7f86ec08c6d8,
> dir=QD_INCOMING, source=0x7f86ec083898,
> target=0x7f86ec083998, link_route=false, unavailable=false,
> core_endpoint=false, fallback=false)
> at
> /home/chug/git/qpid-dispatch/src/router_core/modules/address_lookup_client/lookup_client.c:428
> #7 0x7f870ebc2f6f in qcm_addr_lookup_CT (context=0x7f86f8021c90,
> conn=0x7f86ec079fd8, link=0x7f86ec08c6d8, dir=QD_INCOMING,
> source=0x7f86ec083898, target=0x7f86ec083998)
> at
> /home/chug/git/qpid-dispatch/src/router_core/modules/address_lookup_client/lookup_client.c:573
> #8 0x7f870eb9b13a in qdr_link_inbound_first_attach_CT (core=0x22a1640,
> action=0x7f86e802ef18, discard=false) at
> /home/chug/git/qpid-dispatch/src/router_core/connections.c:1582
> #9 0x7f870ebb1b24 in router_core_thread (arg=0x22a1640) at
> /home/chug/git/qpid-dispatch/src/router_core/router_core_thread.c:194
> #10 0x7f870ea9558e in start_thread () from /lib64/libpthread.so.0
> #11 0x7f870e607713 in clone () from /lib64/libc.so.6
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-dispatch] ChugR commented on issue #629: DISPATCH-1492 - Prevent router crash when senders connect to edge lis…
ChugR commented on issue #629: DISPATCH-1492 - Prevent router crash when senders connect to edge lis… URL: https://github.com/apache/qpid-dispatch/pull/629#issuecomment-558295275 +! I can connect to the edge listener as a client and the system does not crash. The edge listener behaves well as a normal client listener 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] (PROTON-2140) proton-c has very high memory footprint for links
[ https://issues.apache.org/jira/browse/PROTON-2140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16981793#comment-16981793 ] ASF subversion and git services commented on PROTON-2140: - Commit 3b84a5b8ab1c33fff1ded82aa2d8f7ea08fb5ec4 in qpid-proton's branch refs/heads/master from Andrew Stitcher [ https://gitbox.apache.org/repos/asf?p=qpid-proton.git;h=3b84a5b ] PROTON-2140: remove encoder & decoder elements from pn_data_t > proton-c has very high memory footprint for links > - > > Key: PROTON-2140 > URL: https://issues.apache.org/jira/browse/PROTON-2140 > Project: Qpid Proton > Issue Type: Improvement >Reporter: Gordon Sim >Priority: Major > Fix For: proton-c-0.30.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2140) proton-c has very high memory footprint for links
[ https://issues.apache.org/jira/browse/PROTON-2140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16981795#comment-16981795 ] ASF subversion and git services commented on PROTON-2140: - Commit 9e3c18b5b84e11e069a97980ac1e602479473bad in qpid-proton's branch refs/heads/master from Andrew Stitcher [ https://gitbox.apache.org/repos/asf?p=qpid-proton.git;h=9e3c18b ] PROTON-2140: remove str scratch element from pn_data_t > proton-c has very high memory footprint for links > - > > Key: PROTON-2140 > URL: https://issues.apache.org/jira/browse/PROTON-2140 > Project: Qpid Proton > Issue Type: Improvement >Reporter: Gordon Sim >Priority: Major > Fix For: proton-c-0.30.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1186) qdstat to include csv output format
[ https://issues.apache.org/jira/browse/DISPATCH-1186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16981772#comment-16981772 ] ASF GitHub Bot commented on DISPATCH-1186: -- ChugR commented on pull request #630: DISPATCH-1186: Add qdstat option to get CSV format for tables URL: https://github.com/apache/qpid-dispatch/pull/630 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 > qdstat to include csv output format > --- > > Key: DISPATCH-1186 > URL: https://issues.apache.org/jira/browse/DISPATCH-1186 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Management Agent >Affects Versions: 1.4.1 >Reporter: Charles E. Rolke >Assignee: Charles E. Rolke >Priority: Major > > qdstat text output is difficult to manage after a cut and paste. For > instance, _qdstat -l_ shows some rows where the columns are blank. This > makes it difficult to reconstruct the original display given just the body > text. See _qdstat -l_ example in > [https://raw.githubusercontent.com/apache/qpid-dispatch/master/docs/books/user-guide/monitoring-using-qdstat.adoc] > Even having a two-word column title "conn id" adds confusion. > With a CSV format and quoted strings this table could be communicated through > email, chat, or Jira with authority. Readers would not have to guess about > which data goes in which columns. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1186) qdstat to include csv output format
[ https://issues.apache.org/jira/browse/DISPATCH-1186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16981771#comment-16981771 ] ASF GitHub Bot commented on DISPATCH-1186: -- ChugR commented on issue #630: DISPATCH-1186: Add qdstat option to get CSV format for tables URL: https://github.com/apache/qpid-dispatch/pull/630#issuecomment-558276782 Fixed at commit 7a10a4d 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 > qdstat to include csv output format > --- > > Key: DISPATCH-1186 > URL: https://issues.apache.org/jira/browse/DISPATCH-1186 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Management Agent >Affects Versions: 1.4.1 >Reporter: Charles E. Rolke >Assignee: Charles E. Rolke >Priority: Major > > qdstat text output is difficult to manage after a cut and paste. For > instance, _qdstat -l_ shows some rows where the columns are blank. This > makes it difficult to reconstruct the original display given just the body > text. See _qdstat -l_ example in > [https://raw.githubusercontent.com/apache/qpid-dispatch/master/docs/books/user-guide/monitoring-using-qdstat.adoc] > Even having a two-word column title "conn id" adds confusion. > With a CSV format and quoted strings this table could be communicated through > email, chat, or Jira with authority. Readers would not have to guess about > which data goes in which columns. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-dispatch] ChugR closed pull request #630: DISPATCH-1186: Add qdstat option to get CSV format for tables
ChugR closed pull request #630: DISPATCH-1186: Add qdstat option to get CSV format for tables URL: https://github.com/apache/qpid-dispatch/pull/630 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-dispatch] ChugR commented on issue #630: DISPATCH-1186: Add qdstat option to get CSV format for tables
ChugR commented on issue #630: DISPATCH-1186: Add qdstat option to get CSV format for tables URL: https://github.com/apache/qpid-dispatch/pull/630#issuecomment-558276782 Fixed at commit 7a10a4d 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] (PROTON-2145) libqpid-proton-cpp-static.a not included in make install
[
https://issues.apache.org/jira/browse/PROTON-2145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16981769#comment-16981769
]
berge2007 commented on PROTON-2145:
---
[~jdanek] here is the output of single thread make: [^qpidbuild.txt]
There are many test project builded despite that "-{{DBUILD_TESTING=OFF}}"
switch added to cmake options
BTW it would be nice if I could skip building the examples projects too, but
its should be another issue's topic.
> libqpid-proton-cpp-static.a not included in make install
>
>
> Key: PROTON-2145
> URL: https://issues.apache.org/jira/browse/PROTON-2145
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Affects Versions: proton-c-0.29.0
> Environment: Linux raspberrypi 4.19.75-v7l+ #1270 SMP Tue Sep 24
> 18:51:41 BST 2019 armv7l GNU/Linux
> cmake version 3.13.4
>Reporter: berge2007
>Priority: Major
> Labels: build
> Attachments: qpidbuild.txt
>
>
> +After these steps:+
> {{git clone [https://github.com/apache/qpid-proton.git]}}
> {{cd qpid-proton}}
> {{git checkout 0.29.0}}
> {{mkdir _build}}
> {{cd _build}}
> cmake .. -DCMAKE_INSTALL_PREFIX=/usr/local\
> -DSYSINSTALL_BINDINGS=ON\
> -DBUILD_STATIC_LIBS=ON\
> -DBUILD_TESTING=OFF\
> -DBUILD_WITH_CXX=ON\
> -DENABLE_FUZZ_TESTING=OFF\
> -DFUZZ_REGRESSION_TESTS=OFF\
> {{make -j4}}
> {{make install}}
> +installed files in "/usr/local/lib" folder are:+
> {{/usr/local/lib/libqpid-proton-core.so}}
> {{/usr/local/lib/libqpid-proton-core.so.10}}
> {{/usr/local/lib/libqpid-proton-core.so.10.7.1}}
> {{/usr/local/lib/libqpid-proton-core-static.a}}
> {{/usr/local/lib/libqpid-proton-cpp.so}}
> {{/usr/local/lib/libqpid-proton-cpp.so.12}}
> {{/usr/local/lib/libqpid-proton-cpp.so.12.6.0}}
> {{/usr/local/lib/libqpid-proton-proactor.so}}
> {{/usr/local/lib/libqpid-proton-proactor.so.1}}
> {{/usr/local/lib/libqpid-proton-proactor.so.1.4.1}}
> {{/usr/local/lib/libqpid-proton-proactor-static.a}}
> {{/usr/local/lib/libqpid-proton.so}}
> {{/usr/local/lib/libqpid-proton.so.11}}
> {{/usr/local/lib/libqpid-proton.so.11.8.1}}
> {{/usr/local/lib/libqpid-proton-static.a}}
> so the "libqpid-proton-cpp-static.a" is missing despite that
> "DBUILD_STATIC_LIBS=ON" option
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8381) [Broker-J] Cannot run Qpid Broker-J with Azul Zulu JRE 11
[
https://issues.apache.org/jira/browse/QPID-8381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16981761#comment-16981761
]
Alex Rudyy commented on QPID-8381:
--
The BDB JE upgrade to version 7.5.11 caused the failure of upgrade test
{{BDBUpgradeTest#testBindingAndMessageDurability}}. It seems that environment
cannot start, when the number of store files drops to one. I never seen the
manifestation of the same issue when environment is created from scratch. The
BDB JE seems always keeping at least 2 files on the disk. Though, in order to
avoid any surprises in production environments, I think it would be better to
revert the changes from both master and branch and exclude this change from
version 7.1.6
I raise the issue on Oracle BDB JE forum
[https://community.oracle.com/message/15504459#15504459]. Though, that forum
is not very active.
> [Broker-J] Cannot run Qpid Broker-J with Azul Zulu JRE 11
> -
>
> Key: QPID-8381
> URL: https://issues.apache.org/jira/browse/QPID-8381
> Project: Qpid
> Issue Type: Bug
> Environment: * Qpid Broker-J 7.1.5
> * Java Zulu Community 11.0.4+11 LTS
> * Windows 10
>Reporter: Geert Graat
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-8.0.0, qpid-java-broker-7.1.6
>
> Attachments: log.txt
>
>
> When running the Qpid Java broker with Zulu Community JRE, I get an error on
> startup when my configured virtual node is validated. The maximum amount of
> runtime memory needs to be computed, and specifically for the Zulu runtime
> the class {{com.azul.zing.management.ManagementFactory}} is needed, which is
> not part of the Zulu Community. It seems to be part of the (commercial) Zing
> JVM, which is also developed by Azul systems.
> The problem seems to be in the {{com.sleepycat.je.utilint.JVMSystemUtils}}
> class in the dependencies of Qpid, which checks the {{java.vendor}}, which is
> apparently the same for the Zulu Community and Zing.
> When using the Oracle JDK, this problem does not occur.
> Attached is the stacktrace in the log.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-2145) libqpid-proton-cpp-static.a not included in make install
[
https://issues.apache.org/jira/browse/PROTON-2145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
berge2007 updated PROTON-2145:
--
Attachment: qpidbuild.txt
> libqpid-proton-cpp-static.a not included in make install
>
>
> Key: PROTON-2145
> URL: https://issues.apache.org/jira/browse/PROTON-2145
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Affects Versions: proton-c-0.29.0
> Environment: Linux raspberrypi 4.19.75-v7l+ #1270 SMP Tue Sep 24
> 18:51:41 BST 2019 armv7l GNU/Linux
> cmake version 3.13.4
>Reporter: berge2007
>Priority: Major
> Labels: build
> Attachments: qpidbuild.txt
>
>
> +After these steps:+
> {{git clone [https://github.com/apache/qpid-proton.git]}}
> {{cd qpid-proton}}
> {{git checkout 0.29.0}}
> {{mkdir _build}}
> {{cd _build}}
> cmake .. -DCMAKE_INSTALL_PREFIX=/usr/local\
> -DSYSINSTALL_BINDINGS=ON\
> -DBUILD_STATIC_LIBS=ON\
> -DBUILD_TESTING=OFF\
> -DBUILD_WITH_CXX=ON\
> -DENABLE_FUZZ_TESTING=OFF\
> -DFUZZ_REGRESSION_TESTS=OFF\
> {{make -j4}}
> {{make install}}
> +installed files in "/usr/local/lib" folder are:+
> {{/usr/local/lib/libqpid-proton-core.so}}
> {{/usr/local/lib/libqpid-proton-core.so.10}}
> {{/usr/local/lib/libqpid-proton-core.so.10.7.1}}
> {{/usr/local/lib/libqpid-proton-core-static.a}}
> {{/usr/local/lib/libqpid-proton-cpp.so}}
> {{/usr/local/lib/libqpid-proton-cpp.so.12}}
> {{/usr/local/lib/libqpid-proton-cpp.so.12.6.0}}
> {{/usr/local/lib/libqpid-proton-proactor.so}}
> {{/usr/local/lib/libqpid-proton-proactor.so.1}}
> {{/usr/local/lib/libqpid-proton-proactor.so.1.4.1}}
> {{/usr/local/lib/libqpid-proton-proactor-static.a}}
> {{/usr/local/lib/libqpid-proton.so}}
> {{/usr/local/lib/libqpid-proton.so.11}}
> {{/usr/local/lib/libqpid-proton.so.11.8.1}}
> {{/usr/local/lib/libqpid-proton-static.a}}
> so the "libqpid-proton-cpp-static.a" is missing despite that
> "DBUILD_STATIC_LIBS=ON" option
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-1459) Python3: exception thrown when processing MAUs
[ https://issues.apache.org/jira/browse/DISPATCH-1459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy updated DISPATCH-1459: Fix Version/s: (was: 1.10.0) 1.11.0 > Python3: exception thrown when processing MAUs > -- > > Key: DISPATCH-1459 > URL: https://issues.apache.org/jira/browse/DISPATCH-1459 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 1.9.0 > Environment: 3 router mesh configuration with test client that > generates a large # of subscriptions. > Configurations and client attached. > Run like this: > (in build directory) > > rm Router*.log; qdrouterd -c > /home/kgiusti/work/dispatch/qpid-dispatch/BUILD/RouterA.conf & sleep 2; > qdrouterd -c /home/kgiusti/work/dispatch/qpid-dispatch/BUILD/RouterB.conf & > sleep 2; qdrouterd -c > /home/kgiusti/work/dispatch/qpid-dispatch/BUILD/RouterC.conf & sleep 2; > ~/tmp/test-receiver -a 127.0.0.1:28782 & > > Monitor logs until traceback is hit. >Reporter: Ken Giusti >Priority: Major > Fix For: 1.11.0 > > Attachments: RouterA.conf, RouterB.conf, RouterC.conf, test-receiver.c > > > While running an address load test with system python == 3.7.4: > 2019-10-24 09:22:56.131966 -0400 ROUTER (error) Exception in control message > processing > Traceback (most recent call last): > File > "/home/kgiusti/work/dispatch/qpid-dispatch/python/qpid_dispatch_internal/router/engine.py", > line 163, in handleControlMessage > msg = MessageMAU(body) > File > "/home/kgiusti/work/dispatch/qpid-dispatch/python/qpid_dispatch_internal/router/data.py", > line 267, in __init__ > self.mobile_seq = LONG(_seq) > File > "/home/kgiusti/work/dispatch/qpid-dispatch/python/qpid_dispatch_internal/compat/__init__.py", > line 136, in LONG > return int(i) > TypeError: int() argument must be a string, a bytes-like object or a number, > not 'NoneType' > > (/home/kgiusti/work/dispatch/qpid-dispatch/python/qpid_dispatch_internal/router/engine.py:176) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-1444) Top level Dockerfile fails to build on centos:latest
[ https://issues.apache.org/jira/browse/DISPATCH-1444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy updated DISPATCH-1444: Fix Version/s: (was: 1.10.0) > Top level Dockerfile fails to build on centos:latest > > > Key: DISPATCH-1444 > URL: https://issues.apache.org/jira/browse/DISPATCH-1444 > Project: Qpid Dispatch > Issue Type: Bug > Components: Tools >Affects Versions: 1.9.0 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Major > > Since the docker repo moved centos:latest from centos 7 to centos 8 the > docker build fails due to packages no longer available: > > Step 4/11 : RUN yum -y install gcc cmake libuuid-devel openssl-devel > cyrus-sasl-devel cyrus-sasl-plain cyrus-sasl-gssapi cyrus-sasl-md5 swig > python-devel java-1.8.0-openjdk-devel git make doxygen valgrind emacs libuv > libuv-devel libwebsockets-devel python-unittest2 && yum clean all -y > ---> Running in 4f52d3d2f071 > Extra Packages for Enterprise Linux 8 - x86_64 32 kB/s | 2.0 MB 01:04 > Last metadata expiration check: 0:00:01 ago on Mon Oct 7 14:05:07 2019. > No match for argument: python-devel > No match for argument: doxygen > No match for argument: libuv-devel > No match for argument: libwebsockets-devel > No match for argument: python-unittest2 > Error: Unable to find a match > The command '/bin/sh -c yum -y install gcc cmake libuuid-devel openssl-devel > cyrus-sasl-devel cyrus-sasl-plain cyrus-sasl-gssapi cyrus-sasl-md5 swig > python-devel java-1.8.0-openjdk-devel git make doxygen valgrind emacs libuv > libuv-devel libwebsockets-devel python-unittest2 && yum clean all -y' > returned a non-zero code: 1 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-1496) router can grant extra credit during drain of a link-routed receiver
[
https://issues.apache.org/jira/browse/DISPATCH-1496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell updated DISPATCH-1496:
-
Summary: router can grant extra credit during drain of a link-routed
receiver (was: router can grant extra credit during drain a link-routed
receiver)
> router can grant extra credit during drain of a link-routed receiver
>
>
> Key: DISPATCH-1496
> URL: https://issues.apache.org/jira/browse/DISPATCH-1496
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 1.10.0
>Reporter: Robbie Gemmell
>Priority: Major
>
> The router can grant extra credit during drain of a link-routed receiver,
> leading to the router having more outstanding credit to the peer than the
> receiver has actually granted.
> The following shows a link-routed receiver draining credit from the link,
> after a single message having been received from the broker it was
> link-routed to. The router relays the flow from client to broker as expected,
> with "delivery-count=1, link-credit=999, drain=true", and relays the brokers
> response with "delivery-count=1000, link-credit=0, drain=true":
> {noformat}
> [0x27bb800]:1 <- @flow(19) [next-incoming-id=1, incoming-window=2047,
> next-outgoing-id=5, outgoing-window=2147483647, handle=2, delivery-count=1,
> link-credit=999, drain=true]
> [0x2763c90]:0 -> @flow(19) [next-incoming-id=2, incoming-window=2147483647,
> next-outgoing-id=4, outgoing-window=2147483647, handle=2, delivery-count=1,
> link-credit=999, drain=true]
> [0x2763c90]:0 <- @flow(19) [next-incoming-id=4, incoming-window=2147483647,
> next-outgoing-id=2, outgoing-window=2147483647, handle=2,
> delivery-count=1000, link-credit=0, drain=true]
> [0x27bb800]:1 -> @flow(19) [next-incoming-id=5, incoming-window=2147483647,
> next-outgoing-id=1, outgoing-window=2147483647, handle=2,
> delivery-count=1000, link-credit=0, drain=true]
> {noformat}
> The receiver then supplies more credit, which the router again relays as
> expected:
> {noformat}
> [0x27bb800]:1 <- @flow(19) [next-incoming-id=1, incoming-window=2047,
> next-outgoing-id=5, outgoing-window=2147483647, handle=2,
> delivery-count=1000, link-credit=1000]
> [0x2763c90]:0 -> @flow(19) [next-incoming-id=2, incoming-window=2147483647,
> next-outgoing-id=4, outgoing-window=2147483647, handle=2,
> delivery-count=1000, link-credit=1000, drain=false]
> {noformat}
> The receiver then drained this credit without having received any messages.
> The router relays the drain, but _incorrectly grants additional credit to the
> broker at the same time_, despite the receiver not having done so itself. The
> credit is drained, and the router updates the receiver to note it is also
> drained. Note however that the delivery counts have now diverged between
> client->router and router->broker, which seems unexpected for a link route.
> {noformat}
> [0x27bb800]:1 <- @flow(19) [next-incoming-id=1, incoming-window=2047,
> next-outgoing-id=7, outgoing-window=2147483647, handle=2,
> delivery-count=1000, link-credit=1000, drain=true]
> [0x2763c90]:0 -> @flow(19) [next-incoming-id=2, incoming-window=2147483647,
> next-outgoing-id=6, outgoing-window=2147483647, handle=2,
> delivery-count=1000, link-credit=2000, drain=true]
> [0x2763c90]:0 <- @flow(19) [next-incoming-id=6, incoming-window=2147483647,
> next-outgoing-id=2, outgoing-window=2147483647, handle=2,
> delivery-count=3000, link-credit=0, drain=true]
> [0x27bb800]:1 -> @flow(19) [next-incoming-id=7, incoming-window=2147483647,
> next-outgoing-id=1, outgoing-window=2147483647, handle=2,
> delivery-count=2000, link-credit=0, drain=true]
> {noformat}
> Had the broker been able to send messages using the mistakenly granted extra
> credit, the router would not be able to pass these all on to the client until
> it granted more credit. It isnt clear what would happen to them, but it seems
> like they could get stuck in the router until more credit is granted by the
> receiver, or the receiver detaches, etc. Again, unexpected for a link-route.
> The system continued on in this case since since this receiver grants (and
> drains) new credit:
> {noformat}
> [0x27bb800]:1 <- @flow(19) [next-incoming-id=1, incoming-window=2047,
> next-outgoing-id=7, outgoing-window=2147483647, handle=2,
> delivery-count=2000, link-credit=1000]
> [0x2763c90]:0 -> @flow(19) [next-incoming-id=2, incoming-window=2147483647,
> next-outgoing-id=6, outgoing-window=2147483647, handle=2,
> delivery-count=3000, link-credit=1000, drain=false]
> etc etc
> {noformat}
> however the delivery-count divergence grows over time as the situation
> repeats.
>
> Noticed while trying out changes for DISPATCH-1488.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
[jira] [Comment Edited] (DISPATCH-1488) link-routed transaction coordination broken due to 'declared' state truncation
[
https://issues.apache.org/jira/browse/DISPATCH-1488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16981737#comment-16981737
]
Robbie Gemmell edited comment on DISPATCH-1488 at 11/25/19 5:41 PM:
I tested the changes out and they got things going again.
I did however also spot DISPATCH-1496 while doing that (presumably unrelated)
was (Author: gemmellr):
I tested the changes out and they got things going again.
I did however also spot DISPATCH-1496 while doing that.
> link-routed transaction coordination broken due to 'declared' state truncation
> --
>
> Key: DISPATCH-1488
> URL: https://issues.apache.org/jira/browse/DISPATCH-1488
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 1.9.0, 1.10.0
>Reporter: Robbie Gemmell
>Assignee: Ken Giusti
>Priority: Blocker
> Fix For: 1.10.0
>
>
> The 1.9.0 release and current master for 1.10.0 both truncate the 'declared'
> transaction delivery state when routing a transaction coordinator link to a
> broker peer, omitting the contained txn-id and breaking all ability to link
> route transactional work through the router.
> Some output while trying this to debug an unrelated issue is detailed below.
> First, a message transfer arrives at the router with body requesting a
> transaction declare. The router sends the link-routed transfer onward to the
> broker:
> {noformat}
> [0x2251560]:1 <- @transfer(20) [handle=0, delivery-id=0,
> delivery-tag=b"\x00", message-format=0, settled=false] (7) "\x00Sw\x00S1E"
> [0x21ddf40]:0 -> @transfer(20) [handle=1, delivery-id=0,
> delivery-tag=b"\x00", message-format=0] (7) "\x00Sw\x00S1E"
> {noformat}
> (Not shown, after the above in the case being debugged, there was a
> non-transactional transfer on a second session across the same client->router
> connection, then forwarded on the same router->broker connection).
> The broker peer establishes a transaction and responds with disposition to
> indicate it is declared, and providing the mandatory txn-id. The router
> relays this disposition, but critically drops the txn-id from the delivery
> state:
> {noformat}
> [0x21ddf40]:0 <- @disposition(21) [role=true, first=0, last=0, settled=true,
> state=@declared(51) [txn-id=b"4a12a39a-09fe-11ea-91ae-000c29e9f622"]]
> [0x2251560]:1 -> @disposition(21) [role=true, first=0, settled=true,
> state=@declared(51) null]
> {noformat}
> The recipient client then barfs at this point since txn-id is mandatory for
> the declared state.
> Using 1.8.0, the declared state transited the router fine:
> {noformat}
> [0x1f49530]:0 <- @disposition(21) [role=true, first=0, last=0, settled=true,
> state=@declared(51) [txn-id=b"78dabc4f-0a00-11ea-bb46-000c29e9f622"]]
> [0x1fc2b20]:2 -> @disposition(21) [role=true, first=0, settled=true,
> state=@declared(51) [txn-id=b"78dabc4f-0a00-11ea-bb46-000c29e9f622"]]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1488) link-routed transaction coordination broken due to 'declared' state truncation
[
https://issues.apache.org/jira/browse/DISPATCH-1488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16981737#comment-16981737
]
Robbie Gemmell commented on DISPATCH-1488:
--
I tested the changes out and they got things going again.
I did however also spot DISPATCH-1496 while doing that.
> link-routed transaction coordination broken due to 'declared' state truncation
> --
>
> Key: DISPATCH-1488
> URL: https://issues.apache.org/jira/browse/DISPATCH-1488
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 1.9.0, 1.10.0
>Reporter: Robbie Gemmell
>Assignee: Ken Giusti
>Priority: Blocker
> Fix For: 1.10.0
>
>
> The 1.9.0 release and current master for 1.10.0 both truncate the 'declared'
> transaction delivery state when routing a transaction coordinator link to a
> broker peer, omitting the contained txn-id and breaking all ability to link
> route transactional work through the router.
> Some output while trying this to debug an unrelated issue is detailed below.
> First, a message transfer arrives at the router with body requesting a
> transaction declare. The router sends the link-routed transfer onward to the
> broker:
> {noformat}
> [0x2251560]:1 <- @transfer(20) [handle=0, delivery-id=0,
> delivery-tag=b"\x00", message-format=0, settled=false] (7) "\x00Sw\x00S1E"
> [0x21ddf40]:0 -> @transfer(20) [handle=1, delivery-id=0,
> delivery-tag=b"\x00", message-format=0] (7) "\x00Sw\x00S1E"
> {noformat}
> (Not shown, after the above in the case being debugged, there was a
> non-transactional transfer on a second session across the same client->router
> connection, then forwarded on the same router->broker connection).
> The broker peer establishes a transaction and responds with disposition to
> indicate it is declared, and providing the mandatory txn-id. The router
> relays this disposition, but critically drops the txn-id from the delivery
> state:
> {noformat}
> [0x21ddf40]:0 <- @disposition(21) [role=true, first=0, last=0, settled=true,
> state=@declared(51) [txn-id=b"4a12a39a-09fe-11ea-91ae-000c29e9f622"]]
> [0x2251560]:1 -> @disposition(21) [role=true, first=0, settled=true,
> state=@declared(51) null]
> {noformat}
> The recipient client then barfs at this point since txn-id is mandatory for
> the declared state.
> Using 1.8.0, the declared state transited the router fine:
> {noformat}
> [0x1f49530]:0 <- @disposition(21) [role=true, first=0, last=0, settled=true,
> state=@declared(51) [txn-id=b"78dabc4f-0a00-11ea-bb46-000c29e9f622"]]
> [0x1fc2b20]:2 -> @disposition(21) [role=true, first=0, settled=true,
> state=@declared(51) [txn-id=b"78dabc4f-0a00-11ea-bb46-000c29e9f622"]]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (DISPATCH-1186) qdstat to include csv output format
[ https://issues.apache.org/jira/browse/DISPATCH-1186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti reassigned DISPATCH-1186: Assignee: Charles E. Rolke (was: Ken Giusti) > qdstat to include csv output format > --- > > Key: DISPATCH-1186 > URL: https://issues.apache.org/jira/browse/DISPATCH-1186 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Management Agent >Affects Versions: 1.4.1 >Reporter: Charles E. Rolke >Assignee: Charles E. Rolke >Priority: Major > > qdstat text output is difficult to manage after a cut and paste. For > instance, _qdstat -l_ shows some rows where the columns are blank. This > makes it difficult to reconstruct the original display given just the body > text. See _qdstat -l_ example in > [https://raw.githubusercontent.com/apache/qpid-dispatch/master/docs/books/user-guide/monitoring-using-qdstat.adoc] > Even having a two-word column title "conn id" adds confusion. > With a CSV format and quoted strings this table could be communicated through > email, chat, or Jira with authority. Readers would not have to guess about > which data goes in which columns. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2145) libqpid-proton-cpp-static.a not included in make install
[
https://issues.apache.org/jira/browse/PROTON-2145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16981736#comment-16981736
]
berge2007 commented on PROTON-2145:
---
additional info:
here are all the ".a" lib file under the building folder:
{{qpid-proton/_build/cpp/libqpid-proton-cpp-static.a}}
{{qpid-proton/_build/c/libqpid-proton-static.a}}
{{qpid-proton/_build/c/tests/fuzz/libStandaloneFuzzTargetMain.a}}
{{qpid-proton/_build/c/libqpid-proton-core-static.a}}
{{qpid-proton/_build/c/libqpid-proton-proactor-static.a}}
As you seen "libqpid-proton-cpp-static.a" exists but in the "cpp" folder
(because obviously its a C++ wrapper).
Maybe there is a little disturbance around "cpp" and "c" folder names in cmake
files' install sections?
> libqpid-proton-cpp-static.a not included in make install
>
>
> Key: PROTON-2145
> URL: https://issues.apache.org/jira/browse/PROTON-2145
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Affects Versions: proton-c-0.29.0
> Environment: Linux raspberrypi 4.19.75-v7l+ #1270 SMP Tue Sep 24
> 18:51:41 BST 2019 armv7l GNU/Linux
> cmake version 3.13.4
>Reporter: berge2007
>Priority: Major
> Labels: build
>
> +After these steps:+
> {{git clone [https://github.com/apache/qpid-proton.git]}}
> {{cd qpid-proton}}
> {{git checkout 0.29.0}}
> {{mkdir _build}}
> {{cd _build}}
> cmake .. -DCMAKE_INSTALL_PREFIX=/usr/local\
> -DSYSINSTALL_BINDINGS=ON\
> -DBUILD_STATIC_LIBS=ON\
> -DBUILD_TESTING=OFF\
> -DBUILD_WITH_CXX=ON\
> -DENABLE_FUZZ_TESTING=OFF\
> -DFUZZ_REGRESSION_TESTS=OFF\
> {{make -j4}}
> {{make install}}
> +installed files in "/usr/local/lib" folder are:+
> {{/usr/local/lib/libqpid-proton-core.so}}
> {{/usr/local/lib/libqpid-proton-core.so.10}}
> {{/usr/local/lib/libqpid-proton-core.so.10.7.1}}
> {{/usr/local/lib/libqpid-proton-core-static.a}}
> {{/usr/local/lib/libqpid-proton-cpp.so}}
> {{/usr/local/lib/libqpid-proton-cpp.so.12}}
> {{/usr/local/lib/libqpid-proton-cpp.so.12.6.0}}
> {{/usr/local/lib/libqpid-proton-proactor.so}}
> {{/usr/local/lib/libqpid-proton-proactor.so.1}}
> {{/usr/local/lib/libqpid-proton-proactor.so.1.4.1}}
> {{/usr/local/lib/libqpid-proton-proactor-static.a}}
> {{/usr/local/lib/libqpid-proton.so}}
> {{/usr/local/lib/libqpid-proton.so.11}}
> {{/usr/local/lib/libqpid-proton.so.11.8.1}}
> {{/usr/local/lib/libqpid-proton-static.a}}
> so the "libqpid-proton-cpp-static.a" is missing despite that
> "DBUILD_STATIC_LIBS=ON" option
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-1496) router can grant extra credit during drain a link-routed receiver
[
https://issues.apache.org/jira/browse/DISPATCH-1496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell updated DISPATCH-1496:
-
Affects Version/s: 1.10.0
> router can grant extra credit during drain a link-routed receiver
> -
>
> Key: DISPATCH-1496
> URL: https://issues.apache.org/jira/browse/DISPATCH-1496
> Project: Qpid Dispatch
> Issue Type: Task
>Affects Versions: 1.10.0
>Reporter: Robbie Gemmell
>Priority: Major
>
> The router can grant extra credit during drain of a link-routed receiver,
> leading to the router having more outstanding credit to the peer than the
> receiver has actually granted.
> The following shows a link-routed receiver draining credit from the link,
> after a single message having been received from the broker it was
> link-routed to. The router relays the flow from client to broker as expected,
> with "delivery-count=1, link-credit=999, drain=true", and relays the brokers
> response with "delivery-count=1000, link-credit=0, drain=true":
> {noformat}
> [0x27bb800]:1 <- @flow(19) [next-incoming-id=1, incoming-window=2047,
> next-outgoing-id=5, outgoing-window=2147483647, handle=2, delivery-count=1,
> link-credit=999, drain=true]
> [0x2763c90]:0 -> @flow(19) [next-incoming-id=2, incoming-window=2147483647,
> next-outgoing-id=4, outgoing-window=2147483647, handle=2, delivery-count=1,
> link-credit=999, drain=true]
> [0x2763c90]:0 <- @flow(19) [next-incoming-id=4, incoming-window=2147483647,
> next-outgoing-id=2, outgoing-window=2147483647, handle=2,
> delivery-count=1000, link-credit=0, drain=true]
> [0x27bb800]:1 -> @flow(19) [next-incoming-id=5, incoming-window=2147483647,
> next-outgoing-id=1, outgoing-window=2147483647, handle=2,
> delivery-count=1000, link-credit=0, drain=true]
> {noformat}
> The receiver then supplies more credit, which the router again relays as
> expected:
> {noformat}
> [0x27bb800]:1 <- @flow(19) [next-incoming-id=1, incoming-window=2047,
> next-outgoing-id=5, outgoing-window=2147483647, handle=2,
> delivery-count=1000, link-credit=1000]
> [0x2763c90]:0 -> @flow(19) [next-incoming-id=2, incoming-window=2147483647,
> next-outgoing-id=4, outgoing-window=2147483647, handle=2,
> delivery-count=1000, link-credit=1000, drain=false]
> {noformat}
> The receiver then drained this credit without having received any messages.
> The router relays the drain, but _incorrectly grants additional credit to the
> broker at the same time_, despite the receiver not having done so itself. The
> credit is drained, and the router updates the receiver to note it is also
> drained. Note however that the delivery counts have now diverged between
> client->router and router->broker, which seems unexpected for a link route.
> {noformat}
> [0x27bb800]:1 <- @flow(19) [next-incoming-id=1, incoming-window=2047,
> next-outgoing-id=7, outgoing-window=2147483647, handle=2,
> delivery-count=1000, link-credit=1000, drain=true]
> [0x2763c90]:0 -> @flow(19) [next-incoming-id=2, incoming-window=2147483647,
> next-outgoing-id=6, outgoing-window=2147483647, handle=2,
> delivery-count=1000, link-credit=2000, drain=true]
> [0x2763c90]:0 <- @flow(19) [next-incoming-id=6, incoming-window=2147483647,
> next-outgoing-id=2, outgoing-window=2147483647, handle=2,
> delivery-count=3000, link-credit=0, drain=true]
> [0x27bb800]:1 -> @flow(19) [next-incoming-id=7, incoming-window=2147483647,
> next-outgoing-id=1, outgoing-window=2147483647, handle=2,
> delivery-count=2000, link-credit=0, drain=true]
> {noformat}
> Had the broker been able to send messages using the mistakenly granted extra
> credit, the router would not be able to pass these all on to the client until
> it granted more credit. It isnt clear what would happen to them, but it seems
> like they could get stuck in the router until more credit is granted by the
> receiver, or the receiver detaches, etc. Again, unexpected for a link-route.
> The system continued on in this case since since this receiver grants (and
> drains) new credit:
> {noformat}
> [0x27bb800]:1 <- @flow(19) [next-incoming-id=1, incoming-window=2047,
> next-outgoing-id=7, outgoing-window=2147483647, handle=2,
> delivery-count=2000, link-credit=1000]
> [0x2763c90]:0 -> @flow(19) [next-incoming-id=2, incoming-window=2147483647,
> next-outgoing-id=6, outgoing-window=2147483647, handle=2,
> delivery-count=3000, link-credit=1000, drain=false]
> etc etc
> {noformat}
> however the delivery-count divergence grows over time as the situation
> repeats.
>
> Noticed while trying out changes for DISPATCH-1488.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-m
[jira] [Updated] (DISPATCH-1496) router can grant extra credit during drain a link-routed receiver
[
https://issues.apache.org/jira/browse/DISPATCH-1496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell updated DISPATCH-1496:
-
Issue Type: Bug (was: Task)
> router can grant extra credit during drain a link-routed receiver
> -
>
> Key: DISPATCH-1496
> URL: https://issues.apache.org/jira/browse/DISPATCH-1496
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 1.10.0
>Reporter: Robbie Gemmell
>Priority: Major
>
> The router can grant extra credit during drain of a link-routed receiver,
> leading to the router having more outstanding credit to the peer than the
> receiver has actually granted.
> The following shows a link-routed receiver draining credit from the link,
> after a single message having been received from the broker it was
> link-routed to. The router relays the flow from client to broker as expected,
> with "delivery-count=1, link-credit=999, drain=true", and relays the brokers
> response with "delivery-count=1000, link-credit=0, drain=true":
> {noformat}
> [0x27bb800]:1 <- @flow(19) [next-incoming-id=1, incoming-window=2047,
> next-outgoing-id=5, outgoing-window=2147483647, handle=2, delivery-count=1,
> link-credit=999, drain=true]
> [0x2763c90]:0 -> @flow(19) [next-incoming-id=2, incoming-window=2147483647,
> next-outgoing-id=4, outgoing-window=2147483647, handle=2, delivery-count=1,
> link-credit=999, drain=true]
> [0x2763c90]:0 <- @flow(19) [next-incoming-id=4, incoming-window=2147483647,
> next-outgoing-id=2, outgoing-window=2147483647, handle=2,
> delivery-count=1000, link-credit=0, drain=true]
> [0x27bb800]:1 -> @flow(19) [next-incoming-id=5, incoming-window=2147483647,
> next-outgoing-id=1, outgoing-window=2147483647, handle=2,
> delivery-count=1000, link-credit=0, drain=true]
> {noformat}
> The receiver then supplies more credit, which the router again relays as
> expected:
> {noformat}
> [0x27bb800]:1 <- @flow(19) [next-incoming-id=1, incoming-window=2047,
> next-outgoing-id=5, outgoing-window=2147483647, handle=2,
> delivery-count=1000, link-credit=1000]
> [0x2763c90]:0 -> @flow(19) [next-incoming-id=2, incoming-window=2147483647,
> next-outgoing-id=4, outgoing-window=2147483647, handle=2,
> delivery-count=1000, link-credit=1000, drain=false]
> {noformat}
> The receiver then drained this credit without having received any messages.
> The router relays the drain, but _incorrectly grants additional credit to the
> broker at the same time_, despite the receiver not having done so itself. The
> credit is drained, and the router updates the receiver to note it is also
> drained. Note however that the delivery counts have now diverged between
> client->router and router->broker, which seems unexpected for a link route.
> {noformat}
> [0x27bb800]:1 <- @flow(19) [next-incoming-id=1, incoming-window=2047,
> next-outgoing-id=7, outgoing-window=2147483647, handle=2,
> delivery-count=1000, link-credit=1000, drain=true]
> [0x2763c90]:0 -> @flow(19) [next-incoming-id=2, incoming-window=2147483647,
> next-outgoing-id=6, outgoing-window=2147483647, handle=2,
> delivery-count=1000, link-credit=2000, drain=true]
> [0x2763c90]:0 <- @flow(19) [next-incoming-id=6, incoming-window=2147483647,
> next-outgoing-id=2, outgoing-window=2147483647, handle=2,
> delivery-count=3000, link-credit=0, drain=true]
> [0x27bb800]:1 -> @flow(19) [next-incoming-id=7, incoming-window=2147483647,
> next-outgoing-id=1, outgoing-window=2147483647, handle=2,
> delivery-count=2000, link-credit=0, drain=true]
> {noformat}
> Had the broker been able to send messages using the mistakenly granted extra
> credit, the router would not be able to pass these all on to the client until
> it granted more credit. It isnt clear what would happen to them, but it seems
> like they could get stuck in the router until more credit is granted by the
> receiver, or the receiver detaches, etc. Again, unexpected for a link-route.
> The system continued on in this case since since this receiver grants (and
> drains) new credit:
> {noformat}
> [0x27bb800]:1 <- @flow(19) [next-incoming-id=1, incoming-window=2047,
> next-outgoing-id=7, outgoing-window=2147483647, handle=2,
> delivery-count=2000, link-credit=1000]
> [0x2763c90]:0 -> @flow(19) [next-incoming-id=2, incoming-window=2147483647,
> next-outgoing-id=6, outgoing-window=2147483647, handle=2,
> delivery-count=3000, link-credit=1000, drain=false]
> etc etc
> {noformat}
> however the delivery-count divergence grows over time as the situation
> repeats.
>
> Noticed while trying out changes for DISPATCH-1488.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e
[GitHub] [qpid-dispatch] asfgit closed pull request #628: NO-JIRA -Default the DISPATCH_TEST_TIMEOUT to 600 seconds. Travis wil…
asfgit closed pull request #628: NO-JIRA -Default the DISPATCH_TEST_TIMEOUT to 600 seconds. Travis wil… URL: https://github.com/apache/qpid-dispatch/pull/628 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] [Resolved] (DISPATCH-1438) Have ctest parse the routers debug dump files for memory pool leaks
[ https://issues.apache.org/jira/browse/DISPATCH-1438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti resolved DISPATCH-1438. -- Fix Version/s: (was: Backlog) 1.10.0 Resolution: Fixed > Have ctest parse the routers debug dump files for memory pool leaks > --- > > Key: DISPATCH-1438 > URL: https://issues.apache.org/jira/browse/DISPATCH-1438 > Project: Qpid Dispatch > Issue Type: Test > Components: Tests >Affects Versions: 1.9.0 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Minor > Labels: memory-bug > Fix For: 1.10.0 > > > When the router has been built for Debug via -DCMAKE_BUILD_TYPE=Debug it will > write a debug dump file on shutdown. > This debug dump file reports how many pool objects remain in thread on > shutdown. > A large number of in-thread pooled objects on shutdown may indicate a memory > leak. > It would be useful to have ctest parse these files and report any in-thread > objects at the end of a test run. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1496) router can grant extra credit during drain a link-routed receiver
Robbie Gemmell created DISPATCH-1496:
Summary: router can grant extra credit during drain a link-routed
receiver
Key: DISPATCH-1496
URL: https://issues.apache.org/jira/browse/DISPATCH-1496
Project: Qpid Dispatch
Issue Type: Task
Reporter: Robbie Gemmell
The router can grant extra credit during drain of a link-routed receiver,
leading to the router having more outstanding credit to the peer than the
receiver has actually granted.
The following shows a link-routed receiver draining credit from the link, after
a single message having been received from the broker it was link-routed to.
The router relays the flow from client to broker as expected, with
"delivery-count=1, link-credit=999, drain=true", and relays the brokers
response with "delivery-count=1000, link-credit=0, drain=true":
{noformat}
[0x27bb800]:1 <- @flow(19) [next-incoming-id=1, incoming-window=2047,
next-outgoing-id=5, outgoing-window=2147483647, handle=2, delivery-count=1,
link-credit=999, drain=true]
[0x2763c90]:0 -> @flow(19) [next-incoming-id=2, incoming-window=2147483647,
next-outgoing-id=4, outgoing-window=2147483647, handle=2, delivery-count=1,
link-credit=999, drain=true]
[0x2763c90]:0 <- @flow(19) [next-incoming-id=4, incoming-window=2147483647,
next-outgoing-id=2, outgoing-window=2147483647, handle=2, delivery-count=1000,
link-credit=0, drain=true]
[0x27bb800]:1 -> @flow(19) [next-incoming-id=5, incoming-window=2147483647,
next-outgoing-id=1, outgoing-window=2147483647, handle=2, delivery-count=1000,
link-credit=0, drain=true]
{noformat}
The receiver then supplies more credit, which the router again relays as
expected:
{noformat}
[0x27bb800]:1 <- @flow(19) [next-incoming-id=1, incoming-window=2047,
next-outgoing-id=5, outgoing-window=2147483647, handle=2, delivery-count=1000,
link-credit=1000]
[0x2763c90]:0 -> @flow(19) [next-incoming-id=2, incoming-window=2147483647,
next-outgoing-id=4, outgoing-window=2147483647, handle=2, delivery-count=1000,
link-credit=1000, drain=false]
{noformat}
The receiver then drained this credit without having received any messages. The
router relays the drain, but _incorrectly grants additional credit to the
broker at the same time_, despite the receiver not having done so itself. The
credit is drained, and the router updates the receiver to note it is also
drained. Note however that the delivery counts have now diverged between
client->router and router->broker, which seems unexpected for a link route.
{noformat}
[0x27bb800]:1 <- @flow(19) [next-incoming-id=1, incoming-window=2047,
next-outgoing-id=7, outgoing-window=2147483647, handle=2, delivery-count=1000,
link-credit=1000, drain=true]
[0x2763c90]:0 -> @flow(19) [next-incoming-id=2, incoming-window=2147483647,
next-outgoing-id=6, outgoing-window=2147483647, handle=2, delivery-count=1000,
link-credit=2000, drain=true]
[0x2763c90]:0 <- @flow(19) [next-incoming-id=6, incoming-window=2147483647,
next-outgoing-id=2, outgoing-window=2147483647, handle=2, delivery-count=3000,
link-credit=0, drain=true]
[0x27bb800]:1 -> @flow(19) [next-incoming-id=7, incoming-window=2147483647,
next-outgoing-id=1, outgoing-window=2147483647, handle=2, delivery-count=2000,
link-credit=0, drain=true]
{noformat}
Had the broker been able to send messages using the mistakenly granted extra
credit, the router would not be able to pass these all on to the client until
it granted more credit. It isnt clear what would happen to them, but it seems
like they could get stuck in the router until more credit is granted by the
receiver, or the receiver detaches, etc. Again, unexpected for a link-route.
The system continued on in this case since since this receiver grants (and
drains) new credit:
{noformat}
[0x27bb800]:1 <- @flow(19) [next-incoming-id=1, incoming-window=2047,
next-outgoing-id=7, outgoing-window=2147483647, handle=2, delivery-count=2000,
link-credit=1000]
[0x2763c90]:0 -> @flow(19) [next-incoming-id=2, incoming-window=2147483647,
next-outgoing-id=6, outgoing-window=2147483647, handle=2, delivery-count=3000,
link-credit=1000, drain=false]
etc etc
{noformat}
however the delivery-count divergence grows over time as the situation repeats.
Noticed while trying out changes for DISPATCH-1488.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-1483) Link counters for dispositions are not incremented for outgoing links
[ https://issues.apache.org/jira/browse/DISPATCH-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti resolved DISPATCH-1483. -- Resolution: Fixed > Link counters for dispositions are not incremented for outgoing links > - > > Key: DISPATCH-1483 > URL: https://issues.apache.org/jira/browse/DISPATCH-1483 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 1.9.0 >Reporter: Ted Ross >Assignee: Ken Giusti >Priority: Major > Fix For: 1.10.0 > > > When transferring messages across a router with the deliveries being accepted > by the receiver, the deliveries-accepted counter for the _outgoing_ link are > not incremented. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-1488) link-routed transaction coordination broken due to 'declared' state truncation
[
https://issues.apache.org/jira/browse/DISPATCH-1488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ken Giusti resolved DISPATCH-1488.
--
Resolution: Fixed
> link-routed transaction coordination broken due to 'declared' state truncation
> --
>
> Key: DISPATCH-1488
> URL: https://issues.apache.org/jira/browse/DISPATCH-1488
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 1.9.0, 1.10.0
>Reporter: Robbie Gemmell
>Assignee: Ken Giusti
>Priority: Blocker
> Fix For: 1.10.0
>
>
> The 1.9.0 release and current master for 1.10.0 both truncate the 'declared'
> transaction delivery state when routing a transaction coordinator link to a
> broker peer, omitting the contained txn-id and breaking all ability to link
> route transactional work through the router.
> Some output while trying this to debug an unrelated issue is detailed below.
> First, a message transfer arrives at the router with body requesting a
> transaction declare. The router sends the link-routed transfer onward to the
> broker:
> {noformat}
> [0x2251560]:1 <- @transfer(20) [handle=0, delivery-id=0,
> delivery-tag=b"\x00", message-format=0, settled=false] (7) "\x00Sw\x00S1E"
> [0x21ddf40]:0 -> @transfer(20) [handle=1, delivery-id=0,
> delivery-tag=b"\x00", message-format=0] (7) "\x00Sw\x00S1E"
> {noformat}
> (Not shown, after the above in the case being debugged, there was a
> non-transactional transfer on a second session across the same client->router
> connection, then forwarded on the same router->broker connection).
> The broker peer establishes a transaction and responds with disposition to
> indicate it is declared, and providing the mandatory txn-id. The router
> relays this disposition, but critically drops the txn-id from the delivery
> state:
> {noformat}
> [0x21ddf40]:0 <- @disposition(21) [role=true, first=0, last=0, settled=true,
> state=@declared(51) [txn-id=b"4a12a39a-09fe-11ea-91ae-000c29e9f622"]]
> [0x2251560]:1 -> @disposition(21) [role=true, first=0, settled=true,
> state=@declared(51) null]
> {noformat}
> The recipient client then barfs at this point since txn-id is mandatory for
> the declared state.
> Using 1.8.0, the declared state transited the router fine:
> {noformat}
> [0x1f49530]:0 <- @disposition(21) [role=true, first=0, last=0, settled=true,
> state=@declared(51) [txn-id=b"78dabc4f-0a00-11ea-bb46-000c29e9f622"]]
> [0x1fc2b20]:2 -> @disposition(21) [role=true, first=0, settled=true,
> state=@declared(51) [txn-id=b"78dabc4f-0a00-11ea-bb46-000c29e9f622"]]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1488) link-routed transaction coordination broken due to 'declared' state truncation
[
https://issues.apache.org/jira/browse/DISPATCH-1488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16981732#comment-16981732
]
ASF subversion and git services commented on DISPATCH-1488:
---
Commit 28c3a1b6188f3907984c1e7c0765ee6c0249be92 in qpid-dispatch's branch
refs/heads/master from Ken Giusti
[ https://gitbox.apache.org/repos/asf?p=qpid-dispatch.git;h=28c3a1b ]
DISPATCH-1488: properly forward transaction coordinator disposition data
This closes #625
> link-routed transaction coordination broken due to 'declared' state truncation
> --
>
> Key: DISPATCH-1488
> URL: https://issues.apache.org/jira/browse/DISPATCH-1488
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 1.9.0, 1.10.0
>Reporter: Robbie Gemmell
>Assignee: Ken Giusti
>Priority: Blocker
> Fix For: 1.10.0
>
>
> The 1.9.0 release and current master for 1.10.0 both truncate the 'declared'
> transaction delivery state when routing a transaction coordinator link to a
> broker peer, omitting the contained txn-id and breaking all ability to link
> route transactional work through the router.
> Some output while trying this to debug an unrelated issue is detailed below.
> First, a message transfer arrives at the router with body requesting a
> transaction declare. The router sends the link-routed transfer onward to the
> broker:
> {noformat}
> [0x2251560]:1 <- @transfer(20) [handle=0, delivery-id=0,
> delivery-tag=b"\x00", message-format=0, settled=false] (7) "\x00Sw\x00S1E"
> [0x21ddf40]:0 -> @transfer(20) [handle=1, delivery-id=0,
> delivery-tag=b"\x00", message-format=0] (7) "\x00Sw\x00S1E"
> {noformat}
> (Not shown, after the above in the case being debugged, there was a
> non-transactional transfer on a second session across the same client->router
> connection, then forwarded on the same router->broker connection).
> The broker peer establishes a transaction and responds with disposition to
> indicate it is declared, and providing the mandatory txn-id. The router
> relays this disposition, but critically drops the txn-id from the delivery
> state:
> {noformat}
> [0x21ddf40]:0 <- @disposition(21) [role=true, first=0, last=0, settled=true,
> state=@declared(51) [txn-id=b"4a12a39a-09fe-11ea-91ae-000c29e9f622"]]
> [0x2251560]:1 -> @disposition(21) [role=true, first=0, settled=true,
> state=@declared(51) null]
> {noformat}
> The recipient client then barfs at this point since txn-id is mandatory for
> the declared state.
> Using 1.8.0, the declared state transited the router fine:
> {noformat}
> [0x1f49530]:0 <- @disposition(21) [role=true, first=0, last=0, settled=true,
> state=@declared(51) [txn-id=b"78dabc4f-0a00-11ea-bb46-000c29e9f622"]]
> [0x1fc2b20]:2 -> @disposition(21) [role=true, first=0, settled=true,
> state=@declared(51) [txn-id=b"78dabc4f-0a00-11ea-bb46-000c29e9f622"]]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1488) link-routed transaction coordination broken due to 'declared' state truncation
[
https://issues.apache.org/jira/browse/DISPATCH-1488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16981733#comment-16981733
]
ASF GitHub Bot commented on DISPATCH-1488:
--
asfgit commented on pull request #625: DISPATCH-1488: properly forward
tranaction coordinator disposition data
URL: https://github.com/apache/qpid-dispatch/pull/625
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
> link-routed transaction coordination broken due to 'declared' state truncation
> --
>
> Key: DISPATCH-1488
> URL: https://issues.apache.org/jira/browse/DISPATCH-1488
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 1.9.0, 1.10.0
>Reporter: Robbie Gemmell
>Assignee: Ken Giusti
>Priority: Blocker
> Fix For: 1.10.0
>
>
> The 1.9.0 release and current master for 1.10.0 both truncate the 'declared'
> transaction delivery state when routing a transaction coordinator link to a
> broker peer, omitting the contained txn-id and breaking all ability to link
> route transactional work through the router.
> Some output while trying this to debug an unrelated issue is detailed below.
> First, a message transfer arrives at the router with body requesting a
> transaction declare. The router sends the link-routed transfer onward to the
> broker:
> {noformat}
> [0x2251560]:1 <- @transfer(20) [handle=0, delivery-id=0,
> delivery-tag=b"\x00", message-format=0, settled=false] (7) "\x00Sw\x00S1E"
> [0x21ddf40]:0 -> @transfer(20) [handle=1, delivery-id=0,
> delivery-tag=b"\x00", message-format=0] (7) "\x00Sw\x00S1E"
> {noformat}
> (Not shown, after the above in the case being debugged, there was a
> non-transactional transfer on a second session across the same client->router
> connection, then forwarded on the same router->broker connection).
> The broker peer establishes a transaction and responds with disposition to
> indicate it is declared, and providing the mandatory txn-id. The router
> relays this disposition, but critically drops the txn-id from the delivery
> state:
> {noformat}
> [0x21ddf40]:0 <- @disposition(21) [role=true, first=0, last=0, settled=true,
> state=@declared(51) [txn-id=b"4a12a39a-09fe-11ea-91ae-000c29e9f622"]]
> [0x2251560]:1 -> @disposition(21) [role=true, first=0, settled=true,
> state=@declared(51) null]
> {noformat}
> The recipient client then barfs at this point since txn-id is mandatory for
> the declared state.
> Using 1.8.0, the declared state transited the router fine:
> {noformat}
> [0x1f49530]:0 <- @disposition(21) [role=true, first=0, last=0, settled=true,
> state=@declared(51) [txn-id=b"78dabc4f-0a00-11ea-bb46-000c29e9f622"]]
> [0x1fc2b20]:2 -> @disposition(21) [role=true, first=0, settled=true,
> state=@declared(51) [txn-id=b"78dabc4f-0a00-11ea-bb46-000c29e9f622"]]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-dispatch] asfgit closed pull request #625: DISPATCH-1488: properly forward tranaction coordinator disposition data
asfgit closed pull request #625: DISPATCH-1488: properly forward tranaction coordinator disposition data URL: https://github.com/apache/qpid-dispatch/pull/625 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] (PROTON-2140) proton-c has very high memory footprint for links
[ https://issues.apache.org/jira/browse/PROTON-2140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16981722#comment-16981722 ] ASF subversion and git services commented on PROTON-2140: - Commit 10b5131c894655a51f76fd1dc008e8d8a79d8f4b in qpid-proton's branch refs/heads/master from Andrew Stitcher [ https://gitbox.apache.org/repos/asf?p=qpid-proton.git;h=10b5131 ] PROTON-2140: Fill in padding gap in pn_terminus_t to save 32 bytes in pn_link_t > proton-c has very high memory footprint for links > - > > Key: PROTON-2140 > URL: https://issues.apache.org/jira/browse/PROTON-2140 > Project: Qpid Proton > Issue Type: Improvement >Reporter: Gordon Sim >Priority: Major > Fix For: proton-c-0.30.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1483) Link counters for dispositions are not incremented for outgoing links
[ https://issues.apache.org/jira/browse/DISPATCH-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16981713#comment-16981713 ] ASF subversion and git services commented on DISPATCH-1483: --- Commit 520133e72353c789456d444f0b7e481febf86677 in qpid-dispatch's branch refs/heads/master from Ken Giusti [ https://gitbox.apache.org/repos/asf?p=qpid-dispatch.git;h=520133e ] DISPATCH-1483: properly update per-link delivery statistics Update the delivery counter tests to include additional checking of the link level delivery counters. This closes #620 > Link counters for dispositions are not incremented for outgoing links > - > > Key: DISPATCH-1483 > URL: https://issues.apache.org/jira/browse/DISPATCH-1483 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 1.9.0 >Reporter: Ted Ross >Assignee: Ken Giusti >Priority: Major > Fix For: 1.10.0 > > > When transferring messages across a router with the deliveries being accepted > by the receiver, the deliveries-accepted counter for the _outgoing_ link are > not incremented. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1483) Link counters for dispositions are not incremented for outgoing links
[ https://issues.apache.org/jira/browse/DISPATCH-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16981714#comment-16981714 ] ASF GitHub Bot commented on DISPATCH-1483: -- asfgit commented on pull request #620: DISPATCH-1483: properly update per-link delivery statistics URL: https://github.com/apache/qpid-dispatch/pull/620 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 > Link counters for dispositions are not incremented for outgoing links > - > > Key: DISPATCH-1483 > URL: https://issues.apache.org/jira/browse/DISPATCH-1483 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 1.9.0 >Reporter: Ted Ross >Assignee: Ken Giusti >Priority: Major > Fix For: 1.10.0 > > > When transferring messages across a router with the deliveries being accepted > by the receiver, the deliveries-accepted counter for the _outgoing_ link are > not incremented. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-dispatch] asfgit closed pull request #620: DISPATCH-1483: properly update per-link delivery statistics
asfgit closed pull request #620: DISPATCH-1483: properly update per-link delivery statistics URL: https://github.com/apache/qpid-dispatch/pull/620 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] (PROTON-2145) libqpid-proton-cpp-static.a not included in make install
[
https://issues.apache.org/jira/browse/PROTON-2145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16981706#comment-16981706
]
Jiri Daněk commented on PROTON-2145:
I wont be trying this this today, whether any of my comments are relevant, but
I feel suspicious about some of the compile options used.
First, {{DBUILD_WITH_CXX=ON}}. That option means "use c+= compiler to build c
sources, in addition to cpp sources" and is used to workaround lack of c99
support in old visual studio. It does not mean "build me cop binding".
Lastly {{DBUILD_TESTING=OFF}} should disable fuzz tests, if it doesn't then
this needs to be fixed.
Also, i dont like "DSYSINSTALL_BINDINGS=ON" because nobody uses it, and it
should be a noop regarding cop binding anyways.
I had some problems with {{DBUILD_WITH_CXX=ON}} on Friday, but I don't remember
now if it was just clang related (options for clang ended up wrong and it
failed due to -Werror), or if it was anything more serious.
> libqpid-proton-cpp-static.a not included in make install
>
>
> Key: PROTON-2145
> URL: https://issues.apache.org/jira/browse/PROTON-2145
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Affects Versions: proton-c-0.29.0
> Environment: Linux raspberrypi 4.19.75-v7l+ #1270 SMP Tue Sep 24
> 18:51:41 BST 2019 armv7l GNU/Linux
> cmake version 3.13.4
>Reporter: berge2007
>Priority: Major
> Labels: build
>
> +After these steps:+
> {{git clone [https://github.com/apache/qpid-proton.git]}}
> {{cd qpid-proton}}
> {{git checkout 0.29.0}}
> {{mkdir _build}}
> {{cd _build}}
> cmake .. -DCMAKE_INSTALL_PREFIX=/usr/local\
> -DSYSINSTALL_BINDINGS=ON\
> -DBUILD_STATIC_LIBS=ON\
> -DBUILD_TESTING=OFF\
> -DBUILD_WITH_CXX=ON\
> -DENABLE_FUZZ_TESTING=OFF\
> -DFUZZ_REGRESSION_TESTS=OFF\
> {{make -j4}}
> {{make install}}
> +installed files in "/usr/local/lib" folder are:+
> {{/usr/local/lib/libqpid-proton-core.so}}
> {{/usr/local/lib/libqpid-proton-core.so.10}}
> {{/usr/local/lib/libqpid-proton-core.so.10.7.1}}
> {{/usr/local/lib/libqpid-proton-core-static.a}}
> {{/usr/local/lib/libqpid-proton-cpp.so}}
> {{/usr/local/lib/libqpid-proton-cpp.so.12}}
> {{/usr/local/lib/libqpid-proton-cpp.so.12.6.0}}
> {{/usr/local/lib/libqpid-proton-proactor.so}}
> {{/usr/local/lib/libqpid-proton-proactor.so.1}}
> {{/usr/local/lib/libqpid-proton-proactor.so.1.4.1}}
> {{/usr/local/lib/libqpid-proton-proactor-static.a}}
> {{/usr/local/lib/libqpid-proton.so}}
> {{/usr/local/lib/libqpid-proton.so.11}}
> {{/usr/local/lib/libqpid-proton.so.11.8.1}}
> {{/usr/local/lib/libqpid-proton-static.a}}
> so the "libqpid-proton-cpp-static.a" is missing despite that
> "DBUILD_STATIC_LIBS=ON" option
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1186) qdstat to include csv output format
[ https://issues.apache.org/jira/browse/DISPATCH-1186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16981686#comment-16981686 ] ASF subversion and git services commented on DISPATCH-1186: --- Commit 7a10a4d467d9cd1d7a1d75467266cfb01e770b86 in qpid-dispatch's branch refs/heads/master from Charles E. Rolke [ https://gitbox.apache.org/repos/asf?p=qpid-dispatch.git;h=7a10a4d ] DISPATCH-1186: Add qdstat option to get CSV format for tables Add a "--csv" switch to qdstat command line to apply to display tables. || CSV character || value|| | separator | comma| | string quote | double quote | All non-blank values in headings and tables are output as quoted strings. Blank values in tables are not quoted. The output shall be consecutive separator commas. This option removes ambiguity for certain tables (like 'qdstat -l') where columns (like peer and phs) have no entry, and headers (like 'conn id') have spaces in their names. > qdstat to include csv output format > --- > > Key: DISPATCH-1186 > URL: https://issues.apache.org/jira/browse/DISPATCH-1186 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Management Agent >Affects Versions: 1.4.1 >Reporter: Charles E. Rolke >Assignee: Ken Giusti >Priority: Major > > qdstat text output is difficult to manage after a cut and paste. For > instance, _qdstat -l_ shows some rows where the columns are blank. This > makes it difficult to reconstruct the original display given just the body > text. See _qdstat -l_ example in > [https://raw.githubusercontent.com/apache/qpid-dispatch/master/docs/books/user-guide/monitoring-using-qdstat.adoc] > Even having a two-word column title "conn id" adds confusion. > With a CSV format and quoted strings this table could be communicated through > email, chat, or Jira with authority. Readers would not have to guess about > which data goes in which columns. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1186) qdstat to include csv output format
[ https://issues.apache.org/jira/browse/DISPATCH-1186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16981682#comment-16981682 ] ASF GitHub Bot commented on DISPATCH-1186: -- ganeshmurthy commented on issue #630: DISPATCH-1186: Add qdstat option to get CSV format for tables URL: https://github.com/apache/qpid-dispatch/pull/630#issuecomment-558232515 1. Tested all qdstat option combinations with --csv and looked at output in LibreOffice - looks good 2. All system tests pass with this PR. Approving this PR. Ready to go into master. 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 > qdstat to include csv output format > --- > > Key: DISPATCH-1186 > URL: https://issues.apache.org/jira/browse/DISPATCH-1186 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Management Agent >Affects Versions: 1.4.1 >Reporter: Charles E. Rolke >Assignee: Ken Giusti >Priority: Major > > qdstat text output is difficult to manage after a cut and paste. For > instance, _qdstat -l_ shows some rows where the columns are blank. This > makes it difficult to reconstruct the original display given just the body > text. See _qdstat -l_ example in > [https://raw.githubusercontent.com/apache/qpid-dispatch/master/docs/books/user-guide/monitoring-using-qdstat.adoc] > Even having a two-word column title "conn id" adds confusion. > With a CSV format and quoted strings this table could be communicated through > email, chat, or Jira with authority. Readers would not have to guess about > which data goes in which columns. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-dispatch] ganeshmurthy commented on issue #630: DISPATCH-1186: Add qdstat option to get CSV format for tables
ganeshmurthy commented on issue #630: DISPATCH-1186: Add qdstat option to get CSV format for tables URL: https://github.com/apache/qpid-dispatch/pull/630#issuecomment-558232515 1. Tested all qdstat option combinations with --csv and looked at output in LibreOffice - looks good 2. All system tests pass with this PR. Approving this PR. Ready to go into master. 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] [Resolved] (DISPATCH-1493) qdstat test_address_priority fails by issuing false positive
[
https://issues.apache.org/jira/browse/DISPATCH-1493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Charles E. Rolke resolved DISPATCH-1493.
Fix Version/s: 1.10.0
Resolution: Fixed
Fixed at Commit a99156b5
> qdstat test_address_priority fails by issuing false positive
>
>
> Key: DISPATCH-1493
> URL: https://issues.apache.org/jira/browse/DISPATCH-1493
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Tests
>Affects Versions: 1.9.0
>Reporter: Charles E. Rolke
>Assignee: Charles E. Rolke
>Priority: Major
> Fix For: 1.10.0
>
>
> The test verifies that the priority field of _qdstat --address_ output lines
> each hold a priority between -1 and 9. Unfortunately the priority fields are
> all blank. The actual qdstat output looks like this:
> {noformat}
> 2019-11-22 00:32:51.921253 UTC
> 28: QDR.A
> 28:
> 28: Router Addresses
> 28: class addr phs distrib pri local remote in
> out thru fallback
> 28:
> ===
> 28: local $_management_internal closest0 0 0 0
>0 0
> 28: mobile $management0closest0 0 14 0
>0 0
> 28: local $management closest0 0 0 0
>0 0
> 28: local temp.XTQ3id3e5RY0E9Pbalanced 1 0 0 1
>0 0
> {noformat}
> This test makes no sense in the context of qdstat output with no values in
> the columns of interest.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-2145) libqpid-proton-cpp-static.a not included in make install
[
https://issues.apache.org/jira/browse/PROTON-2145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
berge2007 updated PROTON-2145:
--
Summary: libqpid-proton-cpp-static.a not included in make install (was:
libqpid-proton-cpp-static.a not included in cmake install)
> libqpid-proton-cpp-static.a not included in make install
>
>
> Key: PROTON-2145
> URL: https://issues.apache.org/jira/browse/PROTON-2145
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Affects Versions: proton-c-0.29.0
> Environment: Linux raspberrypi 4.19.75-v7l+ #1270 SMP Tue Sep 24
> 18:51:41 BST 2019 armv7l GNU/Linux
> cmake version 3.13.4
>Reporter: berge2007
>Priority: Major
> Labels: build
>
> +After these steps:+
> {{git clone [https://github.com/apache/qpid-proton.git]}}
> {{cd qpid-proton}}
> {{git checkout 0.29.0}}
> {{mkdir _build}}
> {{cd _build}}
> cmake .. -DCMAKE_INSTALL_PREFIX=/usr/local\
> -DSYSINSTALL_BINDINGS=ON\
> -DBUILD_STATIC_LIBS=ON\
> -DBUILD_TESTING=OFF\
> -DBUILD_WITH_CXX=ON\
> -DENABLE_FUZZ_TESTING=OFF\
> -DFUZZ_REGRESSION_TESTS=OFF\
> {{make -j4}}
> {{make install}}
> +installed files in "/usr/local/lib" folder are:+
> {{/usr/local/lib/libqpid-proton-core.so}}
> {{/usr/local/lib/libqpid-proton-core.so.10}}
> {{/usr/local/lib/libqpid-proton-core.so.10.7.1}}
> {{/usr/local/lib/libqpid-proton-core-static.a}}
> {{/usr/local/lib/libqpid-proton-cpp.so}}
> {{/usr/local/lib/libqpid-proton-cpp.so.12}}
> {{/usr/local/lib/libqpid-proton-cpp.so.12.6.0}}
> {{/usr/local/lib/libqpid-proton-proactor.so}}
> {{/usr/local/lib/libqpid-proton-proactor.so.1}}
> {{/usr/local/lib/libqpid-proton-proactor.so.1.4.1}}
> {{/usr/local/lib/libqpid-proton-proactor-static.a}}
> {{/usr/local/lib/libqpid-proton.so}}
> {{/usr/local/lib/libqpid-proton.so.11}}
> {{/usr/local/lib/libqpid-proton.so.11.8.1}}
> {{/usr/local/lib/libqpid-proton-static.a}}
> so the "libqpid-proton-cpp-static.a" is missing despite that
> "DBUILD_STATIC_LIBS=ON" option
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-2145) libqpid-proton-cpp-static.a not included in cmake install
[
https://issues.apache.org/jira/browse/PROTON-2145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
berge2007 updated PROTON-2145:
--
Description:
+After these steps:+
{{git clone [https://github.com/apache/qpid-proton.git]}}
{{cd qpid-proton}}
{{git checkout 0.29.0}}
{{mkdir _build}}
{{cd _build}}
cmake .. -DCMAKE_INSTALL_PREFIX=/usr/local\
-DSYSINSTALL_BINDINGS=ON\
-DBUILD_STATIC_LIBS=ON\
-DBUILD_TESTING=OFF\
-DBUILD_WITH_CXX=ON\
-DENABLE_FUZZ_TESTING=OFF\
-DFUZZ_REGRESSION_TESTS=OFF\
{{make -j4}}
{{make install}}
+installed files in "/usr/local/lib" folder are:+
{{/usr/local/lib/libqpid-proton-core.so}}
{{/usr/local/lib/libqpid-proton-core.so.10}}
{{/usr/local/lib/libqpid-proton-core.so.10.7.1}}
{{/usr/local/lib/libqpid-proton-core-static.a}}
{{/usr/local/lib/libqpid-proton-cpp.so}}
{{/usr/local/lib/libqpid-proton-cpp.so.12}}
{{/usr/local/lib/libqpid-proton-cpp.so.12.6.0}}
{{/usr/local/lib/libqpid-proton-proactor.so}}
{{/usr/local/lib/libqpid-proton-proactor.so.1}}
{{/usr/local/lib/libqpid-proton-proactor.so.1.4.1}}
{{/usr/local/lib/libqpid-proton-proactor-static.a}}
{{/usr/local/lib/libqpid-proton.so}}
{{/usr/local/lib/libqpid-proton.so.11}}
{{/usr/local/lib/libqpid-proton.so.11.8.1}}
{{/usr/local/lib/libqpid-proton-static.a}}
so the "libqpid-proton-cpp-static.a" is missing despite that
"DBUILD_STATIC_LIBS=ON" option
was:
+After these steps:+
{{git clone [https://github.com/apache/qpid-proton.git]}}
{{cd qpid-proton}}
{{git checkout 0.29.0}}
{{mkdir _build}}
{{cd _build}}
cmake .. -DCMAKE_INSTALL_PREFIX=/usr/local\
-DSYSINSTALL_BINDINGS=ON\
-DBUILD_STATIC_LIBS=ON\
-DBUILD_TESTING=OFF\
-DBUILD_WITH_CXX=ON\
-DENABLE_FUZZ_TESTING=OFF\
-DFUZZ_REGRESSION_TESTS=OFF\
{{make -j4}}
{{make install}}
+installed files the "/usr/local/lib" folder are:+
{{/usr/local/lib/libqpid-proton-core.so}}
{{/usr/local/lib/libqpid-proton-core.so.10}}
{{/usr/local/lib/libqpid-proton-core.so.10.7.1}}
{{/usr/local/lib/libqpid-proton-core-static.a}}
{{/usr/local/lib/libqpid-proton-cpp.so}}
{{/usr/local/lib/libqpid-proton-cpp.so.12}}
{{/usr/local/lib/libqpid-proton-cpp.so.12.6.0}}
{{/usr/local/lib/libqpid-proton-proactor.so}}
{{/usr/local/lib/libqpid-proton-proactor.so.1}}
{{/usr/local/lib/libqpid-proton-proactor.so.1.4.1}}
{{/usr/local/lib/libqpid-proton-proactor-static.a}}
{{/usr/local/lib/libqpid-proton.so}}
{{/usr/local/lib/libqpid-proton.so.11}}
{{/usr/local/lib/libqpid-proton.so.11.8.1}}
{{/usr/local/lib/libqpid-proton-static.a}}
so the "libqpid-proton-cpp-static.a" is missing despite that
"DBUILD_STATIC_LIBS=ON" option
> libqpid-proton-cpp-static.a not included in cmake install
> -
>
> Key: PROTON-2145
> URL: https://issues.apache.org/jira/browse/PROTON-2145
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Affects Versions: proton-c-0.29.0
> Environment: Linux raspberrypi 4.19.75-v7l+ #1270 SMP Tue Sep 24
> 18:51:41 BST 2019 armv7l GNU/Linux
> cmake version 3.13.4
>Reporter: berge2007
>Priority: Major
> Labels: build
>
> +After these steps:+
> {{git clone [https://github.com/apache/qpid-proton.git]}}
> {{cd qpid-proton}}
> {{git checkout 0.29.0}}
> {{mkdir _build}}
> {{cd _build}}
> cmake .. -DCMAKE_INSTALL_PREFIX=/usr/local\
> -DSYSINSTALL_BINDINGS=ON\
> -DBUILD_STATIC_LIBS=ON\
> -DBUILD_TESTING=OFF\
> -DBUILD_WITH_CXX=ON\
> -DENABLE_FUZZ_TESTING=OFF\
> -DFUZZ_REGRESSION_TESTS=OFF\
> {{make -j4}}
> {{make install}}
> +installed files in "/usr/local/lib" folder are:+
> {{/usr/local/lib/libqpid-proton-core.so}}
> {{/usr/local/lib/libqpid-proton-core.so.10}}
> {{/usr/local/lib/libqpid-proton-core.so.10.7.1}}
> {{/usr/local/lib/libqpid-proton-core-static.a}}
> {{/usr/local/lib/libqpid-proton-cpp.so}}
> {{/usr/local/lib/libqpid-proton-cpp.so.12}}
> {{/usr/local/lib/libqpid-proton-cpp.so.12.6.0}}
> {{/usr/local/lib/libqpid-proton-proactor.so}}
> {{/usr/local/lib/libqpid-proton-proactor.so.1}}
> {{/usr/local/lib/libqpid-proton-proactor.so.1.4.1}}
> {{/usr/local/lib/libqpid-proton-proactor-static.a}}
> {{/usr/local/lib/libqpid-proton.so}}
> {{/usr/local/lib/libqpid-proton.so.11}}
> {{/usr/local/lib/libqpid-proton.so.11.8.1}}
> {{/usr/local/lib/libqpid-proton-static.a}}
> so the "libqpid-proton-cpp-static.a" is missing despite that
> "DBUILD_STATIC_LIBS=ON" option
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-2145) libqpid-proton-cpp-static.a not included in cmake install
[
https://issues.apache.org/jira/browse/PROTON-2145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
berge2007 updated PROTON-2145:
--
Description:
+After these steps:+
{{git clone [https://github.com/apache/qpid-proton.git]}}
{{cd qpid-proton}}
{{git checkout 0.29.0}}
{{mkdir _build}}
{{cd _build}}
cmake .. -DCMAKE_INSTALL_PREFIX=/usr/local\
-DSYSINSTALL_BINDINGS=ON\
-DBUILD_STATIC_LIBS=ON\
-DBUILD_TESTING=OFF\
-DBUILD_WITH_CXX=ON\
-DENABLE_FUZZ_TESTING=OFF\
-DFUZZ_REGRESSION_TESTS=OFF\
{{make -j4}}
{{make install}}
+installed files the "/usr/local/lib" folder are:+
{{/usr/local/lib/libqpid-proton-core.so}}
{{/usr/local/lib/libqpid-proton-core.so.10}}
{{/usr/local/lib/libqpid-proton-core.so.10.7.1}}
{{/usr/local/lib/libqpid-proton-core-static.a}}
{{/usr/local/lib/libqpid-proton-cpp.so}}
{{/usr/local/lib/libqpid-proton-cpp.so.12}}
{{/usr/local/lib/libqpid-proton-cpp.so.12.6.0}}
{{/usr/local/lib/libqpid-proton-proactor.so}}
{{/usr/local/lib/libqpid-proton-proactor.so.1}}
{{/usr/local/lib/libqpid-proton-proactor.so.1.4.1}}
{{/usr/local/lib/libqpid-proton-proactor-static.a}}
{{/usr/local/lib/libqpid-proton.so}}
{{/usr/local/lib/libqpid-proton.so.11}}
{{/usr/local/lib/libqpid-proton.so.11.8.1}}
{{/usr/local/lib/libqpid-proton-static.a}}
so the "libqpid-proton-cpp-static.a" is missing despite that
"DBUILD_STATIC_LIBS=ON" option
was:
+After these steps:+
{{git clone [https://github.com/apache/qpid-proton.git]}}
{{cd qpid-proton}}
{{git checkout 0.29.0}}
{{mkdir _build}}
{{cd _build}}
cmake .. -DCMAKE_INSTALL_PREFIX=/usr/local\
-DSYSINSTALL_BINDINGS=ON\
-DBUILD_STATIC_LIBS=ON\
-DBUILD_TESTING=OFF\
-DBUILD_WITH_CXX=ON\
-DENABLE_FUZZ_TESTING=OFF\
-DFUZZ_REGRESSION_TESTS=OFF\
{{make -j4}}
{{make install}}
+the in the "/usr/local/lib" folder are:+
{{/usr/local/lib/libqpid-proton-core.so}}
{{/usr/local/lib/libqpid-proton-core.so.10}}
{{/usr/local/lib/libqpid-proton-core.so.10.7.1}}
{{/usr/local/lib/libqpid-proton-core-static.a}}
{{/usr/local/lib/libqpid-proton-cpp.so}}
{{/usr/local/lib/libqpid-proton-cpp.so.12}}
{{/usr/local/lib/libqpid-proton-cpp.so.12.6.0}}
{{/usr/local/lib/libqpid-proton-proactor.so}}
{{/usr/local/lib/libqpid-proton-proactor.so.1}}
{{/usr/local/lib/libqpid-proton-proactor.so.1.4.1}}
{{/usr/local/lib/libqpid-proton-proactor-static.a}}
{{/usr/local/lib/libqpid-proton.so}}
{{/usr/local/lib/libqpid-proton.so.11}}
{{/usr/local/lib/libqpid-proton.so.11.8.1}}
{{/usr/local/lib/libqpid-proton-static.a}}
so the "libqpid-proton-cpp-static.a" is missing despite that
"DBUILD_STATIC_LIBS=ON" option
> libqpid-proton-cpp-static.a not included in cmake install
> -
>
> Key: PROTON-2145
> URL: https://issues.apache.org/jira/browse/PROTON-2145
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Affects Versions: proton-c-0.29.0
> Environment: Linux raspberrypi 4.19.75-v7l+ #1270 SMP Tue Sep 24
> 18:51:41 BST 2019 armv7l GNU/Linux
> cmake version 3.13.4
>Reporter: berge2007
>Priority: Major
> Labels: build
>
> +After these steps:+
> {{git clone [https://github.com/apache/qpid-proton.git]}}
> {{cd qpid-proton}}
> {{git checkout 0.29.0}}
> {{mkdir _build}}
> {{cd _build}}
> cmake .. -DCMAKE_INSTALL_PREFIX=/usr/local\
> -DSYSINSTALL_BINDINGS=ON\
> -DBUILD_STATIC_LIBS=ON\
> -DBUILD_TESTING=OFF\
> -DBUILD_WITH_CXX=ON\
> -DENABLE_FUZZ_TESTING=OFF\
> -DFUZZ_REGRESSION_TESTS=OFF\
> {{make -j4}}
> {{make install}}
> +installed files the "/usr/local/lib" folder are:+
> {{/usr/local/lib/libqpid-proton-core.so}}
> {{/usr/local/lib/libqpid-proton-core.so.10}}
> {{/usr/local/lib/libqpid-proton-core.so.10.7.1}}
> {{/usr/local/lib/libqpid-proton-core-static.a}}
> {{/usr/local/lib/libqpid-proton-cpp.so}}
> {{/usr/local/lib/libqpid-proton-cpp.so.12}}
> {{/usr/local/lib/libqpid-proton-cpp.so.12.6.0}}
> {{/usr/local/lib/libqpid-proton-proactor.so}}
> {{/usr/local/lib/libqpid-proton-proactor.so.1}}
> {{/usr/local/lib/libqpid-proton-proactor.so.1.4.1}}
> {{/usr/local/lib/libqpid-proton-proactor-static.a}}
> {{/usr/local/lib/libqpid-proton.so}}
> {{/usr/local/lib/libqpid-proton.so.11}}
> {{/usr/local/lib/libqpid-proton.so.11.8.1}}
> {{/usr/local/lib/libqpid-proton-static.a}}
> so the "libqpid-proton-cpp-static.a" is missing despite that
> "DBUILD_STATIC_LIBS=ON" option
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-2145) libqpid-proton-cpp-static.a not included in cmake install
[
https://issues.apache.org/jira/browse/PROTON-2145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
berge2007 updated PROTON-2145:
--
Description:
+After these steps:+
{{git clone [https://github.com/apache/qpid-proton.git]}}
{{cd qpid-proton}}
{{git checkout 0.29.0}}
{{mkdir _build}}
{{cd _build}}
cmake .. -DCMAKE_INSTALL_PREFIX=/usr/local\
-DSYSINSTALL_BINDINGS=ON\
-DBUILD_STATIC_LIBS=ON\
-DBUILD_TESTING=OFF\
-DBUILD_WITH_CXX=ON\
-DENABLE_FUZZ_TESTING=OFF\
-DFUZZ_REGRESSION_TESTS=OFF\
{{make -j4}}
{{make install}}
+the in the "/usr/local/lib" folder are:+
{{/usr/local/lib/libqpid-proton-core.so}}
{{/usr/local/lib/libqpid-proton-core.so.10}}
{{/usr/local/lib/libqpid-proton-core.so.10.7.1}}
{{/usr/local/lib/libqpid-proton-core-static.a}}
{{/usr/local/lib/libqpid-proton-cpp.so}}
{{/usr/local/lib/libqpid-proton-cpp.so.12}}
{{/usr/local/lib/libqpid-proton-cpp.so.12.6.0}}
{{/usr/local/lib/libqpid-proton-proactor.so}}
{{/usr/local/lib/libqpid-proton-proactor.so.1}}
{{/usr/local/lib/libqpid-proton-proactor.so.1.4.1}}
{{/usr/local/lib/libqpid-proton-proactor-static.a}}
{{/usr/local/lib/libqpid-proton.so}}
{{/usr/local/lib/libqpid-proton.so.11}}
{{/usr/local/lib/libqpid-proton.so.11.8.1}}
{{/usr/local/lib/libqpid-proton-static.a}}
so the "libqpid-proton-cpp-static.a" is missing despite that
"DBUILD_STATIC_LIBS=ON" option
was:
+After these steps:+
{{git clone [https://github.com/apache/qpid-proton.git]}}
{{cd qpid-proton}}
{{git checkout 0.29.0}}
{{mkdir _build}}
{{cd _build}}
cmake .. -DCMAKE_INSTALL_PREFIX=/usr/local\
-DSYSINSTALL_BINDINGS=ON\
-DBUILD_STATIC_LIBS=ON\
-DBUILD_TESTING=OFF\
-DBUILD_WITH_CXX=ON\
-DENABLE_FUZZ_TESTING=OFF\
-DFUZZ_REGRESSION_TESTS=OFF\
{{make -j4}}
{{make install}}
+the ".a" files in the "/usr/local/lib" folder are:+
{{/usr/local/lib/libqpid-proton-core.so}}
{{/usr/local/lib/libqpid-proton-core.so.10}}
{{/usr/local/lib/libqpid-proton-core.so.10.7.1}}
{{/usr/local/lib/libqpid-proton-core-static.a}}
{{/usr/local/lib/libqpid-proton-cpp.so}}
{{/usr/local/lib/libqpid-proton-cpp.so.12}}
{{/usr/local/lib/libqpid-proton-cpp.so.12.6.0}}
{{/usr/local/lib/libqpid-proton-proactor.so}}
{{/usr/local/lib/libqpid-proton-proactor.so.1}}
{{/usr/local/lib/libqpid-proton-proactor.so.1.4.1}}
{{/usr/local/lib/libqpid-proton-proactor-static.a}}
{{/usr/local/lib/libqpid-proton.so}}
{{/usr/local/lib/libqpid-proton.so.11}}
{{/usr/local/lib/libqpid-proton.so.11.8.1}}
{{/usr/local/lib/libqpid-proton-static.a}}
so the "libqpid-proton-cpp-static.a" is missing despite that
"DBUILD_STATIC_LIBS=ON" option
> libqpid-proton-cpp-static.a not included in cmake install
> -
>
> Key: PROTON-2145
> URL: https://issues.apache.org/jira/browse/PROTON-2145
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Affects Versions: proton-c-0.29.0
> Environment: Linux raspberrypi 4.19.75-v7l+ #1270 SMP Tue Sep 24
> 18:51:41 BST 2019 armv7l GNU/Linux
> cmake version 3.13.4
>Reporter: berge2007
>Priority: Major
> Labels: build
>
> +After these steps:+
> {{git clone [https://github.com/apache/qpid-proton.git]}}
> {{cd qpid-proton}}
> {{git checkout 0.29.0}}
> {{mkdir _build}}
> {{cd _build}}
> cmake .. -DCMAKE_INSTALL_PREFIX=/usr/local\
> -DSYSINSTALL_BINDINGS=ON\
> -DBUILD_STATIC_LIBS=ON\
> -DBUILD_TESTING=OFF\
> -DBUILD_WITH_CXX=ON\
> -DENABLE_FUZZ_TESTING=OFF\
> -DFUZZ_REGRESSION_TESTS=OFF\
> {{make -j4}}
> {{make install}}
> +the in the "/usr/local/lib" folder are:+
> {{/usr/local/lib/libqpid-proton-core.so}}
> {{/usr/local/lib/libqpid-proton-core.so.10}}
> {{/usr/local/lib/libqpid-proton-core.so.10.7.1}}
> {{/usr/local/lib/libqpid-proton-core-static.a}}
> {{/usr/local/lib/libqpid-proton-cpp.so}}
> {{/usr/local/lib/libqpid-proton-cpp.so.12}}
> {{/usr/local/lib/libqpid-proton-cpp.so.12.6.0}}
> {{/usr/local/lib/libqpid-proton-proactor.so}}
> {{/usr/local/lib/libqpid-proton-proactor.so.1}}
> {{/usr/local/lib/libqpid-proton-proactor.so.1.4.1}}
> {{/usr/local/lib/libqpid-proton-proactor-static.a}}
> {{/usr/local/lib/libqpid-proton.so}}
> {{/usr/local/lib/libqpid-proton.so.11}}
> {{/usr/local/lib/libqpid-proton.so.11.8.1}}
> {{/usr/local/lib/libqpid-proton-static.a}}
> so the "libqpid-proton-cpp-static.a" is missing despite that
> "DBUILD_STATIC_LIBS=ON" option
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-2145) libqpid-proton-cpp-static.a not included in cmake install
[
https://issues.apache.org/jira/browse/PROTON-2145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
berge2007 updated PROTON-2145:
--
Description:
+After these steps:+
{{git clone [https://github.com/apache/qpid-proton.git]}}
{{cd qpid-proton}}
{{git checkout 0.29.0}}
{{mkdir _build}}
{{cd _build}}
cmake .. -DCMAKE_INSTALL_PREFIX=/usr/local\
-DSYSINSTALL_BINDINGS=ON\
-DBUILD_STATIC_LIBS=ON\
-DBUILD_TESTING=OFF\
-DBUILD_WITH_CXX=ON\
-DENABLE_FUZZ_TESTING=OFF\
-DFUZZ_REGRESSION_TESTS=OFF\
{{make -j4}}
{{make install}}
+the ".a" files in the "/usr/local/lib" folder are:+
{{/usr/local/lib/libqpid-proton-core.so}}
{{/usr/local/lib/libqpid-proton-core.so.10}}
{{/usr/local/lib/libqpid-proton-core.so.10.7.1}}
{{/usr/local/lib/libqpid-proton-core-static.a}}
{{/usr/local/lib/libqpid-proton-cpp.so}}
{{/usr/local/lib/libqpid-proton-cpp.so.12}}
{{/usr/local/lib/libqpid-proton-cpp.so.12.6.0}}
{{/usr/local/lib/libqpid-proton-proactor.so}}
{{/usr/local/lib/libqpid-proton-proactor.so.1}}
{{/usr/local/lib/libqpid-proton-proactor.so.1.4.1}}
{{/usr/local/lib/libqpid-proton-proactor-static.a}}
{{/usr/local/lib/libqpid-proton.so}}
{{/usr/local/lib/libqpid-proton.so.11}}
{{/usr/local/lib/libqpid-proton.so.11.8.1}}
{{/usr/local/lib/libqpid-proton-static.a}}
so the "libqpid-proton-cpp-static.a" is missing despite that
"DBUILD_STATIC_LIBS=ON" option
was:
+After these steps:+
{{git clone https://github.com/apache/qpid-proton.git}}
{{cd qpid-proton}}
{{git checkout 0.29.0}}
{{mkdir _build}}
{{cd _build}}
{{cmake .. -DCMAKE_INSTALL_PREFIX=/usr/local\ }}
{{ -DSYSINSTALL_BINDINGS=ON\}}
{{ -DBUILD_STATIC_LIBS=ON\}}
{{ -DBUILD_TESTING=OFF\}}
{{ -DBUILD_WITH_CXX=ON\}}
{{ -DENABLE_FUZZ_TESTING=OFF\}}
{{ -DFUZZ_REGRESSION_TESTS=OFF}}
{{make -j4}}
{{make install}}
+the ".a" files in the "/usr/local/lib" folder are:+
{{/usr/local/lib/libqpid-proton-core.so}}
{{/usr/local/lib/libqpid-proton-core.so.10}}
{{/usr/local/lib/libqpid-proton-core.so.10.7.1}}
{{/usr/local/lib/libqpid-proton-core-static.a}}
{{/usr/local/lib/libqpid-proton-cpp.so}}
{{/usr/local/lib/libqpid-proton-cpp.so.12}}
{{/usr/local/lib/libqpid-proton-cpp.so.12.6.0}}
{{/usr/local/lib/libqpid-proton-proactor.so}}
{{/usr/local/lib/libqpid-proton-proactor.so.1}}
{{/usr/local/lib/libqpid-proton-proactor.so.1.4.1}}
{{/usr/local/lib/libqpid-proton-proactor-static.a}}
{{/usr/local/lib/libqpid-proton.so}}
{{/usr/local/lib/libqpid-proton.so.11}}
{{/usr/local/lib/libqpid-proton.so.11.8.1}}
{{/usr/local/lib/libqpid-proton-static.a}}
so the "libqpid-proton-cpp-static.a" is missing despite that
"DBUILD_STATIC_LIBS=ON" option
> libqpid-proton-cpp-static.a not included in cmake install
> -
>
> Key: PROTON-2145
> URL: https://issues.apache.org/jira/browse/PROTON-2145
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Affects Versions: proton-c-0.29.0
> Environment: Linux raspberrypi 4.19.75-v7l+ #1270 SMP Tue Sep 24
> 18:51:41 BST 2019 armv7l GNU/Linux
> cmake version 3.13.4
>Reporter: berge2007
>Priority: Major
> Labels: build
>
> +After these steps:+
> {{git clone [https://github.com/apache/qpid-proton.git]}}
> {{cd qpid-proton}}
> {{git checkout 0.29.0}}
> {{mkdir _build}}
> {{cd _build}}
> cmake .. -DCMAKE_INSTALL_PREFIX=/usr/local\
> -DSYSINSTALL_BINDINGS=ON\
> -DBUILD_STATIC_LIBS=ON\
> -DBUILD_TESTING=OFF\
> -DBUILD_WITH_CXX=ON\
> -DENABLE_FUZZ_TESTING=OFF\
> -DFUZZ_REGRESSION_TESTS=OFF\
> {{make -j4}}
> {{make install}}
> +the ".a" files in the "/usr/local/lib" folder are:+
> {{/usr/local/lib/libqpid-proton-core.so}}
> {{/usr/local/lib/libqpid-proton-core.so.10}}
> {{/usr/local/lib/libqpid-proton-core.so.10.7.1}}
> {{/usr/local/lib/libqpid-proton-core-static.a}}
> {{/usr/local/lib/libqpid-proton-cpp.so}}
> {{/usr/local/lib/libqpid-proton-cpp.so.12}}
> {{/usr/local/lib/libqpid-proton-cpp.so.12.6.0}}
> {{/usr/local/lib/libqpid-proton-proactor.so}}
> {{/usr/local/lib/libqpid-proton-proactor.so.1}}
> {{/usr/local/lib/libqpid-proton-proactor.so.1.4.1}}
> {{/usr/local/lib/libqpid-proton-proactor-static.a}}
> {{/usr/local/lib/libqpid-proton.so}}
> {{/usr/local/lib/libqpid-proton.so.11}}
> {{/usr/local/lib/libqpid-proton.so.11.8.1}}
> {{/usr/local/lib/libqpid-proton-static.a}}
> so the "libqpid-proton-cpp-static.a" is missing despite that
> "DBUILD_STATIC_LIBS=ON" option
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-2145) libqpid-proton-cpp-static.a not included in cmake install
berge2007 created PROTON-2145:
-
Summary: libqpid-proton-cpp-static.a not included in cmake install
Key: PROTON-2145
URL: https://issues.apache.org/jira/browse/PROTON-2145
Project: Qpid Proton
Issue Type: Bug
Components: cpp-binding
Affects Versions: proton-c-0.29.0
Environment: Linux raspberrypi 4.19.75-v7l+ #1270 SMP Tue Sep 24
18:51:41 BST 2019 armv7l GNU/Linux
cmake version 3.13.4
Reporter: berge2007
+After these steps:+
{{git clone https://github.com/apache/qpid-proton.git}}
{{cd qpid-proton}}
{{git checkout 0.29.0}}
{{mkdir _build}}
{{cd _build}}
{{cmake .. -DCMAKE_INSTALL_PREFIX=/usr/local\ }}
{{ -DSYSINSTALL_BINDINGS=ON\}}
{{ -DBUILD_STATIC_LIBS=ON\}}
{{ -DBUILD_TESTING=OFF\}}
{{ -DBUILD_WITH_CXX=ON\}}
{{ -DENABLE_FUZZ_TESTING=OFF\}}
{{ -DFUZZ_REGRESSION_TESTS=OFF}}
{{make -j4}}
{{make install}}
+the ".a" files in the "/usr/local/lib" folder are:+
{{/usr/local/lib/libqpid-proton-core.so}}
{{/usr/local/lib/libqpid-proton-core.so.10}}
{{/usr/local/lib/libqpid-proton-core.so.10.7.1}}
{{/usr/local/lib/libqpid-proton-core-static.a}}
{{/usr/local/lib/libqpid-proton-cpp.so}}
{{/usr/local/lib/libqpid-proton-cpp.so.12}}
{{/usr/local/lib/libqpid-proton-cpp.so.12.6.0}}
{{/usr/local/lib/libqpid-proton-proactor.so}}
{{/usr/local/lib/libqpid-proton-proactor.so.1}}
{{/usr/local/lib/libqpid-proton-proactor.so.1.4.1}}
{{/usr/local/lib/libqpid-proton-proactor-static.a}}
{{/usr/local/lib/libqpid-proton.so}}
{{/usr/local/lib/libqpid-proton.so.11}}
{{/usr/local/lib/libqpid-proton.so.11.8.1}}
{{/usr/local/lib/libqpid-proton-static.a}}
so the "libqpid-proton-cpp-static.a" is missing despite that
"DBUILD_STATIC_LIBS=ON" option
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2141) [cpp] Make unit tests pass on ipv4 machine
[ https://issues.apache.org/jira/browse/PROTON-2141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16981657#comment-16981657 ] Andrew Stitcher commented on PROTON-2141: - This line is the problem: ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 Your machine is misconfigured. You are telling it that locahost maps to 2 addresses IPv4 127.0.0.1 & IPv6 ::1. So it's not a surprise that both addresses are tried! Closing as not a bug. > [cpp] Make unit tests pass on ipv4 machine > -- > > Key: PROTON-2141 > URL: https://issues.apache.org/jira/browse/PROTON-2141 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: proton-c-0.29.0 >Reporter: Rabih Mourad >Priority: Major > Attachments: errors.log > > > There are test failure when running unit tests on an ipv4 machine. > So we propose the pull request below. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (PROTON-2141) [cpp] Make unit tests pass on ipv4 machine
[ https://issues.apache.org/jira/browse/PROTON-2141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved PROTON-2141. - Resolution: Not A Bug > [cpp] Make unit tests pass on ipv4 machine > -- > > Key: PROTON-2141 > URL: https://issues.apache.org/jira/browse/PROTON-2141 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: proton-c-0.29.0 >Reporter: Rabih Mourad >Priority: Major > Attachments: errors.log > > > There are test failure when running unit tests on an ipv4 machine. > So we propose the pull request below. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1495) [tools] qdstat man - some help strings truncated
Charles E. Rolke created DISPATCH-1495:
--
Summary: [tools] qdstat man - some help strings truncated
Key: DISPATCH-1495
URL: https://issues.apache.org/jira/browse/DISPATCH-1495
Project: Qpid Dispatch
Issue Type: Bug
Components: Tools
Affects Versions: 1.9.0
Environment: Fedora 29, Python 3.7.4
Reporter: Charles E. Rolke
_man qdstat_ shows some help texts truncated
{noformat}
--limit LIMIT : Limit number of output rows. Unlimited if limit is
--all-entities : Show all router entities. Can be combined with --all-
--all-routers : Show entities for all routers in network. Can also be
{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1186) qdstat to include csv output format
[ https://issues.apache.org/jira/browse/DISPATCH-1186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16981630#comment-16981630 ] ASF GitHub Bot commented on DISPATCH-1186: -- ChugR commented on pull request #630: DISPATCH-1186: Add qdstat option to get CSV format for tables URL: https://github.com/apache/qpid-dispatch/pull/630 Add a "--csv" switch to qdstat command line to apply to display tables. || CSV character || value|| | separator | comma| | string quote | double quote | All non-blank values in headings and tables are output as quoted strings. Blank values in tables are not quoted. The output shall be consecutive separator commas. This option removes ambiguity for certain tables (like 'qdstat -l') where columns (like peer and phs) have no entry, and headers (like 'conn id') have spaces in their names. 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 > qdstat to include csv output format > --- > > Key: DISPATCH-1186 > URL: https://issues.apache.org/jira/browse/DISPATCH-1186 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Management Agent >Affects Versions: 1.4.1 >Reporter: Charles E. Rolke >Assignee: Ken Giusti >Priority: Major > > qdstat text output is difficult to manage after a cut and paste. For > instance, _qdstat -l_ shows some rows where the columns are blank. This > makes it difficult to reconstruct the original display given just the body > text. See _qdstat -l_ example in > [https://raw.githubusercontent.com/apache/qpid-dispatch/master/docs/books/user-guide/monitoring-using-qdstat.adoc] > Even having a two-word column title "conn id" adds confusion. > With a CSV format and quoted strings this table could be communicated through > email, chat, or Jira with authority. Readers would not have to guess about > which data goes in which columns. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-dispatch] ChugR opened a new pull request #630: DISPATCH-1186: Add qdstat option to get CSV format for tables
ChugR opened a new pull request #630: DISPATCH-1186: Add qdstat option to get CSV format for tables URL: https://github.com/apache/qpid-dispatch/pull/630 Add a "--csv" switch to qdstat command line to apply to display tables. || CSV character || value|| | separator | comma| | string quote | double quote | All non-blank values in headings and tables are output as quoted strings. Blank values in tables are not quoted. The output shall be consecutive separator commas. This option removes ambiguity for certain tables (like 'qdstat -l') where columns (like peer and phs) have no entry, and headers (like 'conn id') have spaces in their names. 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-1186) qdstat to include csv output format
[ https://issues.apache.org/jira/browse/DISPATCH-1186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16981628#comment-16981628 ] ASF GitHub Bot commented on DISPATCH-1186: -- ChugR commented on issue #623: DISPATCH-1186: Add option to get CSV formatting for qdstat tables URL: https://github.com/apache/qpid-dispatch/pull/623#issuecomment-558195367 This PR is closed. A new PR based on current master to be created. 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 > qdstat to include csv output format > --- > > Key: DISPATCH-1186 > URL: https://issues.apache.org/jira/browse/DISPATCH-1186 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Management Agent >Affects Versions: 1.4.1 >Reporter: Charles E. Rolke >Assignee: Ken Giusti >Priority: Major > > qdstat text output is difficult to manage after a cut and paste. For > instance, _qdstat -l_ shows some rows where the columns are blank. This > makes it difficult to reconstruct the original display given just the body > text. See _qdstat -l_ example in > [https://raw.githubusercontent.com/apache/qpid-dispatch/master/docs/books/user-guide/monitoring-using-qdstat.adoc] > Even having a two-word column title "conn id" adds confusion. > With a CSV format and quoted strings this table could be communicated through > email, chat, or Jira with authority. Readers would not have to guess about > which data goes in which columns. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1186) qdstat to include csv output format
[ https://issues.apache.org/jira/browse/DISPATCH-1186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16981629#comment-16981629 ] ASF GitHub Bot commented on DISPATCH-1186: -- ChugR commented on pull request #623: DISPATCH-1186: Add option to get CSV formatting for qdstat tables URL: https://github.com/apache/qpid-dispatch/pull/623 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 > qdstat to include csv output format > --- > > Key: DISPATCH-1186 > URL: https://issues.apache.org/jira/browse/DISPATCH-1186 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Management Agent >Affects Versions: 1.4.1 >Reporter: Charles E. Rolke >Assignee: Ken Giusti >Priority: Major > > qdstat text output is difficult to manage after a cut and paste. For > instance, _qdstat -l_ shows some rows where the columns are blank. This > makes it difficult to reconstruct the original display given just the body > text. See _qdstat -l_ example in > [https://raw.githubusercontent.com/apache/qpid-dispatch/master/docs/books/user-guide/monitoring-using-qdstat.adoc] > Even having a two-word column title "conn id" adds confusion. > With a CSV format and quoted strings this table could be communicated through > email, chat, or Jira with authority. Readers would not have to guess about > which data goes in which columns. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-dispatch] ChugR closed pull request #623: DISPATCH-1186: Add option to get CSV formatting for qdstat tables
ChugR closed pull request #623: DISPATCH-1186: Add option to get CSV formatting for qdstat tables URL: https://github.com/apache/qpid-dispatch/pull/623 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-dispatch] ChugR commented on issue #623: DISPATCH-1186: Add option to get CSV formatting for qdstat tables
ChugR commented on issue #623: DISPATCH-1186: Add option to get CSV formatting for qdstat tables URL: https://github.com/apache/qpid-dispatch/pull/623#issuecomment-558195367 This PR is closed. A new PR based on current master to be created. 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-proton] jdanekrh commented on issue #211: DISCUSS: gbenchmark c++ microbenchmark
jdanekrh commented on issue #211: DISCUSS: gbenchmark c++ microbenchmark URL: https://github.com/apache/qpid-proton/pull/211#issuecomment-558169649 Initial set of tests ``` $ cmake .. -DENABLE_BENCHMARKS=ON $ ctest -V -R benchmarks ``` Expand UpdateCTestConfiguration from :/home/jdanek/repos/qpid/qpid-proton/cmake-build-release/DartConfiguration.tcl Parse Config file:/home/jdanek/repos/qpid/qpid-proton/cmake-build-release/DartConfiguration.tcl UpdateCTestConfiguration from :/home/jdanek/repos/qpid/qpid-proton/cmake-build-release/DartConfiguration.tcl Parse Config file:/home/jdanek/repos/qpid/qpid-proton/cmake-build-release/DartConfiguration.tcl Test project /home/jdanek/repos/qpid/qpid-proton/cmake-build-release Constructing a list of tests Done constructing a list of tests Updating test list for fixtures Added 0 tests to meet fixture requirements Checking test dependency graph... Checking test dependency graph end test 1 Start 1: c-benchmarks 1: Test command: /home/jdanek/repos/qpid/qpid-proton/cmake-build-release/c/benchmarks/c-benchmarks 1: Test timeout computed to be: 1500 1: 2019-11-25 14:56:51 1: Running /home/jdanek/repos/qpid/qpid-proton/cmake-build-release/c/benchmarks/c-benchmarks 1: Run on (8 X 4200 MHz CPU s) 1: CPU Caches: 1: L1 Data 32K (x4) 1: L1 Instruction 32K (x4) 1: L2 Unified 256K (x4) 1: L3 Unified 8192K (x1) 1: Load Average: 1.03, 0.84, 0.81 1: - 1: Benchmark Time CPU Iterations 1: - 1: BM_InitCloseSender 6.56 us 6.56 us 103901 1: BM_InitCloseReceiver 6.59 us 6.59 us 110445 1: BM_EstablishConnection 58.6 us 58.6 us12014 items_per_second=1.42015/s messages 1: BM_SendReceiveMessages/creditWindow:1 0.007 ms0.007 ms 102669 items_per_second=49.1243k/s messages 1: BM_SendReceiveMessages/creditWindow:3 0.016 ms0.016 ms44874 items_per_second=64.4187k/s messages 1: BM_SendReceiveMessages/creditWindow:9 0.039 ms0.039 ms17263 items_per_second=77.4869k/s messages 1: BM_SendReceiveMessages/creditWindow:27 0.118 ms0.118 ms 5930 items_per_second=76.3999k/s messages 1: BM_SendReceiveMessages/creditWindow:81 0.342 ms0.342 ms 2054 items_per_second=78.8127k/s messages 1: BM_SendReceiveMessages/creditWindow:243 0.993 ms0.993 ms 731 items_per_second=81.0102k/s messages 1: BM_SendReceiveMessages/creditWindow:729 2.50 ms 2.50 ms 287 items_per_second=80.0469k/s messages 1: BM_SendReceiveMessages/creditWindow:2187 2.47 ms 2.47 ms 284 items_per_second=80.9756k/s messages 1: BM_SendReceiveMessages/creditWindow:6561 2.57 ms 2.57 ms 266 items_per_second=77.6695k/s messages 1: BM_SendReceiveMessages/creditWindow:196832.84 ms 2.84 ms 203 items_per_second=69.8212k/s messages 1: BM_SendReceiveMessages/creditWindow:590494.65 ms 4.65 ms 109 items_per_second=41.529k/s messages 1: BM_SendReceiveMessages/creditWindow:177147 81.3 ms 81.3 ms 10 items_per_second=1022.63/s messages 1: BM_SendReceiveMessages/creditWindow:20 87.1 ms 87.1 ms 10 items_per_second=953.899/s messages 1: BM_SendReceiveMessages/creditWindow:1000 2.46 ms 2.46 ms 292 items_per_second=81.3426k/s messages 1: BM_EncodeListMessage/entries:10 0.003 ms0.003 ms 243715 items_per_second=3.48287M/s entries 1: BM_EncodeListMessage/entries:1000.028 ms0.028 ms25122 items_per_second=3.5689M/s entries 1: BM_EncodeListMessage/entries:1 6.48 ms 6.48 ms 107 items_per_second=1.54238M/s entries 1: BM_CreateListMessage 18.7 ns 18.7 ns 36550790 items_per_second=107.191M/s entries 1: BM_EncodeMapMessage/entries:10 0.004 ms0.004 ms 181525 items_per_second=2.58808M/s entries 1: BM_EncodeMapMessage/entries:100 0.064 ms0.064 ms10869 items_per_second=1.56887M/s entries 1: BM_EncodeMapMessage/entries:114.2 ms 14.2 ms 49 i
[jira] [Updated] (QPID-8384) [Broker-J] LastValueQueueList can leak deleted queue entries
[
https://issues.apache.org/jira/browse/QPID-8384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-8384:
-
Fix Version/s: qpid-java-broker-8.0.0
> [Broker-J] LastValueQueueList can leak deleted queue entries
>
>
> Key: QPID-8384
> URL: https://issues.apache.org/jira/browse/QPID-8384
> Project: Qpid
> Issue Type: Task
> Components: Broker-J
>Affects Versions: 0.17, 0.18, 0.19, 0.20, 0.21, 0.22, 0.23, 0.24, 0.25,
> 0.26, 0.27, 0.28, 0.29, 0.30, 0.31, 0.32, 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.1, qpid-java-6.0.6, qpid-java-6.1.1, qpid-java-6.1.2,
> qpid-java-6.0.7, qpid-java-6.1.3, qpid-java-6.0.8, qpid-java-6.1.4,
> qpid-java-broker-7.0.0, qpid-java-6.1.5, qpid-java-broker-7.0.1,
> qpid-java-6.1.7, qpid-java-broker-7.1.0, qpid-java-broker-7.0.4,
> qpid-java-broker-7.0.5, qpid-java-broker-7.0.6, qpid-java-broker-7.0.7,
> qpid-java-6.1.8, qpid-java-broker-7.1.1, qpid-java-broker-7.1.2,
> qpid-java-broker-7.0.8, qpid-java-broker-7.1.3, qpid-java-broker-7.1.4
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-8.0.0, qpid-java-broker-7.1.6
>
>
> Qpid Broker-j can run out of heap memory due to leaking deleted LVQ entries
> via {{LastValueQueueList#_latestValuesMap}}.
> The deleted queue entry can be left in
> {{LastValueQueueList#_latestValuesMap}} in result of race between enqueing
> thread and consuming or management thread, where entry is deleted. An LVQ
> entry is removed from {{LastValueQueueList#_latestValuesMap}}, when
> {{_latestValueReference}} is set on the entry as part of invocation
> {{LastValueQueueList#add(...)}}. If {{_latestValueReference}} is not set in
> result of unfortunate thread scheduling, the LVQ entry might not be removed
> from the {{LastValueQueueList#_latestValuesMap}} as part of invocation of
> {{LastValueQueueList$ConflationQueueEntry#onDelete}}.
> In some unlucky circumstances the deleted entry can hold a reference to
> another deleted entry. They can makes a chain of deleted entries, which is
> referenced from {{LastValueQueueList#_latestValuesMap}}. The latter prevents
> the Garbage Collector from freeing the memory occupied by the chain of
> deleted entries.
> The solution for this problem seems require adding into
> {{LastValueQueueList#add(...)}} after setting of
> {{LastValueQueueList$ConflationQueueEntry#_latestValueReference}} a call to
> {{LastValueQueueList$ConflationQueueEntry#onDelete}}, when the entry state is
> {{DELETED}}.
> The reason why deleted LVQ entries remained linked together is not clear yet.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8378) [Broker-J] Message references can be leaked in some rare circumstances
[
https://issues.apache.org/jira/browse/QPID-8378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Godfrey updated QPID-8378:
-
Description: A defect was found in changes for method
{{AbstractQueue#visit()QueueEntryVisitor}} introduced as part of QPID-8273. In
some rare circumstance the message references can be leaked (when method
{{#visitor()}} is called and entry is deleted between call to
{{QueueEntryIterator#advance}} and
{{org.apache.qpid.server.queue.QueueEntry#newMessageReference}} ), which could
result in unexpected message references left behind. Potentially, the
persistent message can be left un-deleted after removal of queue entry. (was:
A defect was found in changes for method
{{AbstractQueue#visit()QueueEntryVisitor}} introduced as part of QPID-8273. In
some rear circumstance the message references can be leaked (when method
{{#visitor()}} is called and entry is deleted between call to
{{QueueEntryIterator#advance}} and
{{org.apache.qpid.server.queue.QueueEntry#newMessageReference}} ), which could
result in unexpected message references left behind. Potentially, the
persistent message can be left un-deleted after removal of queue entry.)
> [Broker-J] Message references can be leaked in some rare circumstances
> --
>
> Key: QPID-8378
> URL: https://issues.apache.org/jira/browse/QPID-8378
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.1.1, qpid-java-broker-7.1.2,
> qpid-java-broker-7.1.3, qpid-java-broker-7.1.4, qpid-java-broker-7.1.5
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-8.0.0, qpid-java-broker-7.1.6
>
>
> A defect was found in changes for method
> {{AbstractQueue#visit()QueueEntryVisitor}} introduced as part of QPID-8273.
> In some rare circumstance the message references can be leaked (when method
> {{#visitor()}} is called and entry is deleted between call to
> {{QueueEntryIterator#advance}} and
> {{org.apache.qpid.server.queue.QueueEntry#newMessageReference}} ), which
> could result in unexpected message references left behind. Potentially, the
> persistent message can be left un-deleted after removal of queue entry.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8378) [Broker-J] Message references can be leaked in some rare circumstances
[
https://issues.apache.org/jira/browse/QPID-8378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Godfrey updated QPID-8378:
-
Summary: [Broker-J] Message references can be leaked in some rare
circumstances (was: [Broker-J] Message references can be leaked in some rear
circumstances)
> [Broker-J] Message references can be leaked in some rare circumstances
> --
>
> Key: QPID-8378
> URL: https://issues.apache.org/jira/browse/QPID-8378
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.1.1, qpid-java-broker-7.1.2,
> qpid-java-broker-7.1.3, qpid-java-broker-7.1.4, qpid-java-broker-7.1.5
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-8.0.0, qpid-java-broker-7.1.6
>
>
> A defect was found in changes for method
> {{AbstractQueue#visit()QueueEntryVisitor}} introduced as part of QPID-8273.
> In some rear circumstance the message references can be leaked (when method
> {{#visitor()}} is called and entry is deleted between call to
> {{QueueEntryIterator#advance}} and
> {{org.apache.qpid.server.queue.QueueEntry#newMessageReference}} ), which
> could result in unexpected message references left behind. Potentially, the
> persistent message can be left un-deleted after removal of queue entry.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-482) update to proton-j 0.33.3
[ https://issues.apache.org/jira/browse/QPIDJMS-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16981502#comment-16981502 ] Robbie Gemmell commented on QPIDJMS-482: Note: when updating, also action the test change TODOs from QPIDJMS-481. > update to proton-j 0.33.3 > - > > Key: QPIDJMS-482 > URL: https://issues.apache.org/jira/browse/QPIDJMS-482 > Project: Qpid JMS > Issue Type: Task > Components: qpid-jms-client >Reporter: Robbie Gemmell >Priority: Major > Fix For: 0.48.0 > > > update to proton-j 0.33.3 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-481) improve handling of transport/decode errors and better signal failure cause
[ https://issues.apache.org/jira/browse/QPIDJMS-481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16981501#comment-16981501 ] ASF subversion and git services commented on QPIDJMS-481: - Commit c4ab27d2b92c8d9156e138bd7486a9088165ddcb in qpid-jms's branch refs/heads/master from Robbie Gemmell [ https://gitbox.apache.org/repos/asf?p=qpid-jms.git;h=c4ab27d ] QPIDJMS-481: improve handling of transport/decode errors and better signal failure cause > improve handling of transport/decode errors and better signal failure cause > --- > > Key: QPIDJMS-481 > URL: https://issues.apache.org/jira/browse/QPIDJMS-481 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.47.0 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 0.48.0 > > > When a decode exception happens in the proton transport while decoding > incoming frames, proton closes the transport and emits a close frame > (typically causing a response close to be sent) but the client itself is > essentially unaware until later. An example of this was seen while > identifying DISPATCH-1488 recently. > If the response close (or other data) arrives, the client tries to process > the proton transport with the data, which throws due to its input already > being closed. This triggers the connection failure handling and provokes a > stack trace in the logs, but neither gives much helpful info about the cause > of the overall situation, simply referring to the resulting 'tail closed' > situation. > PROTON-2142 fixes the proton-j handling to ensure the close frame emitted > actually contains a decode error giving some indication of what actually lead > to the closure. The client should also look to handle this situation better > itself though, using notice of the transport decode error occurring to > trigger its failure handling directly with the error detail noted as the > failure cause, and skip further input processing. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPIDJMS-481) improve handling of transport/decode errors and better signal failure cause
[ https://issues.apache.org/jira/browse/QPIDJMS-481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved QPIDJMS-481. Resolution: Fixed > improve handling of transport/decode errors and better signal failure cause > --- > > Key: QPIDJMS-481 > URL: https://issues.apache.org/jira/browse/QPIDJMS-481 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.47.0 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 0.48.0 > > > When a decode exception happens in the proton transport while decoding > incoming frames, proton closes the transport and emits a close frame > (typically causing a response close to be sent) but the client itself is > essentially unaware until later. An example of this was seen while > identifying DISPATCH-1488 recently. > If the response close (or other data) arrives, the client tries to process > the proton transport with the data, which throws due to its input already > being closed. This triggers the connection failure handling and provokes a > stack trace in the logs, but neither gives much helpful info about the cause > of the overall situation, simply referring to the resulting 'tail closed' > situation. > PROTON-2142 fixes the proton-j handling to ensure the close frame emitted > actually contains a decode error giving some indication of what actually lead > to the closure. The client should also look to handle this situation better > itself though, using notice of the transport decode error occurring to > trigger its failure handling directly with the error detail noted as the > failure cause, and skip further input processing. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPIDJMS-482) update to proton-j 0.33.3
Robbie Gemmell created QPIDJMS-482: -- Summary: update to proton-j 0.33.3 Key: QPIDJMS-482 URL: https://issues.apache.org/jira/browse/QPIDJMS-482 Project: Qpid JMS Issue Type: Task Components: qpid-jms-client Reporter: Robbie Gemmell Fix For: 0.48.0 update to proton-j 0.33.3 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPIDJMS-481) improve handling of transport/decode errors and better signal failure cause
Robbie Gemmell created QPIDJMS-481: -- Summary: improve handling of transport/decode errors and better signal failure cause Key: QPIDJMS-481 URL: https://issues.apache.org/jira/browse/QPIDJMS-481 Project: Qpid JMS Issue Type: Bug Components: qpid-jms-client Affects Versions: 0.47.0 Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 0.48.0 When a decode exception happens in the proton transport while decoding incoming frames, proton closes the transport and emits a close frame (typically causing a response close to be sent) but the client itself is essentially unaware until later. An example of this was seen while identifying DISPATCH-1488 recently. If the response close (or other data) arrives, the client tries to process the proton transport with the data, which throws due to its input already being closed. This triggers the connection failure handling and provokes a stack trace in the logs, but neither gives much helpful info about the cause of the overall situation, simply referring to the resulting 'tail closed' situation. PROTON-2142 fixes the proton-j handling to ensure the close frame emitted actually contains a decode error giving some indication of what actually lead to the closure. The client should also look to handle this situation better itself though, using notice of the transport decode error occurring to trigger its failure handling directly with the error detail noted as the failure cause, and skip further input processing. -- This message was sent by Atlassian Jira (v8.3.4#803005) - 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 edited a comment on issue #42: Qpid-8374: [Broker-J][ACL] Allow case insensitive mapping of group members to groups in existing GroupProvider
alex-rufous edited a comment on issue #42: Qpid-8374: [Broker-J][ACL] Allow
case insensitive mapping of group members to groups in existing GroupProvider
URL: https://github.com/apache/qpid-broker-j/pull/42#issuecomment-558125705
Hi Stanislav,
I looked through the suggested changes and got the following review comments
and questions:
* FileBasedGroupProviderImpl does not extend AbstractGroupProvider. It seems
for consistency sake it has to follow the rest of group provider
implementations and extend AbstractGroupProvider
* The default value for caseSensitive attribute in GroupProvider interface
can be derived from context variable. I would like to add the context variable
in GroupProvider interface as illustrated in a code snippet below:
`String GROUP_PROVIDER_CASE_SENSITIVE = "qpid.groupProvider.caseSensitive";
@SuppressWarnings("unused")
@ManagedContextDefault(name = GROUP_PROVIDER_CASE_SENSITIVE)
String DEFAULT_GROUP_PROVIDER_CASE_SENSITIVE = "true";
@ManagedAttribute(defaultValue = "${" + GROUP_PROVIDER_CASE_SENSITIVE + "}",
description = "Allow to choose CaseSensitive or CaseInsensitive search of
Groups and Users")
boolean isCaseSensitive();
`
* In FileGroupDatabaseCaseInsensitiveTest the test fields are initialized in
static block. Is there any reason not to use junit @BeforeClass and @AfterClass
methods to perform the initialization and clean up of test suite resources?
* The same applies to FileGroupDatabaseTest; it seems initialization can be
done @BeforeClass method and clean up in @AfterClass method.
* It seems that case sensitive search seems is not applicable to
CloudFoundryDashboardManagementGroupProvider. I am actually thinking that
adding caseSensitive attribute there would be a mistake, as it will have no
meaning there. I think we need an intermediate interface for GroupProvider
supporting case insensitive group mapping. I think that it would be better to
move attribute caseSensitive into special GroupProvider interface and extend
FileBasedGroupProvider and GroupProviderImpl from that interface. Whilst
CloudFoundryDashboardManagementGroupProvider can continue to extend original
GroupProvider interface. That means that we need to change the UI as attribute
"caseSensitive" will no longer be a common attribute. What do you think?
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 issue #42: Qpid-8374: [Broker-J][ACL] Allow case insensitive mapping of group members to groups in existing GroupProvider
alex-rufous commented on issue #42: Qpid-8374: [Broker-J][ACL] Allow case
insensitive mapping of group members to groups in existing GroupProvider
URL: https://github.com/apache/qpid-broker-j/pull/42#issuecomment-558125705
Hi Stanislav,
I looked through the suggested changes and got the following review comments
and questions:
* FileBasedGroupProviderImpl does not extend AbstractGroupProvider. It seems
for consistency sake it has to follow the rest of group provider
implementations and extend AbstractGroupProvider
* The default value for caseSensitive attribute in GroupProvider interface
can be derived from context variable. I would like to add the context variable
in GroupProvider interface as illustrated in a code snippet below:
`
String GROUP_PROVIDER_CASE_SENSITIVE = "qpid.groupProvider.caseSensitive";
@SuppressWarnings("unused")
@ManagedContextDefault(name = GROUP_PROVIDER_CASE_SENSITIVE)
String DEFAULT_GROUP_PROVIDER_CASE_SENSITIVE = "true";
@ManagedAttribute(defaultValue = "${" + GROUP_PROVIDER_CASE_SENSITIVE + "}",
description = "Allow to choose CaseSensitive or CaseInsensitive search of
Groups and Users")
boolean isCaseSensitive();
`
* In FileGroupDatabaseCaseInsensitiveTest the test fields are initialized in
static block. Is there any reason not to use junit @BeforeClass and @AfterClass
methods to perform the initialization and clean up of test suite resources?
* The same applies to FileGroupDatabaseTest; it seems initialization can be
done @BeforeClass method and clean up in @AfterClass method.
* It seems that case sensitive search seems is not applicable to
CloudFoundryDashboardManagementGroupProvider. I am actually thinking that
adding caseSensitive attribute there would be a mistake, as it will have no
meaning there. I think we need an intermediate interface for GroupProvider
supporting case insensitive group mapping. I think that it would be better to
move attribute caseSensitive into special GroupProvider interface and extend
FileBasedGroupProvider and GroupProviderImpl from that interface. Whilst
CloudFoundryDashboardManagementGroupProvider can continue to extend original
GroupProvider interface. That means that we need to change the UI as attribute
"caseSensitive" will no longer be a common attribute. What do you think?
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] (PROTON-2141) [cpp] Make unit tests pass on ipv4 machine
[ https://issues.apache.org/jira/browse/PROTON-2141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16981463#comment-16981463 ] Ali Hadi commented on PROTON-2141: -- [~astitcher] in our host config we have : 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 Both solutions below resolve the problem : - Removing the second line with the ::1 - Replacing "localhost" by "127.0.0.1" in the tests makes them pass. > [cpp] Make unit tests pass on ipv4 machine > -- > > Key: PROTON-2141 > URL: https://issues.apache.org/jira/browse/PROTON-2141 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: proton-c-0.29.0 >Reporter: Rabih Mourad >Priority: Major > Attachments: errors.log > > > There are test failure when running unit tests on an ipv4 machine. > So we propose the pull request below. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
