[jira] [Created] (QPID-8156) [Broker-J] Heap memory is leaked on deletion of virtual host node

2018-04-09 Thread Alex Rudyy (JIRA) 
Alex Rudyy created QPID-8156:


 Summary: [Broker-J] Heap memory is leaked on deletion of virtual 
host node
 Key: QPID-8156
 URL: https://issues.apache.org/jira/browse/QPID-8156
 Project: Qpid
  Issue Type: Improvement
  Components: Broker-J
Affects Versions: qpid-java-broker-7.0.3, qpid-java-broker-7.1.0
Reporter: Alex Rudyy


{{SystemNodeRegistry}} of deleted {{VirtualHost}} is still referenced after 
virtual host node deletion. It prevents its garbage collection. The reference 
to registry is hold by 
{{TrustStoreMessageSourceCreator$TrustStoreChangeListener}} which is registered 
 on broker as part of invocation {{TrustStoreMessageSourceCreator#register}}.

The user impact is minimalistic as it is not expected that virtual host nodes 
are often created and deleted in production environment.

Broker restart should resolve the issue.

Steps to reproduce:
 # create BDB HA virtual host node
 # delete BDB HA virtual host node
 # collect heap dump and check references to deleted virtual host node
{noformat}
select * from 
org.apache.qpid.server.virtualhostnode.berkeleydb.BDBHAVirtualHostNodeImplWithAccessChecking
{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

Re: [jira] [Commented] (PROTON-1823) [c] make it easier to send a message

2018-04-09 Thread Alan Conway 
On Fri, Apr 6, 2018 at 9:05 PM, Justin Ross (JIRA)  wrote:

>
> [ https://issues.apache.org/jira/browse/PROTON-1823?page=
> com.atlassian.jira.plugin.system.issuetabpanels:comment-
> tabpanel=16429180#comment-16429180 ]
>
> Justin Ross commented on PROTON-1823:
> -
>
> This is really nice!
>
> > [c] make it easier to send a message
> > 
> >
> > Key: PROTON-1823
> > URL: https://issues.apache.org/jira/browse/PROTON-1823
> > Project: Qpid Proton
> >  Issue Type: Improvement
> >  Components: proton-c
> >Affects Versions: proton-c-0.22.0
> >Reporter: Alan Conway
> >Assignee: Alan Conway
> >Priority: Minor
> > Fix For: proton-c-0.23.0
> >
> >
> > Encapsulates the awkward allocate-encode-expand dance required by
> pn_message_encode()
> > Supports the following 2 scenarios:
> > 1. Simple: don't care about allocations, just send `pn_message_t *msg`
> and forget it:
> > pn_message_send(msg, sender, NULL)
> > 2. Efficient: re-use a buffer, buffer is allocated and expanded as
> required:
> > pn_rwbytes_t buffer=\{0}; // Zero initialize, libary will do the
> allocation
> > ...
> > pn_message_send(msg, sender, ); // Expand as needed
> > pn_message_send(msg2, sender2, ); // etc.
> > ...
> > free(buffer->start);// Application must do final free of
> buffer
>
>
>
Since you like that here's another thought - add a public API for just the
"encode" part of pn_message_send() but allow the user to specify the
realloc function.
This covers two slightly more complicated cases with one extra API
function, the implementation is already written in pn_message_send:

1.  encode a message but don't send it immediately (e.g. because I have my
own in-memory message queues and don't want to hold up the proton IO thread
with the encoding work - which is among the  most CPU intensive things
proton does)

pn_message_encode_realloc(msg, , realloc); /* standard realloc */
  pn_link_send(sender, mybuf.start, mybuf.size); /*later*/

2. User your own allocator

pn_message_encode_realloc(msg, , _realloc_fn);

Originally I thought about adding a 'realloc' parameter to pn_message_send
itself, but that makes the simple cases less simple. By adding a separate
function that encodes, but doesn't send, we keep those cases simple but
kill 2 other birds with one stone (encoding outside the proton thread and
using your own allocator.)

Of course all this can be done directly by the user with the existing
pn_message_encode(), but it's about 25 error-prone lines so maybe worth
simplifying for something so common.

[jira] [Updated] (QPID-8156) [Broker-J] Heap memory is leaked on deletion of virtual host node

2018-04-09 Thread Alex Rudyy (JIRA) 

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

Alex Rudyy updated QPID-8156:
-
Description: 
{{SystemNodeRegistry}} of deleted {{VirtualHost}} is still referenced after 
virtual host node deletion. It prevents VHN/VH garbage collection. The 
reference to registry is hold by 
{{TrustStoreMessageSourceCreator$TrustStoreChangeListener}} which is registered 
 on broker as part of invocation {{TrustStoreMessageSourceCreator#register}}.

The user impact is minimalistic as it is not expected that virtual host nodes 
are often created and deleted in production environment.

Broker restart should resolve the issue.

Steps to reproduce:
 # create BDB HA virtual host node
 # delete BDB HA virtual host node
 # collect heap dump and check references to deleted virtual host node
{noformat}
select * from 
org.apache.qpid.server.virtualhostnode.berkeleydb.BDBHAVirtualHostNodeImplWithAccessChecking
{noformat}
 

  was:
{{SystemNodeRegistry}} of deleted {{VirtualHost}} is still referenced after 
virtual host node deletion. It prevents its garbage collection. The reference 
to registry is hold by 
{{TrustStoreMessageSourceCreator$TrustStoreChangeListener}} which is registered 
 on broker as part of invocation {{TrustStoreMessageSourceCreator#register}}.

The user impact is minimalistic as it is not expected that virtual host nodes 
are often created and deleted in production environment.

Broker restart should resolve the issue.

Steps to reproduce:
 # create BDB HA virtual host node
 # delete BDB HA virtual host node
 # collect heap dump and check references to deleted virtual host node
{noformat}
select * from 
org.apache.qpid.server.virtualhostnode.berkeleydb.BDBHAVirtualHostNodeImplWithAccessChecking
{noformat}
 


> [Broker-J] Heap memory is leaked on deletion of virtual host node
> -
>
> Key: QPID-8156
> URL: https://issues.apache.org/jira/browse/QPID-8156
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.3, qpid-java-broker-7.1.0
>Reporter: Alex Rudyy
>Priority: Major
>
> {{SystemNodeRegistry}} of deleted {{VirtualHost}} is still referenced after 
> virtual host node deletion. It prevents VHN/VH garbage collection. The 
> reference to registry is hold by 
> {{TrustStoreMessageSourceCreator$TrustStoreChangeListener}} which is 
> registered  on broker as part of invocation 
> {{TrustStoreMessageSourceCreator#register}}.
> The user impact is minimalistic as it is not expected that virtual host nodes 
> are often created and deleted in production environment.
> Broker restart should resolve the issue.
> Steps to reproduce:
>  # create BDB HA virtual host node
>  # delete BDB HA virtual host node
>  # collect heap dump and check references to deleted virtual host node
> {noformat}
> select * from 
> org.apache.qpid.server.virtualhostnode.berkeleydb.BDBHAVirtualHostNodeImplWithAccessChecking
> {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] (PROTON-1794) Improve detection strategy for executable python modules

2018-04-09 Thread ASF subversion and git services (JIRA) 

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

ASF subversion and git services commented on PROTON-1794:
-

Commit e91457c7ed2bf7caee9414b19df54264fba71444 in qpid-proton's branch 
refs/heads/master from [~astitcher]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=e91457c ]

PROTON-1794: Improve python module detection
- Specifically detecting/running tox

[reapplied as this was overwritten in the source tree reorg]


> Improve detection strategy for executable python modules
> 
>
> Key: PROTON-1794
> URL: https://issues.apache.org/jira/browse/PROTON-1794
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c, python-binding
>Reporter: Andrew Stitcher
>Assignee: Andrew Stitcher
>Priority: Major
> Fix For: proton-c-0.22.0
>
>
> We should make sure that detected python modules are actually the ones run by 
> the detected python interpreter.
> Currently we are just checking that the we can find an executable for the 
> module, but that doesn't ensure that it can actually run using the detected 
> python.
> [This applies to the build system's handling of the tox python module]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Closed] (QPID-8148) [Broker-J] Release Qpid Broker-J 7.0.3

2018-04-09 Thread Alex Rudyy (JIRA) 

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

Alex Rudyy closed QPID-8148.

Resolution: Fixed

> [Broker-J] Release Qpid Broker-J 7.0.3
> --
>
> Key: QPID-8148
> URL: https://issues.apache.org/jira/browse/QPID-8148
> Project: Qpid
>  Issue Type: Task
>  Components: Broker-J
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-7.0.3
>
>
> Release Qpid Broker-J following instructions provided at 
> [https://cwiki.apache.org/confluence/display/qpid/Releasing+Qpid+Broker-J]



--
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] (QPID-7926) [c++ broker] Windows build error "cannot convert from 'int' to 'qpid::sys::PODMutex"

2018-04-09 Thread Alan Conway (JIRA) 

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

Alan Conway updated QPID-7926:
--
Summary: [c++ broker] Windows build error "cannot convert from 'int' to 
'qpid::sys::PODMutex"  (was: [c++ broker] Windows PODMutex is not a POD)

> [c++ broker] Windows build error "cannot convert from 'int' to 
> 'qpid::sys::PODMutex"
> 
>
> Key: QPID-7926
> URL: https://issues.apache.org/jira/browse/QPID-7926
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker
>Affects Versions: qpid-cpp-1.36.0
> Environment: Windows Server 2012 R2, Visual Studio 2012, x64 build
> Today's master branch
>Reporter: Chuck Rolke
>Priority: Major
>
> {noformat}
> 1>-- Build started: Project: qpidcommon, Configuration: Debug x64 --
> 1>  Logger.cpp
> 1>D:\Users\crolke\git\qpid-cpp\src\qpid\log\Logger.cpp(48): error C2440: 
> 'initializing' : cannot convert from 'int' to 'qpid::sys::PODMutex'
> 1>  No constructor could take the source type, or constructor 
> overload resolution was ambiguous
> {noformat}
> The issue is with the definition of QPID_MUTEX_INITIALIZER.
> In Linux it is defined as PTHREAD_MUTEX_INITIALIZER which is a complex 
> structure initializer.
> In Windows it is a naked 0.
> In a stand-alone windows program
> {noformat}
> std::is_pod::value
> {noformat}
> returns false. In Linux the same statement in qpidd broker returns true.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Closed] (QPID-7892) [Java Broker] Qpid Logback plugin RollingPolicyDecorator tests fail since java.io.tmpdir pointed at directory containing parentheses

2018-04-09 Thread Alex Rudyy (JIRA) 

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

Alex Rudyy closed QPID-7892.

Assignee: (was: Alex Rudyy)

> [Java Broker] Qpid Logback plugin RollingPolicyDecorator tests fail since 
> java.io.tmpdir pointed at directory containing parentheses 
> -
>
> Key: QPID-7892
> URL: https://issues.apache.org/jira/browse/QPID-7892
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J, Java Tests
>Reporter: Keith Wall
>Priority: Minor
> Fix For: qpid-java-6.1.6, qpid-java-broker-7.0.0, qpid-java-6.0.9
>
>
> Currently on master the following tests are failing on Apache CI.  The fails 
> started at the point {{$\{java.io.tmpdir\}}} was reassigned to the Jenkins 
> job's workspace directory.   The workspace directory contains a pair of 
> parentheses.   The following tests are affected:
> {noformat}
> org.apache.qpid.server.logging.logback.RollingPolicyDecoratorTest.testSequentialRollover
> org.apache.qpid.server.logging.logback.RollingPolicyDecoratorTest.testRolloverRescanLimit
> org.apache.qpid.server.logging.logback.RollingPolicyDecoratorTest.testRolloverWithFile
> {noformat}
> I can see the issue is occurring because the regex match within 
> {{org.apache.qpid.server.logging.logback.RollingPolicyDecorator.ScanTask#scan}}
>  is treating the parentheses as regex meta characters and this is causing the 
> test to fail.
> I do not yet understand if this issue is a simple a test one, or whether core 
> code is affected.
> {{Pattern.escape}} can be used to escape regex metacharacters. Perhaps it 
> should be used??



--
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-1824) [Python binding] Use of proton.Array causes SIGSEGV in encoder

2018-04-09 Thread Kim van der Riet (JIRA) 
Kim van der Riet created PROTON-1824:


 Summary: [Python binding] Use of proton.Array causes SIGSEGV in 
encoder
 Key: PROTON-1824
 URL: https://issues.apache.org/jira/browse/PROTON-1824
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-c, python-binding
Reporter: Kim van der Riet
 Attachments: simple_send.py

Using proton.Array as a message body in Python 2.7 causes a segmentation fault 
in Proton.

A reproducer which is based on the Python examples simple_send.py is attached. 
The trace (last seven frames only) is as follows:
{noformat}
(gdb) bt
#0 0x7f54f71b27de in pn_encoder_writef32 (encoder=0x55f61e8602f0, 
value=512110782) at /home/kvdr/RedHat/qpid-proton/c/src/core/encoder.c:183
#1 0x7f54f71b3369 in pni_encoder_exit (ctx=0x55f61e8602f0, 
data=0x55f61e85fd70, node=0x55f61e863a98) at 
/home/kvdr/RedHat/qpid-proton/c/src/core/encoder.c:381
#2 0x7f54f71af26f in pni_data_traverse (data=0x55f61e85fd70, 
enter=0x7f54f71b2b8f , exit=0x7f54f71b31bd 
, ctx=0x55f61e8602f0)
at /home/kvdr/RedHat/qpid-proton/c/src/core/codec.c:1264
#3 0x7f54f71b3417 in pn_encoder_encode (encoder=0x55f61e8602f0, 
src=0x55f61e85fd70, dst=0x55f61e8630a0 "", size=16) at 
/home/kvdr/RedHat/qpid-proton/c/src/core/encoder.c:401
#4 0x7f54f71af925 in pn_data_encode (data=0x55f61e85fd70, 
bytes=0x55f61e8630a0 "", size=16) at 
/home/kvdr/RedHat/qpid-proton/c/src/core/codec.c:1441
#5 0x7f54f71c693d in pn_message_encode (msg=0x55f61e84ec40, 
bytes=0x55f61e8630a0 "", size=0x7fff60a71d10) at 
/home/kvdr/RedHat/qpid-proton/c/src/core/message.c:764
#6 0x7f54f742071c in _wrap_pn_message_encode (self=0x0, 
args=0x7f54f2a2a440) at 
/home/kvdr/RedHat/qpid-proton/build/python/cprotonPYTHON_wrap.c:4098
{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] [Closed] (QPID-8149) Release Apache Qpid for Java 6.1.6

2018-04-09 Thread Alex Rudyy (JIRA) 

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

Alex Rudyy closed QPID-8149.

Resolution: Fixed

> Release Apache Qpid for Java 6.1.6
> --
>
> Key: QPID-8149
> URL: https://issues.apache.org/jira/browse/QPID-8149
> Project: Qpid
>  Issue Type: Task
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-6.1.6
>
>
> Release Apache Qpid for Java 6.1.6 following the instructions at 
> [https://cwiki.apache.org/confluence/display/qpid/Releasing+Qpid+Java+Components+6.x]



--
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-8157) [Broker-J] Deletion of Virtual Host Node fails to clean-up properly all Virtual Host/Virtual Host Node resources

2018-04-09 Thread Alex Rudyy (JIRA) 
Alex Rudyy created QPID-8157:


 Summary: [Broker-J] Deletion of Virtual Host Node fails to 
clean-up properly all Virtual Host/Virtual Host Node resources
 Key: QPID-8157
 URL: https://issues.apache.org/jira/browse/QPID-8157
 Project: Qpid
  Issue Type: Improvement
  Components: Broker-J
Affects Versions: qpid-java-broker-7.1
Reporter: Alex Rudyy


Deletion of BDB HA Virtual Host Node ends up in left behind configuration and 
coalescing committer threads, open amqp connections, etc

Steps to reproduce
* Create BDB HA Virtual Host Node using management
* Delete BDB HA Virtual Host Node using management (preferably amqp management)
* Collect heap dump and check references to deleted  virtual host node
{noformat}
select * from 
org.apache.qpid.server.virtualhostnode.berkeleydb.BDBHAVirtualHostNodeImplWithAccessChecking
{noformat}

Only master sources are affected by the issue. It seems one of recent 
refactoring of delete functionality introduced the regression.




--
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-934) Add a way to annotate configuration as experimental

2018-04-09 Thread Ganesh Murthy (JIRA) 

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

Ganesh Murthy reassigned DISPATCH-934:
--

Assignee: Alan Conway  (was: Ganesh Murthy)

> Add a way to annotate configuration as experimental
> ---
>
> Key: DISPATCH-934
> URL: https://issues.apache.org/jira/browse/DISPATCH-934
> Project: Qpid Dispatch
>  Issue Type: New Feature
>  Components: Management Agent
>Reporter: Ted Ross
>Assignee: Alan Conway
>Priority: Minor
> Fix For: 1.1.0
>
>
> Add a management-schema annotation for entities and attributes that labels 
> them as "experimental".  Any time an experimental item is used in 
> configuration (or via the management protocol) the router shall issue a log 
> warning stating that the configuration is experimental and may not be 
> supported in the future.
>  



--
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-1824) [Python binding] Use of proton.Array causes SIGSEGV in Proton encoder

