[jira] [Commented] (PROTON-1394) Creating a Container leaks two file descriptors

2017-05-17 Thread Mike Bonnet (JIRA)

[ 
https://issues.apache.org/jira/browse/PROTON-1394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16014994#comment-16014994
 ] 

Mike Bonnet commented on PROTON-1394:
-

We really need this backport-able to python 2.6 and 2.7. Is a WeakMethod the 
only option?

> Creating a Container leaks two file descriptors
> ---
>
> Key: PROTON-1394
> URL: https://issues.apache.org/jira/browse/PROTON-1394
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: python-binding
>Affects Versions: 0.16.0
>Reporter: Mike Bonnet
> Attachments: fix_container_leak.patch, leakyprotonpipes.py, 
> new_fix_container_leak.patch
>
>
> Creating a Container (Reactor) creates a pipe (two file descriptors). This 
> pipe is never freed, even after the Container is stopped and goes out of 
> scope. An application that creates many short-lived Containers will quickly 
> exhaust file descriptors and Container creation will start failing.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Commented] (DISPATCH-775) allow authentication against a remote server

2017-05-17 Thread Gordon Sim (JIRA)

[ 
https://issues.apache.org/jira/browse/DISPATCH-775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16014667#comment-16014667
 ] 

Gordon Sim commented on DISPATCH-775:
-

WIP: https://reviews.apache.org/r/59352/

> allow authentication against a remote server
> 
>
> Key: DISPATCH-775
> URL: https://issues.apache.org/jira/browse/DISPATCH-775
> Project: Qpid Dispatch
>  Issue Type: New Feature
>Reporter: Gordon Sim
>Assignee: Gordon Sim
>
> When running lots of routers, it would be handy to be able to have them all 
> authenticate against some centralized, external auth service. This can be 
> done by relaying the AMQP SASL frames to that remote service.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Commented] (PROTON-1485) allow authentication against a remote server

2017-05-17 Thread Gordon Sim (JIRA)

[ 
https://issues.apache.org/jira/browse/PROTON-1485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16014659#comment-16014659
 ] 

Gordon Sim commented on PROTON-1485:


WIP: https://reviews.apache.org/r/59351/

> allow authentication against a remote server
> 
>
> Key: PROTON-1485
> URL: https://issues.apache.org/jira/browse/PROTON-1485
> Project: Qpid Proton
>  Issue Type: New Feature
>Reporter: Gordon Sim
>
> see DISPATCH-775



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Created] (PROTON-1485) allow authentication against a remote server

2017-05-17 Thread Gordon Sim (JIRA)
Gordon Sim created PROTON-1485:
--

 Summary: allow authentication against a remote server
 Key: PROTON-1485
 URL: https://issues.apache.org/jira/browse/PROTON-1485
 Project: Qpid Proton
  Issue Type: New Feature
Reporter: Gordon Sim


see DISPATCH-775



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Closed] (DISPATCH-776) allow authentication against a remote server

2017-05-17 Thread Gordon Sim (JIRA)

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

Gordon Sim closed DISPATCH-776.
---
Resolution: Invalid

> allow authentication against a remote server
> 
>
> Key: DISPATCH-776
> URL: https://issues.apache.org/jira/browse/DISPATCH-776
> Project: Qpid Dispatch
>  Issue Type: New Feature
>Reporter: Gordon Sim
>Assignee: Gordon Sim
>
> When running lots of routers, it would be handy to be able to have them all 
> authenticate against some centralized, external auth service. This can be 
> done by relaying the AMQP SASL frames to that remote service.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Created] (DISPATCH-776) allow authentication against a remote server

2017-05-17 Thread Gordon Sim (JIRA)
Gordon Sim created DISPATCH-776:
---

 Summary: allow authentication against a remote server
 Key: DISPATCH-776
 URL: https://issues.apache.org/jira/browse/DISPATCH-776
 Project: Qpid Dispatch
  Issue Type: New Feature
Reporter: Gordon Sim
Assignee: Gordon Sim


When running lots of routers, it would be handy to be able to have them all 
authenticate against some centralized, external auth service. This can be done 
by relaying the AMQP SASL frames to that remote service.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Created] (DISPATCH-775) allow authentication against a remote server

2017-05-17 Thread Gordon Sim (JIRA)
Gordon Sim created DISPATCH-775:
---

 Summary: allow authentication against a remote server
 Key: DISPATCH-775
 URL: https://issues.apache.org/jira/browse/DISPATCH-775
 Project: Qpid Dispatch
  Issue Type: New Feature
Reporter: Gordon Sim
Assignee: Gordon Sim


When running lots of routers, it would be handy to be able to have them all 
authenticate against some centralized, external auth service. This can be done 
by relaying the AMQP SASL frames to that remote service.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Commented] (DISPATCH-209) Three+ router test is needed in the system test suite.

2017-05-17 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/DISPATCH-209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16014537#comment-16014537
 ] 

ASF GitHub Bot commented on DISPATCH-209:
-

GitHub user mgoulish opened a pull request:

https://github.com/apache/qpid-dispatch/pull/163

DISPATCH-209 -- three-router test #3 dynamic reply-to

New test for dynamic reply-to  -- simulation of request-response server and 
client.

test #3 survived a 1000-iteration run with 7 failures, all in teardown.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/mgoulish/qpid-dispatch master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/qpid-dispatch/pull/163.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #163


commit a07122b349def57cd6d97f85f59bd7f5c8577cf3
Author: mick goulish 
Date:   2017-05-17T18:12:40Z

DISPATCH-209 -- three-router test #3 dynamic reply-to




> Three+ router test is needed in the system test suite.
> --
>
> Key: DISPATCH-209
> URL: https://issues.apache.org/jira/browse/DISPATCH-209
> Project: Qpid Dispatch
>  Issue Type: New Feature
>  Components: Tests
>Reporter: Ted Ross
>Assignee: michael goulish
>
> There have arisen some issues that would have been caught had there been a 
> three-router test in the regression suite.  This test should be added.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[GitHub] qpid-dispatch pull request #163: DISPATCH-209 -- three-router test #3 dynami...

2017-05-17 Thread mgoulish
GitHub user mgoulish opened a pull request:

https://github.com/apache/qpid-dispatch/pull/163

DISPATCH-209 -- three-router test #3 dynamic reply-to

New test for dynamic reply-to  -- simulation of request-response server and 
client.

test #3 survived a 1000-iteration run with 7 failures, all in teardown.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/mgoulish/qpid-dispatch master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/qpid-dispatch/pull/163.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #163


