from:"Chuck Rolke"

Re: [VOTE] Release Qpid Dispatch Router 1.14.0 (RC1)

2020-09-11 Thread Chuck Rolke




- 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=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)

2020-04-28 Thread Chuck Rolke

+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)

2020-03-16 Thread Chuck Rolke

+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 -

Re: [VOTE] Release Qpid Dispatch Router 1.10.0 (RC3)

2019-12-17 Thread Chuck Rolke

+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)

2019-12-13 Thread Chuck Rolke

-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

[jira] [Created] (PROTON-2104) [c++ client] Error specifying url with IPv6 literal host address

2019-09-20 Thread Chuck Rolke (Jira)

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

2019-09-19 Thread Chuck Rolke (Jira)



 [ 
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

2019-09-17 Thread Chuck Rolke (Jira)



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

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

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



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

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

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

2019-09-17 Thread Chuck Rolke

+1

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

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

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

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

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

2019-09-17 Thread Chuck Rolke (Jira)



 [ 
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

2019-09-17 Thread Chuck Rolke (Jira)



 [ 
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

2019-09-17 Thread Chuck Rolke (Jira)



 [ 
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

2019-09-17 Thread Chuck Rolke (Jira)

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

2019-09-12 Thread Chuck Rolke (Jira)



[ 
https://issues.apache.org/jira/browse/DISPATCH-1417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2019-09-11 Thread Chuck Rolke (Jira)



[ 
https://issues.apache.org/jira/browse/DISPATCH-1417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2019-09-11 Thread Chuck Rolke (Jira)

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)

2019-09-11 Thread Chuck Rolke

-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

2019-09-10 Thread Chuck Rolke (Jira)

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

2019-09-09 Thread Chuck Rolke (Jira)

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

2019-09-09 Thread Chuck Rolke (Jira)



 [ 
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

2019-09-09 Thread Chuck Rolke (Jira)



 [ 
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

2019-09-09 Thread Chuck Rolke (Jira)



[ 
https://issues.apache.org/jira/browse/DISPATCH-1414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2019-09-09 Thread Chuck Rolke (Jira)

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

2019-09-09 Thread Chuck Rolke (Jira)



 [ 
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

2019-09-08 Thread Chuck Rolke (Jira)



[ 
https://issues.apache.org/jira/browse/DISPATCH-1407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2019-09-07 Thread Chuck Rolke (Jira)



[ 
https://issues.apache.org/jira/browse/DISPATCH-1407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2019-09-06 Thread Chuck Rolke (Jira)



[ 
https://issues.apache.org/jira/browse/DISPATCH-1407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2019-09-06 Thread Chuck Rolke (Jira)



[ 
https://issues.apache.org/jira/browse/DISPATCH-1407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2019-09-06 Thread Chuck Rolke (Jira)



 [ 
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

2019-09-06 Thread Chuck Rolke (Jira)



 [ 
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

2019-09-05 Thread Chuck Rolke (Jira)

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

2019-09-03 Thread Chuck Rolke (Jira)

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

2019-08-23 Thread Chuck Rolke (Jira)



 [ 
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

2019-08-20 Thread Chuck Rolke (Jira)

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

2019-07-30 Thread Chuck Rolke (JIRA)

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

2019-07-30 Thread Chuck Rolke (JIRA)



 [ 
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

2019-07-18 Thread Chuck Rolke (JIRA)

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

2019-07-01 Thread Chuck Rolke (JIRA)

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

2019-06-28 Thread Chuck Rolke (JIRA)



[ 
https://issues.apache.org/jira/browse/DISPATCH-1377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2019-06-17 Thread Chuck Rolke (JIRA)



[ 
https://issues.apache.org/jira/browse/DISPATCH-1371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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.

2019-06-14 Thread Chuck Rolke (JIRA)



 [ 
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] [Resolved] (DISPATCH-480) Default tests timeout is too short for some machines

2019-06-12 Thread Chuck Rolke (JIRA)



 [ 
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.

2019-06-12 Thread Chuck Rolke (JIRA)



 [ 
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)

2019-06-11 Thread Chuck Rolke

+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.

2019-06-10 Thread Chuck Rolke (JIRA)



[ 
https://issues.apache.org/jira/browse/DISPATCH-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2019-06-10 Thread Chuck Rolke (JIRA)



 [ 
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

2019-06-03 Thread Chuck Rolke (JIRA)

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

2019-05-31 Thread Chuck Rolke (JIRA)

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

2019-05-14 Thread Chuck Rolke (JIRA)

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

2019-05-09 Thread Chuck Rolke (JIRA)



 [ 
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

2019-05-08 Thread Chuck Rolke (JIRA)



 [ 
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

2019-05-08 Thread Chuck Rolke (JIRA)



 [ 
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

2019-05-08 Thread Chuck Rolke (JIRA)



 [ 
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

2019-05-08 Thread Chuck Rolke (JIRA)



 [ 
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

2019-05-08 Thread Chuck Rolke (JIRA)

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

2019-05-07 Thread Chuck Rolke (JIRA)



 [ 
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

2019-05-07 Thread Chuck Rolke (JIRA)

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

2019-05-06 Thread Chuck Rolke (JIRA)



[ 
https://issues.apache.org/jira/browse/PROTON-2042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2019-05-03 Thread Chuck Rolke (JIRA)



 [ 
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

2019-05-03 Thread Chuck Rolke (JIRA)



 [ 
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

2019-05-03 Thread Chuck Rolke (JIRA)



 [ 
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

2019-05-02 Thread Chuck Rolke (JIRA)



 [ 
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

2019-05-02 Thread Chuck Rolke (JIRA)



 [ 
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

2019-05-02 Thread Chuck Rolke (JIRA)



 [ 
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

2019-05-02 Thread Chuck Rolke (JIRA)



[ 
https://issues.apache.org/jira/browse/PROTON-2039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2019-05-02 Thread Chuck Rolke (JIRA)



 [ 
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

2019-05-02 Thread Chuck Rolke (JIRA)

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

2019-05-02 Thread Chuck Rolke (JIRA)



 [ 
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

2019-05-01 Thread Chuck Rolke (JIRA)



 [ 
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

2019-04-30 Thread Chuck Rolke (JIRA)

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

2019-04-30 Thread Chuck Rolke (JIRA)



 [ 
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

2019-04-29 Thread Chuck Rolke (JIRA)



 [ 
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

2019-04-29 Thread Chuck Rolke (JIRA)



 [ 
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

2019-04-26 Thread Chuck Rolke (JIRA)



[ 
https://issues.apache.org/jira/browse/DISPATCH-1327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2019-04-26 Thread Chuck Rolke (JIRA)



[ 
https://issues.apache.org/jira/browse/PROTON-2033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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-dispatch] , or add it as a remo

[jira] [Updated] (DISPATCH-1325) Sender connections to edge router that connect 'too soon' never get credit

2019-04-26 Thread Chuck Rolke (JIRA)



 [ 
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

2019-04-26 Thread Chuck Rolke (JIRA)

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

2019-04-25 Thread Chuck Rolke (JIRA)

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

2019-04-24 Thread Chuck Rolke (JIRA)



[ 
https://issues.apache.org/jira/browse/DISPATCH-1322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2019-04-22 Thread Chuck Rolke (JIRA)



 [ 
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

2019-04-18 Thread Chuck Rolke (JIRA)



[ 
https://issues.apache.org/jira/browse/PROTON-2033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2019-04-16 Thread Chuck Rolke (JIRA)



[ 
https://issues.apache.org/jira/browse/PROTON-2033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2019-04-15 Thread Chuck Rolke (JIRA)

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

2019-04-14 Thread Chuck Rolke (JIRA)



 [ 
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

2019-04-14 Thread Chuck Rolke (JIRA)



 [ 
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

2019-04-14 Thread Chuck Rolke (JIRA)



 [ 
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

2019-04-14 Thread Chuck Rolke (JIRA)

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

2019-04-14 Thread Chuck Rolke (JIRA)



[ 
https://issues.apache.org/jira/browse/DISPATCH-1318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2019-04-12 Thread Chuck Rolke (JIRA)



 [ 
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

2019-04-11 Thread Chuck Rolke (JIRA)

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

2019-04-10 Thread Chuck Rolke (JIRA)



 [ 
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

2019-04-10 Thread Chuck Rolke (JIRA)



[ 
https://issues.apache.org/jira/browse/DISPATCH-1283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2019-04-09 Thread Chuck Rolke (JIRA)



 [ 
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

2019-04-04 Thread Chuck Rolke (JIRA)

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

2019-04-04 Thread Chuck Rolke (JIRA)



[ 
https://issues.apache.org/jira/browse/DISPATCH-1309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2019-04-02 Thread Chuck Rolke (JIRA)



[ 
https://issues.apache.org/jira/browse/DISPATCH-1309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 (oparg=, pp_stack=0x7f9717ffde30) at 
/usr/src/debug/python2-2.7.15-11.fc29.x86_64/Python/ceval.c:4469}}
{{#20 PyEval_EvalFrame

[jira] [Updated] (DISPATCH-1309) Various crashes in 1.6 release

2019-04-02 Thread Chuck Rolke (JIRA)



 [ 
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

2019-04-02 Thread Chuck Rolke (JIRA)



 [ 
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

2019-04-02 Thread Chuck Rolke (JIRA)



 [ 
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

[jira] [Created] (DISPATCH-1309) Various crashes in 1.6 release

2019-04-02 Thread Chuck Rolke (JIRA)

Chuck Rolke created DISPATCH-1309:
-

 Summary: 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


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

1 2 3 4 5 6 7 8 9 10 >

1 - 100 of 1301 matches

Mail list logo