2018-04-09 Thread Justin Ross (JIRA) 

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

Justin Ross reassigned PROTON-1824:
---

Assignee: Andrew Stitcher

> [Python binding] Use of proton.Array causes SIGSEGV in Proton encoder
> -
>
> Key: PROTON-1824
> URL: https://issues.apache.org/jira/browse/PROTON-1824
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c, python-binding
>Reporter: Kim van der Riet
>Assignee: Andrew Stitcher
>Priority: Major
> Attachments: simple_send.py
>
>
> Using proton.Array as a message body in Python 2.7 causes a segmentation 
> fault in Proton.
> A reproducer which is based on the Python examples simple_send.py is 
> attached. The trace (last seven frames only) is as follows:
> {noformat}
> (gdb) bt
> #0 0x7f54f71b27de in pn_encoder_writef32 (encoder=0x55f61e8602f0, 
> value=512110782) at /home/kvdr/RedHat/qpid-proton/c/src/core/encoder.c:183
> #1 0x7f54f71b3369 in pni_encoder_exit (ctx=0x55f61e8602f0, 
> data=0x55f61e85fd70, node=0x55f61e863a98) at 
> /home/kvdr/RedHat/qpid-proton/c/src/core/encoder.c:381
> #2 0x7f54f71af26f in pni_data_traverse (data=0x55f61e85fd70, 
> enter=0x7f54f71b2b8f , exit=0x7f54f71b31bd 
> , ctx=0x55f61e8602f0)
> at /home/kvdr/RedHat/qpid-proton/c/src/core/codec.c:1264
> #3 0x7f54f71b3417 in pn_encoder_encode (encoder=0x55f61e8602f0, 
> src=0x55f61e85fd70, dst=0x55f61e8630a0 "", size=16) at 
> /home/kvdr/RedHat/qpid-proton/c/src/core/encoder.c:401
> #4 0x7f54f71af925 in pn_data_encode (data=0x55f61e85fd70, 
> bytes=0x55f61e8630a0 "", size=16) at 
> /home/kvdr/RedHat/qpid-proton/c/src/core/codec.c:1441
> #5 0x7f54f71c693d in pn_message_encode (msg=0x55f61e84ec40, 
> bytes=0x55f61e8630a0 "", size=0x7fff60a71d10) at 
> /home/kvdr/RedHat/qpid-proton/c/src/core/message.c:764
> #6 0x7f54f742071c in _wrap_pn_message_encode (self=0x0, 
> args=0x7f54f2a2a440) at 
> /home/kvdr/RedHat/qpid-proton/build/python/cprotonPYTHON_wrap.c:4098
> {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

[GitHub] qpid-dispatch pull request #281: NO-JIRA: Update some doc attribute names

2018-04-09 Thread asfgit 
Github user asfgit closed the pull request at:

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


---

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

[jira] [Commented] (PROTON-1794) Improve detection strategy for executable python modules

2018-04-09 Thread Justin Ross (JIRA) 

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

Justin Ross commented on PROTON-1794:
-

Sorry!

> Improve detection strategy for executable python modules
> 
>
> Key: PROTON-1794
> URL: https://issues.apache.org/jira/browse/PROTON-1794
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c, python-binding
>Reporter: Andrew Stitcher
>Assignee: Andrew Stitcher
>Priority: Major
> Fix For: proton-c-0.22.0
>
>
> We should make sure that detected python modules are actually the ones run by 
> the detected python interpreter.
> Currently we are just checking that the we can find an executable for the 
> module, but that doesn't ensure that it can actually run using the detected 
> python.
> [This applies to the build system's handling of the tox python module]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[GitHub] qpid-cpp pull request #13: QPID-7926: [c++ broker] Windows build error "cann...

2018-04-09 Thread alanconway 
GitHub user alanconway opened a pull request:

https://github.com/apache/qpid-cpp/pull/13

QPID-7926: [c++ broker] Windows build error "cannot convert from 'int…

…' to 'qpid::sys::PODMutex'"

Renamed PODMutex as GlobalMutex. The important point is that it can be used 
as a
global variable. In POSIX we use a POD class and static initializer to 
acomplish
this, but on windows we use boost::recursive_mutex, which is documented as 
being
safe for use as a global variable.

Modified the QPID_MUTEX_INITIALIZER macro to be empty on windows and '= { 0 
}'
on POSIX.

This closes #11

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

$ git pull https://github.com/alanconway/qpid-cpp winfix

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

https://github.com/apache/qpid-cpp/pull/13.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 #13


commit e078f320b656fb1b5c79b3a9e490fca23e4d03f7
Author: Justin Ross 
Date:   2018-03-28T13:40:03Z

QPID-7926: [c++ broker] Windows build error "cannot convert from 'int' to 
'qpid::sys::PODMutex'"

Renamed PODMutex as GlobalMutex. The important point is that it can be used 
as a
global variable. In POSIX we use a POD class and static initializer to 
acomplish
this, but on windows we use boost::recursive_mutex, which is documented as 
being
safe for use as a global variable.

Modified the QPID_MUTEX_INITIALIZER macro to be empty on windows and '= { 0 
}'
on POSIX.