commit a07122b349def57cd6d97f85f59bd7f5c8577cf3
Author: mick goulish 
Date:   2017-05-17T18:12:40Z

DISPATCH-209 -- three-router test #3 dynamic reply-to




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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



[GitHub] qpid-proton pull request #105: Port of C++ binding to Proton Proactor

2017-05-17 Thread astitcher
GitHub user astitcher opened a pull request:

https://github.com/apache/qpid-proton/pull/105

Port of C++ binding to Proton Proactor

This set of changes reimplements the C++ binding do that it no longer uses 
the Proton Reactor library at all and now only links to the Proton Core and 
Proton Proactor libraries.

It is not 100% finished yet, missing pieces include:
* Multi thread support - Currently the API is thread safe if you obey the 
thread safety rules, but only one thread is used to service handler callbacks - 
This will be fixed soon.
* Reconnect is not implemented - If a network connection fails no reconnect 
action is attempted - This will also be fixed, but ntoe that the C++ binding 
implementation of reconnect is subject to change as we don't have a lot of 
experience with it yet.

Included in this PR is a reworking of the mechanism for injecting work into 
safe contexts. The concepts have been renamed for clarity (`proton::work_queue` 
& `proton::work`) and some convenience functions have been added to help those 
(poor benighted souls) using C++03. There is some more work to come which 
should also improve injecting work using the scheduler.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/astitcher/qpid-proton cpp-proactor

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/qpid-proton/pull/105.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #105


commit 96435b5cfac13283c612ba60feefd73901bc9c4f
Author: Andrew Stitcher 
Date:   2017-01-23T17:32:50Z

PROTON-1400: [C++ binding] Removed proton_event and proton_handler
- Removed old low level proton event handling completely
- Now directly dispatch to the messaging_handler
- Moved private message::decode directly into message handling code

commit 84dcd7bcaa97106ef43a6a8b44a7f3e819f07107
Author: Andrew Stitcher 
Date:   2017-01-25T04:36:03Z

PROTON-1400: WIP Use the mt broker example as the example instead of the 
previous st broker
- The st broker didn't correctly respect the object access constraints from 
within handlers

commit b95f252ede1aaa20c8a5fd1abd42fdbe2c7c3ebe
Author: Andrew Stitcher 
Date:   2017-02-08T07:32:36Z

PROTON-1400: [C++ binding] Proactor container implementation
- Remove all reactor use
- Rearrange object context code
- Change container includes to proactor container includes

commit ea7f0e989ba5b90aa322b38336dfbbb089fae899
Author: Andrew Stitcher 
Date:   2017-02-09T01:12:36Z

PROTON-1400: [C++ binding] Remove reactor container implementation files.

commit a0c9e9a756d452bc7c992e4a9875f681b69d5c44
Author: Andrew Stitcher 
Date:   2017-03-03T20:51:58Z

NO-JIRA: Header file corrections

commit 6ed1d1ab4a68f0a132f44b59a09b1582a2f6b4ff
Author: Andrew Stitcher 
Date:   2017-03-28T17:45:28Z

PROTON-1400: [C++ example] Rework broker to use container event loops

commit db92f4c73444d186899e5fa28e638195f3adf5f4
Author: Andrew Stitcher 
Date:   2017-04-14T06:13:12Z

PROTON-1400: [C+ binding] Change semantic for incoming xx_open
- If not overridden then you get automatic outgoing matching xx_open
- If overridden then it is assumed you will handle the outgoing open
  yourself.

commit a52e5d16363caa736062359dab0733b4db6b8992
Author: Andrew Stitcher 
Date:   2017-04-20T19:20:40Z

PROTON-1400: Implement container level event_loops

commit 95a7ded6410e599f6327adedbf5386b5d8b4fca1
Author: Andrew Stitcher 
Date:   2017-04-27T17:05:14Z

PROTON-1400: [C++ binding] Use pn_proactor_now() to implement 
timestamp::now()

commit 2da87d20cff09b00503dd70341fde73b5ae36bd5
Author: Andrew Stitcher 
Date:   2017-05-15T05:27:54Z

PROTON-1481: [C++ binding] Rename event_loop API to work_queue

commit efd5ec09f1a7cfc311fe8f612d48160ce16d7e2b
Author: Andrew Stitcher 
Date:   2017-05-15T05:36:52Z

PROTON-1481: [C++ binding] simpify work_queue code by introducing work type
- The work type can be created from std::function or void_function0
- and so pushes those c++1/C++03 differences into a single place

commit e252354b82f3a4273275a15da614abda3859a2c9
Author: Andrew Stitcher 
Date:   2017-05-15T05:45:43Z

PROTON-1481: [C++ binding] Split out general work deferring functions to 
the work_queue header
Add efficient C++11 versions of work factories
Reorder defer arguments to be like std::bind
Add extra overloads for defer like std::bind (for free functions arbitrary 
work_queues)




---
If your project is set up for it, you can reply to 

[GitHub] qpid-proton pull request #104: Port of thre C++ binding to the Proton Proact...

2017-05-17 Thread astitcher
Github user astitcher closed the pull request at:

https://github.com/apache/qpid-proton/pull/104


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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



[GitHub] qpid-proton pull request #104: Port of thre C++ binding to the Proton Proact...

2017-05-17 Thread astitcher
GitHub user astitcher opened a pull request:

https://github.com/apache/qpid-proton/pull/104

Port of thre C++ binding to the Proton Proactor library

This set of changes reimplements the C++ binding do that it no longer uses 
the Proton Reactor library at all and now only links to the Proton Core and 
Proton Proactor libraries.

It is not 100% finished yet, missing pieces include:
* Multi thread support - Currently the API is thread safe if you obey the 
thread safety rules, but only one thread is used to service handler callbacks - 
This will be fixed soon.
* Reconnect is not implemented - If a network connection fails no reconnect 
action is attempted - This will also be fixed, but ntoe that the C++ binding 
implementation of reconnect is subject to change as we don't have a lot of 
experience with it yet.

Included in this PR is a reworking of the mechanism for injecting work into 
safe contexts. The concepts have been renamed for clarity (`proton::work_queue` 
& `proton::work`) and some convenience functions have been added to help those 
(poor benighted souls) using C++03. There is some more work to come which 
should also improve injecting work using the scheduler.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/astitcher/qpid-proton cpp-proactor

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/qpid-proton/pull/104.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #104


