Re: [VOTE] Release Qpid Dispatch Router 1.14.0 (RC1)
- Original Message - > From: "Robbie Gemmell" > To: "dev" > Cc: us...@qpid.apache.org > Sent: Friday, September 11, 2020 9:41:16 AM > Subject: Re: [VOTE] Release Qpid Dispatch Router 1.14.0 (RC1) > > On Wed, 9 Sep 2020 at 22:01, Ganesh Murthy wrote: > > > > Hello All, > > Please cast your vote on this thread to release RC1 as the > > official Qpid Dispatch Router version 1.14.0. > > > > RC1 of Qpid Dispatch Router version 1.14.0 can be found here: > > > > https://dist.apache.org/repos/dist/dev/qpid/dispatch/1.14.0-rc1/ > > It is tagged as 1.14.0-rc1. > > > > The JIRAs assigned are here - > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315321&version=12348204 > > > > Thanks > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org > > For additional commands, e-mail: dev-h...@qpid.apache.org > > > > +1 > > I checked things out as follows: > - Verified the signature and checksum files. > - Checked for LICENCE and NOTICE files present in the archive. > - Ran mvn apache-rat:check to verify the source licence headers. > - Built against Proton 0.32.0 and ran the tests. > - Ran the Qpid JMS 0.54.0 HelloWorld example against installed router. > > Robbie > > (Can we stop cross-posting the Dispatch votes to both lists, just use > users like the rest do) > > - > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org > > +1 * checked checksum * built with qpid-proton git branch master @ 9a43b8b78 * passed self tests * pass brief ad hoc test network tests - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: [VOTE] Release Qpid Dispatch Router 1.12.0 (RC1)
+1 * Ran system self tests (using current qpid-proton master) * Ran ad-hoc 12-router tests * Ran connect-disconnect exercisers * Ran policy and oversize message tests - Original Message - > From: "Ganesh Murthy" > To: dev@qpid.apache.org, us...@qpid.apache.org > Sent: Monday, April 27, 2020 5:03:30 PM > Subject: Re: [VOTE] Release Qpid Dispatch Router 1.12.0 (RC1) > > On Mon, Apr 27, 2020 at 3:22 PM Ganesh Murthy wrote: > > > > Hello All, > > > > Please cast your vote on this thread to release RC1 as the > > official Qpid Dispatch Router version 1.12.0. > > > > RC1 of Qpid Dispatch Router version 1.12.0 can be found here: > > > > https://dist.apache.org/repos/dist/dev/qpid/dispatch/1.12.0-rc1/ > > > > The following improvements, and bug fixes are introduced in 1.12.0: > > > I missed to list a major new feature - > > > New Feature - > DISPATCH-975 - Policy has no provision for limiting user message size > > My apologies. > Thanks. > > > Improvements - > > DISPATCH-1479 - multicast/routing behaviour doc improvements > > DISPATCH-1608 - Display workerThreads in the output of qdstat -g > > and qdmanage query --type=router > > DISPATCH-1611 - In debug mode, provide time and backtrace of > > leaked pool allocations > > DISPATCH-1615 - Backtrace of leaked allocations does not show object > > address > > DISPATCH-1616 - Scraper could export facts for creating sequence > > diagrams > > DISPATCH-1617 - Prevent router startup if edge or standalone > > routers have 'edge' role listeners > > > > Bug fixes - > > DISPATCH-1581 - Policy counters are int and should be uint64 > > DISPATCH-1593 - Fix legend in console's topology view > > DISPATCH-1606 - Qpid dispatch console keeps trying to open > > connections when using empty username and password against a listener > > configured with SASL plain > > DISPATCH-1607 - [test] one_router > > test_48_connection_uptime_last_dlv ConnectionUptimeLastDlvTest > > intermittent fail > > DISPATCH-1609 - Policy denial logs omit the 'C' in the connection ID > > DISPATCH-1610 - qd_pn_free_link_session_t objects leaking when > > connections are socket closed > > DISPATCH-1612 - Automatically fill in the address and port that > > was used to serve the console into the console's connect form > > DISPATCH-1613 - Remove error log that is issued when > > > QDR_N_PRIORITY router links attach > > DISPATCH-1614 - Edge router crash when interior closes edge uplink > > connection > > DISPATCH-1618 - Server shutdown leaks policy setting objects > > DISPATCH-1622 - Router crash when trying to create connector via > > qdmanage > > DISPATCH-1626 - On released callback invoked twice for same delivery > > tag > > DISPATCH-1627 - Occasional leak of qd_iterator_buffer during > > system_tests_link_route_credit test > > DISPATCH-1628 - Crash after enforcing oversize message connection close > > DISPATCH-1630 - Coverity issues on master branch > > > > Thanks. > > - > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: [VOTE] Release Qpid Dispatch Router 1.11.0 (RC1)
+1 * Verified checksum * Ran tests on Fedora 29 python2 and python3 systems: ** pass self test ** ad hock 12-router formerly-problematic network: OK ** verified console and multiple consoles: OK ** 100s of thousands of connections during multicast tests: OK - Original Message - > From: "Ganesh Murthy" > To: dev@qpid.apache.org, us...@qpid.apache.org > Sent: Monday, March 16, 2020 12:30:22 PM > Subject: [VOTE] Release Qpid Dispatch Router 1.11.0 (RC1) > > Hello All, > > Please cast your vote on this thread to release RC1 as the > official Qpid Dispatch Router version 1.11.0. > > RC1 of Qpid Dispatch Router version 1.11.0 can be found here: > > https://dist.apache.org/repos/dist/dev/qpid/dispatch/1.11.0-rc1/ > > The following features, improvements, and bug fixes are introduced in 1.11.0: > > Features - > DISPATCH-1282 - Support for building on macOS > DISPATCH-1569 - Add total memory usage to router management entity > > Improvements - > DISPATCH-1415 - qdstat does not show process memory usage > DISPATCH-1506 - system_tests_multicast fails with ASAN leak > DISPATCH-1518 - Add ability to turn on router trace logging for a > specific connection > DISPATCH-1532 - Reimplement mobile-sync as a core module > DISPATCH-1536 - Tests needs common utility for printing timestamped > messages > DISPATCH-1537 - [tools] Scraper could help make transfer output more > legible > DISPATCH-1538 - [tools] Scraper transfer and link nicknames not > created in time order > DISPATCH-1544 - Coverity false positive use-after-free error > DISPATCH-1546 - Augment the existing tests in > system_tests_delivery_counts to use large messages > DISPATCH-1548 - Modularize Dispatch Router Doc > DISPATCH-1553 - Router ID text name is not restricted > DISPATCH-1555 - Update documentation for console UI changes > DISPATCH-1556 - Doc should specify correct ownership/permission on > sasldb file > DISPATCH-1558 - Add a new logging module called PROTOCOL > DISPATCH-1561 - Write system test to test writing different log > modules to different output files > DISPATCH-1562 - Make attribute names provided to Prometheus more > router specific > DISPATCH-1567 - Compilation errors on s390x platform > DISPATCH-1576 - Disable Q2/Q3 on router control links > DISPATCH-1577 - Create multiple inter-router sessions for > different types of traffic > DISPATCH-1580 - Add a --edge-router option to qdstat and qdmanage > to enable directly connecting to edge routers > DISPATCH-1582 - Prepare Routing Protocol for Backward Compatibility > DISPATCH-1583 - Scraper top level Disposition could show settled > t/f and state > DISPATCH-1592 - Show dropped routers in grey instead of displaying > popup error message > DISPATCH-1599 - Add edge routers to the console's Overview->Routers table > DISPATCH-1524 - Remove stale hawtio console plugin > > Bug fixes - > DISPATCH-1384 - Fix tests in Travis CI on macOS > DISPATCH-1459 - Python3: exception thrown when processing MAUs > DISPATCH-1508 - Leak of qd_listener_t's on shutdown > DISPATCH-1509 - Leak of core agent timer > DISPATCH-1510 - Leak of qdr_error_t in system_tests_link_route_credit > DISPATCH-1511 - Leak reported by coverity static analysis > DISPATCH-1513 - system_tests_http failing with libwebsockets 3.2 > on Fedora 31 > DISPATCH-1526 - Local temp address credit growing unpectedly, edge > and interior > DISPATCH-1527 - Mobile address lookup server grants insufficient credit > DISPATCH-1528 - CMake script to find tox tool is broken > DISPATCH-1529 - New python-checker warnings fail the unit tests > DISPATCH-1534 - python unit tests does not validate qdstat or qdmanage > DISPATCH-1540 - multiframe presettled messages not included in > presettled count on downstream router > DISPATCH-1541 - released and modified counters can get incremented > for presettled deliveries > DISPATCH-1549 - Leak of qdr_terminus_t in > system_tests_one_router::test_34_reject_coordinator > DISPATCH-1550 - [tools] Scraper fails to parse ROUTER_LS costs > DISPATCH-1551 - Mobile addresses can get out of sync > (DISPATCH-1532 regression) > DISPATCH-1552 - Qpid Dispatch Dockerfile for CentOS 7 is broken > DISPATCH-1557 - Router crash due to pn_link double free > DISPATCH-1559 - Delivery_abort test fails by streaming multiple > messages into one > DISPATCH-1560 - Compilation error on Fedora 32 (fedora rawhide) > DISPATCH-1564 - Two system tests fail on Fedora 32(fedora:rawhide) > DISPATCH-1566 - safe_snpritf is not safe. > DISPATCH-1575 - Core thread logs to ROUTER module instead of > ROUTER_CORE module > DISPATCH-1579 - Traffic hangs when multiple large messages are > sent using different priorities > DISPATCH-1584 - Scraper fails to parse transfers when the > delivery-id is absent > DISPATCH-1587 - Speci
Re: [VOTE] Release Qpid Dispatch Router 1.10.0 (RC3)
+1 to RC3 * Pass checksum check * Built/ran self test on Fedora 29 * Tested with python 2.7.15 and 3.7.4 * Ran numerous multirouter torture tests on local network - Original Message - > From: "Ganesh Murthy" > To: us...@qpid.apache.org, dev@qpid.apache.org > Sent: Monday, December 16, 2019 5:39:30 PM > Subject: [VOTE] Release Qpid Dispatch Router 1.10.0 (RC3) > > Hello All, > > Please cast your vote on this thread to release RC3 as the > official Qpid Dispatch Router version 1.10.0. > > RC3 of Qpid Dispatch Router version 1.10.0 can be found here: > > https://dist.apache.org/repos/dist/dev/qpid/dispatch/1.10.0-rc3/ > > The following features, improvements, and bug fixes are introduced in 1.10.0: > > Features - > DISPATCH-1441 - optparse python library deprecated, migrate to argparse > DISPATCH-1442 - Add a metadata field to the router management entity > DISPATCH-1463 - Detect deliveries that are stuck in the router for > a long time > DISPATCH-1467 - Add build option to enable Address Sanitizer build (ASAN) > > Improvements - > DISPATCH-1186 - qdstat to include csv output format > DISPATCH-1358 - Port console to patternfly 4 / React > DISPATCH-1369 - Update console dependencies to avoid npm security > warnings > DISPATCH-1399 - Allow arrows on console's topology page to be disabled > DISPATCH-1409 - Update qdstat -l output to include the current credit > DISPATCH-1411 - Add timestamp and router name to header of qdstat output > DISPATCH-1412 - Policy C code performance issue: reload python > module for each call > DISPATCH-1416 - Policy log could include denial counts on connection > close > DISPATCH-1419 - Add status to connector mgmt schema > DISPATCH-1427 - Allow policy to define user (group) specific > connection limits > DISPATCH-1434 - Add new attribute saslPasswordFile to the connector > entity > DISPATCH-1438 - Have ctest parse the routers debug dump files for > memory pool leaks > DISPATCH-1439 - Expose create time/last transfer time through the > Connection management entity > DISPATCH-1440 - Deprecate the passwordFile field in sslProfile and > consolidate all password scenarios to use the password field > DISPATCH-1445 - Update saslPassword attribute in connector entity > to use openssl style prefixes > DISPATCH-1446 - system_tests_qdmanage failing on test_get_log > DISPATCH-1450 - Add build option to enable thread sanitizer build > DISPATCH-1454 - system_tests_one_router failing due to changes in > qpid-proton > DISPATCH-1455 - Two system tests failing after optparse to > argparse migration > DISPATCH-1465 - system_tests_policy.test_verify_z_connection_stats fails > DISPATCH-1466 - flake8 errors in system_test.py > DISPATCH-1471 - [test] When string comparison asserts fail the > strings are not printed > DISPATCH-1480 - Address Sanitizer leak in system_tests_multi_phase > DISPATCH-1491 - bottleneck adding or removing addresses in mobile > address engine > DISPATCH-1500 - inefficiencies in handling large MAU messages > DISPATCH-1507 - Don't collapse small number of edge routers and > clients into single circle > DISPATCH-1516 - Trace log the peer delivery id and link id when > linking and unlinking peers > > Bug fixes - > DISPATCH-1172 - Link routes and auto links activated on wrong > connections if many route-container conns exist > DISPATCH-1258 - Crash executing http test > DISPATCH-1377 - system_tests_topology_disposition failing on > machine with python3 only > DISPATCH-1418 - The default forwarding treatment is not overridden > by the treatment in the address configuration > DISPATCH-1421 - Attaching link to unavailable address sets source > address to null in attach reply > DISPATCH-1423 - Multicast sender with no receiver has first 250 > messages released > DISPATCH-1426 - Repetitive receiver fail over causes memory leak > DISPATCH-1428 - route connection not indexed by 'connection' field > of connector > DISPATCH-1431 - system_tests_one_router_failing on > test_19_semantics_multicast > DISPATCH-1433 - system_tests_delivery_abort failing due to > receiver connecting late > DISPATCH-1443 - Unable to run ctest on Centos 8 > DISPATCH-1453 - Adding "defaultDistribution: unavailable" > overrides the regular handling of transaction coordinator link refusal > DISPATCH-1460 - Router control messages for local subscribers hang > in Q2 holdoff > DISPATCH-1461 - Crashed router due to terminus address overflow > DISPATCH-1462 - [policy] Test for IPv6 leaves socket open > DISPATCH-1468 - out-of-bounds array access in qd_entity_refresh_connector > DISPATCH-1473 - [test] test_command fail on python 2.7 > DISPATCH-1474 - Console message path skips one router hop > DISPATCH-1475 - Seg fault in qdr_link_cleanup_CT after 12,400+ > connections > DISPATCH-1476
Re: [VOTE] Release Qpid Dispatch Router 1.10.0 (RC1)
-1 A segfault has been identified. https://issues.apache.org/jira/browse/DISPATCH-1523 - Original Message - > From: "Ganesh Murthy" > To: us...@qpid.apache.org, dev@qpid.apache.org > Sent: Thursday, December 12, 2019 1:32:39 PM > Subject: [VOTE] Release Qpid Dispatch Router 1.10.0 (RC1) > > Hello All, > > Please cast your vote on this thread to release RC1 as the > official Qpid Dispatch Router version 1.10.0. > > RC1 of Qpid Dispatch Router version 1.10.0 can be found here: > > https://dist.apache.org/repos/dist/dev/qpid/dispatch/1.10.0-rc1/ > > The following features, improvements, and bug fixes are introduced in 1.10.0: > > Features - > DISPATCH-1441 - optparse python library deprecated, migrate to argparse > DISPATCH-1442 - Add a metadata field to the router management entity > DISPATCH-1463 - Detect deliveries that are stuck in the router for > a long time > DISPATCH-1467 - Add build option to enable Address Sanitizer build (ASAN) > > Improvements - > DISPATCH-1186 - qdstat to include csv output format > DISPATCH-1358 - Port console to patternfly 4 / React > DISPATCH-1369 - Update console dependencies to avoid npm security > warnings > DISPATCH-1399 - Allow arrows on console's topology page to be disabled > DISPATCH-1409 - Update qdstat -l output to include the current credit > DISPATCH-1411 - Add timestamp and router name to header of qdstat output > DISPATCH-1412 - Policy C code performance issue: reload python > module for each call > DISPATCH-1416 - Policy log could include denial counts on connection > close > DISPATCH-1419 - Add status to connector mgmt schema > DISPATCH-1427 - Allow policy to define user (group) specific > connection limits > DISPATCH-1434 - Add new attribute saslPasswordFile to the connector > entity > DISPATCH-1438 - Have ctest parse the routers debug dump files for > memory pool leaks > DISPATCH-1439 - Expose create time/last transfer time through the > Connection management entity > DISPATCH-1440 - Deprecate the passwordFile field in sslProfile and > consolidate all password scenarios to use the password field > DISPATCH-1445 - Update saslPassword attribute in connector entity > to use openssl style prefixes > DISPATCH-1446 - system_tests_qdmanage failing on test_get_log > DISPATCH-1450 - Add build option to enable thread sanitizer build > DISPATCH-1454 - system_tests_one_router failing due to changes in > qpid-proton > DISPATCH-1455 - Two system tests failing after optparse to > argparse migration > DISPATCH-1465 - system_tests_policy.test_verify_z_connection_stats fails > DISPATCH-1466 - flake8 errors in system_test.py > DISPATCH-1471 - [test] When string comparison asserts fail the > strings are not printed > DISPATCH-1480 - Address Sanitizer leak in system_tests_multi_phase > DISPATCH-1491 - bottleneck adding or removing addresses in mobile > address engine > DISPATCH-1500 - inefficiencies in handling large MAU messages > DISPATCH-1507 - Don't collapse small number of edge routers and > clients into single circle > DISPATCH-1516 - Trace log the peer delivery id and link id when > linking and unlinking peers > > Bug fixes - > DISPATCH-1172 - Link routes and auto links activated on wrong > connections if many route-container conns exist > DISPATCH-1258 - Crash executing http test > DISPATCH-1377 - system_tests_topology_disposition failing on > machine with python3 only > DISPATCH-1418 - The default forwarding treatment is not overridden > by the treatment in the address configuration > DISPATCH-1421 - Attaching link to unavailable address sets source > address to null in attach reply > DISPATCH-1423 - Multicast sender with no receiver has first 250 > messages released > DISPATCH-1426 - Repetitive receiver fail over causes memory leak > DISPATCH-1428 - route connection not indexed by 'connection' field > of connector > DISPATCH-1431 - system_tests_one_router_failing on > test_19_semantics_multicast > DISPATCH-1433 - system_tests_delivery_abort failing due to > receiver connecting late > DISPATCH-1443 - Unable to run ctest on Centos 8 > DISPATCH-1453 - Adding "defaultDistribution: unavailable" > overrides the regular handling of transaction coordinator link refusal > DISPATCH-1460 - Router control messages for local subscribers hang > in Q2 holdoff > DISPATCH-1461 - Crashed router due to terminus address overflow > DISPATCH-1462 - [policy] Test for IPv6 leaves socket open > DISPATCH-1468 - out-of-bounds array access in qd_entity_refresh_connector > DISPATCH-1473 - [test] test_command fail on python 2.7 > DISPATCH-1474 - Console message path skips one router hop > DISPATCH-1475 - Seg fault in qdr_link_cleanup_CT after 12,400+ > connections > DISPATCH-1476 - [tools] New proton logging breaks Scraper > DISPATCH-1477 - Crash ro
[jira] [Created] (PROTON-2104) [c++ client] Error specifying url with IPv6 literal host address
Chuck Rolke created PROTON-2104: --- Summary: [c++ client] Error specifying url with IPv6 literal host address Key: PROTON-2104 URL: https://issues.apache.org/jira/browse/PROTON-2104 Project: Qpid Proton Issue Type: Bug Components: cpp-binding Affects Versions: proton-c-0.29.0 Reporter: Chuck Rolke C++ examples simple_send and simple_recv accept IPv6 loopback address [::1] but have issues with other apparently legal addresses. These work on my system: {{ ping6 fe80::c662:ab36:1ef1:1596 ping6 fe80::c662:ab36:1ef1:1596%wlp4s0 ping6 fe80::::c662:ab36:1ef1:1596 }} Wrapping the host part in square brackets and sending that address to simple_send fails: {{ ./simple_send -a [fe80::c662:ab36:1ef1:1596]:5672/abc proton:io: Invalid argument - on connect fe80::c662:ab36:1ef1:1596:5672 }} All three variants of the address that work with ping6 fail with the same error on the simple_send command line. -- 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] [Closed] (DISPATCH-255) Policy miscounts quick socket open/close against total connection limit
[ https://issues.apache.org/jira/browse/DISPATCH-255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke closed DISPATCH-255. Resolution: Fixed Fixed in 0.6 > Policy miscounts quick socket open/close against total connection limit > --- > > Key: DISPATCH-255 > URL: https://issues.apache.org/jira/browse/DISPATCH-255 > Project: Qpid Dispatch > Issue Type: Bug > Reporter: Chuck Rolke > Assignee: Chuck Rolke >Priority: Major > Fix For: Backlog > > > Self test system_tests_policy is failing. > In the test the tester.router is created with > {noformat} > cls.router = cls.tester.qdrouterd('conn-limit-router', config, wait=True) > {noformat} > For the Wait=true the test code repeated opens a socket to the configured > listener. > When the socket connects then the router is declared up and ready. > Internally though the policy code has counted the socket open as an incoming > listener connection. This failure comes when the socket closes and the > connection is not 'uncounted'. -- 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-1423) Multicast sender with no receiver has first 250 messages released
[ https://issues.apache.org/jira/browse/DISPATCH-1423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke updated DISPATCH-1423: -- Attachment: INTB-250-released-1.8.0.html > Multicast sender with no receiver has first 250 messages released > - > > Key: DISPATCH-1423 > URL: https://issues.apache.org/jira/browse/DISPATCH-1423 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 1.8.0 > Reporter: Chuck Rolke >Priority: Major > Attachments: INTB-250-released-1.8.0.html, INTB.conf > > > When a sender starts and there's no receiver already attached then the first > 250 messages the sender sends get released. After that the router waits for > the a receiver to attach before issuing more credit to the sender. The proton > c++ simple_send and simple receive clients expose this problem. > 1. Start router with attached config file > 2. Start sender > simple_send -a 127.0.0.1:5672/multicast/q1 -m 500 > 3. Start receiver >simple_recv -a 127.0.0.1:5672/multicast/q1 -m 500 > The sender competes with 'all messages confirmed'. > The receiver is waiting for the second 250 messages. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: [VOTE] Release Qpid Dispatch Router 1.9.0 (RC2)
+1 * Passes checksum verify * Build and pass self tests * Run local test environment stress test OK. Note: observed issue described in DISPATCH-1423. That issue is also present in 1.8.0 and is not a regression - Original Message - > From: "Ganesh Murthy" > To: us...@qpid.apache.org, dev@qpid.apache.org > Sent: Monday, September 16, 2019 2:17:05 PM > Subject: [VOTE] Release Qpid Dispatch Router 1.9.0 (RC2) > > Hello All, > > Please cast your vote on this thread to release RC2 as the > official Qpid Dispatch Router version 1.9.0. > > RC2 of Qpid Dispatch Router version 1.9.0 can be found here: > > https://dist.apache.org/repos/dist/dev/qpid/dispatch/1.9.0-rc2/ > > The following improvements, and bug fixes are introduced in 1.9.0: > > Improvements - > DISPATCH-480 - Default tests timeout is too short for some machines > DISPATCH-1266 - Improve router's handling of unsettled multicast > deliveries > DISPATCH-1338 - Improvements to edge router documentation > DISPATCH-1345 - Reduce the number of QDR_LINK_FLOW events by > coalescing credit grants > DISPATCH-1346 - Create documentation for priority delivery > DISPATCH-1347 - Update documentation for Dispatch Router console > DISPATCH-1350 - Update logging/monitoring documentation > DISPATCH-1353 - Document how to configure access policy control on > router-initiated connections > DISPATCH-1354 - Interrouter annotation processing uses slow methods > DISPATCH-1370 - Move the schema, connect, and entities tabs to the > right in the console > DISPATCH-1372 - alloc_pool intrusive linked list can be replaced > by a linked stack > DISPATCH-1374 - Add qdstat options --all-routers and all-entities > which display statistics of all routers and displays all entities > DISPATCH-1376 - Make it easier to change the product name in the console > DISPATCH-1379 - Message receive performance improvements > DISPATCH-1381 - Create documentation for configuring fallback > destinations > DISPATCH-1382 - Document ability to force-close a connection from > the web console > DISPATCH-1385 - qd_message_list_t is dead code > DISPATCH-1388 - Authorization doc fails to describe vhost > abstraction clearly > DISPATCH-1396 - Doc how to start the router > > Bugs - > DISPATCH-1359 - Set ctest timeout to 300 seconds. > DISPATCH-1361 - system_tests_fallback_dest hanging in some cases > DISPATCH-1362 - Shutdown crash when trying to clean up fallback addresses > DISPATCH-1365 - Table of links with delayed deliveries is showing > all endpoint links > DISPATCH-1378 - missing lock of connection's links_with_work list > DISPATCH-1380 - qdrouterd leaves dangling qd_link_t pointer > DISPATCH-1383 - system_tests_policy is timing out > DISPATCH-1387 - Coverity issues on master branch > DISPATCH-1391 - Proton link reference not cleared on router link > objects during session close > DISPATCH-1394 - qd_check_message() incorrectly validates partially > received messages > DISPATCH-1398 - "Expression with no effect" warning for console web > DISPATCH-1404 - message annotation parsing incorrectly uses > ->remainder for current buffer capacity > DISPATCH-1406 - Inter-router link stall on receive client failover > DISPATCH-1407 - Memory leak on link policy denial > DISPATCH-1408 - system_tests_distribution failing when running > under valgrind > DISPATCH-1410 - attach of auto-links not logged > DISPATCH-1413 - system_tests_two_routers.py failing intermittently on > Travis > DISPATCH-1417 - Crash when connection_wake ctx points to freed memory > > Thanks. > > - > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-1417) Crash when connection_wake ctx points to freed memory
[ https://issues.apache.org/jira/browse/DISPATCH-1417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke updated DISPATCH-1417: -- Attachment: (was: INTB.conf) > Crash when connection_wake ctx points to freed memory > - > > Key: DISPATCH-1417 > URL: https://issues.apache.org/jira/browse/DISPATCH-1417 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 1.8.0 > Reporter: Chuck Rolke >Assignee: Ganesh Murthy >Priority: Major > Fix For: 1.9.0 > > > Test clients are streaming unsettled multicast messages to and from an edge > router. Another client repeats the cycle "connect, receive one message from > the stream, disconnect". Soon the edge router core dumps with: > {{(gdb) bt > #0 get_pconnection (c=0x) at > /home/chug/git/qpid-proton/c/src/proactor/epoll.c:578 > #1 0x7fc8c0582a1c in pn_connection_wake (c=0x) at > /home/chug/git/qpid-proton/c/src/proactor/epoll.c:1439 > #2 0x7fc8c0668472 in connection_wake (ctx=0x1a43658) at > /home/chug/Downloads/qpid-dispatch-1.9.0/src/server.c:505 > #3 0x7fc8c066b2af in qd_server_activate (ctx=0x1a43658) at > /home/chug/Downloads/qpid-dispatch-1.9.0/src/server.c:1304 > #4 0x7fc8c064f3dd in qdr_activate_connections_CT (core=0x19c8ce0) at > /home/chug/Downloads/qpid-dispatch-1.9.0/src/router_core/router_core_thread.c:65 > #5 0x7fc8c064fa1d in router_core_thread (arg=0x19c8ce0) at > /home/chug/Downloads/qpid-dispatch-1.9.0/src/router_core/router_core_thread.c:171 > #6 0x7fc8c056258e in start_thread () from /usr/lib64/libpthread.so.0 > #7 0x7fc8c0201713 in clone () from /usr/lib64/libc.so.6 > (gdb) info threads > Id Target Id Frame > * 1 Thread 0x7fc8b1e44700 (LWP 21706) get_pconnection (c=0x) > at /home/chug/git/qpid-proton/c/src/proactor/epoll.c:578 > 2 Thread 0x7fc8bf8ff240 (LWP 21696) 0x7fc8c0201a47 in epoll_wait () from > /usr/lib64/libc.so.6 > 3 Thread 0x7fc8b0e42700 (LWP 21708) 0x7fc8c0201a47 in epoll_wait () from > /usr/lib64/libc.so.6 > 4 Thread 0x7fc8abfff700 (LWP 21709) 0x7fc8c0201a47 in epoll_wait () from > /usr/lib64/libc.so.6 > 5 Thread 0x7fc8b1643700 (LWP 21707) 0x7fc8c01f6481 in poll () from > /usr/lib64/libc.so.6 > 6 Thread 0x7fc8ab7fe700 (LWP 21710) 0x7fc8c0201a47 in epoll_wait () from > /usr/lib64/libc.so.6}} -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-1423) Multicast sender with no receiver has first 250 messages released
[ https://issues.apache.org/jira/browse/DISPATCH-1423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke updated DISPATCH-1423: -- Attachment: INTB.conf > Multicast sender with no receiver has first 250 messages released > - > > Key: DISPATCH-1423 > URL: https://issues.apache.org/jira/browse/DISPATCH-1423 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 1.8.0 > Reporter: Chuck Rolke >Priority: Major > Attachments: INTB.conf > > > When a sender starts and there's no receiver already attached then the first > 250 messages the sender sends get released. After that the router waits for > the a receiver to attach before issuing more credit to the sender. The proton > c++ simple_send and simple receive clients expose this problem. > 1. Start router with attached config file > 2. Start sender > simple_send -a 127.0.0.1:5672/multicast/q1 -m 500 > 3. Start receiver >simple_recv -a 127.0.0.1:5672/multicast/q1 -m 500 > The sender competes with 'all messages confirmed'. > The receiver is waiting for the second 250 messages. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-1417) Crash when connection_wake ctx points to freed memory
[ https://issues.apache.org/jira/browse/DISPATCH-1417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke updated DISPATCH-1417: -- Attachment: INTB.conf > Crash when connection_wake ctx points to freed memory > - > > Key: DISPATCH-1417 > URL: https://issues.apache.org/jira/browse/DISPATCH-1417 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 1.8.0 > Reporter: Chuck Rolke >Assignee: Ganesh Murthy >Priority: Major > Fix For: 1.9.0 > > Attachments: INTB.conf > > > Test clients are streaming unsettled multicast messages to and from an edge > router. Another client repeats the cycle "connect, receive one message from > the stream, disconnect". Soon the edge router core dumps with: > {{(gdb) bt > #0 get_pconnection (c=0x) at > /home/chug/git/qpid-proton/c/src/proactor/epoll.c:578 > #1 0x7fc8c0582a1c in pn_connection_wake (c=0x) at > /home/chug/git/qpid-proton/c/src/proactor/epoll.c:1439 > #2 0x7fc8c0668472 in connection_wake (ctx=0x1a43658) at > /home/chug/Downloads/qpid-dispatch-1.9.0/src/server.c:505 > #3 0x7fc8c066b2af in qd_server_activate (ctx=0x1a43658) at > /home/chug/Downloads/qpid-dispatch-1.9.0/src/server.c:1304 > #4 0x7fc8c064f3dd in qdr_activate_connections_CT (core=0x19c8ce0) at > /home/chug/Downloads/qpid-dispatch-1.9.0/src/router_core/router_core_thread.c:65 > #5 0x7fc8c064fa1d in router_core_thread (arg=0x19c8ce0) at > /home/chug/Downloads/qpid-dispatch-1.9.0/src/router_core/router_core_thread.c:171 > #6 0x7fc8c056258e in start_thread () from /usr/lib64/libpthread.so.0 > #7 0x7fc8c0201713 in clone () from /usr/lib64/libc.so.6 > (gdb) info threads > Id Target Id Frame > * 1 Thread 0x7fc8b1e44700 (LWP 21706) get_pconnection (c=0x) > at /home/chug/git/qpid-proton/c/src/proactor/epoll.c:578 > 2 Thread 0x7fc8bf8ff240 (LWP 21696) 0x7fc8c0201a47 in epoll_wait () from > /usr/lib64/libc.so.6 > 3 Thread 0x7fc8b0e42700 (LWP 21708) 0x7fc8c0201a47 in epoll_wait () from > /usr/lib64/libc.so.6 > 4 Thread 0x7fc8abfff700 (LWP 21709) 0x7fc8c0201a47 in epoll_wait () from > /usr/lib64/libc.so.6 > 5 Thread 0x7fc8b1643700 (LWP 21707) 0x7fc8c01f6481 in poll () from > /usr/lib64/libc.so.6 > 6 Thread 0x7fc8ab7fe700 (LWP 21710) 0x7fc8c0201a47 in epoll_wait () from > /usr/lib64/libc.so.6}} -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1423) Multicast sender with no receiver has first 250 messages released
Chuck Rolke created DISPATCH-1423: - Summary: Multicast sender with no receiver has first 250 messages released Key: DISPATCH-1423 URL: https://issues.apache.org/jira/browse/DISPATCH-1423 Project: Qpid Dispatch Issue Type: Bug Components: Routing Engine Affects Versions: 1.8.0 Reporter: Chuck Rolke When a sender starts and there's no receiver already attached then the first 250 messages the sender sends get released. After that the router waits for the a receiver to attach before issuing more credit to the sender. The proton c++ simple_send and simple receive clients expose this problem. 1. Start router with attached config file 2. Start sender simple_send -a 127.0.0.1:5672/multicast/q1 -m 500 3. Start receiver simple_recv -a 127.0.0.1:5672/multicast/q1 -m 500 The sender competes with 'all messages confirmed'. The receiver is waiting for the second 250 messages. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1417) Crash when connection_wake ctx points to freed memory
[ https://issues.apache.org/jira/browse/DISPATCH-1417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16928758#comment-16928758 ] Chuck Rolke commented on DISPATCH-1417: --- I withdraw the earlier statement about the regression since 1.8.0. Heavier testing got the same error with the 1.8.0 release code. > Crash when connection_wake ctx points to freed memory > - > > Key: DISPATCH-1417 > URL: https://issues.apache.org/jira/browse/DISPATCH-1417 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 1.8.0 >Reporter: Chuck Rolke >Assignee: Ganesh Murthy >Priority: Major > Fix For: 1.9.0 > > > Test clients are streaming unsettled multicast messages to and from an edge > router. Another client repeats the cycle "connect, receive one message from > the stream, disconnect". Soon the edge router core dumps with: > {{(gdb) bt > #0 get_pconnection (c=0x) at > /home/chug/git/qpid-proton/c/src/proactor/epoll.c:578 > #1 0x7fc8c0582a1c in pn_connection_wake (c=0x) at > /home/chug/git/qpid-proton/c/src/proactor/epoll.c:1439 > #2 0x7fc8c0668472 in connection_wake (ctx=0x1a43658) at > /home/chug/Downloads/qpid-dispatch-1.9.0/src/server.c:505 > #3 0x7fc8c066b2af in qd_server_activate (ctx=0x1a43658) at > /home/chug/Downloads/qpid-dispatch-1.9.0/src/server.c:1304 > #4 0x7fc8c064f3dd in qdr_activate_connections_CT (core=0x19c8ce0) at > /home/chug/Downloads/qpid-dispatch-1.9.0/src/router_core/router_core_thread.c:65 > #5 0x7fc8c064fa1d in router_core_thread (arg=0x19c8ce0) at > /home/chug/Downloads/qpid-dispatch-1.9.0/src/router_core/router_core_thread.c:171 > #6 0x7fc8c056258e in start_thread () from /usr/lib64/libpthread.so.0 > #7 0x7fc8c0201713 in clone () from /usr/lib64/libc.so.6 > (gdb) info threads > Id Target Id Frame > * 1 Thread 0x7fc8b1e44700 (LWP 21706) get_pconnection (c=0x) > at /home/chug/git/qpid-proton/c/src/proactor/epoll.c:578 > 2 Thread 0x7fc8bf8ff240 (LWP 21696) 0x7fc8c0201a47 in epoll_wait () from > /usr/lib64/libc.so.6 > 3 Thread 0x7fc8b0e42700 (LWP 21708) 0x7fc8c0201a47 in epoll_wait () from > /usr/lib64/libc.so.6 > 4 Thread 0x7fc8abfff700 (LWP 21709) 0x7fc8c0201a47 in epoll_wait () from > /usr/lib64/libc.so.6 > 5 Thread 0x7fc8b1643700 (LWP 21707) 0x7fc8c01f6481 in poll () from > /usr/lib64/libc.so.6 > 6 Thread 0x7fc8ab7fe700 (LWP 21710) 0x7fc8c0201a47 in epoll_wait () from > /usr/lib64/libc.so.6}} -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1417) Crash when connection_wake ctx points to freed memory
[ https://issues.apache.org/jira/browse/DISPATCH-1417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16928108#comment-16928108 ] Chuck Rolke commented on DISPATCH-1417: --- This appears to be a regression since 1.8.0. 1.8.0 has no crash. Running the same setup and sender/receiver pattern all the routers stay up for 3,000,000 messages. > Crash when connection_wake ctx points to freed memory > - > > Key: DISPATCH-1417 > URL: https://issues.apache.org/jira/browse/DISPATCH-1417 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 1.8.0 >Reporter: Chuck Rolke >Assignee: Ganesh Murthy >Priority: Major > Fix For: 1.9.0 > > > Test clients are streaming unsettled multicast messages to and from an edge > router. Another client repeats the cycle "connect, receive one message from > the stream, disconnect". Soon the edge router core dumps with: > {{(gdb) bt > #0 get_pconnection (c=0x) at > /home/chug/git/qpid-proton/c/src/proactor/epoll.c:578 > #1 0x7fc8c0582a1c in pn_connection_wake (c=0x) at > /home/chug/git/qpid-proton/c/src/proactor/epoll.c:1439 > #2 0x7fc8c0668472 in connection_wake (ctx=0x1a43658) at > /home/chug/Downloads/qpid-dispatch-1.9.0/src/server.c:505 > #3 0x7fc8c066b2af in qd_server_activate (ctx=0x1a43658) at > /home/chug/Downloads/qpid-dispatch-1.9.0/src/server.c:1304 > #4 0x7fc8c064f3dd in qdr_activate_connections_CT (core=0x19c8ce0) at > /home/chug/Downloads/qpid-dispatch-1.9.0/src/router_core/router_core_thread.c:65 > #5 0x7fc8c064fa1d in router_core_thread (arg=0x19c8ce0) at > /home/chug/Downloads/qpid-dispatch-1.9.0/src/router_core/router_core_thread.c:171 > #6 0x7fc8c056258e in start_thread () from /usr/lib64/libpthread.so.0 > #7 0x7fc8c0201713 in clone () from /usr/lib64/libc.so.6 > (gdb) info threads > Id Target Id Frame > * 1 Thread 0x7fc8b1e44700 (LWP 21706) get_pconnection (c=0x) > at /home/chug/git/qpid-proton/c/src/proactor/epoll.c:578 > 2 Thread 0x7fc8bf8ff240 (LWP 21696) 0x7fc8c0201a47 in epoll_wait () from > /usr/lib64/libc.so.6 > 3 Thread 0x7fc8b0e42700 (LWP 21708) 0x7fc8c0201a47 in epoll_wait () from > /usr/lib64/libc.so.6 > 4 Thread 0x7fc8abfff700 (LWP 21709) 0x7fc8c0201a47 in epoll_wait () from > /usr/lib64/libc.so.6 > 5 Thread 0x7fc8b1643700 (LWP 21707) 0x7fc8c01f6481 in poll () from > /usr/lib64/libc.so.6 > 6 Thread 0x7fc8ab7fe700 (LWP 21710) 0x7fc8c0201a47 in epoll_wait () from > /usr/lib64/libc.so.6}} -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1417) Crash when connection_wake ctx points to freed memory
Chuck Rolke created DISPATCH-1417: - Summary: Crash when connection_wake ctx points to freed memory Key: DISPATCH-1417 URL: https://issues.apache.org/jira/browse/DISPATCH-1417 Project: Qpid Dispatch Issue Type: Bug Components: Router Node Affects Versions: 1.8.0 Reporter: Chuck Rolke Assignee: Ganesh Murthy Fix For: 1.9.0 Test clients are streaming unsettled multicast messages to and from an edge router. Another client repeats the cycle "connect, receive one message from the stream, disconnect". Soon the edge router core dumps with: {{(gdb) bt #0 get_pconnection (c=0x) at /home/chug/git/qpid-proton/c/src/proactor/epoll.c:578 #1 0x7fc8c0582a1c in pn_connection_wake (c=0x) at /home/chug/git/qpid-proton/c/src/proactor/epoll.c:1439 #2 0x7fc8c0668472 in connection_wake (ctx=0x1a43658) at /home/chug/Downloads/qpid-dispatch-1.9.0/src/server.c:505 #3 0x7fc8c066b2af in qd_server_activate (ctx=0x1a43658) at /home/chug/Downloads/qpid-dispatch-1.9.0/src/server.c:1304 #4 0x7fc8c064f3dd in qdr_activate_connections_CT (core=0x19c8ce0) at /home/chug/Downloads/qpid-dispatch-1.9.0/src/router_core/router_core_thread.c:65 #5 0x7fc8c064fa1d in router_core_thread (arg=0x19c8ce0) at /home/chug/Downloads/qpid-dispatch-1.9.0/src/router_core/router_core_thread.c:171 #6 0x7fc8c056258e in start_thread () from /usr/lib64/libpthread.so.0 #7 0x7fc8c0201713 in clone () from /usr/lib64/libc.so.6 (gdb) info threads Id Target Id Frame * 1 Thread 0x7fc8b1e44700 (LWP 21706) get_pconnection (c=0x) at /home/chug/git/qpid-proton/c/src/proactor/epoll.c:578 2 Thread 0x7fc8bf8ff240 (LWP 21696) 0x7fc8c0201a47 in epoll_wait () from /usr/lib64/libc.so.6 3 Thread 0x7fc8b0e42700 (LWP 21708) 0x7fc8c0201a47 in epoll_wait () from /usr/lib64/libc.so.6 4 Thread 0x7fc8abfff700 (LWP 21709) 0x7fc8c0201a47 in epoll_wait () from /usr/lib64/libc.so.6 5 Thread 0x7fc8b1643700 (LWP 21707) 0x7fc8c01f6481 in poll () from /usr/lib64/libc.so.6 6 Thread 0x7fc8ab7fe700 (LWP 21710) 0x7fc8c0201a47 in epoll_wait () from /usr/lib64/libc.so.6}} -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: [VOTE] Release Qpid Dispatch Router 1.9.0 (RC1)
-1 There's a race where lots of connect-receive_one_message-disconnect cycles eventually core dump when the system tries to process a freed connection. - Original Message - > From: "Ganesh Murthy" > To: dev@qpid.apache.org, us...@qpid.apache.org > Sent: Monday, September 9, 2019 5:35:59 PM > Subject: [VOTE] Release Qpid Dispatch Router 1.9.0 (RC1) > > Hello All, > > Please cast your vote on this thread to release RC1 as the > official Qpid Dispatch Router version 1.9.0. > > RC1 of Qpid Dispatch Router version 1.9.0 can be found here: > > https://dist.apache.org/repos/dist/dev/qpid/dispatch/1.9.0-rc1/ > > The following improvements, and bug fixes are introduced in 1.9.0: > > Improvements - > DISPATCH-480 - Default tests timeout is too short for some machines > DISPATCH-1266 - Improve router's handling of unsettled multicast > deliveries > DISPATCH-1338 - Improvements to edge router documentation > DISPATCH-1345 - Reduce the number of QDR_LINK_FLOW events by > coalescing credit grants > DISPATCH-1346 - Create documentation for priority delivery > DISPATCH-1347 - Update documentation for Dispatch Router console > DISPATCH-1350 - Update logging/monitoring documentation > DISPATCH-1353 - Document how to configure access policy control on > router-initiated connections > DISPATCH-1354 - Interrouter annotation processing uses slow methods > DISPATCH-1370 - Move the schema, connect, and entities tabs to the > right in the console > DISPATCH-1372 - alloc_pool intrusive linked list can be replaced > by a linked stack > DISPATCH-1374 - Add qdstat options --all-routers and all-entities > which display statistics of all routers and displays all entities > DISPATCH-1376 - Make it easier to change the product name in the console > DISPATCH-1379 - Message receive performance improvements > DISPATCH-1381 - Create documentation for configuring fallback > destinations > DISPATCH-1382 - Document ability to force-close a connection from > the web console > DISPATCH-1385 - qd_message_list_t is dead code > DISPATCH-1388 - Authorization doc fails to describe vhost > abstraction clearly > DISPATCH-1396 - Doc how to start the router > > Bug fixes - > DISPATCH-1359 - Set ctest timeout to 300 seconds. > DISPATCH-1361 - system_tests_fallback_dest hanging in some cases > DISPATCH-1362 - Shutdown crash when trying to clean up fallback addresses > DISPATCH-1365 - Table of links with delayed deliveries is showing > all endpoint links > DISPATCH-1378 - missing lock of connection's links_with_work list > DISPATCH-1380 - qdrouterd leaves dangling qd_link_t pointer > DISPATCH-1383 - system_tests_policy is timing out > DISPATCH-1387 - Coverity issues on master branch > DISPATCH-1391 - Proton link reference not cleared on router link > objects during session close > DISPATCH-1394 - qd_check_message() incorrectly validates partially > received messages > DISPATCH-1398 - "Expression with no effect" warning for console web > DISPATCH-1404 - message annotation parsing incorrectly uses > ->remainder for current buffer capacity > DISPATCH-1406 - Inter-router link stall on receive client failover > DISPATCH-1407 - Memory leak on link policy denial > DISPATCH-1408 - system_tests_distribution failing when running > under valgrind > DISPATCH-1410 - attach of auto-links not logged > DISPATCH-1413 - system_tests_two_routers.py failing intermittently on > Travis > > > Thanks. > > - > To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org > For additional commands, e-mail: dev-h...@qpid.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1416) Policy log could include denial counts on connection close
Chuck Rolke created DISPATCH-1416: - Summary: Policy log could include denial counts on connection close Key: DISPATCH-1416 URL: https://issues.apache.org/jira/browse/DISPATCH-1416 Project: Qpid Dispatch Issue Type: Improvement Components: Policy Engine Affects Versions: 1.8.0 Reporter: Chuck Rolke Assignee: Chuck Rolke Currently the Policy module logs the number of active sessions, senders, receivers, and nConnections(see below) on a connection when it is closed. This list could be expanded to include the policy statistics block that counts sessions, senders, and receiver denials. nConnections is the current live number of total incoming connections managed by policy and is not directly related to the current connection. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1415) qdstat does not show process memory usage
Chuck Rolke created DISPATCH-1415: - Summary: qdstat does not show process memory usage Key: DISPATCH-1415 URL: https://issues.apache.org/jira/browse/DISPATCH-1415 Project: Qpid Dispatch Issue Type: Improvement Components: Management Agent Affects Versions: 1.8.0 Reporter: Chuck Rolke *qdstat -m* shows managed memory usage but it does not show qdrouterd process memory usage. An improvement would be to display process memory usage somewhere via qdstat. Often a memory leak (DISPATCH-1407) will be in objects not held in managed memory. In these cases memory usage may grow unbounded but not be visible by qdstat. A new line or three could be added to qdstat -g or a new switch could be added to qdstat. Good values to show are the standard columns from top: VIRT, RES, and SHR. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (DISPATCH-1414) Include source/target address in the policy DENY info messages
[ https://issues.apache.org/jira/browse/DISPATCH-1414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke closed DISPATCH-1414. - Assignee: Chuck Rolke Resolution: Not A Bug The requested information is already present. > Include source/target address in the policy DENY info messages > -- > > Key: DISPATCH-1414 > URL: https://issues.apache.org/jira/browse/DISPATCH-1414 > Project: Qpid Dispatch > Issue Type: Improvement >Reporter: Keith Wall > Assignee: Chuck Rolke >Priority: Major > Attachments: DISPATCH-1414.txt > > > The policy DENY info message currently omits the source/target address. This > impedes the diagnosis of policy misconfigurations. Currently the message > looks like this: > {{POLICY (info) [1228]: DENY AMQP Attach sender link '' for user 'u', > rhost '10.128.6.1', vhost 'vv' based on link target name}} -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-1414) Include source/target address in the policy DENY info messages
[ https://issues.apache.org/jira/browse/DISPATCH-1414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke updated DISPATCH-1414: -- Attachment: DISPATCH-1414.txt > Include source/target address in the policy DENY info messages > -- > > Key: DISPATCH-1414 > URL: https://issues.apache.org/jira/browse/DISPATCH-1414 > Project: Qpid Dispatch > Issue Type: Improvement >Reporter: Keith Wall >Priority: Major > Attachments: DISPATCH-1414.txt > > > The policy DENY info message currently omits the source/target address. This > impedes the diagnosis of policy misconfigurations. Currently the message > looks like this: > {{POLICY (info) [1228]: DENY AMQP Attach sender link '' for user 'u', > rhost '10.128.6.1', vhost 'vv' based on link target name}} -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1414) Include source/target address in the policy DENY info messages
[ https://issues.apache.org/jira/browse/DISPATCH-1414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16926013#comment-16926013 ] Chuck Rolke commented on DISPATCH-1414: --- In the log entry the '' field is the name of the requested source or target. Attached find a text file that shows two trace snippets. Each has the proton trace of the attach frame and policy log of the denial. There you can correlate the name requested by the attach and the policy message showing the name when the request was denied. > Include source/target address in the policy DENY info messages > -- > > Key: DISPATCH-1414 > URL: https://issues.apache.org/jira/browse/DISPATCH-1414 > Project: Qpid Dispatch > Issue Type: Improvement >Reporter: Keith Wall >Priority: Major > > The policy DENY info message currently omits the source/target address. This > impedes the diagnosis of policy misconfigurations. Currently the message > looks like this: > {{POLICY (info) [1228]: DENY AMQP Attach sender link '' for user 'u', > rhost '10.128.6.1', vhost 'vv' based on link target name}} -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1412) Policy C code performance issue: reload python module for each call
Chuck Rolke created DISPATCH-1412: - Summary: Policy C code performance issue: reload python module for each call Key: DISPATCH-1412 URL: https://issues.apache.org/jira/browse/DISPATCH-1412 Project: Qpid Dispatch Issue Type: Improvement Components: Policy Engine Affects Versions: 1.8.0 Reporter: Chuck Rolke Assignee: Chuck Rolke The module could be loaded once for the lifetime of the router instance. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-1407) Memory leak on link policy denial
[ https://issues.apache.org/jira/browse/DISPATCH-1407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke resolved DISPATCH-1407. --- Fix Version/s: 1.9.0 Resolution: Fixed Fixed at 0ed5d5 > Memory leak on link policy denial > - > > Key: DISPATCH-1407 > URL: https://issues.apache.org/jira/browse/DISPATCH-1407 > Project: Qpid Dispatch > Issue Type: Bug > Components: Policy Engine >Affects Versions: 1.8.0 > Reporter: Chuck Rolke >Assignee: Chuck Rolke >Priority: Major > Fix For: 1.9.0 > > Attachments: A.conf, default.json > > > A router with a simple policy that denies most addresses starts and uses 10M > bytes of memory. A test client loops 25k times opening a link to a denied > address over a single connection and session. Now the router uses 276 Mbytes. > An example policy is > ``` > [ >["vhost", { > "hostname": "$default", > "allowUnknownUser": true, > "groups" : { >"$default": { > "remoteHosts": "*", > "allowDynamicSource": true, > "allowAnonymousSender": true, > "sources": "$management, examples, q1", > "targets": "$management, examples, q1" >} > } >}] > ] > ``` -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1407) Memory leak on link policy denial
[ https://issues.apache.org/jira/browse/DISPATCH-1407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16925174#comment-16925174 ] Chuck Rolke commented on DISPATCH-1407: --- Router policy also allows controlling clients with a maxSessions limit. This limit is enforced differently and will not produce a memory leak. For sessions the limit is negotiated at the AMQP level. The router has no handlers for denying sessions because it is a protocol violation for the client to exceed that limit. An AmqpDotnetLite client attempting to open 256 sessions when the router limit is 2 will see: ``` Exception Amqp.AmqpException: remote channel 2 is above negotiated channel_max 1. at Amqp.Connection.ThrowIfClosed(String operation) at Amqp.Connection.AddSession(Session session) at Amqp.Session..ctor(Connection connection, Begin begin, OnBegin onBegin) at Amqp.Session..ctor(Connection connection) at Examples.Interop.SessionHammer.Main(String[] args) in /home/chug/Downloads/amq-dotnet-2.5.0-core-sdk/examples/Interop.SessionHammer/Interop.SessionHammer.cs:line 54. ``` > Memory leak on link policy denial > - > > Key: DISPATCH-1407 > URL: https://issues.apache.org/jira/browse/DISPATCH-1407 > Project: Qpid Dispatch > Issue Type: Bug > Components: Policy Engine >Affects Versions: 1.8.0 >Reporter: Chuck Rolke >Assignee: Chuck Rolke >Priority: Major > Attachments: A.conf, default.json > > > A router with a simple policy that denies most addresses starts and uses 10M > bytes of memory. A test client loops 25k times opening a link to a denied > address over a single connection and session. Now the router uses 276 Mbytes. > An example policy is > ``` > [ >["vhost", { > "hostname": "$default", > "allowUnknownUser": true, > "groups" : { >"$default": { > "remoteHosts": "*", > "allowDynamicSource": true, > "allowAnonymousSender": true, > "sources": "$management, examples, q1", > "targets": "$management, examples, q1" >} > } >}] > ] > ``` -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1407) Memory leak on link policy denial
[ https://issues.apache.org/jira/browse/DISPATCH-1407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16924995#comment-16924995 ] Chuck Rolke commented on DISPATCH-1407: --- Thanks Gordon. Indeed that fixes it and in a place that logically fits. Please go ahead an commit this. > Memory leak on link policy denial > - > > Key: DISPATCH-1407 > URL: https://issues.apache.org/jira/browse/DISPATCH-1407 > Project: Qpid Dispatch > Issue Type: Bug > Components: Policy Engine >Affects Versions: 1.8.0 >Reporter: Chuck Rolke >Assignee: Chuck Rolke >Priority: Major > Attachments: A.conf, default.json > > > A router with a simple policy that denies most addresses starts and uses 10M > bytes of memory. A test client loops 25k times opening a link to a denied > address over a single connection and session. Now the router uses 276 Mbytes. > An example policy is > ``` > [ >["vhost", { > "hostname": "$default", > "allowUnknownUser": true, > "groups" : { >"$default": { > "remoteHosts": "*", > "allowDynamicSource": true, > "allowAnonymousSender": true, > "sources": "$management, examples, q1", > "targets": "$management, examples, q1" >} > } >}] > ] > ``` -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1407) Memory leak on link policy denial
[ https://issues.apache.org/jira/browse/DISPATCH-1407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16924651#comment-16924651 ] Chuck Rolke commented on DISPATCH-1407: --- Analysis to date: * Valgrind shows only python-related mallocs; this is inconclusive. Valgrind shows no actionable C-language malloc leaks. * The same problem is present in 1.7.0, 1.6.0, 1.5.0, and 1.4.x * Policy code was modified not to include setting pn_condition to signal the error - still has memory growth * Container code was modified to call pn_condition_clear for local and remote conditions when link is detached - no change * Tried making a policy.c static python module load and not loading only when needed - no change > Memory leak on link policy denial > - > > Key: DISPATCH-1407 > URL: https://issues.apache.org/jira/browse/DISPATCH-1407 > Project: Qpid Dispatch > Issue Type: Bug > Components: Policy Engine >Affects Versions: 1.8.0 >Reporter: Chuck Rolke >Assignee: Chuck Rolke >Priority: Major > Attachments: A.conf, default.json > > > A router with a simple policy that denies most addresses starts and uses 10M > bytes of memory. A test client loops 25k times opening a link to a denied > address over a single connection and session. Now the router uses 276 Mbytes. > An example policy is > ``` > [ >["vhost", { > "hostname": "$default", > "allowUnknownUser": true, > "groups" : { >"$default": { > "remoteHosts": "*", > "allowDynamicSource": true, > "allowAnonymousSender": true, > "sources": "$management, examples, q1", > "targets": "$management, examples, q1" >} > } >}] > ] > ``` -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1407) Memory leak on link policy denial
[ https://issues.apache.org/jira/browse/DISPATCH-1407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16924642#comment-16924642 ] Chuck Rolke commented on DISPATCH-1407: --- With A.conf and default.json in your cwd, run _qdrouterd -c A.conf_ Then open a disallowed source or target. > Memory leak on link policy denial > - > > Key: DISPATCH-1407 > URL: https://issues.apache.org/jira/browse/DISPATCH-1407 > Project: Qpid Dispatch > Issue Type: Bug > Components: Policy Engine >Affects Versions: 1.8.0 >Reporter: Chuck Rolke >Assignee: Chuck Rolke >Priority: Major > Attachments: A.conf, default.json > > > A router with a simple policy that denies most addresses starts and uses 10M > bytes of memory. A test client loops 25k times opening a link to a denied > address over a single connection and session. Now the router uses 276 Mbytes. > An example policy is > ``` > [ >["vhost", { > "hostname": "$default", > "allowUnknownUser": true, > "groups" : { >"$default": { > "remoteHosts": "*", > "allowDynamicSource": true, > "allowAnonymousSender": true, > "sources": "$management, examples, q1", > "targets": "$management, examples, q1" >} > } >}] > ] > ``` -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-1407) Memory leak on link policy denial
[ https://issues.apache.org/jira/browse/DISPATCH-1407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke updated DISPATCH-1407: -- Attachment: default.json > Memory leak on link policy denial > - > > Key: DISPATCH-1407 > URL: https://issues.apache.org/jira/browse/DISPATCH-1407 > Project: Qpid Dispatch > Issue Type: Bug > Components: Policy Engine >Affects Versions: 1.8.0 > Reporter: Chuck Rolke >Assignee: Chuck Rolke >Priority: Major > Attachments: A.conf, default.json > > > A router with a simple policy that denies most addresses starts and uses 10M > bytes of memory. A test client loops 25k times opening a link to a denied > address over a single connection and session. Now the router uses 276 Mbytes. > An example policy is > ``` > [ >["vhost", { > "hostname": "$default", > "allowUnknownUser": true, > "groups" : { >"$default": { > "remoteHosts": "*", > "allowDynamicSource": true, > "allowAnonymousSender": true, > "sources": "$management, examples, q1", > "targets": "$management, examples, q1" >} > } >}] > ] > ``` -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-1407) Memory leak on link policy denial
[ https://issues.apache.org/jira/browse/DISPATCH-1407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke updated DISPATCH-1407: -- Attachment: A.conf > Memory leak on link policy denial > - > > Key: DISPATCH-1407 > URL: https://issues.apache.org/jira/browse/DISPATCH-1407 > Project: Qpid Dispatch > Issue Type: Bug > Components: Policy Engine >Affects Versions: 1.8.0 > Reporter: Chuck Rolke >Assignee: Chuck Rolke >Priority: Major > Attachments: A.conf, default.json > > > A router with a simple policy that denies most addresses starts and uses 10M > bytes of memory. A test client loops 25k times opening a link to a denied > address over a single connection and session. Now the router uses 276 Mbytes. > An example policy is > ``` > [ >["vhost", { > "hostname": "$default", > "allowUnknownUser": true, > "groups" : { >"$default": { > "remoteHosts": "*", > "allowDynamicSource": true, > "allowAnonymousSender": true, > "sources": "$management, examples, q1", > "targets": "$management, examples, q1" >} > } >}] > ] > ``` -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1407) Memory leak on link policy denial
Chuck Rolke created DISPATCH-1407: - Summary: Memory leak on link policy denial Key: DISPATCH-1407 URL: https://issues.apache.org/jira/browse/DISPATCH-1407 Project: Qpid Dispatch Issue Type: Bug Components: Policy Engine Affects Versions: 1.8.0 Reporter: Chuck Rolke Assignee: Chuck Rolke A router with a simple policy that denies most addresses starts and uses 10M bytes of memory. A test client loops 25k times opening a link to a denied address over a single connection and session. Now the router uses 276 Mbytes. An example policy is ``` [ ["vhost", { "hostname": "$default", "allowUnknownUser": true, "groups" : { "$default": { "remoteHosts": "*", "allowDynamicSource": true, "allowAnonymousSender": true, "sources": "$management, examples, q1", "targets": "$management, examples, q1" } } }] ] ``` -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1405) Display local addresses at startup
Chuck Rolke created DISPATCH-1405: - Summary: Display local addresses at startup Key: DISPATCH-1405 URL: https://issues.apache.org/jira/browse/DISPATCH-1405 Project: Qpid Dispatch Issue Type: Improvement Components: Management Agent Affects Versions: 1.8.0 Reporter: Chuck Rolke At boot time the router could display its local addresses. This would help debugging certain issues. An example of the information is from hawtio: ``` [io.hawt.system.ProxyWhitelist] Probing local addresses ... [io.hawt.system.ProxyWhitelist] Initial proxy whitelist: [localhost, 127.0.0.1, 10.10.111.222, ovpn-111-222.gw.example.com, 192.168.100.100, unused] ``` -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-1383) system_tests_policy is timing out
[ https://issues.apache.org/jira/browse/DISPATCH-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke resolved DISPATCH-1383. --- Fix Version/s: 1.9.0 Resolution: Fixed > system_tests_policy is timing out > - > > Key: DISPATCH-1383 > URL: https://issues.apache.org/jira/browse/DISPATCH-1383 > Project: Qpid Dispatch > Issue Type: Bug > Components: Tests >Affects Versions: 1.8.0 >Reporter: Fernando Giorgetti >Assignee: Chuck Rolke >Priority: Major > Fix For: 1.9.0 > > > We are seeing system_tests_policy timing out on RHEL6, RHEL7 and RHEL8 > platforms. > This is happening with latest bits from master branch and latest proton > (downstream). -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1400) [tools] Scraper fails with log file BOM byte order marks
Chuck Rolke created DISPATCH-1400: - Summary: [tools] Scraper fails with log file BOM byte order marks Key: DISPATCH-1400 URL: https://issues.apache.org/jira/browse/DISPATCH-1400 Project: Qpid Dispatch Issue Type: Bug Components: Tools Affects Versions: 1.8.0 Reporter: Chuck Rolke Assignee: Chuck Rolke Logs captured from downloading Openshift pod logs have BOMs. Scraper fails right away. A workaround is to process the log with dos2unix: {{ dos2unix PVT.log}} -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1393) Router link logging on interQDR connection is skipped on connecting router
Chuck Rolke created DISPATCH-1393: - Summary: Router link logging on interQDR connection is skipped on connecting router Key: DISPATCH-1393 URL: https://issues.apache.org/jira/browse/DISPATCH-1393 Project: Qpid Dispatch Issue Type: Bug Components: Router Node Affects Versions: 1.8.0 Environment: In test directory build/tests/system_test.dir/system_tests_edge_router/EdgeRouterTest/setUpClass grep "Link attached" INT*.log and see that the log lines are only in INT.A.log Reporter: Chuck Rolke A useful ROUTER info log message describing interrouter links is emitted at the end of function qdr_link_inbound_first_attach_CT. Thus the link messages are logged only on the router that is listening. The connecting router should log the same link details so that connection and link pairs are more easily correlated. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-1388) Authorization doc fails to describe vhost abstraction clearly
[ https://issues.apache.org/jira/browse/DISPATCH-1388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke resolved DISPATCH-1388. --- Resolution: Fixed Fix Version/s: 1.9.0 Fixed at Commit ab6657 > Authorization doc fails to describe vhost abstraction clearly > - > > Key: DISPATCH-1388 > URL: https://issues.apache.org/jira/browse/DISPATCH-1388 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Documentation >Affects Versions: 1.8.0 > Reporter: Chuck Rolke >Assignee: Chuck Rolke >Priority: Major > Fix For: 1.9.0 > > > Security documentation misses an important point when describing policy and > how policy is effected by vhost settings: Access policy is applied at the > point of ingress to a router network. Once access is granted to a resource > then all resources with that name anywhere in the network are accessible. > Access restrictions are specified in a policy vhost object. The vhost > contains the restrictions that get applied to a connection when the > connection is established. Reading the doc it sounds as if there are vhost > objects that may contain addresses somewhere in the router. That conceptual > model is the issue in the doc that needs to be fixed. > Methods for Specifying Vhost Policy Source and Target Addresses is a good > example. In the table the first item is titled _Allow all users in the user > group to access all source or target addresses on the vhost_ . In reality the > addresses are not _on the vhost but are in the router network_. > Throughout the document the text "on a vhost" could be changed to "through a > vhost" or "specified by a vhost", or could be removed entirely. > h4. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1388) Authorization doc fails to describe vhost abstraction clearly
Chuck Rolke created DISPATCH-1388: - Summary: Authorization doc fails to describe vhost abstraction clearly Key: DISPATCH-1388 URL: https://issues.apache.org/jira/browse/DISPATCH-1388 Project: Qpid Dispatch Issue Type: Improvement Components: Documentation Affects Versions: 1.8.0 Reporter: Chuck Rolke Assignee: Chuck Rolke Security documentation misses an important point when describing policy and how policy is effected by vhost settings: Access policy is applied at the point of ingress to a router network. Once access is granted to a resource then all resources with that name anywhere in the network are accessible. Access restrictions are specified in a policy vhost object. The vhost contains the restrictions that get applied to a connection when the connection is established. Reading the doc it sounds as if there are vhost objects that may contain addresses somewhere in the router. That conceptual model is the issue in the doc that needs to be fixed. Methods for Specifying Vhost Policy Source and Target Addresses is a good example. In the table the first item is titled _Allow all users in the user group to access all source or target addresses on the vhost_ . In reality the addresses are not _on the vhost but are in the router network_. Throughout the document the text "on a vhost" could be changed to "through a vhost" or "specified by a vhost", or could be removed entirely. h4. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1379) Message receive performance improvements
Chuck Rolke created DISPATCH-1379: - Summary: Message receive performance improvements Key: DISPATCH-1379 URL: https://issues.apache.org/jira/browse/DISPATCH-1379 Project: Qpid Dispatch Issue Type: Improvement Components: Router Node Affects Versions: 1.8.0 Reporter: Chuck Rolke Assignee: Chuck Rolke Code inspection reveals three function calls per message that may be eliminated and a buffer free that could be executed outside of holding the content lock. * Message allocator initializes object in memory ascending order Despite the size of the code, setting the required fields to zero directly is faster that calling ZERO. * Eliminate redundant calls to pn_link_get_context * Free empty pending buffer outside of content lock -- 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-1377) system_tests_topology_disposition failing on machine with python3 only
[ https://issues.apache.org/jira/browse/DISPATCH-1377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16875080#comment-16875080 ] Chuck Rolke commented on DISPATCH-1377: --- The failing system has 'python3' but it does not have 'python' linked to it. The test launches scraper with {{/usr/bin/env python /root/qpid-dispatch/build/tests/scraper/scraper.py -f ../setUpClass/A.log ../setUpClass/B.log ../setUpClass/C.log ../setUpClass/D.log}} {{/usr/bin/env: ‘python’: No such file or directory}} Other tests that pass launch 'python3'. > system_tests_topology_disposition failing on machine with python3 only > -- > > Key: DISPATCH-1377 > URL: https://issues.apache.org/jira/browse/DISPATCH-1377 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Tests >Affects Versions: 1.8.0 > Reporter: Ganesh Murthy >Assignee: Chuck Rolke >Priority: Major > Fix For: 1.9.0 > > > The following is the output of the test failure > > {noformat} > Stacktrace > test_01_delete_spurious_connector > (system_tests_topology_disposition.TopologyDispositionTests) ... ok > test_02_topology_disposition > (system_tests_topology_disposition.TopologyDispositionTests) ... ok > test_03_connection_id_propagation > (system_tests_topology_disposition.TopologyDispositionTests) ... ok > test_04_scraper_tool > (system_tests_topology_disposition.TopologyDispositionTests) ... FAIL > == > FAIL: test_04_scraper_tool > (system_tests_topology_disposition.TopologyDispositionTests) > -- > Traceback (most recent call last): > File "/opt/interconnect-src/tests/system_tests_topology_disposition.py", > line 459, in test_04_scraper_tool > self.assertEqual ( None, error ) > AssertionError: None != 'Process 7713 error: exit code 126, expec[311 > chars]<<<<'{noformat} -- 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-1371) qd_alloc can reuse instances in LIFO order
[ https://issues.apache.org/jira/browse/DISPATCH-1371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16865856#comment-16865856 ] Chuck Rolke commented on DISPATCH-1371: --- When trying to figure out a use-after-free bug it is harder when the most recently used object is put back in service immediately this way. If this change is known to be a faster way to go overall then I won't object to it. With the DEQ of objects doesn't adding an object to end of a queue also change the pointer at the head of the queue? If so then maybe there is not that much cache advantage to adding or removing from the tail instead of the head. > qd_alloc can reuse instances in LIFO order > -- > > Key: DISPATCH-1371 > URL: https://issues.apache.org/jira/browse/DISPATCH-1371 > Project: Qpid Dispatch > Issue Type: Improvement >Affects Versions: 1.8.0 >Reporter: Francesco Nigro >Priority: Minor > > qd_dealloc is inserting instances on the tail of the thread local free_list > while qd_alloc is reading from the head, always causing cache misses unless > free_list size is 1. > qd_alloc could instead reuse the last inserted instance ie the tail, using > free_list as a stack (with LIFO accesses). -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Reopened] (DISPATCH-1359) Set ctest timeout to 300 seconds.
[ https://issues.apache.org/jira/browse/DISPATCH-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke reopened DISPATCH-1359: --- Assignee: Chuck Rolke (was: Ganesh Murthy) The fix so as committed has an issue wherein it nullifies the effect of cmake command line option "-- timeout N" (See note 1). Test developers depend on temporarily overriding the test timeout. Note 1: The timeout can be changed by running ccmake and editing option DART_TESTING_TIMEOUT. However, if cmake sets the test timeout property then that value cannot be overridden. > Set ctest timeout to 300 seconds. > - > > Key: DISPATCH-1359 > URL: https://issues.apache.org/jira/browse/DISPATCH-1359 > Project: Qpid Dispatch > Issue Type: Bug > Components: Container >Affects Versions: 1.7.0 >Reporter: Ganesh Murthy >Assignee: Chuck Rolke >Priority: Minor > Fix For: 1.9.0 > > > Currently when running system tests, ctest has a default timeout of 1500 > seconds which is way too long. So for example, system_tests_edge_router if it > should hang for some reason, gets terminated by ctest only after 1500 seconds > (25 mins). This is way too long. > We need to set a smaller more reasonable timeout per test for ctest. > system_tests_edge_router is the longest executing test in the test suite. > Looking at how long it takes to execute on a slow Travis system, we have > reached the conclusion that 300 seconds would be a good timeout value for > ctest. -- 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-1366) Performance improvement in qd_parse_as functions
Chuck Rolke created DISPATCH-1366: - Summary: Performance improvement in qd_parse_as functions Key: DISPATCH-1366 URL: https://issues.apache.org/jira/browse/DISPATCH-1366 Project: Qpid Dispatch Issue Type: Improvement Components: Router Node Affects Versions: 1.8.0 Reporter: Chuck Rolke Fix For: Backlog Most of the calls to qd_iterator_octet in file parse.c could be avoided when enough of the field's data is in the current underlying buffer. The objective is to use the same technques used in DISPATCH-1354 -- This message was sent by Atlassian JIRA (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-480) Default tests timeout is too short for some machines
[ https://issues.apache.org/jira/browse/DISPATCH-480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke resolved DISPATCH-480. -- Resolution: Fixed Fix Version/s: (was: Backlog) 1.9.0 Fixed at Commit 03e59d3131 (2019-06-12) > Default tests timeout is too short for some machines > > > Key: DISPATCH-480 > URL: https://issues.apache.org/jira/browse/DISPATCH-480 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Tests >Affects Versions: 0.7.0 >Reporter: Jiri Daněk >Priority: Major > Fix For: 1.9.0 > > > I created a Docker image on hub.docker.com. The website offers the following > free service: you provide a Dockerfile and it builds the image for you on > some IaaS platform. Problem is, their VMs are slow and Dispatch tests tend to > timeout. > I ran the build more than 10 times already and not once did the tests succeed. > For example, see this build, > https://hub.docker.com/r/jdanekrh/dispatch-console-tests/builds/be4azv4jnyywc93nstyti8g/, > scroll to the bottom to see the build log. > Would it be possible to increase the test timeout? Is it actually already > configurable somehow? -- 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-1359) Set ctest timeout to 300 seconds.
[ https://issues.apache.org/jira/browse/DISPATCH-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke resolved DISPATCH-1359. --- Resolution: Fixed Fix Version/s: 1.9.0 Fixed at Commit 03e59d3131 > Set ctest timeout to 300 seconds. > - > > Key: DISPATCH-1359 > URL: https://issues.apache.org/jira/browse/DISPATCH-1359 > Project: Qpid Dispatch > Issue Type: Bug > Components: Container >Affects Versions: 1.7.0 >Reporter: Ganesh Murthy >Assignee: Ganesh Murthy >Priority: Minor > Fix For: 1.9.0 > > > Currently when running system tests, ctest has a default timeout of 1500 > seconds which is way too long. So for example, system_tests_edge_router if it > should hang for some reason, gets terminated by ctest only after 1500 seconds > (25 mins). This is way too long. > We need to set a smaller more reasonable timeout per test for ctest. > system_tests_edge_router is the longest executing test in the test suite. > Looking at how long it takes to execute on a slow Travis system, we have > reached the conclusion that 300 seconds would be a good timeout value for > ctest. -- 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
Re: [VOTE] Release Qpid Dispatch Router 1.8.0 (RC1)
+1 * Checked checksums * Build/test Fedora 29, python 3 * Fails system_tests_http (known problem, not a regression) * Build/test Fedora 28, python 2 * Occasional test fail system_tests_fallback_dest known problem in new test code and not in mission code; fix is already on master; not a regression - Original Message - > From: "Ganesh Murthy" > To: us...@qpid.apache.org, dev@qpid.apache.org > Sent: Friday, June 7, 2019 11:23:40 AM > Subject: [VOTE] Release Qpid Dispatch Router 1.8.0 (RC1) > > Hello All, > Please cast your vote on this thread to release RC1 as the > official Qpid Dispatch Router version 1.8.0. > > RC1 of Qpid Dispatch Router version 1.8.0 can be found here: > > https://dist.apache.org/repos/dist/dev/qpid/dispatch/1.8.0-rc1/ > > The following features, improvements, and bug fixes are introduced in 1.8.0: > > Features - >DISPATCH-1337 - Fallback Destination for Unreachable Addresses > > Improvements - > DISPATCH-1308 - Console access to the force-close a connection feature > DISPATCH-1320 - Make it easier to use separate logos for upstream > and downstream masthead > DISPATCH-1321 - Set rpath for qpid-proton (and other dependencies) > when they are found in nonstandard location > DISPATCH-1329 - Edge router system test needs skip test convenience > switches > DISPATCH-1340 - Show settlement rate and delayed deliveries in client > popup > DISPATCH-1341 - Add list of delayed links to console's overview page > DISPATCH-1348 - Avoid qdr_error_t allocation if not necessary > DISPATCH-1356 - Remove the dotted line around routers that > indicates the router is fixed. > DISPATCH-1357 - Change the name of the 'Kill' feature to 'Close' > > Bug fixes - > DISPATCH-974 - Getting connections via the router management > protocol causes AMQP framing errors > DISPATCH-1230 - System test failing with OpenSSL >= 1.1 - > system_tests_ssl > DISPATCH-1312 - Remove cmake option USE_MEMORY_POOL > DISPATCH-1317 - HTTP system test is failing on python2.6 > DISPATCH-1318 - edge_router system test failing > DISPATCH-1322 - Edge router drops disposition when remote receiver closes > DISPATCH-1323 - Deprecate addr and externalAddr attributes of > autoLink entity. Add address and externalAddress instead. > DISPATCH-1324 - [tools] Scraper uses deprecated cgi.escape function > DISPATCH-1325 - Sender connections to edge router that connect > 'too soon' never get credit > DISPATCH-1326 - Anonymous messages are released by edge router > even if there is a receiver for the messages > DISPATCH-1330 - Q2 stall due to incorrect msg buffer ref count > decrement on link detach > DISPATCH-1334 - Background map on topology page incorrect height > DISPATCH-1335 - After adding client, topology page shows new icon > in upper-left corner > DISPATCH-1339 - Multiple consoles attached to a router are showing > as separate icons > > > Thanks. > > - > To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org > For additional commands, e-mail: dev-h...@qpid.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1359) Set ctest timeout to 300 seconds.
[ https://issues.apache.org/jira/browse/DISPATCH-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16860319#comment-16860319 ] Chuck Rolke commented on DISPATCH-1359: --- A good improvement would be to make the timeout adjustable for each test. If a test normally takes 0.85 seconds then the value of 300 seems pretty outrageous. Also, some time ago there was a request https://issues.apache.org/jira/browse/DISPATCH-480 to *raise* the default test timeout. > Set ctest timeout to 300 seconds. > - > > Key: DISPATCH-1359 > URL: https://issues.apache.org/jira/browse/DISPATCH-1359 > Project: Qpid Dispatch > Issue Type: Bug > Components: Container >Affects Versions: 1.7.0 >Reporter: Ganesh Murthy >Assignee: Ganesh Murthy >Priority: Minor > > Currently when running system tests, ctest has a default timeout of 1500 > seconds which is way too long. So for example, system_tests_edge_router if it > should hang for some reason, gets terminated by ctest only after 1500 seconds > (25 mins). This is way too long. > We need to set a smaller more reasonable timeout per test for ctest. > system_tests_edge_router is the longest executing test in the test suite. > Looking at how long it takes to execute on a slow Travis system, we have > reached the conclusion that 300 seconds would be a good timeout value for > ctest. -- 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-1354) Interrouter annotation processing uses slow methods
[ https://issues.apache.org/jira/browse/DISPATCH-1354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke resolved DISPATCH-1354. --- Resolution: Fixed Fix Version/s: 1.9.0 > Interrouter annotation processing uses slow methods > --- > > Key: DISPATCH-1354 > URL: https://issues.apache.org/jira/browse/DISPATCH-1354 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Router Node >Affects Versions: 1.7.0 > Reporter: Chuck Rolke >Assignee: Chuck Rolke >Priority: Major > Fix For: 1.9.0 > > > Message annotation processing on received messages stages key names byte by > byte into a flat buffer and then uses strcmp to check them. > Easy improvements are: > * Use name in raw buffer if it does not cross a buffer boundary > * If name crosses a boundary then use memmoves to get the name in chunks > * Check the name prefix only once and then check variable parts of name > strings > * Don't create unnecessary qd_iterators and qd_parsed_fields > * Don't check names whose lengths differ from the given keys -- 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-1354) Interrouter annotation processing uses slow methods
Chuck Rolke created DISPATCH-1354: - Summary: Interrouter annotation processing uses slow methods Key: DISPATCH-1354 URL: https://issues.apache.org/jira/browse/DISPATCH-1354 Project: Qpid Dispatch Issue Type: Improvement Components: Router Node Affects Versions: 1.7.0 Reporter: Chuck Rolke Assignee: Chuck Rolke Message annotation processing on received messages stages key names byte by byte into a flat buffer and then uses strcmp to check them. Easy improvements are: * Use name in raw buffer if it does not cross a buffer boundary * If name crosses a boundary then use memmoves to get the name in chunks * Check the name prefix only once and then check variable parts of name strings * Don't create unnecessary qd_iterators and qd_parsed_fields * Don't check names whose lengths differ from the given keys -- 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] (QPID-8319) QMF requests rerouted to QMF exchange may crash with invalid connection
Chuck Rolke created QPID-8319: - Summary: QMF requests rerouted to QMF exchange may crash with invalid connection Key: QPID-8319 URL: https://issues.apache.org/jira/browse/QPID-8319 Project: Qpid Issue Type: Improvement Components: C++ Broker Affects Versions: qpid-cpp-1.39.0 Reporter: Chuck Rolke Reported by Pavel in [https://bugzilla.redhat.com/show_bug.cgi?id=1713560] Description of problem: User story: when running concurrently 2 times a program that: 1) Creates a queue on the broker "HelloQueue" 2) Creates a second queue called "HelloQueue.AutoDelete" with auto-delete set and alternate exchange set to "qmf.default.direct" and hold open the Receiver that is subscribed to it. 3) Puts a QMF message into the "HelloQueue.AutoDelete" queue that will delete the "HelloQueue" queue when it is processed. 4) Waits 10 seconds. 5) Closes the receiver, triggering the auto-delete of "HelloQueue.AutoDelete". Then the QMF message will be sent to "qmf.default.direct" because of the alternate exchange, resulting in the deletion of "HelloQueue" regardless of whether or not there are other subscribers connected to it. And with some high probability, the 2nd QMF request from just dropped connection will attempt to be processed, but causes segfault. Version-Release number of selected component (if applicable): qpid-cpp 1.36.0-15 (or -21 or -21+hf2), I expect any How reproducible: 75% in my case Steps to Reproduce: 1. Compile attached program. 2. qpidd & 3. ./QmfBrokerCrashRepro localhost:5672 & ./QmfBrokerCrashRepro localhost:5672 & Actual results: client program aborts every time (unhandled exception, no deal), but very often qpidd segfaults as well, with backtrace: {code:java} (gdb) bt #0 0x in ?? () #1 0x7f9b5cdca752 in qpid::management::(anonymous namespace)::ScopedManagementContext::getUserId (this=) at /usr/src/debug/qpid-cpp-1.36.0/src/qpid/management/ManagementAgent.cpp:105 #2 0x7f9b5cde8055 in qpid::management::ManagementAgent::dispatchAgentCommand (this=0x1680930, msg=..., viaLocal=true) at /usr/src/debug/qpid-cpp-1.36.0/src/qpid/management/ManagementAgent.cpp:2347 #3 0x7f9b5cde8958 in qpid::management::ManagementAgent::dispatchCommand (this=0x1680930, deliverable=, routingKey="broker", topic=false, qmfVersion=2) at /usr/src/debug/qpid-cpp-1.36.0/src/qpid/management/ManagementAgent.cpp:1255 #4 0x7f9b5cdfb219 in qpid::broker::ManagementDirectExchange::route (this=0x168b6f0, msg=...) at /usr/src/debug/qpid-cpp-1.36.0/src/qpid/management/ManagementDirectExchange.cpp:48 #5 0x7f9b5cccfa2a in qpid::broker::Exchange::routeWithAlternate (this=0x168b768, msg=...) at /usr/src/debug/qpid-cpp-1.36.0/src/qpid/broker/Exchange.cpp:410 #6 0x7f9b5ccfddb5 in qpid::broker::Queue::reroute (e=, m=) at /usr/src/debug/qpid-cpp-1.36.0/src/qpid/broker/Queue.cpp:1761 #7 0x7f9b5ccfe006 in qpid::broker::Queue::abandoned (this=0x16ba740, message=) at /usr/src/debug/qpid-cpp-1.36.0/src/qpid/broker/Queue.cpp:1156 #8 0x7f9b5ccf16cd in operator() (this=0x16ba740, maxCount=0, p=..., f=..., type=, triggerAutoDelete=false, maxTests=0) at /usr/include/boost/function/function_template.hpp:1013 #9 qpid::broker::Queue::remove (this=0x16ba740, maxCount=0, p=..., f=..., type=, triggerAutoDelete=false, maxTests=0) at /usr/src/debug/qpid-cpp-1.36.0/src/qpid/broker/Queue.cpp:795 #10 0x7f9b5ccf49d5 in qpid::broker::Queue::destroyed (this=0x16ba740) at /usr/src/debug/qpid-cpp-1.36.0/src/qpid/broker/Queue.cpp:1167 #11 0x7f9b5cd73b09 in qpid::broker::QueueRegistry::destroyIfUntouched (this=0x167f2f8, targetQ=, version=, connectionId="", userId="") at /usr/src/debug/qpid-cpp-1.36.0/src/qpid/broker/QueueRegistry.cpp:156 #12 0x7f9b5ccee336 in qpid::broker::Queue::tryAutoDelete (this=0x16ba740, expectedVersion=1) at /usr/src/debug/qpid-cpp-1.36.0/src/qpid/broker/Queue.cpp:1358 #13 0x7f9b5ccee834 in qpid::broker::Queue::scheduleAutoDelete (this=0x16ba740, immediate=false) at /usr/src/debug/qpid-cpp-1.36.0/src/qpid/broker/Queue.cpp:1342 #14 0x7f9b5ccef626 in qpid::broker::Queue::cancel (this=0x16ba740, c=..., connectionId="qpid.[::1]:5672-[::1]:54658", userId="anonymous@QPID") at /usr/src/debug/qpid-cpp-1.36.0/src/qpid/broker/Queue.cpp:638 #15 0x7f9b5cd90eca in qpid::broker::SemanticState::cancel (this=0x7f9b4c00a078, c=...) at /usr/src/debug/qpid-cpp-1.36.0/src/qpid/broker/SemanticState.cpp:475 #16 0x7f9b5cd98775 in qpid::broker::SemanticState::closed (this=0x7f9b4c00a078) at /usr/src/debug/qpid-cpp-1.36.0/src/qpid/broker/SemanticState.cpp:111 #17 0x7f9b5cdb0301 in qpid::broker::SessionState::~SessionState (this
[jira] [Created] (DISPATCH-1336) Deliveries settled out of order in simple test case
Chuck Rolke created DISPATCH-1336: - Summary: Deliveries settled out of order in simple test case Key: DISPATCH-1336 URL: https://issues.apache.org/jira/browse/DISPATCH-1336 Project: Qpid Dispatch Issue Type: Improvement Components: Router Node Affects Versions: 1.7.0 Environment: Fedora 29, Python 3 Debug builds Proton git: branch master @ 0481a507c Dispatch git: branch master @ 7b3a8e25 Reporter: Chuck Rolke 1. A router is started with a simple qdrouterd 2. A single qpid-proton-c sender sends 100,000 messages to port 5672 3. A simple qpid-proton-c receiver receives the messages and accepts them. 4. In the sender's on_accept method occasionally the message IDs appear out of order. In this snippet the message id numbers are marching along in the correct order. Then settlements 77441..77459 jump ahead of settlement 77430. After that the streams get synchronized again and match for the remainder of the run. This is not necessarily wrong from an AMQP standpoint. But one might expect that the settlements would propagate from the receiver back to the sender in order every time. Can anyone explain how this happens? {code:java} Fail to match message id 77430 with settlement id 77441 Fail to match message id 77431 with settlement id 77442 Fail to match message id 77432 with settlement id 77443 Fail to match message id 77433 with settlement id 77444 Fail to match message id 77434 with settlement id 77445 Fail to match message id 77435 with settlement id 77446 Fail to match message id 77436 with settlement id 77447 Fail to match message id 77437 with settlement id 77448 Fail to match message id 77438 with settlement id 77449 Fail to match message id 77439 with settlement id 77450 Fail to match message id 77440 with settlement id 77451 Fail to match message id 77441 with settlement id 77452 Fail to match message id 77442 with settlement id 77453 Fail to match message id 77443 with settlement id 77454 Fail to match message id 77444 with settlement id 77455 Fail to match message id 77445 with settlement id 77456 Fail to match message id 77446 with settlement id 77457 Fail to match message id 77447 with settlement id 77458 Fail to match message id 77448 with settlement id 77459 Fail to match message id 77449 with settlement id 77430 Fail to match message id 77450 with settlement id 77431 Fail to match message id 77451 with settlement id 77432 Fail to match message id 77452 with settlement id 77433 Fail to match message id 77453 with settlement id 77434 Fail to match message id 77454 with settlement id 77435 Fail to match message id 77455 with settlement id 77436 Fail to match message id 77456 with settlement id 77437 Fail to match message id 77457 with settlement id 77438 Fail to match message id 77458 with settlement id 77439 Fail to match message id 77459 with settlement id 77440 {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (DISPATCH-1333) Console test fails printing to file with python 3
[ https://issues.apache.org/jira/browse/DISPATCH-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke reassigned DISPATCH-1333: - Assignee: Chuck Rolke > Console test fails printing to file with python 3 > - > > Key: DISPATCH-1333 > URL: https://issues.apache.org/jira/browse/DISPATCH-1333 > Project: Qpid Dispatch > Issue Type: Bug > Components: Tests >Affects Versions: 1.7.0 > Environment: Fedora 29, Python 3, proton and dispatch master branches >Reporter: Chuck Rolke >Assignee: Chuck Rolke >Priority: Major > Attachments: console-test.patch, run_console_test.out.txt > > > {code:java} > test 53 > Start 53: system_tests_console > 53: Test command: /bin/python > "/home/chug/git/qpid-dispatch/build/tests/run.py" "unit2" "-v" > "system_tests_console" > 53: Test timeout computed to be: 1500 > 53: test_console (system_tests_console.ConsoleTest) ... ERROR > 53: > 53: == > 53: ERROR: test_console (system_tests_console.ConsoleTest) > 53: -- > 53: Traceback (most recent call last): > 53: File "/home/chug/git/qpid-dispatch/tests/system_test.py", line 706, in > wrap > 53: return f(*args, **kwargs) > 53: File "/home/chug/git/qpid-dispatch/tests/system_tests_console.py", line > 132, in test_console > 53: self.run_console_test() > 53: File "/home/chug/git/qpid-dispatch/tests/system_tests_console.py", line > 116, in run_console_test > 53: popenfile.writelines(out) > 53: TypeError: write() argument must be str, not int > 53: > 53: -- > 53: Ran 1 test in 0.959s > 53: > 53: FAILED (errors=1) > 1/1 Test #53: system_tests_console .***Failed 1.63 sec > 0% tests passed, 1 tests failed out of 1 > {code} > The test passes with the attached patch. > The content of the failed printout is attached. > > -- 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] [Updated] (DISPATCH-1333) Console test fails printing to file with python 3
[ https://issues.apache.org/jira/browse/DISPATCH-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke updated DISPATCH-1333: -- Attachment: run_console_test.out.txt > Console test fails printing to file with python 3 > - > > Key: DISPATCH-1333 > URL: https://issues.apache.org/jira/browse/DISPATCH-1333 > Project: Qpid Dispatch > Issue Type: Bug > Components: Tests >Affects Versions: 1.7.0 > Environment: Fedora 29, Python 3, proton and dispatch master branches >Reporter: Chuck Rolke >Priority: Major > Attachments: console-test.patch, run_console_test.out.txt > > > {code:java} > test 53 > Start 53: system_tests_console > 53: Test command: /bin/python > "/home/chug/git/qpid-dispatch/build/tests/run.py" "unit2" "-v" > "system_tests_console" > 53: Test timeout computed to be: 1500 > 53: test_console (system_tests_console.ConsoleTest) ... ERROR > 53: > 53: == > 53: ERROR: test_console (system_tests_console.ConsoleTest) > 53: -- > 53: Traceback (most recent call last): > 53: File "/home/chug/git/qpid-dispatch/tests/system_test.py", line 706, in > wrap > 53: return f(*args, **kwargs) > 53: File "/home/chug/git/qpid-dispatch/tests/system_tests_console.py", line > 132, in test_console > 53: self.run_console_test() > 53: File "/home/chug/git/qpid-dispatch/tests/system_tests_console.py", line > 116, in run_console_test > 53: popenfile.writelines(out) > 53: TypeError: write() argument must be str, not int > 53: > 53: -- > 53: Ran 1 test in 0.959s > 53: > 53: FAILED (errors=1) > 1/1 Test #53: system_tests_console .***Failed 1.63 sec > 0% tests passed, 1 tests failed out of 1 > {code} > The test passes with the attached patch. > The content of the failed printout is attached. > > -- 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] [Updated] (DISPATCH-1333) Console test fails printing to file with python 3
[ https://issues.apache.org/jira/browse/DISPATCH-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke updated DISPATCH-1333: -- Attachment: (was: run_console_test.out) > Console test fails printing to file with python 3 > - > > Key: DISPATCH-1333 > URL: https://issues.apache.org/jira/browse/DISPATCH-1333 > Project: Qpid Dispatch > Issue Type: Bug > Components: Tests >Affects Versions: 1.7.0 > Environment: Fedora 29, Python 3, proton and dispatch master branches >Reporter: Chuck Rolke >Priority: Major > Attachments: console-test.patch, run_console_test.out.txt > > > {code:java} > test 53 > Start 53: system_tests_console > 53: Test command: /bin/python > "/home/chug/git/qpid-dispatch/build/tests/run.py" "unit2" "-v" > "system_tests_console" > 53: Test timeout computed to be: 1500 > 53: test_console (system_tests_console.ConsoleTest) ... ERROR > 53: > 53: == > 53: ERROR: test_console (system_tests_console.ConsoleTest) > 53: -- > 53: Traceback (most recent call last): > 53: File "/home/chug/git/qpid-dispatch/tests/system_test.py", line 706, in > wrap > 53: return f(*args, **kwargs) > 53: File "/home/chug/git/qpid-dispatch/tests/system_tests_console.py", line > 132, in test_console > 53: self.run_console_test() > 53: File "/home/chug/git/qpid-dispatch/tests/system_tests_console.py", line > 116, in run_console_test > 53: popenfile.writelines(out) > 53: TypeError: write() argument must be str, not int > 53: > 53: -- > 53: Ran 1 test in 0.959s > 53: > 53: FAILED (errors=1) > 1/1 Test #53: system_tests_console .***Failed 1.63 sec > 0% tests passed, 1 tests failed out of 1 > {code} > The test passes with the attached patch. > The content of the failed printout is attached. > > -- 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] [Updated] (DISPATCH-1333) Console test fails printing to file with python 3
[ https://issues.apache.org/jira/browse/DISPATCH-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke updated DISPATCH-1333: -- Attachment: run_console_test.out > Console test fails printing to file with python 3 > - > > Key: DISPATCH-1333 > URL: https://issues.apache.org/jira/browse/DISPATCH-1333 > Project: Qpid Dispatch > Issue Type: Bug > Components: Tests >Affects Versions: 1.7.0 > Environment: Fedora 29, Python 3, proton and dispatch master branches >Reporter: Chuck Rolke >Priority: Major > Attachments: console-test.patch, run_console_test.out > > > {code:java} > test 53 > Start 53: system_tests_console > 53: Test command: /bin/python > "/home/chug/git/qpid-dispatch/build/tests/run.py" "unit2" "-v" > "system_tests_console" > 53: Test timeout computed to be: 1500 > 53: test_console (system_tests_console.ConsoleTest) ... ERROR > 53: > 53: == > 53: ERROR: test_console (system_tests_console.ConsoleTest) > 53: -- > 53: Traceback (most recent call last): > 53: File "/home/chug/git/qpid-dispatch/tests/system_test.py", line 706, in > wrap > 53: return f(*args, **kwargs) > 53: File "/home/chug/git/qpid-dispatch/tests/system_tests_console.py", line > 132, in test_console > 53: self.run_console_test() > 53: File "/home/chug/git/qpid-dispatch/tests/system_tests_console.py", line > 116, in run_console_test > 53: popenfile.writelines(out) > 53: TypeError: write() argument must be str, not int > 53: > 53: -- > 53: Ran 1 test in 0.959s > 53: > 53: FAILED (errors=1) > 1/1 Test #53: system_tests_console .***Failed 1.63 sec > 0% tests passed, 1 tests failed out of 1 > {code} > The test passes with the attached patch. > The content of the failed printout is attached. > > -- 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] [Updated] (DISPATCH-1333) Console test fails printing to file with python 3
[ https://issues.apache.org/jira/browse/DISPATCH-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke updated DISPATCH-1333: -- Attachment: console-test.patch > Console test fails printing to file with python 3 > - > > Key: DISPATCH-1333 > URL: https://issues.apache.org/jira/browse/DISPATCH-1333 > Project: Qpid Dispatch > Issue Type: Bug > Components: Tests >Affects Versions: 1.7.0 > Environment: Fedora 29, Python 3, proton and dispatch master branches >Reporter: Chuck Rolke >Priority: Major > Attachments: console-test.patch > > > {code:java} > test 53 > Start 53: system_tests_console > 53: Test command: /bin/python > "/home/chug/git/qpid-dispatch/build/tests/run.py" "unit2" "-v" > "system_tests_console" > 53: Test timeout computed to be: 1500 > 53: test_console (system_tests_console.ConsoleTest) ... ERROR > 53: > 53: == > 53: ERROR: test_console (system_tests_console.ConsoleTest) > 53: -- > 53: Traceback (most recent call last): > 53: File "/home/chug/git/qpid-dispatch/tests/system_test.py", line 706, in > wrap > 53: return f(*args, **kwargs) > 53: File "/home/chug/git/qpid-dispatch/tests/system_tests_console.py", line > 132, in test_console > 53: self.run_console_test() > 53: File "/home/chug/git/qpid-dispatch/tests/system_tests_console.py", line > 116, in run_console_test > 53: popenfile.writelines(out) > 53: TypeError: write() argument must be str, not int > 53: > 53: -- > 53: Ran 1 test in 0.959s > 53: > 53: FAILED (errors=1) > 1/1 Test #53: system_tests_console .***Failed 1.63 sec > 0% tests passed, 1 tests failed out of 1 > {code} > The test passes with the attached patch. > The content of the failed printout is attached. > > -- 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-1333) Console test fails printing to file with python 3
Chuck Rolke created DISPATCH-1333: - Summary: Console test fails printing to file with python 3 Key: DISPATCH-1333 URL: https://issues.apache.org/jira/browse/DISPATCH-1333 Project: Qpid Dispatch Issue Type: Bug Components: Tests Affects Versions: 1.7.0 Environment: Fedora 29, Python 3, proton and dispatch master branches Reporter: Chuck Rolke Attachments: console-test.patch {code:java} test 53 Start 53: system_tests_console 53: Test command: /bin/python "/home/chug/git/qpid-dispatch/build/tests/run.py" "unit2" "-v" "system_tests_console" 53: Test timeout computed to be: 1500 53: test_console (system_tests_console.ConsoleTest) ... ERROR 53: 53: == 53: ERROR: test_console (system_tests_console.ConsoleTest) 53: -- 53: Traceback (most recent call last): 53: File "/home/chug/git/qpid-dispatch/tests/system_test.py", line 706, in wrap 53: return f(*args, **kwargs) 53: File "/home/chug/git/qpid-dispatch/tests/system_tests_console.py", line 132, in test_console 53: self.run_console_test() 53: File "/home/chug/git/qpid-dispatch/tests/system_tests_console.py", line 116, in run_console_test 53: popenfile.writelines(out) 53: TypeError: write() argument must be str, not int 53: 53: -- 53: Ran 1 test in 0.959s 53: 53: FAILED (errors=1) 1/1 Test #53: system_tests_console .***Failed 1.63 sec 0% tests passed, 1 tests failed out of 1 {code} The test passes with the attached patch. The content of the failed printout is attached. -- 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] [Updated] (DISPATCH-1332) Reconcile install directories and content
[ https://issues.apache.org/jira/browse/DISPATCH-1332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke updated DISPATCH-1332: -- Attachment: opt-local-tree-full.txt > Reconcile install directories and content > - > > Key: DISPATCH-1332 > URL: https://issues.apache.org/jira/browse/DISPATCH-1332 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Tools >Affects Versions: 1.6.0 > Reporter: Chuck Rolke >Priority: Major > Attachments: opt-local-tree-full.txt > > > An installation of qpid-proton and qpid-dispatch is created with a cmake > install where both projects use: > {{cmake -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=/opt/local}} > qpid-dispatch places a 64-bit .so file in /opt/local/lib when it rightfully > belongs in /opt/local/lib64. > Further investigation of the install directories reveals some discrepancies > between qpid-proton and qpid-dispatch installation hierarchies. Please see > attached _tree_ listing. One might expect them to be symmetric where > possible. The current arrangement is confusing and makes it unnecessarily > difficult to use them both. Note that self tests force PATH and PYTHONPATH to > reflect the discovered locations but the values they use are not always > practical for simple stand-alone product usage. Using the /opt/local install > prefix then requires a PYTHONPATH like this; > {{/opt/local/lib/python3.7/site-packages}} > {{/opt/local/lib64/proton/bindings/python}} > -- 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-1332) Reconcile install directories and content
Chuck Rolke created DISPATCH-1332: - Summary: Reconcile install directories and content Key: DISPATCH-1332 URL: https://issues.apache.org/jira/browse/DISPATCH-1332 Project: Qpid Dispatch Issue Type: Improvement Components: Tools Affects Versions: 1.6.0 Reporter: Chuck Rolke An installation of qpid-proton and qpid-dispatch is created with a cmake install where both projects use: {{cmake -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=/opt/local}} qpid-dispatch places a 64-bit .so file in /opt/local/lib when it rightfully belongs in /opt/local/lib64. Further investigation of the install directories reveals some discrepancies between qpid-proton and qpid-dispatch installation hierarchies. Please see attached _tree_ listing. One might expect them to be symmetric where possible. The current arrangement is confusing and makes it unnecessarily difficult to use them both. Note that self tests force PATH and PYTHONPATH to reflect the discovered locations but the values they use are not always practical for simple stand-alone product usage. Using the /opt/local install prefix then requires a PYTHONPATH like this; {{/opt/local/lib/python3.7/site-packages}} {{/opt/local/lib64/proton/bindings/python}} -- 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] (PROTON-2042) Occasional engine.c:691: pni_add_work: Assertion `!delivery->local.settled' failed
[ https://issues.apache.org/jira/browse/PROTON-2042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16834165#comment-16834165 ] Chuck Rolke commented on PROTON-2042: - This failure is triggered by the same subsection (test_06_message_route_abort_two_routers) of the same qpid-dispatch self test (system_tests_delivery_abort) as PROTON-2005. > Occasional engine.c:691: pni_add_work: Assertion `!delivery->local.settled' > failed > -- > > Key: PROTON-2042 > URL: https://issues.apache.org/jira/browse/PROTON-2042 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: proton-c-0.27.1 > Environment: To reproduce (I'm on fedora 29) > 1) build both qpid-dispatch and qpid-proton with -DCMAKE_BUILD_TYPE=Debug > 2) run the delivery abort Qpid dispatch router unit test in a loop: > $ while ctest -VV -R system_tests_delivery_abort; do date; done > The assert usually fires after a few minutes. >Reporter: Ken Giusti >Priority: Major > Fix For: proton-c-0.28.0 > > > When running the Qpid Dispatch Router's unit tests (written in python), > occasionally we see the test client (reactor based) core dump on the > following (abbreviated) assert: > Program terminated with signal SIGABRT, Aborted. > #0 0x7fc515270efb in raise () from /lib64/libc.so.6 > Missing separate debuginfos, use: dnf debuginfo-install > bzip2-libs-1.0.6-26.fc28.x86_64 compat-openssl10-1.0.2o-1.fc28.x86_64 > glibc-2.27-38.fc28.x86_64 krb5-libs-1.16.1-25.fc28.x86_64 > libdb-5.3.28-30.fc28.x86_64 libuuid-2.32.1-1.fc28.x86_64 > libxcrypt-4.4.4-2.fc28.x86_64 pcre2-10.33-1.fc28.x86_64 > (gdb) bt > #0 0x7fc515270efb in raise () from /lib64/libc.so.6 > #1 0x7fc51525b5b9 in abort () from /lib64/libc.so.6 > #2 0x7fc51525b491 in __assert_fail_base.cold.0 () from /lib64/libc.so.6 > #3 0x7fc515269662 in __assert_fail () from /lib64/libc.so.6 > #4 0x7fc5047512d8 in pni_add_work (connection=0x5651b44603e0, > delivery=0x5651b44d4920) at > /home/kgiusti/work/proton/qpid-proton/c/src/core/engine.c:691 > #5 0x7fc5047514cf in pn_work_update (connection=0x5651b44603e0, > delivery=0x5651b44d4920) at > /home/kgiusti/work/proton/qpid-proton/c/src/core/engine.c:715 > #6 0x7fc50475437f in pn_link_advance (link=0x5651b4441af0) at > /home/kgiusti/work/proton/qpid-proton/c/src/core/engine.c:1796 > #7 0x7fc5049c57ac in _wrap_pn_link_advance (self=0x0, > args=(,)) > at > /home/kgiusti/work/proton/qpid-proton/BUILD/python/CMakeFiles/_cproton.dir/cprotonPYTHON_wrap.c:9539 > #8 0x7fc5161216bb in call_function (oparg=, > pp_stack=0x7ffcfa109470) at > /usr/src/debug/python2-2.7.15-4.fc28.x86_64/Python/ceval.c:4449 > #9 PyEval_EvalFrameEx ( > f=f@entry=Frame 0x7fc5014d1578, for file > /opt/kgiusti/lib64/proton/bindings/python/proton/_endpoints.py, line 497, in > advance (self=, > _record=, _attrs={'tag_generator': > , 'condition': None}) at remote > 0x7fc5015078d0>), throwflag=throwflag@entry=0) at > /usr/src/debug/python2-2.7.15-4.fc28.x86_64/Python/ceval.c:3083 > #10 0x7fc516121e72 in PyEval_EvalCodeEx (co=, > globals=, locals=, args=, > argcount=, > kws=, kwcount=0, defs=0x0, defcount=0, closure=0x0) at > /usr/src/debug/python2-2.7.15-4.fc28.x86_64/Python/ceval.c:3681 > #11 0x7fc51611eaac in fast_function (nk=, na= out>, n=, pp_stack=0x7ffcfa109630, func= 0x7fc501ec5d70>) > at /usr/src/debug/python2-2.7.15-4.fc28.x86_64/Python/ceval.c:4544 > #12 call_function (oparg=, pp_stack=0x7ffcfa109630) at > /usr/src/debug/python2-2.7.15-4.fc28.x86_64/Python/ceval.c:4469 > #13 PyEval_EvalFrameEx ( > f=f@entry=Frame 0x7fc501a05400, for file > /opt/kgiusti/lib64/proton/bindings/python/proton/_message.py, line 405, in > send (self= 0x7fc501509de0>, annotations=None, _correlation_id= at remote 0x7fc501509c60>, _free=False) at remote 0x7fc5014fa710>, > _id=, _free=False) at > remote 0x7fc5014fab48>, properties=None, instructions=None) at remote > 0x7fc5000900d0>, sender= 0x7fc501509630>, _record=, > _attrs={'tag_generator': , 'condition': > None}) at remote 0x7fc5015078d0>, tag=None, dlv= at remote 0x7fc5015097e0>, _record=, > _attrs={'remote': , > _condition=None, _data=None, local=False, _annotations=None) at remote > 0x7fc5000902d0>, 'local': throwflag=throwflag@entry=0) at > /usr/src/debug/python2-2.7.15-4.fc28.x86_64/Python/ceval.c:3083 -- 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-1312) Remove cmake option USE_MEMORY_POOL
[ https://issues.apache.org/jira/browse/DISPATCH-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke resolved DISPATCH-1312. --- Resolution: Fixed Fix Version/s: 1.8.0 Fixed at Commit 9500b4 > Remove cmake option USE_MEMORY_POOL > --- > > Key: DISPATCH-1312 > URL: https://issues.apache.org/jira/browse/DISPATCH-1312 > Project: Qpid Dispatch > Issue Type: Bug > Components: Tools >Affects Versions: 1.6.0 > Reporter: Chuck Rolke >Assignee: Chuck Rolke >Priority: Major > Fix For: 1.8.0 > > > Memory pool must be ON and is no longer optional. -- 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] [Assigned] (PROTON-2039) Python listener.close leaves socket in time_wait
[ https://issues.apache.org/jira/browse/PROTON-2039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke reassigned PROTON-2039: --- Assignee: Chuck Rolke > Python listener.close leaves socket in time_wait > > > Key: PROTON-2039 > URL: https://issues.apache.org/jira/browse/PROTON-2039 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: proton-c-0.27.1 > Environment: Fedora 29, python 3.7.3 > Fedora 28, python 2.7.15 >Reporter: Chuck Rolke >Assignee: Chuck Rolke >Priority: Major > Attachments: PROTON-2039.patch > > > To demonstrate: execute python/examples/helloworld_direct.py two times within > a few seconds. The first time works and the second time fails with an > 'Address already in use' error. > The expectation is that this program can be run many times in quick > succession. > > {code:java} > (M=713c3 ?7) chug@unused examples> pwd > /home/chug/git/qpid-proton/python/examples > (M=713c3 ?7) chug@unused examples> ./helloworld_direct.py > Hello World! > (M=713c3 ?7) chug@unused examples> ./helloworld_direct.py > Traceback (most recent call last): > File "./helloworld_direct.py", line 48, in > Container(HelloWorld("localhost:/examples")).run() > File "/opt/local/lib64/proton/bindings/python/proton/_reactor.py", line > 181, in run > while self.process(): pass > File "/opt/local/lib64/proton/bindings/python/proton/_reactor.py", line > 238, in process > event.dispatch(handler) > File "/opt/local/lib64/proton/bindings/python/proton/_events.py", line 138, > in dispatch > self.dispatch(h, type) > File "/opt/local/lib64/proton/bindings/python/proton/_events.py", line 135, > in dispatch > _dispatch(handler, type.method, self) > File "/opt/local/lib64/proton/bindings/python/proton/_events.py", line 115, > in _dispatch > m(*args) > File "/opt/local/lib64/proton/bindings/python/proton/_handlers.py", line > 476, in on_reactor_init > self.on_start(event) > File "./helloworld_direct.py", line 32, in on_start > self.acceptor = event.container.listen(self.url) > File "/opt/local/lib64/proton/bindings/python/proton/_reactor.py", line > 1166, in listen > acceptor = self.acceptor(url.host, url.port) > File "/opt/local/lib64/proton/bindings/python/proton/_reactor.py", line > 304, in acceptor > a = Acceptor(self, unicode2utf8(host), int(port), impl) > File "/opt/local/lib64/proton/bindings/python/proton/_reactor.py", line > 678, in __init__ > sock = IO.listen(host, port) > File "/opt/local/lib64/proton/bindings/python/proton/_io.py", line 46, in > listen > s.bind((host, port)) > OSError: [Errno 98] Address already in use > 1 (M=713c3 ?7) chug@unused examples> ss -t -a -n | grep > TIME-WAIT 0 0 127.0.0.1: 127.0.0.1:42648 > > {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] [Resolved] (DISPATCH-1324) [tools] Scraper uses deprecated cgi.escape function
[ https://issues.apache.org/jira/browse/DISPATCH-1324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke resolved DISPATCH-1324. --- Resolution: Fixed Fixed at Commit ed1deb5 > [tools] Scraper uses deprecated cgi.escape function > --- > > Key: DISPATCH-1324 > URL: https://issues.apache.org/jira/browse/DISPATCH-1324 > Project: Qpid Dispatch > Issue Type: Bug > Components: Tools >Affects Versions: 1.7.0 > Reporter: Chuck Rolke >Assignee: Chuck Rolke >Priority: Major > Fix For: 1.8.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] [Updated] (PROTON-2039) Python listener.close leaves socket in time_wait
[ https://issues.apache.org/jira/browse/PROTON-2039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke updated PROTON-2039: Summary: Python listener.close leaves socket in time_wait (was: Python listener.close does not close socket) > Python listener.close leaves socket in time_wait > > > Key: PROTON-2039 > URL: https://issues.apache.org/jira/browse/PROTON-2039 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: proton-c-0.27.1 > Environment: Fedora 29, python 3.7.3 > Fedora 28, python 2.7.15 >Reporter: Chuck Rolke >Priority: Major > Attachments: PROTON-2039.patch > > > To demonstrate: execute python/examples/helloworld_direct.py two times within > a few seconds. The first time works and the second time fails with an > 'Address already in use' error. > The expectation is that this program can be run many times in quick > succession. > > {code:java} > (M=713c3 ?7) chug@unused examples> pwd > /home/chug/git/qpid-proton/python/examples > (M=713c3 ?7) chug@unused examples> ./helloworld_direct.py > Hello World! > (M=713c3 ?7) chug@unused examples> ./helloworld_direct.py > Traceback (most recent call last): > File "./helloworld_direct.py", line 48, in > Container(HelloWorld("localhost:/examples")).run() > File "/opt/local/lib64/proton/bindings/python/proton/_reactor.py", line > 181, in run > while self.process(): pass > File "/opt/local/lib64/proton/bindings/python/proton/_reactor.py", line > 238, in process > event.dispatch(handler) > File "/opt/local/lib64/proton/bindings/python/proton/_events.py", line 138, > in dispatch > self.dispatch(h, type) > File "/opt/local/lib64/proton/bindings/python/proton/_events.py", line 135, > in dispatch > _dispatch(handler, type.method, self) > File "/opt/local/lib64/proton/bindings/python/proton/_events.py", line 115, > in _dispatch > m(*args) > File "/opt/local/lib64/proton/bindings/python/proton/_handlers.py", line > 476, in on_reactor_init > self.on_start(event) > File "./helloworld_direct.py", line 32, in on_start > self.acceptor = event.container.listen(self.url) > File "/opt/local/lib64/proton/bindings/python/proton/_reactor.py", line > 1166, in listen > acceptor = self.acceptor(url.host, url.port) > File "/opt/local/lib64/proton/bindings/python/proton/_reactor.py", line > 304, in acceptor > a = Acceptor(self, unicode2utf8(host), int(port), impl) > File "/opt/local/lib64/proton/bindings/python/proton/_reactor.py", line > 678, in __init__ > sock = IO.listen(host, port) > File "/opt/local/lib64/proton/bindings/python/proton/_io.py", line 46, in > listen > s.bind((host, port)) > OSError: [Errno 98] Address already in use > 1 (M=713c3 ?7) chug@unused examples> ss -t -a -n | grep > TIME-WAIT 0 0 127.0.0.1: 127.0.0.1:42648 > > {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] [Updated] (PROTON-2039) Python listener.close does not close socket
[ https://issues.apache.org/jira/browse/PROTON-2039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke updated PROTON-2039: Attachment: (was: PROTON-2039.patch) > Python listener.close does not close socket > --- > > Key: PROTON-2039 > URL: https://issues.apache.org/jira/browse/PROTON-2039 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: proton-c-0.27.1 > Environment: Fedora 29, python 3.7.3 > Fedora 28, python 2.7.15 >Reporter: Chuck Rolke >Priority: Major > Attachments: PROTON-2039.patch > > > To demonstrate: execute python/examples/helloworld_direct.py two times within > a few seconds. The first time works and the second time fails with an > 'Address already in use' error. > The expectation is that this program can be run many times in quick > succession. > > {code:java} > (M=713c3 ?7) chug@unused examples> pwd > /home/chug/git/qpid-proton/python/examples > (M=713c3 ?7) chug@unused examples> ./helloworld_direct.py > Hello World! > (M=713c3 ?7) chug@unused examples> ./helloworld_direct.py > Traceback (most recent call last): > File "./helloworld_direct.py", line 48, in > Container(HelloWorld("localhost:/examples")).run() > File "/opt/local/lib64/proton/bindings/python/proton/_reactor.py", line > 181, in run > while self.process(): pass > File "/opt/local/lib64/proton/bindings/python/proton/_reactor.py", line > 238, in process > event.dispatch(handler) > File "/opt/local/lib64/proton/bindings/python/proton/_events.py", line 138, > in dispatch > self.dispatch(h, type) > File "/opt/local/lib64/proton/bindings/python/proton/_events.py", line 135, > in dispatch > _dispatch(handler, type.method, self) > File "/opt/local/lib64/proton/bindings/python/proton/_events.py", line 115, > in _dispatch > m(*args) > File "/opt/local/lib64/proton/bindings/python/proton/_handlers.py", line > 476, in on_reactor_init > self.on_start(event) > File "./helloworld_direct.py", line 32, in on_start > self.acceptor = event.container.listen(self.url) > File "/opt/local/lib64/proton/bindings/python/proton/_reactor.py", line > 1166, in listen > acceptor = self.acceptor(url.host, url.port) > File "/opt/local/lib64/proton/bindings/python/proton/_reactor.py", line > 304, in acceptor > a = Acceptor(self, unicode2utf8(host), int(port), impl) > File "/opt/local/lib64/proton/bindings/python/proton/_reactor.py", line > 678, in __init__ > sock = IO.listen(host, port) > File "/opt/local/lib64/proton/bindings/python/proton/_io.py", line 46, in > listen > s.bind((host, port)) > OSError: [Errno 98] Address already in use > 1 (M=713c3 ?7) chug@unused examples> ss -t -a -n | grep > TIME-WAIT 0 0 127.0.0.1: 127.0.0.1:42648 > > {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] [Updated] (PROTON-2039) Python listener.close does not close socket
[ https://issues.apache.org/jira/browse/PROTON-2039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke updated PROTON-2039: Attachment: PROTON-2039.patch > Python listener.close does not close socket > --- > > Key: PROTON-2039 > URL: https://issues.apache.org/jira/browse/PROTON-2039 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: proton-c-0.27.1 > Environment: Fedora 29, python 3.7.3 > Fedora 28, python 2.7.15 >Reporter: Chuck Rolke >Priority: Major > Attachments: PROTON-2039.patch > > > To demonstrate: execute python/examples/helloworld_direct.py two times within > a few seconds. The first time works and the second time fails with an > 'Address already in use' error. > The expectation is that this program can be run many times in quick > succession. > > {code:java} > (M=713c3 ?7) chug@unused examples> pwd > /home/chug/git/qpid-proton/python/examples > (M=713c3 ?7) chug@unused examples> ./helloworld_direct.py > Hello World! > (M=713c3 ?7) chug@unused examples> ./helloworld_direct.py > Traceback (most recent call last): > File "./helloworld_direct.py", line 48, in > Container(HelloWorld("localhost:/examples")).run() > File "/opt/local/lib64/proton/bindings/python/proton/_reactor.py", line > 181, in run > while self.process(): pass > File "/opt/local/lib64/proton/bindings/python/proton/_reactor.py", line > 238, in process > event.dispatch(handler) > File "/opt/local/lib64/proton/bindings/python/proton/_events.py", line 138, > in dispatch > self.dispatch(h, type) > File "/opt/local/lib64/proton/bindings/python/proton/_events.py", line 135, > in dispatch > _dispatch(handler, type.method, self) > File "/opt/local/lib64/proton/bindings/python/proton/_events.py", line 115, > in _dispatch > m(*args) > File "/opt/local/lib64/proton/bindings/python/proton/_handlers.py", line > 476, in on_reactor_init > self.on_start(event) > File "./helloworld_direct.py", line 32, in on_start > self.acceptor = event.container.listen(self.url) > File "/opt/local/lib64/proton/bindings/python/proton/_reactor.py", line > 1166, in listen > acceptor = self.acceptor(url.host, url.port) > File "/opt/local/lib64/proton/bindings/python/proton/_reactor.py", line > 304, in acceptor > a = Acceptor(self, unicode2utf8(host), int(port), impl) > File "/opt/local/lib64/proton/bindings/python/proton/_reactor.py", line > 678, in __init__ > sock = IO.listen(host, port) > File "/opt/local/lib64/proton/bindings/python/proton/_io.py", line 46, in > listen > s.bind((host, port)) > OSError: [Errno 98] Address already in use > 1 (M=713c3 ?7) chug@unused examples> ss -t -a -n | grep > TIME-WAIT 0 0 127.0.0.1: 127.0.0.1:42648 > > {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] (PROTON-2039) Python listener.close does not close socket
[ https://issues.apache.org/jira/browse/PROTON-2039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16831898#comment-16831898 ] Chuck Rolke commented on PROTON-2039: - Setting socket option SO_REUSEADDR along with TCP_NODELAY resolves the issue. See PROTON-2039.patch. > Python listener.close does not close socket > --- > > Key: PROTON-2039 > URL: https://issues.apache.org/jira/browse/PROTON-2039 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: proton-c-0.27.1 > Environment: Fedora 29, python 3.7.3 > Fedora 28, python 2.7.15 >Reporter: Chuck Rolke >Priority: Major > Attachments: PROTON-2039.patch > > > To demonstrate: execute python/examples/helloworld_direct.py two times within > a few seconds. The first time works and the second time fails with an > 'Address already in use' error. > The expectation is that this program can be run many times in quick > succession. > > {code:java} > (M=713c3 ?7) chug@unused examples> pwd > /home/chug/git/qpid-proton/python/examples > (M=713c3 ?7) chug@unused examples> ./helloworld_direct.py > Hello World! > (M=713c3 ?7) chug@unused examples> ./helloworld_direct.py > Traceback (most recent call last): > File "./helloworld_direct.py", line 48, in > Container(HelloWorld("localhost:/examples")).run() > File "/opt/local/lib64/proton/bindings/python/proton/_reactor.py", line > 181, in run > while self.process(): pass > File "/opt/local/lib64/proton/bindings/python/proton/_reactor.py", line > 238, in process > event.dispatch(handler) > File "/opt/local/lib64/proton/bindings/python/proton/_events.py", line 138, > in dispatch > self.dispatch(h, type) > File "/opt/local/lib64/proton/bindings/python/proton/_events.py", line 135, > in dispatch > _dispatch(handler, type.method, self) > File "/opt/local/lib64/proton/bindings/python/proton/_events.py", line 115, > in _dispatch > m(*args) > File "/opt/local/lib64/proton/bindings/python/proton/_handlers.py", line > 476, in on_reactor_init > self.on_start(event) > File "./helloworld_direct.py", line 32, in on_start > self.acceptor = event.container.listen(self.url) > File "/opt/local/lib64/proton/bindings/python/proton/_reactor.py", line > 1166, in listen > acceptor = self.acceptor(url.host, url.port) > File "/opt/local/lib64/proton/bindings/python/proton/_reactor.py", line > 304, in acceptor > a = Acceptor(self, unicode2utf8(host), int(port), impl) > File "/opt/local/lib64/proton/bindings/python/proton/_reactor.py", line > 678, in __init__ > sock = IO.listen(host, port) > File "/opt/local/lib64/proton/bindings/python/proton/_io.py", line 46, in > listen > s.bind((host, port)) > OSError: [Errno 98] Address already in use > 1 (M=713c3 ?7) chug@unused examples> ss -t -a -n | grep > TIME-WAIT 0 0 127.0.0.1: 127.0.0.1:42648 > > {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] [Updated] (PROTON-2039) Python listener.close does not close socket
[ https://issues.apache.org/jira/browse/PROTON-2039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke updated PROTON-2039: Attachment: PROTON-2039.patch > Python listener.close does not close socket > --- > > Key: PROTON-2039 > URL: https://issues.apache.org/jira/browse/PROTON-2039 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: proton-c-0.27.1 > Environment: Fedora 29, python 3.7.3 > Fedora 28, python 2.7.15 >Reporter: Chuck Rolke >Priority: Major > Attachments: PROTON-2039.patch > > > To demonstrate: execute python/examples/helloworld_direct.py two times within > a few seconds. The first time works and the second time fails with an > 'Address already in use' error. > The expectation is that this program can be run many times in quick > succession. > > {code:java} > (M=713c3 ?7) chug@unused examples> pwd > /home/chug/git/qpid-proton/python/examples > (M=713c3 ?7) chug@unused examples> ./helloworld_direct.py > Hello World! > (M=713c3 ?7) chug@unused examples> ./helloworld_direct.py > Traceback (most recent call last): > File "./helloworld_direct.py", line 48, in > Container(HelloWorld("localhost:/examples")).run() > File "/opt/local/lib64/proton/bindings/python/proton/_reactor.py", line > 181, in run > while self.process(): pass > File "/opt/local/lib64/proton/bindings/python/proton/_reactor.py", line > 238, in process > event.dispatch(handler) > File "/opt/local/lib64/proton/bindings/python/proton/_events.py", line 138, > in dispatch > self.dispatch(h, type) > File "/opt/local/lib64/proton/bindings/python/proton/_events.py", line 135, > in dispatch > _dispatch(handler, type.method, self) > File "/opt/local/lib64/proton/bindings/python/proton/_events.py", line 115, > in _dispatch > m(*args) > File "/opt/local/lib64/proton/bindings/python/proton/_handlers.py", line > 476, in on_reactor_init > self.on_start(event) > File "./helloworld_direct.py", line 32, in on_start > self.acceptor = event.container.listen(self.url) > File "/opt/local/lib64/proton/bindings/python/proton/_reactor.py", line > 1166, in listen > acceptor = self.acceptor(url.host, url.port) > File "/opt/local/lib64/proton/bindings/python/proton/_reactor.py", line > 304, in acceptor > a = Acceptor(self, unicode2utf8(host), int(port), impl) > File "/opt/local/lib64/proton/bindings/python/proton/_reactor.py", line > 678, in __init__ > sock = IO.listen(host, port) > File "/opt/local/lib64/proton/bindings/python/proton/_io.py", line 46, in > listen > s.bind((host, port)) > OSError: [Errno 98] Address already in use > 1 (M=713c3 ?7) chug@unused examples> ss -t -a -n | grep > TIME-WAIT 0 0 127.0.0.1: 127.0.0.1:42648 > > {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] [Created] (PROTON-2039) Python listener.close does not close socket
Chuck Rolke created PROTON-2039: --- Summary: Python listener.close does not close socket Key: PROTON-2039 URL: https://issues.apache.org/jira/browse/PROTON-2039 Project: Qpid Proton Issue Type: Bug Components: python-binding Affects Versions: proton-c-0.27.1 Environment: Fedora 29, python 3.7.3 Fedora 28, python 2.7.15 Reporter: Chuck Rolke To demonstrate: execute python/examples/helloworld_direct.py two times within a few seconds. The first time works and the second time fails with an 'Address already in use' error. The expectation is that this program can be run many times in quick succession. {code:java} (M=713c3 ?7) chug@unused examples> pwd /home/chug/git/qpid-proton/python/examples (M=713c3 ?7) chug@unused examples> ./helloworld_direct.py Hello World! (M=713c3 ?7) chug@unused examples> ./helloworld_direct.py Traceback (most recent call last): File "./helloworld_direct.py", line 48, in Container(HelloWorld("localhost:/examples")).run() File "/opt/local/lib64/proton/bindings/python/proton/_reactor.py", line 181, in run while self.process(): pass File "/opt/local/lib64/proton/bindings/python/proton/_reactor.py", line 238, in process event.dispatch(handler) File "/opt/local/lib64/proton/bindings/python/proton/_events.py", line 138, in dispatch self.dispatch(h, type) File "/opt/local/lib64/proton/bindings/python/proton/_events.py", line 135, in dispatch _dispatch(handler, type.method, self) File "/opt/local/lib64/proton/bindings/python/proton/_events.py", line 115, in _dispatch m(*args) File "/opt/local/lib64/proton/bindings/python/proton/_handlers.py", line 476, in on_reactor_init self.on_start(event) File "./helloworld_direct.py", line 32, in on_start self.acceptor = event.container.listen(self.url) File "/opt/local/lib64/proton/bindings/python/proton/_reactor.py", line 1166, in listen acceptor = self.acceptor(url.host, url.port) File "/opt/local/lib64/proton/bindings/python/proton/_reactor.py", line 304, in acceptor a = Acceptor(self, unicode2utf8(host), int(port), impl) File "/opt/local/lib64/proton/bindings/python/proton/_reactor.py", line 678, in __init__ sock = IO.listen(host, port) File "/opt/local/lib64/proton/bindings/python/proton/_io.py", line 46, in listen s.bind((host, port)) OSError: [Errno 98] Address already in use 1 (M=713c3 ?7) chug@unused examples> ss -t -a -n | grep TIME-WAIT 0 0 127.0.0.1: 127.0.0.1:42648 {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] [Resolved] (DISPATCH-1329) Edge router system test needs skip test convenience switches
[ https://issues.apache.org/jira/browse/DISPATCH-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke resolved DISPATCH-1329. --- Resolution: Fixed Assignee: Chuck Rolke Fix Version/s: 1.8.0 Commit 797f3bd > Edge router system test needs skip test convenience switches > > > Key: DISPATCH-1329 > URL: https://issues.apache.org/jira/browse/DISPATCH-1329 > Project: Qpid Dispatch > Issue Type: Improvement > Reporter: Chuck Rolke > Assignee: Chuck Rolke >Priority: Major > Fix For: 1.8.0 > > > See system_tests_topology_disposition.py cls.skip and the application to > skipTest for a model. -- 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] [Reopened] (DISPATCH-1324) [tools] Scraper uses deprecated cgi.escape function
[ https://issues.apache.org/jira/browse/DISPATCH-1324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke reopened DISPATCH-1324: --- commit b1b17b did not work for all users > [tools] Scraper uses deprecated cgi.escape function > --- > > Key: DISPATCH-1324 > URL: https://issues.apache.org/jira/browse/DISPATCH-1324 > Project: Qpid Dispatch > Issue Type: Bug > Components: Tools >Affects Versions: 1.7.0 > Reporter: Chuck Rolke >Assignee: Chuck Rolke >Priority: Major > Fix For: 1.8.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] [Created] (DISPATCH-1329) Edge router system test needs skip test convenience switches
Chuck Rolke created DISPATCH-1329: - Summary: Edge router system test needs skip test convenience switches Key: DISPATCH-1329 URL: https://issues.apache.org/jira/browse/DISPATCH-1329 Project: Qpid Dispatch Issue Type: Improvement Reporter: Chuck Rolke See system_tests_topology_disposition.py cls.skip and the application to skipTest for a model. -- 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-1324) [tools] Scraper uses deprecated cgi.escape function
[ https://issues.apache.org/jira/browse/DISPATCH-1324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke resolved DISPATCH-1324. --- Resolution: Fixed Fixed at Commit b1b17b4 > [tools] Scraper uses deprecated cgi.escape function > --- > > Key: DISPATCH-1324 > URL: https://issues.apache.org/jira/browse/DISPATCH-1324 > Project: Qpid Dispatch > Issue Type: Bug > Components: Tools >Affects Versions: 1.7.0 > Reporter: Chuck Rolke >Assignee: Chuck Rolke >Priority: Major > Fix For: 1.8.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] (PROTON-2033) qpid-proton changes 0.27.x to master(9ff0a) break qpid-dispatch self test
[ https://issues.apache.org/jira/browse/PROTON-2033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke resolved PROTON-2033. - Resolution: Not A Bug Subtle timing changes exposed bug in qpid-dispatch mission code. > qpid-proton changes 0.27.x to master(9ff0a) break qpid-dispatch self test > - > > Key: PROTON-2033 > URL: https://issues.apache.org/jira/browse/PROTON-2033 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c, python-binding >Affects Versions: proton-c-0.28.0 > Environment: Fedora 29, python 3.7, proton and dispatch debug builds >Reporter: Chuck Rolke >Assignee: Andrew Stitcher >Priority: Major > > While cleaning up qpid-dispatch for a 1.6 follow-on release an intermittent > failure in one of the tests was exposed. Analysis of the failure is in > https://issues.apache.org/jira/browse/DISPATCH-1322 in an attached text > document > https://issues.apache.org/jira/secure/attachment/12965891/DISPATCH-1322-analysis.txt > Another part of the cleanup was fixing the failing test to better report what > went wrong. See https://issues.apache.org/jira/browse/DISPATCH-1318 > These issues happened using qpid-proton master @9ff0a. Temporarily the > qpid-proton version was reverted to branch 0.27.x @560ba. Using proton 0.27.x > branch the qpid-dispatch self test does not fail. It passed several thousand > times in a loop. Moving proton back to the master branch brought the dispatch > failures back. > From the qpid-dispatch perspective this issue is serious. If a receiver > detaches a link while a sender is sending to it then the sender may lose a > disposition. > No attempt yet has been made to bisect proton to see where the different > behavior starts showing up. That may be the next best avenue of research. > Another theory for the error is that qpid-dispatch has been mishandling links > all along. > To help expose the problem one may clone > [https://github.com/ChugR/qpid-dispatch] , or add it as a remote, and then > check out branch DISPATCH-1318-cwip. Test system_tests_edge_router has been > gutted to run only test_12 in a loop and to print details of the error(s). > {{ cd build}} > {{ make}} > {{ ctest -VV -R edge}} > > -- 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-1318) edge_router system test failing
[ https://issues.apache.org/jira/browse/DISPATCH-1318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke resolved DISPATCH-1318. --- Resolution: Fixed Fix Version/s: 1.8.0 Fixed at Commit 350a139 > edge_router system test failing > > > Key: DISPATCH-1318 > URL: https://issues.apache.org/jira/browse/DISPATCH-1318 > Project: Qpid Dispatch > Issue Type: Bug > Components: Tests >Affects Versions: 1.6.0 > Reporter: Chuck Rolke >Assignee: Chuck Rolke >Priority: Major > Fix For: 1.8.0 > > > {quote}{{0: > ==}} > {{50: FAIL: test_22_mobile_address_edge_sender_two_interior_receivers > (system_tests_edge_router.RouterTest)}} > {{50: > --}} > {{50: Traceback (most recent call last):}} > {{50: File > "/home/chug/git/qpid-dispatch/tests/system_tests_edge_router.py", line 451, > in test_22_mobile_address_edge_sender_two_interior_receivers}} > {{50: self.assertEqual(None, test.error)}} > {{50: AssertionError: None != 'Timeout Expired - n_sent=350 n_rcvd=300 [36 > chars]t_22'}} > \{{50: }} > {{50: > --}} > {{50: Ran 48 tests in 84.066s}} > \{{50: }} > {{50: FAILED (failures=1)}} > {{1/1 Test #50: system_tests_edge_router .***Failed 84.37 sec}} > {quote} > This test also suffers from the test framework eliding important text in the > error message: > 50: AssertionError: None != 'Timeout Expired - n_sent=350 n_rcvd=300 [36 > chars]t_22' > Seeing the *[36* chars] is a vital to the test showing what went wrong. -- 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-1327) Router stops forwarding multicast deliveries (large messages) to connected receivers after a receiver closes its connection
[ https://issues.apache.org/jira/browse/DISPATCH-1327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16827310#comment-16827310 ] Chuck Rolke commented on DISPATCH-1327: --- Test this again after master commit 39309ea3 which fixed a similar issue in DISPATCH-1322 > Router stops forwarding multicast deliveries (large messages) to connected > receivers after a receiver closes its connection > --- > > Key: DISPATCH-1327 > URL: https://issues.apache.org/jira/browse/DISPATCH-1327 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 1.7.0 >Reporter: Fernando Giorgetti >Priority: Major > > The problem can be observed running > *test_40_drop_rx_client_multicast_large_message*** from > *system_tests_edge_router*. > It does not happen all the time, but after some attempts it will fail and we > can observe receivers won't get all sent messages and then test times out. > Further info to be attached. -- This message was sent by Atlassian JIRA (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] (PROTON-2033) qpid-proton changes 0.27.x to master(9ff0a) break qpid-dispatch self test
[ https://issues.apache.org/jira/browse/PROTON-2033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16827294#comment-16827294 ] Chuck Rolke commented on PROTON-2033: - Working out the analysis proves that post-0.27 proton did not 'break dispatch self tests'. * Dispatch had a latent bug and some (presumably) proton timing changes exposed that bug. * Dispatch self tests were unprepared for the python receiver to get on_settled callbacks. That said, before dismissing this issue a discussion of the timing change and the on_settled callbacks is in order. h3. Test Overview For review, how did the test work? {code:java} +-+ ++ | INT.A | | EA1 | +---+ +---+ +---+ edge | +---+ +---+ | receiver |<--+ 21001 | | 21000 |<* | 21002 |<--+ sender | +---+ +---+ +---+ | +---+ +---+ | interior | | edge | +-+ ++ ^ ^ ^ CONN1 CONN2 CONN3 {code} From a single reactor container a proton python sender and receiver connect to two routers respectively. * The test injects some number of messages at the sender and verifies that they are all accepted. * Then the receiver is closed (connection stays open) and 50 messages are injected by the sender. * The expectation is that all the 50 messages are released. h3. Timing Change A significant change was measured between when the receiver client called receiver.close() and when the corresponding detach was received by INT.A port 21001. ||Time mS||0.27.x||master|| |run 1|3.2|14.5| |run 2|3.3|17.3| These timings are reflected in the self test behavior: * The 0.27.x code is "so fast" that it detaches the receiver before any of the messages in the 50-message storm get through INT.A. All of the messages are released by the router network. No messages were released or modified by the receiver. * The master branch is "so slow" that one or possibly up to a dozen messages are sent to the receiver by INT.A. Now the receiver is dealing with a receiver close in the face of incoming messages. Now some messages are seen as 'modified' by the sender and not just released. Is there an explanation for why the client response to the receiver.close() is so slow compared to 0.27.x? h3. Receiver on_settled callbacks These appear when the receiver is closing in the face of incoming messages. This may not be a new issue as dispatch self tests never had to deal with them before. If it *is* an new issue some consideration must be given for how existing clients (like dispatch self tests) must be modified to deal with them. > qpid-proton changes 0.27.x to master(9ff0a) break qpid-dispatch self test > - > > Key: PROTON-2033 > URL: https://issues.apache.org/jira/browse/PROTON-2033 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c, python-binding >Affects Versions: proton-c-0.28.0 > Environment: Fedora 29, python 3.7, proton and dispatch debug builds >Reporter: Chuck Rolke >Priority: Major > > While cleaning up qpid-dispatch for a 1.6 follow-on release an intermittent > failure in one of the tests was exposed. Analysis of the failure is in > https://issues.apache.org/jira/browse/DISPATCH-1322 in an attached text > document > https://issues.apache.org/jira/secure/attachment/12965891/DISPATCH-1322-analysis.txt > Another part of the cleanup was fixing the failing test to better report what > went wrong. See https://issues.apache.org/jira/browse/DISPATCH-1318 > These issues happened using qpid-proton master @9ff0a. Temporarily the > qpid-proton version was reverted to branch 0.27.x @560ba. Using proton 0.27.x > branch the qpid-dispatch self test does not fail. It passed several thousand > times in a loop. Moving proton back to the master branch brought the dispatch > failures back. > From the qpid-dispatch perspective this issue is serious. If a receiver > detaches a link while a sender is sending to it then the sender may lose a > disposition. > No attempt yet has been made to bisect proton to see where the different > behavior starts showing up. That may be the next best avenue of research. > Another theory for the error is that qpid-dispatch has been mishandling links > all along. > To help expose the problem one may clone > [https://github.com/ChugR/qpid-di
[jira] [Updated] (DISPATCH-1325) Sender connections to edge router that connect 'too soon' never get credit
[ https://issues.apache.org/jira/browse/DISPATCH-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke updated DISPATCH-1325: -- Attachment: DISPATCH-1325-test-hang.html > Sender connections to edge router that connect 'too soon' never get credit > -- > > Key: DISPATCH-1325 > URL: https://issues.apache.org/jira/browse/DISPATCH-1325 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 1.7.0 > Environment: Fedora 29, python 3.7 > Dispatch master of today. > Proton 0.27.x branch > Source code in repository [https://github.com/ChugR/qpid-dispatch] > branch crolke-DISPATCH-1322 > directory tools/DISPATCH-1322 > >Reporter: Chuck Rolke >Priority: Major > Attachments: DISPATCH-1325-test-hang.html > > > A stand-alone self test was extracted from system_tests_edge_router. Running > the test involves starting the routers and then running the client. If this > is repeated in a script then there must be a fairly long delay between > starting the routers and running the client. > If the delay is 6 seconds then the client sender seems to run fine every time. > If the delay is 4 seconds then the client sender routinely (half the time?) > fails to get an on_sendable event as no credit is ever issued by the edge > router. A protocol trace to be attached. > -- 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-1325) Sender connections to edge router that connect 'too soon' never get credit
Chuck Rolke created DISPATCH-1325: - Summary: Sender connections to edge router that connect 'too soon' never get credit Key: DISPATCH-1325 URL: https://issues.apache.org/jira/browse/DISPATCH-1325 Project: Qpid Dispatch Issue Type: Bug Affects Versions: 1.7.0 Environment: Fedora 29, python 3.7 Dispatch master of today. Proton 0.27.x branch Source code in repository [https://github.com/ChugR/qpid-dispatch] branch crolke-DISPATCH-1322 directory tools/DISPATCH-1322 Reporter: Chuck Rolke A stand-alone self test was extracted from system_tests_edge_router. Running the test involves starting the routers and then running the client. If this is repeated in a script then there must be a fairly long delay between starting the routers and running the client. If the delay is 6 seconds then the client sender seems to run fine every time. If the delay is 4 seconds then the client sender routinely (half the time?) fails to get an on_sendable event as no credit is ever issued by the edge router. A protocol trace to be attached. -- 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-1324) [tools] Scraper uses deprecated cgi.escape function
Chuck Rolke created DISPATCH-1324: - Summary: [tools] Scraper uses deprecated cgi.escape function Key: DISPATCH-1324 URL: https://issues.apache.org/jira/browse/DISPATCH-1324 Project: Qpid Dispatch Issue Type: Bug Components: Tools Affects Versions: 1.7.0 Reporter: Chuck Rolke Assignee: Chuck Rolke Fix For: 1.8.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] (DISPATCH-1322) Edge router drops disposition when remote receiver closes
[ https://issues.apache.org/jira/browse/DISPATCH-1322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16825455#comment-16825455 ] Chuck Rolke commented on DISPATCH-1322: --- A standalone test program is available at remote [https://github.com/ChugR/qpid-dispatch] branch crolke-DISPATCH-1322 files tools/DISPATCH-1322 > Edge router drops disposition when remote receiver closes > - > > Key: DISPATCH-1322 > URL: https://issues.apache.org/jira/browse/DISPATCH-1322 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 1.6.0 >Reporter: Chuck Rolke >Priority: Major > Attachments: DISPATCH-1322-analysis.txt > > > The test is available in system_tests_edge_router. > The analysis is attached as a file. > -- 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-1230) System test failing with OpenSSL >= 1.1 - system_tests_ssl
[ https://issues.apache.org/jira/browse/DISPATCH-1230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke resolved DISPATCH-1230. --- Resolution: Fixed Fix Version/s: 1.8.0 Now detects OpenSSL version from CLI, Python, and Proton to skip or to run tests as appropriate. > System test failing with OpenSSL >= 1.1 - system_tests_ssl > -- > > Key: DISPATCH-1230 > URL: https://issues.apache.org/jira/browse/DISPATCH-1230 > Project: Qpid Dispatch > Issue Type: Bug > Components: Tests >Affects Versions: 1.6.0 >Reporter: Fernando Giorgetti >Assignee: Fernando Giorgetti >Priority: Major > Fix For: 1.8.0 > > > A system test is failing when OpenSSL >= 1.1 is installed on running system: > system_tests_ssl. -- 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] (PROTON-2033) qpid-proton changes 0.27.x to master(9ff0a) break qpid-dispatch self test
[ https://issues.apache.org/jira/browse/PROTON-2033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16821447#comment-16821447 ] Chuck Rolke commented on PROTON-2033: - It looks like the python receive client starts getting confused during shutdown in the face of incoming traffic. After further instrumenting the test a run will fail: {code:java} 50: ??? Receiver on_settled. remote: 0, local: RELEASED 50: Bad sender settlement: 0, n_accepted: 300, n_rel_or_mod: 0 50: MobileAddressTest fail: Timeout Expired 50: address test_12_19 50: n_sent = 350. Expected total:350 normal=300, extra=50 50: n_rcvd = 300. Expected 300 50: n_accepted = 300. Expected 300 50: n_rel_or_mod = 49. Expected 50 {code} * The receiver should not receive settlements. A single receive settlement was processed. * The sender settlement of 0 arises at the test expects all settlements to be sender settlements and this one was not. * The test failed because the sender is missing one settlement. The test code is available in branch DISPATCH-1318-2, repo [https://github.com/ChugR/qpid-dispatch.git] The test fails with command *ctest -VV -R edge* > qpid-proton changes 0.27.x to master(9ff0a) break qpid-dispatch self test > - > > Key: PROTON-2033 > URL: https://issues.apache.org/jira/browse/PROTON-2033 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c, python-binding >Affects Versions: proton-c-0.28.0 > Environment: Fedora 29, python 3.7, proton and dispatch debug builds >Reporter: Chuck Rolke >Priority: Major > > While cleaning up qpid-dispatch for a 1.6 follow-on release an intermittent > failure in one of the tests was exposed. Analysis of the failure is in > https://issues.apache.org/jira/browse/DISPATCH-1322 in an attached text > document > https://issues.apache.org/jira/secure/attachment/12965891/DISPATCH-1322-analysis.txt > Another part of the cleanup was fixing the failing test to better report what > went wrong. See https://issues.apache.org/jira/browse/DISPATCH-1318 > These issues happened using qpid-proton master @9ff0a. Temporarily the > qpid-proton version was reverted to branch 0.27.x @560ba. Using proton 0.27.x > branch the qpid-dispatch self test does not fail. It passed several thousand > times in a loop. Moving proton back to the master branch brought the dispatch > failures back. > From the qpid-dispatch perspective this issue is serious. If a receiver > detaches a link while a sender is sending to it then the sender may lose a > disposition. > No attempt yet has been made to bisect proton to see where the different > behavior starts showing up. That may be the next best avenue of research. > Another theory for the error is that qpid-dispatch has been mishandling links > all along. > To help expose the problem one may clone > [https://github.com/ChugR/qpid-dispatch] , or add it as a remote, and then > check out branch DISPATCH-1318-cwip. Test system_tests_edge_router has been > gutted to run only test_12 in a loop and to print details of the error(s). > {{ cd build}} > {{ make}} > {{ ctest -VV -R edge}} > > -- 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] (PROTON-2033) qpid-proton changes 0.27.x to master(9ff0a) break qpid-dispatch self test
[ https://issues.apache.org/jira/browse/PROTON-2033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16819486#comment-16819486 ] Chuck Rolke commented on PROTON-2033: - Things start failing at commit 1d6e14 {{PROTON-1992: [Python] Remove dependency on Proton Reactor API 2019-01-15 16:41:57}} Immediately before this commit the Dispatch self test runs thousands of passes OK. After this commit the tests fail after at most a few hundred passes. This is with Python 3.7.2 on Fedora 29 > qpid-proton changes 0.27.x to master(9ff0a) break qpid-dispatch self test > - > > Key: PROTON-2033 > URL: https://issues.apache.org/jira/browse/PROTON-2033 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c, python-binding >Affects Versions: proton-c-0.28.0 > Environment: Fedora 29, python 3.7, proton and dispatch debug builds >Reporter: Chuck Rolke >Priority: Major > > While cleaning up qpid-dispatch for a 1.6 follow-on release an intermittent > failure in one of the tests was exposed. Analysis of the failure is in > https://issues.apache.org/jira/browse/DISPATCH-1322 in an attached text > document > https://issues.apache.org/jira/secure/attachment/12965891/DISPATCH-1322-analysis.txt > Another part of the cleanup was fixing the failing test to better report what > went wrong. See https://issues.apache.org/jira/browse/DISPATCH-1318 > These issues happened using qpid-proton master @9ff0a. Temporarily the > qpid-proton version was reverted to branch 0.27.x @560ba. Using proton 0.27.x > branch the qpid-dispatch self test does not fail. It passed several thousand > times in a loop. Moving proton back to the master branch brought the dispatch > failures back. > From the qpid-dispatch perspective this issue is serious. If a receiver > detaches a link while a sender is sending to it then the sender may lose a > disposition. > No attempt yet has been made to bisect proton to see where the different > behavior starts showing up. That may be the next best avenue of research. > Another theory for the error is that qpid-dispatch has been mishandling links > all along. > To help expose the problem one may clone > [https://github.com/ChugR/qpid-dispatch] , or add it as a remote, and then > check out branch DISPATCH-1318-cwip. Test system_tests_edge_router has been > gutted to run only test_12 in a loop and to print details of the error(s). > {{ cd build}} > {{ make}} > {{ ctest -VV -R edge}} > > -- 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] (PROTON-2033) qpid-proton changes 0.27.x to master(9ff0a) break qpid-dispatch self test
Chuck Rolke created PROTON-2033: --- Summary: qpid-proton changes 0.27.x to master(9ff0a) break qpid-dispatch self test Key: PROTON-2033 URL: https://issues.apache.org/jira/browse/PROTON-2033 Project: Qpid Proton Issue Type: Bug Components: proton-c, python-binding Affects Versions: proton-c-0.28.0 Environment: Fedora 29, python 3.7, proton and dispatch debug builds Reporter: Chuck Rolke While cleaning up qpid-dispatch for a 1.6 follow-on release an intermittent failure in one of the tests was exposed. Analysis of the failure is in https://issues.apache.org/jira/browse/DISPATCH-1322 in an attached text document https://issues.apache.org/jira/secure/attachment/12965891/DISPATCH-1322-analysis.txt Another part of the cleanup was fixing the failing test to better report what went wrong. See https://issues.apache.org/jira/browse/DISPATCH-1318 These issues happened using qpid-proton master @9ff0a. Temporarily the qpid-proton version was reverted to branch 0.27.x @560ba. Using proton 0.27.x branch the qpid-dispatch self test does not fail. It passed several thousand times in a loop. Moving proton back to the master branch brought the dispatch failures back. >From the qpid-dispatch perspective this issue is serious. If a receiver >detaches a link while a sender is sending to it then the sender may lose a >disposition. No attempt yet has been made to bisect proton to see where the different behavior starts showing up. That may be the next best avenue of research. Another theory for the error is that qpid-dispatch has been mishandling links all along. To help expose the problem one may clone [https://github.com/ChugR/qpid-dispatch] , or add it as a remote, and then check out branch DISPATCH-1318-cwip. Test system_tests_edge_router has been gutted to run only test_12 in a loop and to print details of the error(s). {{ cd build}} {{ make}} {{ ctest -VV -R edge}} -- 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] [Updated] (DISPATCH-1322) Edge router drops disposition when remote receiver closes
[ https://issues.apache.org/jira/browse/DISPATCH-1322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke updated DISPATCH-1322: -- Attachment: (was: DISPATCH-1322-analysis.txt) > Edge router drops disposition when remote receiver closes > - > > Key: DISPATCH-1322 > URL: https://issues.apache.org/jira/browse/DISPATCH-1322 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 1.6.0 > Reporter: Chuck Rolke >Priority: Major > Attachments: DISPATCH-1322-analysis.txt > > > The test is available in system_tests_edge_router. > The analysis is attached as a file. > -- 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] [Updated] (DISPATCH-1322) Edge router drops disposition when remote receiver closes
[ https://issues.apache.org/jira/browse/DISPATCH-1322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke updated DISPATCH-1322: -- Attachment: DISPATCH-1322-analysis.txt > Edge router drops disposition when remote receiver closes > - > > Key: DISPATCH-1322 > URL: https://issues.apache.org/jira/browse/DISPATCH-1322 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 1.6.0 > Reporter: Chuck Rolke >Priority: Major > Attachments: DISPATCH-1322-analysis.txt > > > The test is available in system_tests_edge_router. > The analysis is attached as a file. > -- 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] [Updated] (DISPATCH-1322) Edge router drops disposition when remote receiver closes
[ https://issues.apache.org/jira/browse/DISPATCH-1322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke updated DISPATCH-1322: -- Attachment: DISPATCH-1322-analysis.txt > Edge router drops disposition when remote receiver closes > - > > Key: DISPATCH-1322 > URL: https://issues.apache.org/jira/browse/DISPATCH-1322 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 1.6.0 > Reporter: Chuck Rolke >Priority: Major > Attachments: DISPATCH-1322-analysis.txt > > > The test is available in system_tests_edge_router. > The analysis is attached as a file. > -- 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-1322) Edge router drops disposition when remote receiver closes
Chuck Rolke created DISPATCH-1322: - Summary: Edge router drops disposition when remote receiver closes Key: DISPATCH-1322 URL: https://issues.apache.org/jira/browse/DISPATCH-1322 Project: Qpid Dispatch Issue Type: Bug Components: Routing Engine Affects Versions: 1.6.0 Reporter: Chuck Rolke The test is available in system_tests_edge_router. The analysis is attached as a file. -- 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-1318) edge_router system test failing
[ https://issues.apache.org/jira/browse/DISPATCH-1318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16817484#comment-16817484 ] Chuck Rolke commented on DISPATCH-1318: --- This Jira will focus on the small issues: * dispositions of 'modified' are not counted * Error messages are truncated by the test framework > edge_router system test failing > > > Key: DISPATCH-1318 > URL: https://issues.apache.org/jira/browse/DISPATCH-1318 > Project: Qpid Dispatch > Issue Type: Bug > Components: Tests >Affects Versions: 1.6.0 >Reporter: Chuck Rolke >Assignee: Chuck Rolke >Priority: Major > > {quote}{{0: > ==}} > {{50: FAIL: test_22_mobile_address_edge_sender_two_interior_receivers > (system_tests_edge_router.RouterTest)}} > {{50: > --}} > {{50: Traceback (most recent call last):}} > {{50: File > "/home/chug/git/qpid-dispatch/tests/system_tests_edge_router.py", line 451, > in test_22_mobile_address_edge_sender_two_interior_receivers}} > {{50: self.assertEqual(None, test.error)}} > {{50: AssertionError: None != 'Timeout Expired - n_sent=350 n_rcvd=300 [36 > chars]t_22'}} > \{{50: }} > {{50: > --}} > {{50: Ran 48 tests in 84.066s}} > \{{50: }} > {{50: FAILED (failures=1)}} > {{1/1 Test #50: system_tests_edge_router .***Failed 84.37 sec}} > {quote} > This test also suffers from the test framework eliding important text in the > error message: > 50: AssertionError: None != 'Timeout Expired - n_sent=350 n_rcvd=300 [36 > chars]t_22' > Seeing the *[36* chars] is a vital to the test showing what went wrong. -- 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] [Updated] (DISPATCH-1318) edge_router system test failing
[ https://issues.apache.org/jira/browse/DISPATCH-1318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke updated DISPATCH-1318: -- Description: {quote}{{0: ==}} {{50: FAIL: test_22_mobile_address_edge_sender_two_interior_receivers (system_tests_edge_router.RouterTest)}} {{50: --}} {{50: Traceback (most recent call last):}} {{50: File "/home/chug/git/qpid-dispatch/tests/system_tests_edge_router.py", line 451, in test_22_mobile_address_edge_sender_two_interior_receivers}} {{50: self.assertEqual(None, test.error)}} {{50: AssertionError: None != 'Timeout Expired - n_sent=350 n_rcvd=300 [36 chars]t_22'}} \{{50: }} {{50: --}} {{50: Ran 48 tests in 84.066s}} \{{50: }} {{50: FAILED (failures=1)}} {{1/1 Test #50: system_tests_edge_router .***Failed 84.37 sec}} {quote} This test also suffers from the test framework eliding important text in the error message: 50: AssertionError: None != 'Timeout Expired - n_sent=350 n_rcvd=300 [36 chars]t_22' Seeing the *[36* chars] is a vital to the test showing what went wrong. was: {quote}{{0: ==}} {{50: FAIL: test_22_mobile_address_edge_sender_two_interior_receivers (system_tests_edge_router.RouterTest)}} {{50: --}} {{50: Traceback (most recent call last):}} {{50: File "/home/chug/git/qpid-dispatch/tests/system_tests_edge_router.py", line 451, in test_22_mobile_address_edge_sender_two_interior_receivers}} {{50: self.assertEqual(None, test.error)}} {{50: AssertionError: None != 'Timeout Expired - n_sent=350 n_rcvd=300 [36 chars]t_22'}} {{50: }} {{50: --}} {{50: Ran 48 tests in 84.066s}} {{50: }} {{50: FAILED (failures=1)}} {{1/1 Test #50: system_tests_edge_router .***Failed 84.37 sec}}{quote} Summary: edge_router system test failing (was: edge_router system test failing - timeout with n_sent too big) > edge_router system test failing > > > Key: DISPATCH-1318 > URL: https://issues.apache.org/jira/browse/DISPATCH-1318 > Project: Qpid Dispatch > Issue Type: Bug > Components: Tests >Affects Versions: 1.6.0 >Reporter: Chuck Rolke >Assignee: Chuck Rolke >Priority: Major > > {quote}{{0: > ==}} > {{50: FAIL: test_22_mobile_address_edge_sender_two_interior_receivers > (system_tests_edge_router.RouterTest)}} > {{50: > --}} > {{50: Traceback (most recent call last):}} > {{50: File > "/home/chug/git/qpid-dispatch/tests/system_tests_edge_router.py", line 451, > in test_22_mobile_address_edge_sender_two_interior_receivers}} > {{50: self.assertEqual(None, test.error)}} > {{50: AssertionError: None != 'Timeout Expired - n_sent=350 n_rcvd=300 [36 > chars]t_22'}} > \{{50: }} > {{50: > --}} > {{50: Ran 48 tests in 84.066s}} > \{{50: }} > {{50: FAILED (failures=1)}} > {{1/1 Test #50: system_tests_edge_router .***Failed 84.37 sec}} > {quote} > This test also suffers from the test framework eliding important text in the > error message: > 50: AssertionError: None != 'Timeout Expired - n_sent=350 n_rcvd=300 [36 > chars]t_22' > Seeing the *[36* chars] is a vital to the test showing what went wrong. -- 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-1318) edge_router system test failing - timeout with n_sent too big
Chuck Rolke created DISPATCH-1318: - Summary: edge_router system test failing - timeout with n_sent too big Key: DISPATCH-1318 URL: https://issues.apache.org/jira/browse/DISPATCH-1318 Project: Qpid Dispatch Issue Type: Bug Components: Tests Affects Versions: 1.6.0 Reporter: Chuck Rolke Assignee: Chuck Rolke {quote}{{0: ==}} {{50: FAIL: test_22_mobile_address_edge_sender_two_interior_receivers (system_tests_edge_router.RouterTest)}} {{50: --}} {{50: Traceback (most recent call last):}} {{50: File "/home/chug/git/qpid-dispatch/tests/system_tests_edge_router.py", line 451, in test_22_mobile_address_edge_sender_two_interior_receivers}} {{50: self.assertEqual(None, test.error)}} {{50: AssertionError: None != 'Timeout Expired - n_sent=350 n_rcvd=300 [36 chars]t_22'}} {{50: }} {{50: --}} {{50: Ran 48 tests in 84.066s}} {{50: }} {{50: FAILED (failures=1)}} {{1/1 Test #50: system_tests_edge_router .***Failed 84.37 sec}}{quote} -- 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] [Updated] (DISPATCH-1283) Router crash when link gets freed before its deliveries are freed
[ https://issues.apache.org/jira/browse/DISPATCH-1283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke updated DISPATCH-1283: -- Attachment: ea1.html > Router crash when link gets freed before its deliveries are freed > - > > Key: DISPATCH-1283 > URL: https://issues.apache.org/jira/browse/DISPATCH-1283 > Project: Qpid Dispatch > Issue Type: Bug > Components: Container >Affects Versions: 1.5.0 >Reporter: Ganesh Murthy >Assignee: Ganesh Murthy >Priority: Major > Attachments: ea1.html > > > {noformat} > (gdb) bt > #0 0x7ff1db20d060 in qdr_delete_delivery_internal_CT (core=0x1416180, > delivery=0x7ff1c80d2fe8) at > /home/gmurthy/opensource/qpid-dispatch/src/router_core/transfer.c:613 > #1 0x7ff1db20e9b6 in qdr_delete_delivery_CT (core=0x1416180, > action=0x7ff1bc33d828, discard=false) at > /home/gmurthy/opensource/qpid-dispatch/src/router_core/transfer.c:1221 > #2 0x7ff1db206ec0 in router_core_thread (arg=0x1416180) at > /home/gmurthy/opensource/qpid-dispatch/src/router_core/router_core_thread.c:148 > #3 0x7ff1db11858e in start_thread () from /lib64/libpthread.so.0 > #4 0x7ff1dabc06a3 in clone () from /lib64/libc.so.6 > (gdb){noformat} -- 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-1283) Router crash when link gets freed before its deliveries are freed
[ https://issues.apache.org/jira/browse/DISPATCH-1283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16814904#comment-16814904 ] Chuck Rolke commented on DISPATCH-1283: --- Self test system_tests_edge_router exposes this issue. In the failed run 'test_11' appears to complete ok but 'test_12' is ERROR. The problem is that test_11 crashed router EA1. In RouterTest/setUpClass directory is a core dump. This file shows a back trace similar to the base jira. The core identifies router EA1 as the crashed router. Scraper tool is run on EA1.log and the output is attached as file ea1.html. In this run: * edge router EA1 has a long-lived connection A0_1 to interior router INT.A * edge router EA1 has a client connection to receiver peer_9 Examining the web file ea1.html: * 2019-04-10 15:48:11.998243 peer_9 closes the receiver link to router EA1. * EA1 responds by detaching its link to peer_9 * 2019-04-10 15:48:11.998529 Edge EA1 has no open clients so it detaches its link [0,7] to interior INT.A * INT.A hasn't heard about the closed link yet and blasts transfers 1208..1256 to edge EA1. * 2019-04-10 15:48:12.007543 INT.A closes link [0,7] Now the Edge EA1 and interior INT.A behavior gets a little sketchy: * 2019-04-10 15:48:12.007543 EA1 sends receiver dispositions for 1208..1256 back to INT.A Note that these dispositions have no final state. * 2019-04-10 15:48:12.009673 INT.A, receiving dispositions with no state sends _sender_ dispositions back to EA1. As soon as EA1 starts receiving the sender dispositions it crashes. === >From a protocol standpoint both routers would be better off if they didn't >respond at all to transfers or dispositions after they sent the detach to close the links. > Router crash when link gets freed before its deliveries are freed > - > > Key: DISPATCH-1283 > URL: https://issues.apache.org/jira/browse/DISPATCH-1283 > Project: Qpid Dispatch > Issue Type: Bug > Components: Container >Affects Versions: 1.5.0 >Reporter: Ganesh Murthy >Assignee: Ganesh Murthy >Priority: Major > > {noformat} > (gdb) bt > #0 0x7ff1db20d060 in qdr_delete_delivery_internal_CT (core=0x1416180, > delivery=0x7ff1c80d2fe8) at > /home/gmurthy/opensource/qpid-dispatch/src/router_core/transfer.c:613 > #1 0x7ff1db20e9b6 in qdr_delete_delivery_CT (core=0x1416180, > action=0x7ff1bc33d828, discard=false) at > /home/gmurthy/opensource/qpid-dispatch/src/router_core/transfer.c:1221 > #2 0x7ff1db206ec0 in router_core_thread (arg=0x1416180) at > /home/gmurthy/opensource/qpid-dispatch/src/router_core/router_core_thread.c:148 > #3 0x7ff1db11858e in start_thread () from /lib64/libpthread.so.0 > #4 0x7ff1dabc06a3 in clone () from /lib64/libc.so.6 > (gdb){noformat} -- 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-1309) Various crashes in 1.6 release
[ https://issues.apache.org/jira/browse/DISPATCH-1309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke resolved DISPATCH-1309. --- Resolution: Fixed Commits 57c3603 and c27d73b put the router back on track. * When the console disconnects it usually emits a query immediately (200 uS) before detaching the links and closing the connection. This ensured that there was a work item in the router to be processed as the link/session/connection closed and created the opportunity to perform work on a closed link. Commit 57c3603 fixed that. * Commit c27d7eb fixed an issue where code on one thread freed an object in use by another thread. The result was random memory corruption that manifested itself in a variety of ways. > Various crashes in 1.6 release > -- > > Key: DISPATCH-1309 > URL: https://issues.apache.org/jira/browse/DISPATCH-1309 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 1.6.0 > Environment: System 'unused':( > Fedora 5.0.3-200.fc29.x86_64, > Python 2.7.15, > Proton master @ eab1f. > System 'taj':( > Fedora 4.18.16-200.fc28.x86_64, > Python 3.6.6, > Proton master @ 68b38 >Reporter: Chuck Rolke >Priority: Major > Attachments: DISPATCH-1309-backtraces.txt, > DISPATCH-1309-gen_configs_linear.py > > > qpid-dispatch master @ 51244, which is very close to the 1.6 release, has > various crashes. > The test network is 12 routers spread over two systems. (Configuration > generator to be attached.) Four interior routers are in linear arrangement > with A and C on one system ('unused'), and B and D on the other system > ('taj'). Each system then attaches four edge routers, one to each interior > router. > Running lightweight tests, like proton cpp simple_send and simple_recv to > ports on INTA and INTB interior routers leads to a crash on INTC. The crashes > typically look like reuse of structures after they have been freed (addresses > are 0x). Other crashes hint of general memory corruption > (crashes in malloc.c). > -- 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-1312) Remove cmake option USE_MEMORY_POOL
Chuck Rolke created DISPATCH-1312: - Summary: Remove cmake option USE_MEMORY_POOL Key: DISPATCH-1312 URL: https://issues.apache.org/jira/browse/DISPATCH-1312 Project: Qpid Dispatch Issue Type: Bug Components: Tools Affects Versions: 1.6.0 Reporter: Chuck Rolke Assignee: Chuck Rolke Memory pool must be ON and is no longer optional. -- 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-1309) Various crashes in 1.6 release
[ https://issues.apache.org/jira/browse/DISPATCH-1309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16809845#comment-16809845 ] Chuck Rolke commented on DISPATCH-1309: --- A console disconnect can crash a stand-alone interior router with no client traffic. Start a router with: {{router {}} {{ debugDumpFile: qddebug-INTB.txt}} {{ mode: interior}} {{ id: INTB}} {{}}} {{listener {}} {{ http: true}} {{ port: 5672}} {{}}} {{log {}} {{ outputFile: INTB.log}} {{ enable: trace+}} {{ module: DEFAULT}} {{}}} Connect your browser to 127.0.0.1:5672 In the Connect tab repeatedly disconnect and connect. After some small number of tries my router crashes with one of a wide variety of core dumps. Note this this is an issue with release 1.5.0 as well. > Various crashes in 1.6 release > -- > > Key: DISPATCH-1309 > URL: https://issues.apache.org/jira/browse/DISPATCH-1309 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 1.6.0 > Environment: System 'unused':( > Fedora 5.0.3-200.fc29.x86_64, > Python 2.7.15, > Proton master @ eab1f. > System 'taj':( > Fedora 4.18.16-200.fc28.x86_64, > Python 3.6.6, > Proton master @ 68b38 >Reporter: Chuck Rolke >Priority: Major > Attachments: DISPATCH-1309-backtraces.txt, > DISPATCH-1309-gen_configs_linear.py > > > qpid-dispatch master @ 51244, which is very close to the 1.6 release, has > various crashes. > The test network is 12 routers spread over two systems. (Configuration > generator to be attached.) Four interior routers are in linear arrangement > with A and C on one system ('unused'), and B and D on the other system > ('taj'). Each system then attaches four edge routers, one to each interior > router. > Running lightweight tests, like proton cpp simple_send and simple_recv to > ports on INTA and INTB interior routers leads to a crash on INTC. The crashes > typically look like reuse of structures after they have been freed (addresses > are 0x). Other crashes hint of general memory corruption > (crashes in malloc.c). > -- 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-1309) Various crashes in 1.6 release
[ https://issues.apache.org/jira/browse/DISPATCH-1309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16808111#comment-16808111 ] Chuck Rolke commented on DISPATCH-1309: --- I tried git bisecting from 1.5.0 to 1.6.0 release tags and got no errors. Then eventually I got the following backtrace trying to log "Computed valid origins {}" from python run-time code. The crashes I saw earlier happened when a console was attached to an http-enabled listener. During my bisect exercise I had no consoles attached. I'll go back and try some with consoles attached where I can. {{(gdb) bt}} {{#0 malloc_consolidate (av=av@entry=0x7f970820) at malloc.c:4469}} {{#1 0x7f972b97d098 in _int_malloc (av=av@entry=0x7f970820, bytes=bytes@entry=2288) at malloc.c:3695}} {{#2 0x7f972b97dd7b in _int_memalign (av=av@entry=0x7f970820, alignment=alignment@entry=64, bytes=bytes@entry=2176) at malloc.c:4726}} {{#3 0x7f972b97ef7a in _mid_memalign (alignment=64, bytes=2176, address=) at malloc.c:3306}} {{#4 0x7f972b98052c in __posix_memalign (size=, alignment=, memptr=0x7f9717ffd830) at malloc.c:5401}} {{#5 __posix_memalign (memptr=0x7f9717ffd830, alignment=, size=) at malloc.c:5388}} {{#6 0x7f972be8b3c4 in qd_alloc (desc=0x7f972beb5dc0 <__desc_qd_log_entry_t>, tpool=0x7f9717fff578) at /home/chug/git/qpid-dispatch/src/alloc_pool.c:181}} {{#7 0x7f972be336ab in new_qd_log_entry_t () at /home/chug/git/qpid-dispatch/src/log.c:61}} {{#8 0x7f972be3491d in qd_vlog_impl (source=0x8c0bb0, level=QD_LOG_INFO, }} {{ file=0x7f971df1d3d4 "/opt/local/lib/qpid-dispatch/python/qpid_dispatch_internal/router/node.py", line=162, fmt=0x7f972be928df "%s", ap=0x7f9717ffd8e8)}} {{ at /home/chug/git/qpid-dispatch/src/log.c:416}} {{#9 0x7f972be34ba1 in qd_log_impl (source=0x8c0bb0, level=QD_LOG_INFO, }} {{ file=0x7f971df1d3d4 "/opt/local/lib/qpid-dispatch/python/qpid_dispatch_internal/router/node.py", line=162, fmt=0x7f972be928df "%s")}} {{ at /home/chug/git/qpid-dispatch/src/log.c:435}} {{#10 0x7f972be460a8 in qd_python_log (self=, }} {{ args=(4L, u'Computed valid origins: {}', '/opt/local/lib/qpid-dispatch/python/qpid_dispatch_internal/router/node.py', 162))}} {{ at /home/chug/git/qpid-dispatch/src/python_embedded.c:429}} {{#11 0x7f972bc6314b in call_function (oparg=, pp_stack=0x7f9717ffdab0) at /usr/src/debug/python2-2.7.15-11.fc29.x86_64/Python/ceval.c:4449}} {{#12 PyEval_EvalFrameEx (}} {{ f=f@entry=Frame 0x7f971d714bf0, for file /opt/local/lib/qpid-dispatch/python/qpid_dispatch_internal/router/engine.py, line 229, in log_ls (self=, nodes_by_link_id=\{0: , parent=<...>, neighbor_refresh_time=, keep_alive_count=0, adapter=, valid_origins=[], peer_link_id=None, link_state=) at remote 0x7f971c4952d0>, instance=1554232196L, version=1L, next_hop_router=None, mobile_address_sequence=8, need_mobile_request=False, id=u'INTC', maskbit=1, need_ls_request=False) at remote 0x7f971d7c2790>}, maskbits=[True, True, True, True, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None,...(truncated), throwflag=throwflag@entry=0)}} {{ at /usr/src/debug/python2-2.7.15-11.fc29.x86_64/Python/ceval.c:3083}} {{#13 0x7f972bc63902 in PyEval_EvalCodeEx (co=, globals=, locals=locals@entry=0x0, args=, }} {{ argcount=, kws=, kwcount=0, defs=0x0, defcount=0, closure=0x0)}} {{ at /usr/src/debug/python2-2.7.15-11.fc29.x86_64/Python/ceval.c:3681}} {{#14 0x7f972bc6053c in fast_function (nk=, na=, n=, pp_stack=0x7f9717ffdc70, }} {{ func=) at /usr/src/debug/python2-2.7.15-11.fc29.x86_64/Python/ceval.c:4544}} {{#15 call_function (oparg=, pp_stack=0x7f9717ffdc70) at /usr/src/debug/python2-2.7.15-11.fc29.x86_64/Python/ceval.c:4469}} {{#16 PyEval_EvalFrameEx (}} {{ f=f@entry=Frame 0x7f970404cc40, for file /opt/local/lib/qpid-dispatch/python/qpid_dispatch_internal/router/node.py, line 162, in tick (self=, domain=u'domain', _log_hello=, area=u'0', mobile_address_engine=, 2: }, container=<...>, deleted_addrs=[], treatments=\{u'HED1': 3L, u'HED2': 3L}, added_addrs=[], node_tracker=<...>, local_addrs=[u'HED2', u'HED1'], mobile_seq=2, id=u'INTD') at remote 0x7f971d70cd10>, _config=, globals=, locals=locals@entry=0x0, args=, }} {{ argcount=, kws=, kwcount=0, defs=0x0, defcount=0, closure=0x0)}} {{ at /usr/src/debug/python2-2.7.15-11.fc29.x86_64/Python/ceval.c:3681}} {{#18 0x7f972bc6053c in fast_function (nk=, na=, n=, pp_stack=0x7f9717ffde30, }} {{--Type for more, q to quit, c to continue without paging--}} {{ func=) at /usr/src/debug/python2-2.7.15-11.fc29.x86_64/Python/ceval.c:4544}} {{#19 call_function
[jira] [Updated] (DISPATCH-1309) Various crashes in 1.6 release
[ https://issues.apache.org/jira/browse/DISPATCH-1309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke updated DISPATCH-1309: -- Environment: System 'unused':( Fedora 5.0.3-200.fc29.x86_64, Python 2.7.15, Proton master @ eab1f. System 'taj':( Fedora 4.18.16-200.fc28.x86_64, Python 3.6.6, Proton master @ 68b38 > Various crashes in 1.6 release > -- > > Key: DISPATCH-1309 > URL: https://issues.apache.org/jira/browse/DISPATCH-1309 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 1.6.0 > Environment: System 'unused':( > Fedora 5.0.3-200.fc29.x86_64, > Python 2.7.15, > Proton master @ eab1f. > System 'taj':( > Fedora 4.18.16-200.fc28.x86_64, > Python 3.6.6, > Proton master @ 68b38 >Reporter: Chuck Rolke >Priority: Major > Attachments: DISPATCH-1309-backtraces.txt, > DISPATCH-1309-gen_configs_linear.py > > > qpid-dispatch master @ 51244, which is very close to the 1.6 release, has > various crashes. > The test network is 12 routers spread over two systems. (Configuration > generator to be attached.) Four interior routers are in linear arrangement > with A and C on one system ('unused'), and B and D on the other system > ('taj'). Each system then attaches four edge routers, one to each interior > router. > Running lightweight tests, like proton cpp simple_send and simple_recv to > ports on INTA and INTB interior routers leads to a crash on INTC. The crashes > typically look like reuse of structures after they have been freed (addresses > are 0x). Other crashes hint of general memory corruption > (crashes in malloc.c). > -- 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] [Updated] (DISPATCH-1309) Various crashes in 1.6 release
[ https://issues.apache.org/jira/browse/DISPATCH-1309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke updated DISPATCH-1309: -- Attachment: DISPATCH-1309-gen_configs_linear.py > Various crashes in 1.6 release > -- > > Key: DISPATCH-1309 > URL: https://issues.apache.org/jira/browse/DISPATCH-1309 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 1.6.0 > Reporter: Chuck Rolke >Priority: Major > Attachments: DISPATCH-1309-backtraces.txt, > DISPATCH-1309-gen_configs_linear.py > > > qpid-dispatch master @ 51244, which is very close to the 1.6 release, has > various crashes. > The test network is 12 routers spread over two systems. (Configuration > generator to be attached.) Four interior routers are in linear arrangement > with A and C on one system ('unused'), and B and D on the other system > ('taj'). Each system then attaches four edge routers, one to each interior > router. > Running lightweight tests, like proton cpp simple_send and simple_recv to > ports on INTA and INTB interior routers leads to a crash on INTC. The crashes > typically look like reuse of structures after they have been freed (addresses > are 0x). Other crashes hint of general memory corruption > (crashes in malloc.c). > -- 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] [Updated] (DISPATCH-1309) Various crashes in 1.6 release
[ https://issues.apache.org/jira/browse/DISPATCH-1309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke updated DISPATCH-1309: -- Attachment: DISPATCH-1309-backtraces.txt > Various crashes in 1.6 release > -- > > Key: DISPATCH-1309 > URL: https://issues.apache.org/jira/browse/DISPATCH-1309 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 1.6.0 > Reporter: Chuck Rolke >Priority: Major > Attachments: DISPATCH-1309-backtraces.txt > > > qpid-dispatch master @ 51244, which is very close to the 1.6 release, has > various crashes. > The test network is 12 routers spread over two systems. (Configuration > generator to be attached.) Four interior routers are in linear arrangement > with A and C on one system ('unused'), and B and D on the other system > ('taj'). Each system then attaches four edge routers, one to each interior > router. > Running lightweight tests, like proton cpp simple_send and simple_recv to > ports on INTA and INTB interior routers leads to a crash on INTC. The crashes > typically look like reuse of structures after they have been freed (addresses > are 0x). Other crashes hint of general memory corruption > (crashes in malloc.c). > -- 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