This closes #11




---

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

[jira] [Commented] (QPID-7926) [c++ broker] Windows build error "cannot convert from 'int' to 'qpid::sys::PODMutex"

2018-04-09 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on QPID-7926:
--

GitHub user alanconway opened a pull request:

https://github.com/apache/qpid-cpp/pull/13

QPID-7926: [c++ broker] Windows build error "cannot convert from 'int…

…' to 'qpid::sys::PODMutex'"

Renamed PODMutex as GlobalMutex. The important point is that it can be used 
as a
global variable. In POSIX we use a POD class and static initializer to 
acomplish
this, but on windows we use boost::recursive_mutex, which is documented as 
being
safe for use as a global variable.

Modified the QPID_MUTEX_INITIALIZER macro to be empty on windows and '= { 0 
}'
on POSIX.

This closes #11

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

$ git pull https://github.com/alanconway/qpid-cpp winfix

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

https://github.com/apache/qpid-cpp/pull/13.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 #13


commit e078f320b656fb1b5c79b3a9e490fca23e4d03f7
Author: Justin Ross 
Date:   2018-03-28T13:40:03Z

QPID-7926: [c++ broker] Windows build error "cannot convert from 'int' to 
'qpid::sys::PODMutex'"

Renamed PODMutex as GlobalMutex. The important point is that it can be used 
as a
global variable. In POSIX we use a POD class and static initializer to 
acomplish
this, but on windows we use boost::recursive_mutex, which is documented as 
being
safe for use as a global variable.