commit 085aa00f54be1609f936d5bb93a0bf1437829f3a
Author: Andrew Stitcher 
Date:   2017-02-08T07:32:36Z

PROTON-1400: [C++ binding] Proactor container implementation
- Remove all reactor use
- Rearrange object context code
- Change container includes to proactor container includes

commit 602429bcfd15edaebcb370f5dee010903e3b4d03
Author: Andrew Stitcher 
Date:   2017-02-09T01:12:36Z

PROTON-1400: [C++ binding] Remove reactor container implementation files.

commit fc6b05b1e6762f680310ee80f5fc2afa883e4d71
Author: Andrew Stitcher 
Date:   2017-04-27T17:05:14Z

PROTON-1400: [C++ binding] Use pn_proactor_now() to implement 
timestamp::now()

commit ca95aa36b271ca63293a7287afcedaab575183a9
Author: Andrew Stitcher 
Date:   2017-05-16T20:02:09Z

PROTON-1400: Fixup

commit 6f24b7c88b72363b966f6855ed689c46d82682b0
Author: Andrew Stitcher 
Date:   2017-01-23T17:32:50Z

PROTON-1400: [C++ binding] Removed proton_event and proton_handler
- Removed old low level proton event handling completely
- Now directly dispatch to the messaging_handler
- Moved private message::decode directly into message handling code

commit c4f5ac3b091a37cf4423eca373f41ca382d2f45f
Author: Andrew Stitcher 
Date:   2017-01-25T04:36:03Z

PROTON-1400: WIP Use the mt broker example as the example instead of the 
previous st broker
- The st broker didn't correctly respect the object access constraints from 
within handlers

commit d622676f8abe46d9351236e1ddc55336f524051d
Author: Andrew Stitcher 
Date:   2017-03-03T20:51:58Z

NO-JIRA: Header file corrections

commit e9bf06254d2904192cfe27de291ea2b8ae2443a1
Author: Andrew Stitcher 
Date:   2017-04-14T06:13:12Z

PROTON-1400: [C+ binding] Change semantic for incoming xx_open
- If not overridden then you get automatic outgoing matching xx_open
- If overridden then it is assumed you will handle the outgoing open
  yourself.

commit 6b231dc2857eb8fdb5bb948aa2709da742a09b9f
Author: Andrew Stitcher 
Date:   2017-03-28T17:45:28Z

PROTON-1400: [C++ example] Rework broker to use container event loops

commit 238324b1e636c1c632cef8b45fdd04611cf61aaa
Author: Andrew Stitcher 
Date:   2017-04-20T19:20:40Z

PROTON-1400: Implement container level event_loops

commit 6f00ac312f0a359195aaf005a301657228290063
Author: Andrew Stitcher 
Date:   2017-05-15T05:27:54Z

PROTON-1481: [C++ binding] Rename event_loop API to work_queue

commit f3b84b5ab8bbdaa3422a5e628f8b210371a9cd9a
Author: Andrew Stitcher 
Date:   2017-05-15T05:36:52Z

PROTON-1481: [C++ binding] simpify work_queue code by introducing work type
- The work type can be created from std::function or void_function0
- and so pushes those c++1/C++03 differences into a single place

commit 557a16bf0544a0faa4d1c9aa2d92e7a864264f40
Author: Andrew Stitcher 
Date:   2017-05-15T05:45:43Z

PROTON-1481: [C++ binding] Split out general work deferring functions to 
the work_queue header
Add efficient C++11 versions of work factories
Reorder defer arguments to be like 

[jira] [Reopened] (DISPATCH-774) backport http changes to 0.8.x to use stock libwebsockets

2017-05-17 Thread Robbie Gemmell (JIRA)

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

Robbie Gemmell reopened DISPATCH-774:
-

The fix-version is marked 0.8.0, which can't be the case. Can you update the 
fix version as appropriate [~aconway].

> backport http changes to 0.8.x to use stock libwebsockets
> -
>
> Key: DISPATCH-774
> URL: https://issues.apache.org/jira/browse/DISPATCH-774
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Container
>Affects Versions: 0.8.0
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: 0.8.0
>
>
> The 0.8.x branch requires a patched version of libwebsockets to work. The 
> master branch works with stock libwebsockets 2.1. Backport the changes so the 
> 0.8.x branch also builds with stock libwebsockets.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



Re: Review Request 59340: PROTON-1288: c++ hide proton::message implementation details

2017-05-17 Thread Andrew Stitcher

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/59340/#review175259
---



I like the idea of hiding the implementation, but not if it requires coupling 
the C++ binding to the internals of proton-c.

I've not looked deeply into these changes, but if you need that coupling then 
you may need to add to the proton-c API.


proton-c/bindings/cpp/CMakeLists.txt
Lines 24 (patched)


I'm strongly against making the cpp binding depend on the internals of 
proton-c


- Andrew Stitcher


On May 17, 2017, 3:34 p.m., Alan Conway wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59340/
> ---
> 
> (Updated May 17, 2017, 3:34 p.m.)
> 
> 
> Review request for qpid, Andrew Stitcher and Cliff Jansen.
> 
> 
> Repository: qpid-proton-git
> 
> 
> Description
> ---
> 
> PROTON-1288: c++ hide proton::message implementation details
> 
> No extra allocations, hide extra book-keeping types in extra storage
> allocated with the pn_message_t.
> 
> 
> Diffs
> -
> 
>   proton-c/bindings/cpp/CMakeLists.txt 
> 0cc402478c993f6cc9f58258acb6978cea44c347 
>   proton-c/bindings/cpp/include/proton/message.hpp 
> 85ccff6aa7afa238a146e899f9ba67cbcd680e7a 
>   proton-c/bindings/cpp/src/message.cpp 
> eecfa3b51db59c97c82d0b582c33419e2ad46707 
>   proton-c/src/core/max_align.h PRE-CREATION 
>   proton-c/src/core/message-internal.h PRE-CREATION 
>   proton-c/src/core/message.c f2fb20e8b025807a9306d59746cf27818ca01345 
> 
> 
> Diff: https://reviews.apache.org/r/59340/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Alan Conway
> 
>



[jira] [Commented] (QPID-7776) Add flow to disk queue policy

2017-05-17 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/QPID-7776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16014314#comment-16014314
 ] 

ASF subversion and git services commented on QPID-7776:
---

Commit 62d6ad7d91b0f38904bfa90c61a607fd0a368ad6 in qpid-broker-j's branch 
refs/heads/master from [~k-wall]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=62d6ad7 ]

QPID-7776: [Java Broker] Add FlowToDisk policy documentation


