[jira] [Commented] (DISPATCH-993) Test system_tests_topology_disposition fails intermittently
[
https://issues.apache.org/jira/browse/DISPATCH-993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16548402#comment-16548402
]
Chuck Rolke commented on DISPATCH-993:
--
At issue with this test is the time it takes to propagate the mobile address
for closest/01.
Before the address is fully propagated the test messages go into router A but
then get released by router D when downstream router D does not have a
destination yet.
If enough messages get "released" then the "received" counter never gets to
magic 13, the kill_the_connector never gets sent, and the test fails due to no
confirmed_kill.
In one failing test run the client sends the first message at time 35.7752 S.
{{A.log:2018-07-18 15:30:35.775211 -0400 SERVER (trace) [11]:0 <- @transfer(20)
receive from client}}
{{A.log:2018-07-18 15:30:35.776412 -0400 SERVER (trace) [5]:0 -> @transfer(20)
forward to D}}
But the address propagations are continuing for several seconds:
{{B.log:729 :2018-07-18 15:30:34.597984 -0400 ROUTER_MA (trace) SENT: MAU(id=B
pv=1 area=0 mobile_seq=1 add=[u'M0closest/01'] del=[])}}
{{C.log:712 :2018-07-18 15:30:34.599170 -0400 ROUTER_MA (trace) RCVD: MAU(id=B
pv=1 area=0 mobile_seq=1 add=[u'M0closest/01'] del=[])}}
{{A.log:1097:2018-07-18 15:30:34.600240 -0400 ROUTER_MA (trace) RCVD: MAU(id=B
pv=1 area=0 mobile_seq=1 add=[u'M0closest/01'] del=[])}}
{{}}{{B.log:1138:2018-07-18 15:30:38.656152 -0400 ROUTER_MA (trace) SENT:
MAU(id=B pv=1 area=0 mobile_seq=1 add=[u'M0closest/01'] del=[])}}
{{}}{{D.log:1567:2018-07-18 15:30:38.657701 -0400 ROUTER_MA (trace) RCVD:
MAU(id=B pv=1 area=0 mobile_seq=1 add=[u'M0closest/01'] del=[])}}
Until time 38.6477 S router D releases any messages sent to it from router A.
The four second propagation delay at time 38.656 S may be an issue.
As a bonus the test defines this object twice. Apparently the second definition
wins:
{{def on_released ( self, event ) :}}
> Test system_tests_topology_disposition fails intermittently
> ---
>
> Key: DISPATCH-993
> URL: https://issues.apache.org/jira/browse/DISPATCH-993
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Tests
>Affects Versions: 1.1.0
>Reporter: Chuck Rolke
>Assignee: Chuck Rolke
>Priority: Major
>
> Test: DeleteSpuriousConnector
> This test might run 20 times OK but it fails (for me!) eventually on today's
> master branch.
> For some reason instead of the messages being _received_ they are being
> _released_. This messes up the on_message n_received count so that it never
> reaches the magic 13 and therefore it never sends out the kill connector
> command.
> Here is a debug trace. Not that after 'receiving' 30 messages the n_received
> count only gets to 12.
> {quote}39:
> ==
> 39: FAIL: test_01_delete_spurious_connector
> (system_tests_topology_disposition.TopologyDispositionTests)
> 39: --
> 39: Traceback (most recent call last):
> 39: File
> "/home/chug/git/qpid-dispatch/tests/system_tests_topology_disposition.py",
> line 379, in test_01_delete_spurious_connector
> 39: self.assertEqual ( None, test.error )
> 39: AssertionError: None != 'No confirmed kill on connector.'
> 39:
> 39: --
> 39: Ran 2 tests in 10.250s
> 39:
> 39: FAILED (failures=1, skipped=1)
> 39: 1525876585.928072 on_link_opened
> 39: 1525876585.928256 on_link_opened
> 39: 1525876585.928463 on_link_opened
> 39: 1525876585.928535 on_link_opened
> 39: 1525876587.925026 timeout sender
> 39: 1525876587.925467 sent: 1
> 39: 1525876587.925707 sent: 2
> 39: 1525876587.925920 sent: 3
> 39: 1525876587.930813 on_released 1
> 39: 1525876587.932044 on_released 2
> 39: 1525876587.932671 on_released 3
> 39: 1525876588.424884 timeout sender
> 39: 1525876588.425253 sent: 4
> 39: 1525876588.425495 sent: 5
> 39: 1525876588.425698 sent: 6
> 39: 1525876588.432105 on_released 4
> 39: 1525876588.433035 on_released 5
> 39: 1525876588.433282 on_released 6
> 39: 1525876588.925559 timeout sender
> 39: 1525876588.925939 sent: 7
> 39: 1525876588.926234 sent: 8
> 39: 1525876588.926466 sent: 9
> 39: 1525876588.931285 on_released 7
> 39: 1525876588.931881 on_released 8
> 39: 1525876588.932027 on_released 9
> 39: 1525876589.426222 timeout sender
> 39: 1525876589.426562 sent: 10
> 39: 1525876589.426783 sent: 11
> 39: 1525876589.426976 sent: 12
> 39: 1525876589.432599 on_released 10
> 39: 1525876589.433407 on_released 11
> 39: 1525876589.433601 on_released 12
> 39: 1525876589.927745 timeout sender
> 39: 1525876589.927996 sent: 13
> 39: 1525876589.928149 sent: 14
> 39: 1525876589.928321 sent: 15
> 39: 1525876589.932239 on_released 13
>
[jira] [Assigned] (DISPATCH-993) Test system_tests_topology_disposition fails intermittently
[
https://issues.apache.org/jira/browse/DISPATCH-993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chuck Rolke reassigned DISPATCH-993:
Assignee: Chuck Rolke
> Test system_tests_topology_disposition fails intermittently
> ---
>
> Key: DISPATCH-993
> URL: https://issues.apache.org/jira/browse/DISPATCH-993
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Tests
>Affects Versions: 1.1.0
>Reporter: Chuck Rolke
>Assignee: Chuck Rolke
>Priority: Major
>
> Test: DeleteSpuriousConnector
> This test might run 20 times OK but it fails (for me!) eventually on today's
> master branch.
> For some reason instead of the messages being _received_ they are being
> _released_. This messes up the on_message n_received count so that it never
> reaches the magic 13 and therefore it never sends out the kill connector
> command.
> Here is a debug trace. Not that after 'receiving' 30 messages the n_received
> count only gets to 12.
> {quote}39:
> ==
> 39: FAIL: test_01_delete_spurious_connector
> (system_tests_topology_disposition.TopologyDispositionTests)
> 39: --
> 39: Traceback (most recent call last):
> 39: File
> "/home/chug/git/qpid-dispatch/tests/system_tests_topology_disposition.py",
> line 379, in test_01_delete_spurious_connector
> 39: self.assertEqual ( None, test.error )
> 39: AssertionError: None != 'No confirmed kill on connector.'
> 39:
> 39: --
> 39: Ran 2 tests in 10.250s
> 39:
> 39: FAILED (failures=1, skipped=1)
> 39: 1525876585.928072 on_link_opened
> 39: 1525876585.928256 on_link_opened
> 39: 1525876585.928463 on_link_opened
> 39: 1525876585.928535 on_link_opened
> 39: 1525876587.925026 timeout sender
> 39: 1525876587.925467 sent: 1
> 39: 1525876587.925707 sent: 2
> 39: 1525876587.925920 sent: 3
> 39: 1525876587.930813 on_released 1
> 39: 1525876587.932044 on_released 2
> 39: 1525876587.932671 on_released 3
> 39: 1525876588.424884 timeout sender
> 39: 1525876588.425253 sent: 4
> 39: 1525876588.425495 sent: 5
> 39: 1525876588.425698 sent: 6
> 39: 1525876588.432105 on_released 4
> 39: 1525876588.433035 on_released 5
> 39: 1525876588.433282 on_released 6
> 39: 1525876588.925559 timeout sender
> 39: 1525876588.925939 sent: 7
> 39: 1525876588.926234 sent: 8
> 39: 1525876588.926466 sent: 9
> 39: 1525876588.931285 on_released 7
> 39: 1525876588.931881 on_released 8
> 39: 1525876588.932027 on_released 9
> 39: 1525876589.426222 timeout sender
> 39: 1525876589.426562 sent: 10
> 39: 1525876589.426783 sent: 11
> 39: 1525876589.426976 sent: 12
> 39: 1525876589.432599 on_released 10
> 39: 1525876589.433407 on_released 11
> 39: 1525876589.433601 on_released 12
> 39: 1525876589.927745 timeout sender
> 39: 1525876589.927996 sent: 13
> 39: 1525876589.928149 sent: 14
> 39: 1525876589.928321 sent: 15
> 39: 1525876589.932239 on_released 13
> 39: 1525876589.932775 on_released 14
> 39: 1525876589.932907 on_released 15
> 39: 1525876590.427907 timeout sender
> 39: 1525876590.428106 sent: 16
> 39: 1525876590.428294 sent: 17
> 39: 1525876590.428404 sent: 18
> 39: 1525876590.431869 on_released 16
> 39: 1525876590.432348 on_released 17
> 39: 1525876590.432463 on_released 18
> 39: 1525876590.928454 timeout sender
> 39: 1525876590.928758 sent: 19
> 39: 1525876590.928955 sent: 20
> 39: 1525876590.929130 sent: 21
> 39: 1525876590.935306 received message 18
> 39: 1525876590.935326 n_received == 1
> 39: 1525876590.936363 received message 19
> 39: 1525876590.936381 n_received == 2
> 39: 1525876590.936989 received message 20
> 39: 1525876590.937010 n_received == 3
> 39: 1525876590.938963 on_accepted 1
> 39: 1525876590.940796 on_accepted 2
> 39: 1525876590.941263 on_accepted 3
> 39: 1525876591.429399 timeout sender
> 39: 1525876591.429752 sent: 22
> 39: 1525876591.429980 sent: 23
> 39: 1525876591.430198 sent: 24
> 39: 1525876591.438830 received message 21
> 39: 1525876591.438858 n_received == 4
> 39: 1525876591.439422 received message 22
> 39: 1525876591.439432 n_received == 5
> 39: 1525876591.440099 received message 23
> 39: 1525876591.440111 n_received == 6
> 39: 1525876591.442100 on_accepted 4
> 39: 1525876591.442532 on_accepted 5
> 39: 1525876591.442632 on_accepted 6
> 39: 1525876591.930557 timeout sender
> 39: 1525876591.930793 sent: 25
> 39: 1525876591.930934 sent: 26
> 39: 1525876591.931059 sent: 27
> 39: 1525876591.936629 received message 24
> 39: 1525876591.936649 n_received == 7
> 39: 1525876591.937648 received message 25
> 39: 1525876591.937665 n_received == 8
> 39: 1525876591.938337 received message 26
> 39: 1525876591.938355 n_received == 9
> 39: 1525876591.940128 on_accepted 7
>
[jira] [Commented] (PROTON-1881) C++ code is not built with warning flags
[ https://issues.apache.org/jira/browse/PROTON-1881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16548346#comment-16548346 ] ASF subversion and git services commented on PROTON-1881: - Commit fdb3789b95142a2d64b190bf43c1cc9b4e6ec489 in qpid-proton's branch refs/heads/master from [~astitcher] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=fdb3789 ] PROTON-1881: More C++ warnings that slipped in when flags weren't there > C++ code is not built with warning flags > > > Key: PROTON-1881 > URL: https://issues.apache.org/jira/browse/PROTON-1881 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding, proton-c >Affects Versions: proton-c-0.23.0, proton-c-0.24.0 >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher >Priority: Major > Fix For: proton-c-0.25.0 > > > The source tree reorganisation moved setting the CXX_WARNING_FLAG variable > into the c compilation tree of proton. These variables are inherited > downwards in the build tree. > Since the C++ code is not in the directory heirarchy below the setting of the > variables the warning flags are not set for the C++ builds any more . > So for some number of weeks we have not been getting adequate build warnings > on our C++ code. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1069) memory grows on a long-lived connection when links are opened and closed
[ https://issues.apache.org/jira/browse/DISPATCH-1069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16548322#comment-16548322 ] ASF GitHub Bot commented on DISPATCH-1069: -- GitHub user ganeshmurthy opened a pull request: https://github.com/apache/qpid-dispatch/pull/344 DISPATCH-1069 - Delayed freeing of links and sessions until after the… … the processing of the event batch is complete You can merge this pull request into a Git repository by running: $ git pull https://github.com/ganeshmurthy/qpid-dispatch DISPATCH-1069 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-dispatch/pull/344.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #344 commit f48d981202fbb5d781f2b32125fbe61af1a82fdc Author: Ganesh Murthy Date: 2018-07-18T19:43:39Z DISPATCH-1069 - Delayed freeing of links and sessions until after the the processing of the event batch is complete > memory grows on a long-lived connection when links are opened and closed > > > Key: DISPATCH-1069 > URL: https://issues.apache.org/jira/browse/DISPATCH-1069 > Project: Qpid Dispatch > Issue Type: Bug > Components: Container >Affects Versions: 1.2.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Major > Fix For: 1.3.0 > > Attachments: link-leak.c, link-leak.py > > > The attached reproducers link-leak.c and link-leak.py open and close links > repeatedly on the same connection. This causes the routers memory use to grow. > Massif shows that the memory is due to pn_link_t and related objects. > PROTON-905 describes an old bug where link information is leaked but > experiments show this is not happening with modern proton. > I suspect the growth is due to dispatch sometimes failing to call > pn_link_free() but investigation is still ongoing. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch pull request #344: DISPATCH-1069 - Delayed freeing of links an...
GitHub user ganeshmurthy opened a pull request: https://github.com/apache/qpid-dispatch/pull/344 DISPATCH-1069 - Delayed freeing of links and sessions until after the⦠⦠the processing of the event batch is complete You can merge this pull request into a Git repository by running: $ git pull https://github.com/ganeshmurthy/qpid-dispatch DISPATCH-1069 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-dispatch/pull/344.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #344 commit f48d981202fbb5d781f2b32125fbe61af1a82fdc Author: Ganesh Murthy Date: 2018-07-18T19:43:39Z DISPATCH-1069 - Delayed freeing of links and sessions until after the the processing of the event batch is complete --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-1069) memory grows on a long-lived connection when links are opened and closed
[ https://issues.apache.org/jira/browse/DISPATCH-1069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy updated DISPATCH-1069: Fix Version/s: 1.3.0 > memory grows on a long-lived connection when links are opened and closed > > > Key: DISPATCH-1069 > URL: https://issues.apache.org/jira/browse/DISPATCH-1069 > Project: Qpid Dispatch > Issue Type: Bug > Components: Container >Affects Versions: 1.2.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Major > Fix For: 1.3.0 > > Attachments: link-leak.c, link-leak.py > > > The attached reproducers link-leak.c and link-leak.py open and close links > repeatedly on the same connection. This causes the routers memory use to grow. > Massif shows that the memory is due to pn_link_t and related objects. > PROTON-905 describes an old bug where link information is leaked but > experiments show this is not happening with modern proton. > I suspect the growth is due to dispatch sometimes failing to call > pn_link_free() but investigation is still ongoing. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1080) system_tests_ssl failing consistently on Travis
[
https://issues.apache.org/jira/browse/DISPATCH-1080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16548308#comment-16548308
]
ASF subversion and git services commented on DISPATCH-1080:
---
Commit 0f092ac43d7fef5030401b4451e41ddca75e in qpid-dispatch's branch
refs/heads/master from [~ganeshmurthy]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=0f092ac ]
DISPATCH-1080 - Additional fix to get the router config correct
> system_tests_ssl failing consistently on Travis
> ---
>
> Key: DISPATCH-1080
> URL: https://issues.apache.org/jira/browse/DISPATCH-1080
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Tests
>Affects Versions: 1.2.0
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>Priority: Major
> Fix For: 1.3.0
>
>
> system_tests_ssl is consistently failing on Travis
> {noformat}
> Test command: /usr/bin/python
> "/home/travis/build/apache/qpid-dispatch/build/tests/run.py" "-x" "unit2"
> "-v" "system_tests_ssl"
> 47: Test timeout computed to be: 1500
> 47: test_ssl_invalid (system_tests_ssl.RouterTestSslClient) ... ok
> 47: test_ssl_sasl_client_invalid (system_tests_ssl.RouterTestSslClient) ... ok
> 47: test_ssl_sasl_client_valid (system_tests_ssl.RouterTestSslClient) ... FAIL
> 47: test_tls11_only (system_tests_ssl.RouterTestSslClient) ... FAIL
> 47: test_tls11_tls12_only (system_tests_ssl.RouterTestSslClient) ... FAIL
> 47: test_tls12_only (system_tests_ssl.RouterTestSslClient) ... FAIL
> 47: test_tls1_only (system_tests_ssl.RouterTestSslClient) ... FAIL
> 47: test_tls1_tls11_only (system_tests_ssl.RouterTestSslClient) ... FAIL
> 47: test_tls1_tls12_only (system_tests_ssl.RouterTestSslClient) ... FAIL
> 47: test_tls_all (system_tests_ssl.RouterTestSslClient) ... FAIL
> 47: test_connected_tls_sasl_routers
> (system_tests_ssl.RouterTestSslInterRouter) ... ERROR
> 47:
> 47: ==
> 47: ERROR: test_connected_tls_sasl_routers
> (system_tests_ssl.RouterTestSslInterRouter)
> 47: --
> 47: Traceback (most recent call last):
> 47: File
> "/home/travis/build/apache/qpid-dispatch/tests/system_tests_ssl.py", line
> 584, in test_connected_tls_sasl_routers
> 47: router_nodes = self.get_router_nodes()
> 47: File
> "/home/travis/build/apache/qpid-dispatch/tests/system_tests_ssl.py", line
> 572, in get_router_nodes
> 47: node = Node.connect(url)
> 47: File
> "/home/travis/build/apache/qpid-dispatch/python/qpid_dispatch/management/client.py",
> line 111, in connect
> 47: return Node(Node.connection(url, router, timeout, ssl_domain, sasl))
> 47: File
> "/home/travis/build/apache/qpid-dispatch/python/qpid_dispatch/management/client.py",
> line 106, in connection
> 47: password=str(sasl.password) if sasl else None)
> 47: File
> "/home/travis/build/apache/qpid-dispatch/qpid-proton/python/proton/utils.py",
> line 237, in __init__
> 47: msg="Opening connection")
> 47: File
> "/home/travis/build/apache/qpid-dispatch/qpid-proton/python/proton/utils.py",
> line 314, in wait
> 47: "Connection %s disconnected: %s" % (self.url, self.disconnected))
> 47: ConnectionException: Connection amqp://0.0.0.0:0/$management
> disconnected: Condition('proton:io', 'recv: Connection refused')
> 47:
> 47: ==
> 47: FAIL: test_ssl_sasl_client_valid (system_tests_ssl.RouterTestSslClient)
> 47: --
> 47: Traceback (most recent call last):
> 47: File
> "/home/travis/build/apache/qpid-dispatch/tests/system_tests_ssl.py", line
> 374, in test_ssl_sasl_client_valid
> 47: self.assertTrue(self.is_ssl_sasl_client_accepted(self.PORT_TLS_SASL,
> "TLSv1"))
> 47: AssertionError: False is not true
> 47:
> 47: ==
> 47: FAIL: test_tls11_only (system_tests_ssl.RouterTestSslClient)
> 47: --
> 47: Traceback (most recent call last):
> 47: File
> "/home/travis/build/apache/qpid-dispatch/tests/system_tests_ssl.py", line
> 325, in test_tls11_only
> 47: self.get_allowed_protocols(self.PORT_TLS11))
> 47: AssertionError: Lists differ: [False, True, False] != [False, False,
> False]
> 47:
> 47: First differing element 1:
> 47: True
> 47: False
> 47:
> 47: - [False, True, False]
> 47: ? ^^^
> 47:
> 47: + [False, False, False]
> 47: ?
> 47:
> 47:
> 47: ==
> 47: FAIL: test_tls11_tls12_only (system_tests_ssl.RouterTestSslClient)
> 47:
[jira] [Resolved] (QPIDJMS-405) update to proton-j 0.28.0
[ https://issues.apache.org/jira/browse/QPIDJMS-405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved QPIDJMS-405. Resolution: Fixed > update to proton-j 0.28.0 > - > > Key: QPIDJMS-405 > URL: https://issues.apache.org/jira/browse/QPIDJMS-405 > Project: Qpid JMS > Issue Type: Task > Components: qpid-jms-client >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Minor > Fix For: 0.35.0 > > > update to proton-j 0.28.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-405) update to proton-j 0.28.0
[ https://issues.apache.org/jira/browse/QPIDJMS-405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16548101#comment-16548101 ] ASF subversion and git services commented on QPIDJMS-405: - Commit 965f989d3f47a54f84dcfe43c864ce911a9db088 in qpid-jms's branch refs/heads/master from [~gemmellr] [ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=965f989 ] QPIDJMS-405: update to proton-j 0.28.0 > update to proton-j 0.28.0 > - > > Key: QPIDJMS-405 > URL: https://issues.apache.org/jira/browse/QPIDJMS-405 > Project: Qpid JMS > Issue Type: Task > Components: qpid-jms-client >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Minor > Fix For: 0.35.0 > > > update to proton-j 0.28.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-1083) File console/stand-alone/package-lock.json constantly regenerated
[ https://issues.apache.org/jira/browse/DISPATCH-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Allen resolved DISPATCH-1083. Resolution: Fixed Fix Version/s: 1.3.0 Caused by DISPATCH-1070. That Jira added a new dependency to package.json but neglected to check-in the new package-lock.json file that resulted. > File console/stand-alone/package-lock.json constantly regenerated > - > > Key: DISPATCH-1083 > URL: https://issues.apache.org/jira/browse/DISPATCH-1083 > Project: Qpid Dispatch > Issue Type: Bug > Components: Console >Affects Versions: 1.2.0 >Reporter: Chuck Rolke >Assignee: Ernest Allen >Priority: Major > Fix For: 1.3.0 > > > After a build / self-test run the package-lock.json file is changed. There > was no specific action taken to change it directly. This behavior is new this > week. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPIDJMS-405) update to proton-j 0.28.0
Robbie Gemmell created QPIDJMS-405: -- Summary: update to proton-j 0.28.0 Key: QPIDJMS-405 URL: https://issues.apache.org/jira/browse/QPIDJMS-405 Project: Qpid JMS Issue Type: Task Components: qpid-jms-client Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 0.35.0 update to proton-j 0.28.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-398) Update testing dependencies and bundle plugin to latest
[ https://issues.apache.org/jira/browse/QPIDJMS-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16548096#comment-16548096 ] ASF subversion and git services commented on QPIDJMS-398: - Commit 8eb19c156a0979c18bfe5134b3d70ab10cf74454 in qpid-jms's branch refs/heads/master from [~tabish121] [ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=8eb19c1 ] QPIDJMS-398 Update Mockito to latest point release > Update testing dependencies and bundle plugin to latest > --- > > Key: QPIDJMS-398 > URL: https://issues.apache.org/jira/browse/QPIDJMS-398 > Project: Qpid JMS > Issue Type: Task > Components: qpid-jms-client >Affects Versions: 0.34.0 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Major > Fix For: 0.35.0 > > > Update the test dependencies for Mockito and Jetty to latest and switch to > latest bundle plugin. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1083) File console/stand-alone/package-lock.json constantly regenerated
[ https://issues.apache.org/jira/browse/DISPATCH-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16548095#comment-16548095 ] ASF subversion and git services commented on DISPATCH-1083: --- Commit ce81ad8fe406dc92323d3ef406baa46754c1d857 in qpid-dispatch's branch refs/heads/master from [~eallen] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=ce81ad8 ] DISPATCH-1083 New package-lock.json for angular-patternfly for console > File console/stand-alone/package-lock.json constantly regenerated > - > > Key: DISPATCH-1083 > URL: https://issues.apache.org/jira/browse/DISPATCH-1083 > Project: Qpid Dispatch > Issue Type: Bug > Components: Console >Affects Versions: 1.2.0 >Reporter: Chuck Rolke >Assignee: Ernest Allen >Priority: Major > > After a build / self-test run the package-lock.json file is changed. There > was no specific action taken to change it directly. This behavior is new this > week. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPIDJMS-401) Minor code cleanups and performance improvements
[ https://issues.apache.org/jira/browse/QPIDJMS-401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved QPIDJMS-401. -- Resolution: Fixed > Minor code cleanups and performance improvements > > > Key: QPIDJMS-401 > URL: https://issues.apache.org/jira/browse/QPIDJMS-401 > Project: Qpid JMS > Issue Type: Improvement > Components: qpid-jms-client >Affects Versions: 0.34.0 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Major > Fix For: 0.35.0 > > > Many recent changes leave some older code in need of some housekeeping, clean > up some code based on recent changes and review. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (QPIDJMS-402) Massive performance degradation in 0.34.0
[ https://issues.apache.org/jira/browse/QPIDJMS-402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish closed QPIDJMS-402. Resolution: Fixed Fix Version/s: 0.35.0 > Massive performance degradation in 0.34.0 > - > > Key: QPIDJMS-402 > URL: https://issues.apache.org/jira/browse/QPIDJMS-402 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.34.0 > Environment: Windows 7x64 + Oracle JDK 8u161x64 > Windows 7x64 + Open JDK 8u171x64 > CloudFoundry (Ubuntu Trusty) + Open JDK 8u172x64 >Reporter: Johan Stenberg >Priority: Critical > Fix For: 0.35.0 > > Attachments: QpidJms402_PerfTest.java, > image-2018-07-13-16-39-19-707.png, qpidjms402.zip > > > This is a followup issue for > [http://qpid.2158936.n2.nabble.com/qpid-jms-Severe-performance-issue-after-upgrading-from-0-33-0-to-0-34-0-td7678052.html] > I am attaching a simple test case that shows the issue. When I use qpid jms > 0.33 I get 2000msg/s send + receive on my local machine. When I switch to > 0.34 the message rate drops to 20msg/s. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-404) Performance regressions on some platforms using new ProviderFuture implementation
[ https://issues.apache.org/jira/browse/QPIDJMS-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16548062#comment-16548062 ] ASF subversion and git services commented on QPIDJMS-404: - Commit 264a9a9b6c5d8d8c11a995b7b02289b2938d77ba in qpid-jms's branch refs/heads/master from [~tabish121] [ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=264a9a9 ] QPIDJMS-404 Add variants of ProviderFuture for perf tuning Adds three variations on ProviderFuture that allow for tuning on platforms that don't benefit from the spin / wait pattern used in the current implementation and default to using a variant that does not park on windows to avoid unpredictably long parks that result in performance decreases due to missing the event completion. > Performance regressions on some platforms using new ProviderFuture > implementation > - > > Key: QPIDJMS-404 > URL: https://issues.apache.org/jira/browse/QPIDJMS-404 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.34.0 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Major > Fix For: 0.35.0 > > > The new ProviderFuture implementation introduced in 0.34.0 relies on a > stepped spin / wait algorithm that backs off the spin using yeilds and short > parks which will eventually end in a wait / notify pattern if the event > hasn't completed. On some platforms the length of a park can be > substantially longer than requested which leads to missing the event > completion for long periods of time reducing performance. > Introduce a set of ProviderFuture implementations that can be used on > platforms where the stepped spin / wait variant causes regressions in > performance. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPIDJMS-404) Performance regressions on some platforms using new ProviderFuture implementation
Timothy Bish created QPIDJMS-404: Summary: Performance regressions on some platforms using new ProviderFuture implementation Key: QPIDJMS-404 URL: https://issues.apache.org/jira/browse/QPIDJMS-404 Project: Qpid JMS Issue Type: Bug Components: qpid-jms-client Affects Versions: 0.34.0 Reporter: Timothy Bish Assignee: Timothy Bish Fix For: 0.35.0 The new ProviderFuture implementation introduced in 0.34.0 relies on a stepped spin / wait algorithm that backs off the spin using yeilds and short parks which will eventually end in a wait / notify pattern if the event hasn't completed. On some platforms the length of a park can be substantially longer than requested which leads to missing the event completion for long periods of time reducing performance. Introduce a set of ProviderFuture implementations that can be used on platforms where the stepped spin / wait variant causes regressions in performance. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-403) Failover handler doesn't release pending tasks that could complete on connection drop
[ https://issues.apache.org/jira/browse/QPIDJMS-403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16548033#comment-16548033 ] ASF subversion and git services commented on QPIDJMS-403: - Commit 8b200671ed7a449b5b565b5926b7b8850f010007 in qpid-jms's branch refs/heads/master from [~gemmellr] [ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=8b20067 ] QPIDJMS-403: adjust test to account for changes, avoid spurious failure in CI > Failover handler doesn't release pending tasks that could complete on > connection drop > - > > Key: QPIDJMS-403 > URL: https://issues.apache.org/jira/browse/QPIDJMS-403 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.34.0 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Minor > Fix For: 0.35.0 > > > Some tasks that are in flight in the Failover handler could complete when a > connection drops instead of waiting for a reconnect to occur but are not > having their off line behavior handler triggered when the connection drop is > detected and are forced to wait until a reconnect before they complete. One > such example is a session close which when in flight and the connection drops > we can allow the request to complete because there nothing more to do for > that request on reconnect. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1083) File console/stand-alone/package-lock.json constantly regenerated
Chuck Rolke created DISPATCH-1083: - Summary: File console/stand-alone/package-lock.json constantly regenerated Key: DISPATCH-1083 URL: https://issues.apache.org/jira/browse/DISPATCH-1083 Project: Qpid Dispatch Issue Type: Bug Components: Console Affects Versions: 1.2.0 Reporter: Chuck Rolke Assignee: Ernest Allen After a build / self-test run the package-lock.json file is changed. There was no specific action taken to change it directly. This behavior is new this week. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1082) Log messages can not be correlated to a specific connection
[
https://issues.apache.org/jira/browse/DISPATCH-1082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16547992#comment-16547992
]
ASF subversion and git services commented on DISPATCH-1082:
---
Commit f6a68fd14db5a47f2ef6ea3ae7057309b41dc83d in qpid-dispatch's branch
refs/heads/master from [~chug]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=f6a68fd ]
DISPATCH-1082: Add connection_id to log messages for disambiguation
Eleven log messages are prefixed with '[N]'.
Server on_accept log message deletes the from field as it is unknown
at this stage in the connection life cycle and always blank.
> Log messages can not be correlated to a specific connection
> ---
>
> Key: DISPATCH-1082
> URL: https://issues.apache.org/jira/browse/DISPATCH-1082
> Project: Qpid Dispatch
> Issue Type: Improvement
>Affects Versions: 1.2.0
>Reporter: Chuck Rolke
>Priority: Major
>
> Several components use 'connection name' which is not unique.
> * Policy logs indicating allow/deny at protocol level
> * Connection setup
> A simple improvement is to include the connection_id integer at the beginning
> of the messages. The format should be the same as the prefix added by the
> server to proton transport tracer messages.
> Log files could be processed simply with
> {{ grep '\[4]' router.log}}
> to reveal connection setup, authenticated username associations, policy
> decisions, and AMQP frame traffic.
> This addition would also make it easier to scrape the log file for low-level
> connection life cycle details with no ambiguity.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1082) Log messages can not be correlated to a specific connection
Chuck Rolke created DISPATCH-1082:
-
Summary: Log messages can not be correlated to a specific
connection
Key: DISPATCH-1082
URL: https://issues.apache.org/jira/browse/DISPATCH-1082
Project: Qpid Dispatch
Issue Type: Improvement
Affects Versions: 1.2.0
Reporter: Chuck Rolke
Several components use 'connection name' which is not unique.
* Policy logs indicating allow/deny at protocol level
* Connection setup
A simple improvement is to include the connection_id integer at the beginning
of the messages. The format should be the same as the prefix added by the
server to proton transport tracer messages.
Log files could be processed simply with
{{ grep '\[4]' router.log}}
to reveal connection setup, authenticated username associations, policy
decisions, and AMQP frame traffic.
This addition would also make it easier to scrape the log file for low-level
connection life cycle details with no ambiguity.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (DISPATCH-1009) _qd_policy_link_user_name_subst can return an unterminated string
[
https://issues.apache.org/jira/browse/DISPATCH-1009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chuck Rolke closed DISPATCH-1009.
-
Resolution: Won't Fix
The offending code was completely replaced by work related to DISPATCH-1011
> _qd_policy_link_user_name_subst can return an unterminated string
> -
>
> Key: DISPATCH-1009
> URL: https://issues.apache.org/jira/browse/DISPATCH-1009
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Policy Engine
>Affects Versions: 1.0.1
>Reporter: Alan Conway
>Assignee: Chuck Rolke
>Priority: Major
>
> On fedora 28 the gcc 8.1.1 compiler gives this warning-as-error:
> /home/aconway/dispatch/src/policy.c: In function
> '_qd_policy_link_user_name_subst':
> /home/aconway/dispatch/src/policy.c:541:9: error: 'strncpy' output may be
> truncated copying between 0 and 8 bytes from a string of length 7
> [-Werror=stringop-truncation]
> strncpy(obuf, duser, copysize);
> ^~
> cc1: all warnings being treated as errors
>
> The error is correct: the function is using strncpy to copy a string into a
> space that may be too small for it, resulting in an un-terminated string.
> I fixed some similar issues already but I'm confused by what's going on here:
> it looks like we are searching for the uname parameter and replacing it with
> "${user}" which seems backwards.
> The function would be simpler and clearer if it used snprintf rather than
> successive strncpy, i.e.
> n = snprintf(obuf, osize, "%s%s%s", leading, duser, trailing);
> but the problem of properly handling the error if the resulting string is too
> big for obuf remains.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[ANNOUNCE] Apache Qpid Proton-J 0.28.0 released
The Apache Qpid (http://qpid.apache.org) community is pleased to announce the immediate availability of Apache Qpid Proton-J 0.28.0. Apache Qpid Proton-J is a messaging library for the Advanced Message Queuing Protocol 1.0 (AMQP 1.0, ISO/IEC 19464, http://www.amqp.org). It can be used in a wide range of messaging applications including brokers, clients, routers, bridges, proxies, and more. The release is available now from our website: http://qpid.apache.org/download.html Binaries are also available via Maven Central: http://qpid.apache.org/maven.html Release notes can be found at: http://qpid.apache.org/releases/qpid-proton-j-0.28.0/release-notes.html Thanks to all involved, Robbie - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[ANNOUNCE] Apache Qpid Proton-J 0.27.2 released
The Apache Qpid (http://qpid.apache.org) community is pleased to announce the immediate availability of Apache Qpid Proton-J 0.27.2. Apache Qpid Proton-J is a messaging library for the Advanced Message Queuing Protocol 1.0 (AMQP 1.0, ISO/IEC 19464, http://www.amqp.org). It can be used in a wide range of messaging applications including brokers, clients, routers, bridges, proxies, and more. The release is available now from our website and via Maven Central: http://qpid.apache.org/releases/qpid-proton-j-0.27.2/index.html Release notes can be found at: http://qpid.apache.org/releases/qpid-proton-j-0.27.2/release-notes.html Thanks to all involved, Robbie - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1081) Messages to multicast addresses are being released when no receivers attached
Alexander Rafferty created DISPATCH-1081:
Summary: Messages to multicast addresses are being released when
no receivers attached
Key: DISPATCH-1081
URL: https://issues.apache.org/jira/browse/DISPATCH-1081
Project: Qpid Dispatch
Issue Type: Bug
Affects Versions: 1.2.0
Reporter: Alexander Rafferty
When sending messages to a multicast address to which no consumers are
attached, the router sends back a disposition of RELEASED. The expected
behaviour is that all messages will be immediately settled by the ingress
router with a disposition of ACCEPTED as per section 2.4.1 of the Dispatch
router book:
{quote}Multicast delivery is not reliable. If a producer sends an unsettled
delivery, the ingress router shall settle the delivery with ACCEPTED
disposition regardless of whether the message was delivered to any consumers.
{quote}
Is this a bug, or is this the expected behaviour? If this is the expected
behaviour, can the router be configured to always accept messages to multicast
addresses even where no consumers are actively listening?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