Modified the QPID_MUTEX_INITIALIZER macro to be empty on windows and '= { 0 
}'
on POSIX.

This closes #11




> [c++ broker] Windows build error "cannot convert from 'int' to 
> 'qpid::sys::PODMutex"
> 
>
> Key: QPID-7926
> URL: https://issues.apache.org/jira/browse/QPID-7926
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker
>Affects Versions: qpid-cpp-1.36.0
> Environment: Windows Server 2012 R2, Visual Studio 2012, x64 build
> Today's master branch
>Reporter: Chuck Rolke
>Priority: Major
>
> {noformat}
> 1>-- Build started: Project: qpidcommon, Configuration: Debug x64 --
> 1>  Logger.cpp
> 1>D:\Users\crolke\git\qpid-cpp\src\qpid\log\Logger.cpp(48): error C2440: 
> 'initializing' : cannot convert from 'int' to 'qpid::sys::PODMutex'
> 1>  No constructor could take the source type, or constructor 
> overload resolution was ambiguous
> {noformat}
> The issue is with the definition of QPID_MUTEX_INITIALIZER.
> In Linux it is defined as PTHREAD_MUTEX_INITIALIZER which is a complex 
> structure initializer.
> In Windows it is a naked 0.
> In a stand-alone windows program
> {noformat}
> std::is_pod::value
> {noformat}
> returns false. In Linux the same statement in qpidd broker returns true.