> Add flow to disk queue policy
> -
>
> Key: QPID-7776
> URL: https://issues.apache.org/jira/browse/QPID-7776
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
>
> It should be possible to configure a queue so that enqueues are always flowed 
> to disk, or are flowed to disk when the queue reaches a certain length or 
> depth.
> A common use case for this would be a user who has one queue that is used 
> _store and forward_ (say for an end of day batch) whilst other queues are 
> used 'live'.  It will make sense for such a user for to mark the batch's 
> queue flow to disk.  That way the messages on the batch queue don't 
> needlessly clog the Broker's memory leaving it free for intraday work.
> The C++ Broker already has an analogous feature.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Updated] (PROTON-1484) [c proactor] SIGSEGV in pconnection_cleanup

2017-05-17 Thread Jiri Danek (JIRA)

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

Jiri Danek updated PROTON-1484:
---
Environment: latest git tip for both qpid proton and qpid dispatch on Debian

> [c proactor] SIGSEGV in pconnection_cleanup
> ---
>
> Key: PROTON-1484
> URL: https://issues.apache.org/jira/browse/PROTON-1484
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.18.0
> Environment: latest git tip for both qpid proton and qpid dispatch on 
> Debian
>Reporter: Jiri Danek
>
> I've noticed multiple qdrouterd test failures with seem to come from the same 
> place in proactor code.
> SIGSEGV in qdrouterd tests; in pconnection_cleanup (pc=0x7f...) at 
> /main/qpid-proton/proton-c/src/proactor/epoll.c:645 
> stop_polling(>timer.epoll_io, pc->psocket.proactor->epollfd);
> Reproducibility: the issue seems nondeterministic
> I am attaching logs and backtraces from two of them below.
> {noformat}
> test 14
>   Start 14: system_tests_autolinks
> 14: Test command: /usr/bin/python "/main/qpid-dispatch/build/tests/run.py" 
> "-m" "unittest" "-v" "system_tests_autolinks"
> 14: Test timeout computed to be: 1500
> 14: test_01_autolink_attach (system_tests_autolinks.AutolinkTest) ... FAIL
> 14: test_02_autolink_credit (system_tests_autolinks.AutolinkTest) ... ok
> 14: test_03_autolink_sender (system_tests_autolinks.AutolinkTest) ... ok
> 14: test_04_autolink_receiver (system_tests_autolinks.AutolinkTest) ... ok
> 14: test_05_inter_container_transfer (system_tests_autolinks.AutolinkTest) 
> ... ok
> 14: test_06_manage_autolinks (system_tests_autolinks.AutolinkTest) ... 
> ERROR:root:Connectivity to the peer container was lost
> 14: ERROR:root:Connectivity to the peer container was lost
> 14: ERROR:root:Connectivity to the peer container was lost
> 14: ERROR:root:Connectivity to the peer container was lost
> 14: ERROR:root:Connectivity to the peer container was lost
> 14: ok
> 14: test_07_autolink_attach_with_ext_addr 
> (system_tests_autolinks.AutolinkTest) ... ERROR:root:proton:io: recv: 
> Connection reset by peer
> 14: ERROR:root:proton:io: recv: Connection reset by peer
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: FAIL
> 14: test_08_autolink_sender_with_ext_addr 
> (system_tests_autolinks.AutolinkTest) ... ERROR:root:proton:io: recv: 
> Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: 

[jira] [Updated] (PROTON-1484) [c proactor] SIGSEGV in pconnection_cleanup

2017-05-17 Thread Jiri Danek (JIRA)

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

Jiri Danek updated PROTON-1484:
---
Description: 
I've noticed multiple qdrouterd test failures with seem to come from the same 
place in proactor code.

SIGSEGV in qdrouterd tests; in pconnection_cleanup (pc=0x7f...) at 
/main/qpid-proton/proton-c/src/proactor/epoll.c:645 
stop_polling(>timer.epoll_io, pc->psocket.proactor->epollfd);

Reproducibility: the issue seems nondeterministic

I am attaching logs and backtraces from two of them below.

{noformat}
test 14
  Start 14: system_tests_autolinks

14: Test command: /usr/bin/python "/main/qpid-dispatch/build/tests/run.py" "-m" 
"unittest" "-v" "system_tests_autolinks"
14: Test timeout computed to be: 1500
14: test_01_autolink_attach (system_tests_autolinks.AutolinkTest) ... FAIL
14: test_02_autolink_credit (system_tests_autolinks.AutolinkTest) ... ok
14: test_03_autolink_sender (system_tests_autolinks.AutolinkTest) ... ok
14: test_04_autolink_receiver (system_tests_autolinks.AutolinkTest) ... ok
14: test_05_inter_container_transfer (system_tests_autolinks.AutolinkTest) ... 
ok
14: test_06_manage_autolinks (system_tests_autolinks.AutolinkTest) ... 
ERROR:root:Connectivity to the peer container was lost
14: ERROR:root:Connectivity to the peer container was lost
14: ERROR:root:Connectivity to the peer container was lost
14: ERROR:root:Connectivity to the peer container was lost
14: ERROR:root:Connectivity to the peer container was lost
14: ok
14: test_07_autolink_attach_with_ext_addr (system_tests_autolinks.AutolinkTest) 
... ERROR:root:proton:io: recv: Connection reset by peer
14: ERROR:root:proton:io: recv: Connection reset by peer
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: FAIL
14: test_08_autolink_sender_with_ext_addr (system_tests_autolinks.AutolinkTest) 
... ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: FAIL
14: test_09_autolink_receiver_with_ext_addr 
(system_tests_autolinks.AutolinkTest) ... ERROR:root:proton:io: recv: 
Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: 

[jira] [Updated] (PROTON-1484) [c proactor] SIGSEGV in pconnection_cleanup

2017-05-17 Thread Jiri Danek (JIRA)

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

Jiri Danek updated PROTON-1484:
---
Description: 
I've noticed multiple qdrouterd test failures with seem to come from the same 
place in proactor code.

SIGSEGV in qdrouterd tests; in pconnection_cleanup (pc=0x7f...) at 
/main/qpid-proton/proton-c/src/proactor/epoll.c:645 
stop_polling(>timer.epoll_io, pc->psocket.proactor->epollfd);

I am attaching logs and backtraces from two of them below.

{noformat}
test 14
  Start 14: system_tests_autolinks

14: Test command: /usr/bin/python "/main/qpid-dispatch/build/tests/run.py" "-m" 
"unittest" "-v" "system_tests_autolinks"
14: Test timeout computed to be: 1500
14: test_01_autolink_attach (system_tests_autolinks.AutolinkTest) ... FAIL
14: test_02_autolink_credit (system_tests_autolinks.AutolinkTest) ... ok
14: test_03_autolink_sender (system_tests_autolinks.AutolinkTest) ... ok
14: test_04_autolink_receiver (system_tests_autolinks.AutolinkTest) ... ok
14: test_05_inter_container_transfer (system_tests_autolinks.AutolinkTest) ... 
ok
14: test_06_manage_autolinks (system_tests_autolinks.AutolinkTest) ... 
ERROR:root:Connectivity to the peer container was lost
14: ERROR:root:Connectivity to the peer container was lost
14: ERROR:root:Connectivity to the peer container was lost
14: ERROR:root:Connectivity to the peer container was lost
14: ERROR:root:Connectivity to the peer container was lost
14: ok
14: test_07_autolink_attach_with_ext_addr (system_tests_autolinks.AutolinkTest) 
... ERROR:root:proton:io: recv: Connection reset by peer
14: ERROR:root:proton:io: recv: Connection reset by peer
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: FAIL
14: test_08_autolink_sender_with_ext_addr (system_tests_autolinks.AutolinkTest) 
... ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: FAIL
14: test_09_autolink_receiver_with_ext_addr 
(system_tests_autolinks.AutolinkTest) ... ERROR:root:proton:io: recv: 
Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: 

[jira] [Updated] (PROTON-1484) [c proactor] SIGSEGV in pconnection_cleanup

2017-05-17 Thread Jiri Danek (JIRA)

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

Jiri Danek updated PROTON-1484:
---
Summary: [c proactor] SIGSEGV in pconnection_cleanup  (was: [c proactor] 
SIGSEGV in qdrouterd tests; in pconnection_cleanup (pc=0x7f...) at 
/main/qpid-proton/proton-c/src/proactor/epoll.c:645 
stop_polling(>timer.epoll_io, pc->psocket.proactor->epollfd);)

> [c proactor] SIGSEGV in pconnection_cleanup
> ---
>
> Key: PROTON-1484
> URL: https://issues.apache.org/jira/browse/PROTON-1484
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.18.0
>Reporter: Jiri Danek
>
> I've noticed multiple qdrouterd test failures with seem to come from the same 
> place in proactor code. I am attaching logs and backtraces from two of them 
> below.
> {noformat}
> test 14
>   Start 14: system_tests_autolinks
> 14: Test command: /usr/bin/python "/main/qpid-dispatch/build/tests/run.py" 
> "-m" "unittest" "-v" "system_tests_autolinks"
> 14: Test timeout computed to be: 1500
> 14: test_01_autolink_attach (system_tests_autolinks.AutolinkTest) ... FAIL
> 14: test_02_autolink_credit (system_tests_autolinks.AutolinkTest) ... ok
> 14: test_03_autolink_sender (system_tests_autolinks.AutolinkTest) ... ok
> 14: test_04_autolink_receiver (system_tests_autolinks.AutolinkTest) ... ok
> 14: test_05_inter_container_transfer (system_tests_autolinks.AutolinkTest) 
> ... ok
> 14: test_06_manage_autolinks (system_tests_autolinks.AutolinkTest) ... 
> ERROR:root:Connectivity to the peer container was lost
> 14: ERROR:root:Connectivity to the peer container was lost
> 14: ERROR:root:Connectivity to the peer container was lost
> 14: ERROR:root:Connectivity to the peer container was lost
> 14: ERROR:root:Connectivity to the peer container was lost
> 14: ok
> 14: test_07_autolink_attach_with_ext_addr 
> (system_tests_autolinks.AutolinkTest) ... ERROR:root:proton:io: recv: 
> Connection reset by peer
> 14: ERROR:root:proton:io: recv: Connection reset by peer
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: FAIL
> 14: test_08_autolink_sender_with_ext_addr 
> (system_tests_autolinks.AutolinkTest) ... ERROR:root:proton:io: recv: 
> Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 14: ERROR:root:proton:io: recv: Connection refused
> 

[jira] [Created] (PROTON-1484) [c proactor] SIGSEGV in qdrouterd tests; in pconnection_cleanup (pc=0x7f...) at /main/qpid-proton/proton-c/src/proactor/epoll.c:645 stop_polling(>timer.epoll_io, pc-

2017-05-17 Thread Jiri Danek (JIRA)
Jiri Danek created PROTON-1484:
--

 Summary: [c proactor] SIGSEGV in qdrouterd tests; in 
pconnection_cleanup (pc=0x7f...) at 
/main/qpid-proton/proton-c/src/proactor/epoll.c:645 
stop_polling(>timer.epoll_io, pc->psocket.proactor->epollfd);
 Key: PROTON-1484
 URL: https://issues.apache.org/jira/browse/PROTON-1484
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-c
Affects Versions: 0.18.0
Reporter: Jiri Danek


I've noticed multiple qdrouterd test failures with seem to come from the same 
place in proactor code. I am attaching logs and backtraces from two of them 
below.

{noformat}
test 14
  Start 14: system_tests_autolinks

14: Test command: /usr/bin/python "/main/qpid-dispatch/build/tests/run.py" "-m" 
"unittest" "-v" "system_tests_autolinks"
14: Test timeout computed to be: 1500
14: test_01_autolink_attach (system_tests_autolinks.AutolinkTest) ... FAIL
14: test_02_autolink_credit (system_tests_autolinks.AutolinkTest) ... ok
14: test_03_autolink_sender (system_tests_autolinks.AutolinkTest) ... ok
14: test_04_autolink_receiver (system_tests_autolinks.AutolinkTest) ... ok
14: test_05_inter_container_transfer (system_tests_autolinks.AutolinkTest) ... 
ok
14: test_06_manage_autolinks (system_tests_autolinks.AutolinkTest) ... 
ERROR:root:Connectivity to the peer container was lost
14: ERROR:root:Connectivity to the peer container was lost
14: ERROR:root:Connectivity to the peer container was lost
14: ERROR:root:Connectivity to the peer container was lost
14: ERROR:root:Connectivity to the peer container was lost
14: ok
14: test_07_autolink_attach_with_ext_addr (system_tests_autolinks.AutolinkTest) 
... ERROR:root:proton:io: recv: Connection reset by peer
14: ERROR:root:proton:io: recv: Connection reset by peer
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: FAIL
14: test_08_autolink_sender_with_ext_addr (system_tests_autolinks.AutolinkTest) 
... ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: FAIL
14: test_09_autolink_receiver_with_ext_addr 
(system_tests_autolinks.AutolinkTest) ... ERROR:root:proton:io: recv: 
Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: Connection refused
14: ERROR:root:proton:io: recv: 

[jira] [Commented] (QPID-7776) Add flow to disk queue policy

2017-05-17 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/QPID-7776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16014285#comment-16014285
 ] 