--
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] (QPID-7926) [c++ broker] Windows build error "cannot convert from 'int' to 'qpid::sys::PODMutex"

2018-04-09 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on QPID-7926:
--

Github user alanconway commented on the issue:

https://github.com/apache/qpid-cpp/pull/13
  
This patch cleas up a bit rather than working around the problem like pull 
#11 (which would also work.)


> [c++ broker] Windows build error "cannot convert from 'int' to 
> 'qpid::sys::PODMutex"
> 
>
> Key: QPID-7926
> URL: https://issues.apache.org/jira/browse/QPID-7926
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker
>Affects Versions: qpid-cpp-1.36.0
> Environment: Windows Server 2012 R2, Visual Studio 2012, x64 build
> Today's master branch
>Reporter: Chuck Rolke
>Priority: Major
>
> {noformat}
> 1>-- Build started: Project: qpidcommon, Configuration: Debug x64 --
> 1>  Logger.cpp
> 1>D:\Users\crolke\git\qpid-cpp\src\qpid\log\Logger.cpp(48): error C2440: 
> 'initializing' : cannot convert from 'int' to 'qpid::sys::PODMutex'
> 1>  No constructor could take the source type, or constructor 
> overload resolution was ambiguous
> {noformat}
> The issue is with the definition of QPID_MUTEX_INITIALIZER.
> In Linux it is defined as PTHREAD_MUTEX_INITIALIZER which is a complex 
> structure initializer.
> In Windows it is a naked 0.
> In a stand-alone windows program
> {noformat}
> std::is_pod::value
> {noformat}
> returns false. In Linux the same statement in qpidd broker returns true.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[GitHub] qpid-cpp issue #13: QPID-7926: [c++ broker] Windows build error "cannot conv...

2018-04-09 Thread alanconway 
Github user alanconway commented on the issue:

https://github.com/apache/qpid-cpp/pull/13
  
This patch cleas up a bit rather than working around the problem like pull 
#11 (which would also work.)


---

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

[jira] [Assigned] (QPID-7926) [c++ broker] Windows build error "cannot convert from 'int' to 'qpid::sys::PODMutex"

2018-04-09 Thread Alan Conway (JIRA) 

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

Alan Conway reassigned QPID-7926:
-

Assignee: Alan Conway

> [c++ broker] Windows build error "cannot convert from 'int' to 
> 'qpid::sys::PODMutex"
> 
>
> Key: QPID-7926
> URL: https://issues.apache.org/jira/browse/QPID-7926
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker
>Affects Versions: qpid-cpp-1.36.0
> Environment: Windows Server 2012 R2, Visual Studio 2012, x64 build
> Today's master branch
>Reporter: Chuck Rolke
>Assignee: Alan Conway
>Priority: Major
>
> {noformat}
> 1>-- Build started: Project: qpidcommon, Configuration: Debug x64 --
> 1>  Logger.cpp
> 1>D:\Users\crolke\git\qpid-cpp\src\qpid\log\Logger.cpp(48): error C2440: 
> 'initializing' : cannot convert from 'int' to 'qpid::sys::PODMutex'
> 1>  No constructor could take the source type, or constructor 
> overload resolution was ambiguous
> {noformat}
> The issue is with the definition of QPID_MUTEX_INITIALIZER.
> In Linux it is defined as PTHREAD_MUTEX_INITIALIZER which is a complex 
> structure initializer.
> In Windows it is a naked 0.
> In a stand-alone windows program
> {noformat}
> std::is_pod::value
> {noformat}
> returns false. In Linux the same statement in qpidd broker returns true.



--
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] (QPID-7926) [c++ broker] Windows build error "cannot convert from 'int' to 'qpid::sys::PODMutex"

2018-04-09 Thread Alan Conway (JIRA) 

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

Alan Conway reassigned QPID-7926:
-

Assignee: Chuck Rolke  (was: Alan Conway)

> [c++ broker] Windows build error "cannot convert from 'int' to 
> 'qpid::sys::PODMutex"
> 
>
> Key: QPID-7926
> URL: https://issues.apache.org/jira/browse/QPID-7926
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker
>Affects Versions: qpid-cpp-1.36.0
> Environment: Windows Server 2012 R2, Visual Studio 2012, x64 build
> Today's master branch
>Reporter: Chuck Rolke
>Assignee: Chuck Rolke
>Priority: Major
>
> {noformat}
> 1>-- Build started: Project: qpidcommon, Configuration: Debug x64 --
> 1>  Logger.cpp
> 1>D:\Users\crolke\git\qpid-cpp\src\qpid\log\Logger.cpp(48): error C2440: 
> 'initializing' : cannot convert from 'int' to 'qpid::sys::PODMutex'
> 1>  No constructor could take the source type, or constructor 
> overload resolution was ambiguous
> {noformat}
> The issue is with the definition of QPID_MUTEX_INITIALIZER.
> In Linux it is defined as PTHREAD_MUTEX_INITIALIZER which is a complex 
> structure initializer.
> In Windows it is a naked 0.
> In a stand-alone windows program
> {noformat}
> std::is_pod::value
> {noformat}
> returns false. In Linux the same statement in qpidd broker returns true.



--
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] (QPID-7926) [c++ broker] Windows build error "cannot convert from 'int' to 'qpid::sys::PODMutex"

2018-04-09 Thread Alan Conway (JIRA) 

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

Alan Conway commented on QPID-7926:
---

I've put a fix at [https://github.com/apache/qpid-cpp/pull/13]

The master branch is broken on windows right now (on Appveyor) and I don't have 
a windows box to build & test, [~chug]can you commit this when the master 
branch is fixed?

> [c++ broker] Windows build error "cannot convert from 'int' to 
> 'qpid::sys::PODMutex"
> 
>
> Key: QPID-7926
> URL: https://issues.apache.org/jira/browse/QPID-7926
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker
>Affects Versions: qpid-cpp-1.36.0
> Environment: Windows Server 2012 R2, Visual Studio 2012, x64 build
> Today's master branch
>Reporter: Chuck Rolke
>Assignee: Chuck Rolke
>Priority: Major
>
> {noformat}
> 1>-- Build started: Project: qpidcommon, Configuration: Debug x64 --
> 1>  Logger.cpp
> 1>D:\Users\crolke\git\qpid-cpp\src\qpid\log\Logger.cpp(48): error C2440: 
> 'initializing' : cannot convert from 'int' to 'qpid::sys::PODMutex'
> 1>  No constructor could take the source type, or constructor 
> overload resolution was ambiguous
> {noformat}
> The issue is with the definition of QPID_MUTEX_INITIALIZER.
> In Linux it is defined as PTHREAD_MUTEX_INITIALIZER which is a complex 
> structure initializer.
> In Windows it is a naked 0.
> In a stand-alone windows program
> {noformat}
> std::is_pod::value
> {noformat}
> returns false. In Linux the same statement in qpidd broker returns true.



--
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: Wrt QPID-7926

2018-04-09 Thread Alan Conway 
On Fri, Apr 6, 2018 at 4:52 PM, Chuck Rolke  wrote:

> There has been another solution waiting in a github pull request.
>
> https://github.com/apache/qpid-cpp/pull/11
>
>
This fix looks like it would work, but I put a slightly clearer fix on
https://github.com/apache/qpid-cpp/pull/13
It gets rid of the bogus assignment rather than working around it by adding
a dummy constructor.
Chuck can you commit this? I don't have a local windows box set up and
Appveyor is telling me that the master branch is broken before applying the
fix.


> - Original Message -
> > From: "Alan Conway" 
> > To: "qpid" 
> > Sent: Friday, April 6, 2018 3:33:17 PM
> > Subject: Re: Wrt QPID-7926
> >
> > On Fri, Apr 6, 2018 at 4:33 AM, Michael Arnold  wrote:
> >
> > > Hi,
> > >
> > > Have a couple of questions wrt QPID-7926
> > >
> > > Question 1: what is the relevance of the is_pod<> result?
> > >
> > > JIRA- 7926 (https://issues.apache.org/jira/browse/QPID-7926) states
> that:
> > > "In a stand-alone windows program
> > > std::is_pod::value
> > > returns false. In Linux the same statement in qpidd broker returns
> true."
> > >
> > > If I execute:
> > > grep -r is_pod
> > > in qpid-cpp-1.38.0 directory I get nothing i.e. from what I can see the
> > > broker never uses "is_pod".  What am I missing?
> > >
> >
> > There is no requirement for PODMutex to be a POD, only that it can be
> > initialized at file scope in a thread-safe way. In linux we handle that
> by
> > making it a POD, which gets initialized at library load (before any
> > possible calls) rather than at C++-global-constructor time, when the
> order
> > of constructors between compilation units is undefined, so one
> compilation
> > units (C++ source file) might start using un-constructed global variables
> > in another.
> >
> >
> > > Question 2: Is this a possible approach?
> > > I find 3 non-comment lines using QPID_MUTEX_INITIALIZER:
> > > src/qpid/sys/posix/Mutex.h:#define QPID_MUTEX_INITIALIZER {
> > > PTHREAD_MUTEX_INITIALIZER }
> > > src/qpid/sys/windows/Mutex.h:#define QPID_MUTEX_INITIALIZER 0
> > > src/qpid/log/Logger.cpp:sys::PODMutex loggerLock =
> QPID_MUTEX_INITIALIZER;
> > >
> > > Where the last line is generating the compiler error under windows,
> due to
> > > the type mismatch.
> > >
> > > For windows PODMutex, is a thin wrapper around boost::recusive_mutex,
> while
> > > under linux PODMutex is wrapper around pthread_mutex_t.
> > >
> > > From what I can see boost::recusive_mutex does not need to be
> initalised,
> > > but pthread_mutex_t does, hence under windows+boost the initialisation
> on
> > > the line:
> > > sys::PODMutex loggerLock = QPID_MUTEX_INITIALIZER;
> > > is not required.  So possibly src/qpid/log/Logger.cpp can become:
> > > #if defined(BOOST_WINDOWS)
> > > sys::PODMutex loggerLock;
> > > #else
> > > sys::PODMutex loggerLock = QPID_MUTEX_INITIALIZER;
> > > #endif
> > >
> > >
> > That would compile but has potential race conditions if the loggerLock
> > variable can be used from other compilation units before C++ global
> > constructors are run. For example if there are other C++ files that log
> > start-up information in their own global C++ constructors. It probably
> > won't bite you but if it does it will be a horror to debug.
> >
> > I'm sure that windows, or boost, or both, have a safe solution to this
> > problem. Probably similar to the pthreads/POD aggregate-initialiation
> > approach in Linux. Check the docs, it might require a special type of
> mutex.
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
> For additional commands, e-mail: dev-h...@qpid.apache.org
>
>

[GitHub] qpid-cpp issue #11: Fix build on Windows

2018-04-09 Thread alanconway 
Github user alanconway commented on the issue:

https://github.com/apache/qpid-cpp/pull/11
  
The fix would work but I'd prefer to get rid of the bogus assignment rather 
than add a dummy constructor to hide it. I've put up pull request #13 that does 
that.


---

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

[jira] [Updated] (QPID-8156) [Broker-J] Heap memory is leaked on deletion of virtual host node

2018-04-09 Thread Alex Rudyy (JIRA) 

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

Alex Rudyy updated QPID-8156:
-
Issue Type: Bug  (was: Improvement)

> [Broker-J] Heap memory is leaked on deletion of virtual host node
> -
>
> Key: QPID-8156
> URL: https://issues.apache.org/jira/browse/QPID-8156
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.3, qpid-java-broker-7.1.0
>Reporter: Alex Rudyy
>Priority: Major
>
> {{SystemNodeRegistry}} of deleted {{VirtualHost}} is still referenced after 
> virtual host node deletion. It prevents VHN/VH garbage collection. The 
> reference to registry is hold by 
> {{TrustStoreMessageSourceCreator$TrustStoreChangeListener}} which is 
> registered  on broker as part of invocation 
> {{TrustStoreMessageSourceCreator#register}}.
> The user impact is minimalistic as it is not expected that virtual host nodes 
> are often created and deleted in production environment.
> Broker restart should resolve the issue.
> Steps to reproduce:
>  # create BDB HA virtual host node
>  # delete BDB HA virtual host node
>  # collect heap dump and check references to deleted virtual host node
> {noformat}
> select * from 
> org.apache.qpid.server.virtualhostnode.berkeleydb.BDBHAVirtualHostNodeImplWithAccessChecking
> {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] [Updated] (QPID-8157) [Broker-J] Deletion of Virtual Host Node fails to clean-up properly all Virtual Host/Virtual Host Node resources

2018-04-09 Thread Alex Rudyy (JIRA) 

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

Alex Rudyy updated QPID-8157:
-
Issue Type: Bug  (was: Improvement)

> [Broker-J] Deletion of Virtual Host Node fails to clean-up properly all 
> Virtual Host/Virtual Host Node resources
> 
>
> Key: QPID-8157
> URL: https://issues.apache.org/jira/browse/QPID-8157
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.1
>Reporter: Alex Rudyy
>Priority: Major
>
> Deletion of BDB HA Virtual Host Node ends up in left behind configuration and 
> coalescing committer threads, open amqp connections, etc
> Steps to reproduce
> * Create BDB HA Virtual Host Node using management
> * Delete BDB HA Virtual Host Node using management (preferably amqp 
> management)
> * Collect heap dump and check references to deleted  virtual host node
> {noformat}
> select * from 
> org.apache.qpid.server.virtualhostnode.berkeleydb.BDBHAVirtualHostNodeImplWithAccessChecking
> {noformat}
> Only master sources are affected by the issue. It seems one of recent 
> refactoring of delete functionality introduced the regression.



--
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-8158) [Broker-J] [System Tests] Refactor BDB HA system tests

2018-04-09 Thread Alex Rudyy (JIRA) 
Alex Rudyy created QPID-8158:


 Summary: [Broker-J] [System Tests] Refactor BDB HA system tests
 Key: QPID-8158
 URL: https://issues.apache.org/jira/browse/QPID-8158
 Project: Qpid
  Issue Type: Improvement
  Components: Broker-J, Java Tests
Reporter: Alex Rudyy


Currently BDB HA system tests are extended from {{QpidBrokerTestCase}}. They 
need to be refactored to run with {{QpidTestRunner}}  similar to other system 
tests.
The BDB HA nodes  should be started as spawn brokers using special  
{{BrokerAdmin}} allowing to start broker in a separate JVM.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[GitHub] qpid-dispatch issue #281: NO-JIRA: Update some doc attribute names

2018-04-09 Thread bhardesty 
Github user bhardesty commented on the issue:

https://github.com/apache/qpid-dispatch/pull/281
  
@ganeshmurthy this is ready to merge.


---

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

[jira] [Updated] (PROTON-1824) [Python binding] Use of proton.Array causes SIGSEGV in Proton encoder

2018-04-09 Thread Kim van der Riet (JIRA) 

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

Kim van der Riet updated PROTON-1824:
-
Summary: [Python binding] Use of proton.Array causes SIGSEGV in Proton 
encoder  (was: [Python binding] Use of proton.Array causes SIGSEGV in encoder)

> [Python binding] Use of proton.Array causes SIGSEGV in Proton encoder
> -
>
> Key: PROTON-1824
> URL: https://issues.apache.org/jira/browse/PROTON-1824
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c, python-binding
>Reporter: Kim van der Riet
>Priority: Major
> Attachments: simple_send.py
>
>
> Using proton.Array as a message body in Python 2.7 causes a segmentation 
> fault in Proton.
> A reproducer which is based on the Python examples simple_send.py is 
> attached. The trace (last seven frames only) is as follows:
> {noformat}
> (gdb) bt
> #0 0x7f54f71b27de in pn_encoder_writef32 (encoder=0x55f61e8602f0, 
> value=512110782) at /home/kvdr/RedHat/qpid-proton/c/src/core/encoder.c:183
> #1 0x7f54f71b3369 in pni_encoder_exit (ctx=0x55f61e8602f0, 
> data=0x55f61e85fd70, node=0x55f61e863a98) at 
> /home/kvdr/RedHat/qpid-proton/c/src/core/encoder.c:381
> #2 0x7f54f71af26f in pni_data_traverse (data=0x55f61e85fd70, 
> enter=0x7f54f71b2b8f , exit=0x7f54f71b31bd 
> , ctx=0x55f61e8602f0)
> at /home/kvdr/RedHat/qpid-proton/c/src/core/codec.c:1264
> #3 0x7f54f71b3417 in pn_encoder_encode (encoder=0x55f61e8602f0, 
> src=0x55f61e85fd70, dst=0x55f61e8630a0 "", size=16) at 
> /home/kvdr/RedHat/qpid-proton/c/src/core/encoder.c:401
> #4 0x7f54f71af925 in pn_data_encode (data=0x55f61e85fd70, 
> bytes=0x55f61e8630a0 "", size=16) at 
> /home/kvdr/RedHat/qpid-proton/c/src/core/codec.c:1441
> #5 0x7f54f71c693d in pn_message_encode (msg=0x55f61e84ec40, 
> bytes=0x55f61e8630a0 "", size=0x7fff60a71d10) at 
> /home/kvdr/RedHat/qpid-proton/c/src/core/message.c:764
> #6 0x7f54f742071c in _wrap_pn_message_encode (self=0x0, 
> args=0x7f54f2a2a440) at 
> /home/kvdr/RedHat/qpid-proton/build/python/cprotonPYTHON_wrap.c:4098
> {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

[GitHub] qpid-cpp issue #11: Fix build on Windows

2018-04-09 Thread etengabeko 
Github user etengabeko commented on the issue:

https://github.com/apache/qpid-cpp/pull/11
  
I am agree. I only registered the problem and added temporary patch for fix 
it.


---

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

[jira] [Updated] (DISPATCH-959) Rate limiting policy

2018-04-09 Thread Ted Ross (JIRA) 

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

Ted Ross updated DISPATCH-959:
--
Fix Version/s: Backlog

> Rate limiting policy
> 
>
> Key: DISPATCH-959
> URL: https://issues.apache.org/jira/browse/DISPATCH-959
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Policy Engine, Routing Engine
>Affects Versions: 1.0.1
>Reporter: Chuck Rolke
>Priority: Major
> Fix For: Backlog
>
>
> Router administrators would like rate-limiting policies to allow different 
> classes of users. A network-rate limit similar to how home cable networks are 
> provisioned for bandwidth is a classic model and is being considered as the 
> first choice.
> A message-per-second limit might be easier to enforce. But a single user 
> message may have a large data section, or have a small data section but have 
> huge message annotations. Thus a user might consume a lot of network 
> bandwidth with only a few messages.
> It is still unclear at what level the rate limiting should be applied. 
> Choices are:
>  * Per vhost
>  * Per vhost connection
>  * Per vhost user



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