ASF subversion and git services commented on QPID-7776:
---

Commit 700349d1a929ea22e3ce1626ab397e36d8677d11 in qpid-broker-j's branch 
refs/heads/master from [~k-wall]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=700349d ]

QPID-7776: [Java Broker] Add FlowToDisk Queue overflow policy.


> Add flow to disk queue policy
> -
>
> Key: QPID-7776
> URL: https://issues.apache.org/jira/browse/QPID-7776
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
>
> It should be possible to configure a queue so that enqueues are always flowed 
> to disk, or are flowed to disk when the queue reaches a certain length or 
> depth.
> A common use case for this would be a user who has one queue that is used 
> _store and forward_ (say for an end of day batch) whilst other queues are 
> used 'live'.  It will make sense for such a user for to mark the batch's 
> queue flow to disk.  That way the messages on the batch queue don't 
> needlessly clog the Broker's memory leaving it free for intraday work.
> The C++ Broker already has an analogous feature.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



Review Request 59340: PROTON-1288: c++ hide proton::message implementation details

2017-05-17 Thread Alan Conway

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/59340/
---

Review request for qpid, Andrew Stitcher and Cliff Jansen.


Repository: qpid-proton-git


Description
---

PROTON-1288: c++ hide proton::message implementation details

No extra allocations, hide extra book-keeping types in extra storage
allocated with the pn_message_t.


Diffs
-

  proton-c/bindings/cpp/CMakeLists.txt 0cc402478c993f6cc9f58258acb6978cea44c347 
  proton-c/bindings/cpp/include/proton/message.hpp 
85ccff6aa7afa238a146e899f9ba67cbcd680e7a 
  proton-c/bindings/cpp/src/message.cpp 
eecfa3b51db59c97c82d0b582c33419e2ad46707 
  proton-c/src/core/max_align.h PRE-CREATION 
  proton-c/src/core/message-internal.h PRE-CREATION 
  proton-c/src/core/message.c f2fb20e8b025807a9306d59746cf27818ca01345 


Diff: https://reviews.apache.org/r/59340/diff/1/


Testing
---


Thanks,

Alan Conway



[jira] [Resolved] (DISPATCH-774) backport http changes to 0.8.x to use stock libwebsockets

2017-05-17 Thread Alan Conway (JIRA)

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

Alan Conway resolved DISPATCH-774.
--
Resolution: Fixed

> backport http changes to 0.8.x to use stock libwebsockets
> -
>
> Key: DISPATCH-774
> URL: https://issues.apache.org/jira/browse/DISPATCH-774
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Container
>Affects Versions: 0.8.0
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: 0.8.0
>
>
> The 0.8.x branch requires a patched version of libwebsockets to work. The 
> master branch works with stock libwebsockets 2.1. Backport the changes so the 
> 0.8.x branch also builds with stock libwebsockets.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Commented] (DISPATCH-390) New pn_proactor-based IO driver

2017-05-17 Thread Jiri Danek (JIRA)

[ 
https://issues.apache.org/jira/browse/DISPATCH-390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16014111#comment-16014111
 ] 

Jiri Danek commented on DISPATCH-390:
-

The {{Assertion `exp_count >= pt->skip_count' failed.}} was reported by [~chug] 
in PROTON-1483. At least it looks like the same issue to me.

> New pn_proactor-based IO driver
> ---
>
> Key: DISPATCH-390
> URL: https://issues.apache.org/jira/browse/DISPATCH-390
> Project: Qpid Dispatch
>  Issue Type: New Feature
>  Components: Container
>Affects Versions: 0.6.0
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: 1.0.0
>
> Attachments: exp_count.core.zip
>
>
> Replace the current proton IO driver with a driver based on the pn_proactor 
> API. This will allow drop-in replacement of the IO layer for different 
> platforms.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Updated] (QPID-7763) [Java Broker] Flow to disk if allocated direct memory exceeds broker wide broker.flowToDiskThreshold

2017-05-17 Thread Keith Wall (JIRA)

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

Keith Wall updated QPID-7763:
-
Fix Version/s: qpid-java-6.1.3
   qpid-java-broker-7.0.0
   qpid-java-6.0.7

> [Java Broker] Flow to disk if allocated direct memory exceeds broker wide 
> broker.flowToDiskThreshold
> 
>
> Key: QPID-7763
> URL: https://issues.apache.org/jira/browse/QPID-7763
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Reporter: Lorenz Quack
>Assignee: Alex Rudyy
> Fix For: qpid-java-6.0.7, qpid-java-broker-7.0.0, qpid-java-6.1.3
>
>
> Currently the broker.flowToDiskThreshold is compared against the size used by 
> messages on queues.
> However, the intent was to have a mechanism for preventing the broker going 
> out of direct memory. For this it is much more interesting to observe how 
> much direct memory the QpidByteBuffers use. The two numbers can easily differ 
> since the QBB can be sparsely populated. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Commented] (DISPATCH-512) Link route with alternate that can drain and revert

2017-05-17 Thread Gary Tully (JIRA)

[ 
https://issues.apache.org/jira/browse/DISPATCH-512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16014044#comment-16014044
 ] 

Gary Tully commented on DISPATCH-512:
-

Another view of the same thing is that a message producer has a latency on send 
guarantee. Either the message goes directly to a consumer or  the message gets 
diverted to the alternative sink/source if consumers go away or are too slow to 
respond.

> Link route with alternate that can drain and revert
> ---
>
> Key: DISPATCH-512
> URL: https://issues.apache.org/jira/browse/DISPATCH-512
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Routing Engine
>Reporter: Gary Tully
>
> Link routing provides for direct dispatch. A sender can be directly 
> associated with a receiver.
> What happens when there is no receiver?
> Having the option to use an alternative or divert address when the receivers 
> are unavailable, and having the ability for the router to fall back to the 
> original when the divert address has drained would be magical.
> For example:
> Sender published to address A
> Receiver consumes from A and Sender is rate limited to the consumption rate 
> of the receiver. all is good.
> Receiver goes offline. At this point the Sender can block, however, if there 
> is an alternative address, the Sender can continue to publish at any rate.
> When the Receiver come online, the routing engine 'diverts' it to the 
> alternate address.
> At some stage the routing engine may be able to undo the divert and reconnect 
> the link from Sender to Receiver, once the alternate address has drained.
> In theory this seems possible, in practice it may be tricky, but it would be 
> a smashing feature.
> For a bursty Sender it always gets to publish.
> For a receiver, it gets to consume as fast as it can, and if it cannot 
> keep-up (or is offline) it gets to resume from a alternative address and then 
> auto reconnected to the Sender when there is a window to switch back. i.e: a 
> pause in the producer.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Created] (PROTON-1483) proactor/epoll.c:181: ptimer_callback: Assertion

2017-05-17 Thread Chuck Rolke (JIRA)
Chuck Rolke created PROTON-1483:
---

 Summary: proactor/epoll.c:181: ptimer_callback: Assertion
 Key: PROTON-1483
 URL: https://issues.apache.org/jira/browse/PROTON-1483
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-c
Affects Versions: 0.18.0
 Environment: Fedora 25
Master source builds of qpid-proton and qpid-dispatch
Reporter: Chuck Rolke
 Attachments: A.conf, B.conf

Start a dispatch router network of two routers. Send client traffic or not. Let 
it sit for a few minutes.
{noformat}
qdrouterd: /home/chug/git/qpid-proton/proton-c/src/proactor/epoll.c:181: 
ptimer_callback: Assertion `exp_count >= pt->skip_count' failed.
{noformat}

Either router A or B may fail this way. Looking at one core dump the internals 
show:

{noformat}
(gdb) list
176   ssize_t l = read(pt->timerfd, _exp_count, sizeof(uint64_t));
177   (void)l; /* Silence compiler complaints in release build */
178   assert(l == sizeof(uint64_t));
179   assert(u_exp_count < INT_MAX);  // or test and log it?
180   int exp_count = (int) u_exp_count;
181   assert(exp_count >= pt->skip_count);
182   assert(exp_count <= pt->pending_count);
183   exp_count -= pt->skip_count;
184   pt->skip_count = 0;
185   pt->pending_count -= exp_count;

(gdb) p exp_count
$1 = 1
(gdb) p pt->skip_count 
$2 = 2

(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:58
#1  0x7fc51c49d51a in __GI_abort () at abort.c:89
#2  0x7fc51c493da7 in __assert_fail_base (fmt=, 
assertion=assertion@entry=0x7fc51d45fbc2 "exp_count >= pt->skip_count", 
file=file@entry=0x7fc51d45fb30 
"/home/chug/git/qpid-proton/proton-c/src/proactor/epoll.c", 
line=line@entry=181, 
function=function@entry=0x7fc51d45fe70 <__PRETTY_FUNCTION__.7041> 
"ptimer_callback") at assert.c:92
#3  0x7fc51c493e52 in __GI___assert_fail (assertion=0x7fc51d45fbc2 
"exp_count >= pt->skip_count", file=0x7fc51d45fb30 
"/home/chug/git/qpid-proton/proton-c/src/proactor/epoll.c", line=181, 
function=0x7fc51d45fe70 <__PRETTY_FUNCTION__.7041> "ptimer_callback") at 
assert.c:101
#4  0x7fc51d45b620 in ptimer_callback (pt=0xfd8db8) at 
/home/chug/git/qpid-proton/proton-c/src/proactor/epoll.c:181
#5  0x7fc51d45ebae in proactor_process (p=0xfd8d40, timeout=true) at 
/home/chug/git/qpid-proton/proton-c/src/proactor/epoll.c:1537
#6  0x7fc51d45f0ae in proactor_do_epoll (p=0xfd8d40, can_block=true) at 
/home/chug/git/qpid-proton/proton-c/src/proactor/epoll.c:1657
#7  0x7fc51d45f196 in pn_proactor_wait (p=0xfd8d40) at 
/home/chug/git/qpid-proton/proton-c/src/proactor/epoll.c:1680
#8  0x7fc51d901d6a in thread_run (arg=0xfcfdd0) at 
/home/chug/git/qpid-dispatch/src/server.c:817
#9  0x7fc51d2416ca in start_thread (arg=0x7fc50fd93700) at 
pthread_create.c:333
#10 0x7fc51c56df7f in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:105
{noformat}

The attached conf files are for the test routers.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[GitHub] qpid-jms issue #7: Client+Server class additions - updated 5/15/17

2017-05-17 Thread gemmellr
Github user gemmellr commented on the issue:

https://github.com/apache/qpid-jms/pull/7
  
Hi Austin,

I've squashed your chagnes into a single commit 
(https://github.com/apache/qpid-jms/commit/72c7bb0880b5cc7dd332c0220091f93d0de9a5a2)
 and put it in along with further commit 
(https://github.com/apache/qpid-jms/commit/8a1a498c6c8307da1e3079c09c3d4d2e0aff5776)
 to fix up some remaining indentation+tab issues and make some small 
simplification+clarification changes. Thanks for the contribution!


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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



[GitHub] qpid-jms pull request #7: Client+Server class additions - updated 5/15/17

2017-05-17 Thread asfgit
Github user asfgit closed the pull request at:

https://github.com/apache/qpid-jms/pull/7


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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



[jira] [Commented] (QPID-7434) Mature the AMQP message conversion layer (headers and content)

2017-05-17 Thread Keith Wall (JIRA)

[ 
https://issues.apache.org/jira/browse/QPID-7434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16013896#comment-16013896
 ] 

Keith Wall commented on QPID-7434:
--

We notice that the from 0-10 conversion classes do not guard against null 0-10 
header e.g. 
org.apache.qpid.server.protocol.v0_10.MessageConverter_v0_10_to_Internal#convert

> Mature the AMQP message conversion layer (headers and content)
> --
>
> Key: QPID-7434
> URL: https://issues.apache.org/jira/browse/QPID-7434
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
>
> There are a number of gaps in our message converters that mean some message 
> are not converters with complete fidelity (particularly in the treatment of 
> application headers), and where complete fidelity cannot be acheived we need 
> sensible rules, uniformly implemented to decide how aspects degrade.
> For instance, for AMQP 0-8..0-10 allow application headers whose values were 
> complex types (e.g. map).  AMQP 1.0 disallows this.  What should the 
> behaviour be?  Should the header be dropped?
> Another instance is the length and constituency of the keys of application 
> headers.  AMQP 0-8..0-10 have a protocol restriction of 255 UTF8 bytes.  AMQP 
> has supports longer strings.  Also AMQP 0-9 says further restricts the key to 
> be formed like a Java identifier.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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



[jira] [Commented] (DISPATCH-757) Qpid Dispatch does not compile under Ubuntu

2017-05-17 Thread Jiri Danek (JIRA)

[ 
https://issues.apache.org/jira/browse/DISPATCH-757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16013740#comment-16013740
 ] 

Jiri Danek commented on DISPATCH-757:
-

Another test failure I haven't seen yet, in log at 
https://travis-ci.org/msgqe/travisci/builds/233129345. Because of the way this 
is executed, I don't have access to the core file. I could try to have it run 
in a loop locally until crash and hope to reproduce it this way, if asked...

{noformat}
13: test_zzz_qdmanage_delete_link_route 
(system_tests_link_routes.LinkRouteTest) ... ok
13: ERROR
13: 
13: ==
13: ERROR: tearDownClass (system_tests_link_routes.LinkRouteTest)
13: --
13: Traceback (most recent call last):
13:   File "/main/qpid-dispatch/tests/system_test.py", line 605, in 
tearDownClass
13: cls.tester.teardown()
13:   File "/main/qpid-dispatch/tests/system_test.py", line 543, in teardown
13: raise RuntimeError("Errors during teardown: \n\n%s" % 
"\n\n".join([str(e) for e in errors]))
13: RuntimeError: Errors during teardown: 
13: 
13: Process 26 error: exit code -6, expected 0
13: qdrouterd -c C.conf -I /main/qpid-dispatch/python
13: 
/main/qpid-dispatch/build/tests/system_test.dir/system_tests_link_routes/LinkRouteTest/setUpClass/C-3.cmd
13: 
13: *** Error in `qdrouterd': corrupted double-linked list: 0x55cbadc607a0 
***
13: === Backtrace: =
13: /lib/x86_64-linux-gnu/libc.so.6(+0x70bcb)[0x7f9059724bcb]
13: /lib/x86_64-linux-gnu/libc.so.6(+0x76f96)[0x7f905972af96]
13: /lib/x86_64-linux-gnu/libc.so.6(+0x77f6f)[0x7f905972bf6f]
13: /lib/libqpid-proton-core.so.11(pn_class_decref+0x56)[0x7f905a824c86]
13: /lib/libqpid-proton-proactor.so.11(+0x4642)[0x7f905a611642]
13: /lib/libqpid-proton-proactor.so.11(+0x4cad)[0x7f905a611cad]
13: /main/qpid-dispatch/build/src/libqpid-dispatch.so(+0x42c99)[0x7f905aa8fc99]
13: /lib/x86_64-linux-gnu/libpthread.so.0(+0x7494)[0x7f905a3f7494]
13: /lib/x86_64-linux-gnu/libc.so.6(clone+0x3f)[0x7f905979c93f]
13: === Memory map: 
13: 55cbabdff000-55cbabe02000 r-xp  00:29 468
/main/qpid-dispatch/build/router/qdrouterd
13: 55cbac001000-55cbac002000 r--p 2000 00:29 468
/main/qpid-dispatch/build/router/qdrouterd
13: 55cbac002000-55cbac003000 rw-p 3000 00:29 468
/main/qpid-dispatch/build/router/qdrouterd
13: 55cbad8d6000-55cbadd5e000 rw-p  00:00 0  
[heap]
13: 7f903c00-7f903c0ba000 rw-p  00:00 0 
13: 7f903c0ba000-7f904000 ---p  00:00 0 
13: 7f904400-7f90440ab000 rw-p  00:00 0 
13: 7f90440ab000-7f904800 ---p  00:00 0 
13: 7f904800-7f904811f000 rw-p  00:00 0 
13: 7f904811f000-7f904c00 ---p  00:00 0 
13: 7f904f613000-7f904f629000 r-xp  00:29 59 
/usr/lib/x86_64-linux-gnu/libgcc_s.so.1
13: 7f904f629000-7f904f828000 ---p 00016000 00:29 59 
/usr/lib/x86_64-linux-gnu/libgcc_s.so.1
13: 7f904f828000-7f904f829000 r--p 00015000 00:29 59 
/usr/lib/x86_64-linux-gnu/libgcc_s.so.1
13: 7f904f829000-7f904f82a000 rw-p 00016000 00:29 59 
/usr/lib/x86_64-linux-gnu/libgcc_s.so.1
13: 7f904f82a000-7f904f834000 r-xp  00:29 517
/usr/lib/x86_64-linux-gnu/libnss_files-2.24.so
13: 7f904f834000-7f904fa34000 ---p a000 00:29 517
/usr/lib/x86_64-linux-gnu/libnss_files-2.24.so
13: 7f904fa34000-7f904fa35000 r--p a000 00:29 517
/usr/lib/x86_64-linux-gnu/libnss_files-2.24.so
13: 7f904fa35000-7f904fa36000 rw-p b000 00:29 517
/usr/lib/x86_64-linux-gnu/libnss_files-2.24.so
13: 7f904fa36000-7f904fa3c000 rw-p  00:00 0 
13: 7f904fa3c000-7f904fa41000 r-xp  00:29 544
/usr/lib/x86_64-linux-gnu/sasl2/libcrammd5.so.2.0.25
13: 7f904fa41000-7f904fc4 ---p 5000 00:29 544
/usr/lib/x86_64-linux-gnu/sasl2/libcrammd5.so.2.0.25
13: 7f904fc4-7f904fc41000 r--p 4000 00:29 544
/usr/lib/x86_64-linux-gnu/sasl2/libcrammd5.so.2.0.25
13: 7f904fc41000-7f904fc42000 rw-p 5000 00:29 544
/usr/lib/x86_64-linux-gnu/sasl2/libcrammd5.so.2.0.25
13: 7f904fc42000-7f904fdf6000 r-xp  00:29 566
/usr/lib/x86_64-linux-gnu/libdb-5.3.so
13: 7f904fdf6000-7f904fff6000 ---p 001b4000 00:29 566
/usr/lib/x86_64-linux-gnu/libdb-5.3.so
13: 7f904fff6000-7f904fffd000 r--p 001b4000 00:29 566
/usr/lib/x86_64-linux-gnu/libdb-5.3.so
13: 7f904fffd000-7f905000 rw-p 001bb000 00:29 566
/usr/lib/x86_64-linux-gnu/libdb-5.3.so
13: