Re: Review Request 57702: NO-JIRA: c++ binding - removed circular #define

2017-03-16 Thread Andrew Stitcher 

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



This looks good: Note there is also a PN_WEAKREF object type which might also 
solve the problem, but I'm not entirely sure.


proton-c/src/proactor/libuv.c
Lines 252 (patched)


Might be slightly more idiomatic/clearer to use ```sizeof(pconnection_t)``` 
here, but it amounts to the same thing.


- Andrew Stitcher


On March 16, 2017, 8:41 p.m., Alan Conway wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57702/
> ---
> 
> (Updated March 16, 2017, 8:41 p.m.)
> 
> 
> Review request for qpid, Andrew Stitcher and Cliff Jansen.
> 
> 
> Repository: qpid-proton-git
> 
> 
> Description
> ---
> 
> PROTON-1440: libuv proactor - thread safe pn_connection_wake
> 
> This fix does not change the API but makes pn_connection_wake thread safe.
> 
> To be thread safe we need to a lock, so the pconnection_t attachment stays
> on the pn_connection_t until the pn_connection_t is destroyed.
> 
> pn_proactor_free also was modified to run the normal socket close sequence
> rather than a short-cut that just closes TCP sockets - this allows the
> wake locking logic to run as normal, even if the application calls wake
> after the proactor is freed.
> 
> also at https://github.com/alanconway/qpid-proton/tree/safe-wake
> 
> 
> Diffs
> -
> 
>   proton-c/bindings/cpp/src/contexts.cpp 
> 8da8f7cf5b64c75e7eaddc27069b8a7160e6f9d6 
>   proton-c/src/proactor/libuv.c 102fcdd8a30d2dd57d9545552bcfd695a251a66d 
>   proton-c/src/tests/proactor.c beba46e84c75fb36677576b645fd2f39bb238827 
> 
> 
> Diff: https://reviews.apache.org/r/57702/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Alan Conway
> 
>

[jira] [Closed] (QPID-7691) Qpid Python 1.36.0 release tasks

2017-03-16 Thread Justin Ross (JIRA) 

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

Justin Ross closed QPID-7691.
-
Resolution: Done

> Qpid Python 1.36.0 release tasks
> 
>
> Key: QPID-7691
> URL: https://issues.apache.org/jira/browse/QPID-7691
> Project: Qpid
>  Issue Type: Task
>  Components: Python Client, Python Test Suite
>Reporter: Justin Ross
>Assignee: Justin Ross
> Fix For: qpid-python-1.36.0
>
>




--
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-1440) pn_connection_wake to return bool status

2017-03-16 Thread Alan Conway (JIRA) 

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

Alan Conway commented on PROTON-1440:
-

Review request: https://github.com/alanconway/qpid-proton/tree/safe-wake 
https://reviews.apache.org/r/57702/

I have not changed the API - no return from wake. We can't (easily) guaratnee 
that the return value is correct, since the user has control of the event 
stream between _wait() and _done(), so calls to wake() concurrent with that are 
somewhat out of our control. So better to say nothing than claim there will be 
a WAKE event when there may not be. Wake is fully thread safe however, it can 
be called even after the proactor has been freed, but is a no-op.

The real issue is co-ordination with state outside the proactor, which can't be 
done from inside. Bindings like C++ can still provide more user-friendly 
guarantees, e.g. the c++ inject()  or dispatch qd_deferred_call guarantees  can 
still be implemented but need sync outside the proactor (for C++ it's in the 
event_loop).

> pn_connection_wake to return bool status
> 
>
> Key: PROTON-1440
> URL: https://issues.apache.org/jira/browse/PROTON-1440
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: 0.17.0
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: 0.18.0
>
>
> pn_connection_wake() allows any thread to send a PN_CONNECTION_WAKE event to 
> a proactor-managed connection. Currently it does not return any value, and 
> the application must ensure it is not called after the PN_TRANSPORT_CLOSED 
> event is processed for that connection.
> This is tricky for the application to synchronize and inconsistent with other 
> pn_connection_ functions. If refcounts are used to keep a pn_connection_t in 
> memory after the TRANSPORT_CLOSED, then calling wake() is an error even 
> though the pn_connection_t is valid.
> Change wake to be safe as long as the pn_connection_t is valid. It returns 
> true if the connection will be woken, false if it is too late.



--
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 57702: NO-JIRA: c++ binding - removed circular #define

2017-03-16 Thread Alan Conway 

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

Review request for qpid, Andrew Stitcher and Cliff Jansen.


Repository: qpid-proton-git


Description
---

PROTON-1440: libuv proactor - thread safe pn_connection_wake

This fix does not change the API but makes pn_connection_wake thread safe.

To be thread safe we need to a lock, so the pconnection_t attachment stays
on the pn_connection_t until the pn_connection_t is destroyed.

pn_proactor_free also was modified to run the normal socket close sequence
rather than a short-cut that just closes TCP sockets - this allows the
wake locking logic to run as normal, even if the application calls wake
after the proactor is freed.

also at https://github.com/alanconway/qpid-proton/tree/safe-wake


Diffs
-

  proton-c/bindings/cpp/src/contexts.cpp 
8da8f7cf5b64c75e7eaddc27069b8a7160e6f9d6 
  proton-c/src/proactor/libuv.c 102fcdd8a30d2dd57d9545552bcfd695a251a66d 
  proton-c/src/tests/proactor.c beba46e84c75fb36677576b645fd2f39bb238827 


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


Testing
---


Thanks,

Alan Conway

[jira] [Commented] (PROTON-1438) c proactor listening behavior

2017-03-16 Thread Andrew Stitcher (JIRA) 

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

Andrew Stitcher commented on PROTON-1438:
-

I'm not sure I like the 
https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=03ca9be change.

The newly allowed urls are not at all standard and it might be confusing to 
people why they work for proton but not for any other purpose.

Addi5tionally, there is a good reason why the '['...']' notation is introduced:

For example, how should you interpret fe80::fc54:ff:feb8:6942? This is intended 
to be [fe80::fc54:ff:feb8:6942]:5672 in all probability, but your code is going 
to interpret this as [fe80::fc54:ff:feb8]:6942, which is likely to be 
surprising and perhaps tricky to debug (as long hex strings that you cut and 
pasted are not user friendly to scan).

> c proactor listening behavior
> -
>
> Key: PROTON-1438
> URL: https://issues.apache.org/jira/browse/PROTON-1438
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: 0.17.0
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: 0.18.0
>
>
> Improved listening behavior for pn_proactor_listen to allow selective 
> listening by protocol (ipv4/v6) or portable "listen to everything".
> Host can be a host name, IPV4 or IPV6 literal,
> or the empty string/NULL (treated the same). The empty string listens on all 
> local addresses. A host name listens on all addresses associated with the 
> name. An IPV6 literal address (or wildcard '[::]') listens only for IPV6. An 
> IPV4 literal address (or wildcard '0.0.0.0') listens only for IPV4.
> - pn_proactor_listen may listen on more than one socket for ipv6/v4 or
> for DNS names with multiple address records.
> - the 'backlog' applies to *each* socket (open for debate - we might
> want to divide the backlog among sockets with some minimum if there's
> not enough)
> - pn_listener_close() closes all sockets, PN_LISTENER_CLOSE event
> indicates all sockets are closed.
> - An error on any socket will close all the sockets of the listener,
> PN_LISTERN_CLOSE event indicates all sockets are closed and provides
> the error that triggered the close.



--
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-1434) filter long-running python tests when running under tox

2017-03-16 Thread ASF subversion and git services (JIRA) 

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

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

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

PROTON-1434: add test blacklist to tox tests

This closes #98


> filter long-running python tests when running under tox
> ---
>
> Key: PROTON-1434
> URL: https://issues.apache.org/jira/browse/PROTON-1434
> Project: Qpid Proton
>  Issue Type: Test
>  Components: python-binding
>Affects Versions: 0.17.0
>Reporter: Ken Giusti
>Assignee: Ken Giusti
>Priority: Trivial
> Fix For: 0.18.0
>
>
> Running the entire python test suite under tox is largely redundant - these 
> tests have already been run as the python-test suite.
> The tox tests should really just exercise the binding layer - not the full 
> functionality of proton.
> Let's pare down the number of tox tests executed by filtering the 
> longer-running system tests.



--
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-1434) filter long-running python tests when running under tox

2017-03-16 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on PROTON-1434:


Github user asfgit closed the pull request at:

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


> filter long-running python tests when running under tox
> ---
>
> Key: PROTON-1434
> URL: https://issues.apache.org/jira/browse/PROTON-1434
> Project: Qpid Proton
>  Issue Type: Test
>  Components: python-binding
>Affects Versions: 0.17.0
>Reporter: Ken Giusti
>Assignee: Ken Giusti
>Priority: Trivial
> Fix For: 0.18.0
>
>
> Running the entire python test suite under tox is largely redundant - these 
> tests have already been run as the python-test suite.
> The tox tests should really just exercise the binding layer - not the full 
> functionality of proton.
> Let's pare down the number of tox tests executed by filtering the 
> longer-running system tests.



--
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-proton pull request #98: PROTON-1434: add test blacklist to tox tests

2017-03-16 Thread asfgit 
Github user asfgit closed the pull request at:

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


---
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] (DISPATCH-730) Coverity scan reported errors in Qpid Dispatch master

2017-03-16 Thread ASF subversion and git services (JIRA) 

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

ASF subversion and git services commented on DISPATCH-730:
--

Commit 36930bbd74462dbd20d4f0168c1acea91c6e7a72 in qpid-dispatch's branch 
refs/heads/master from [~ganeshmurthy]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=36930bb ]

DISPATCH-730 - Partial fix to some memory leaks reported by coverity


> Coverity scan reported errors in Qpid Dispatch master
> -
>
> Key: DISPATCH-730
> URL: https://issues.apache.org/jira/browse/DISPATCH-730
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Container
>Affects Versions: 0.8.0
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
> Fix For: 0.8.0
>
>
> 5 new defect(s) introduced to Apache Qpid dispatch-router found with Coverity 
> Scan.
> New defect(s) Reported-by: Coverity Scan
> Showing 5 of 5 defect(s)
> ** CID 142339:(USE_AFTER_FREE)
> /home/gmurthy/opensource/dispatch/src/router_core/connections.c: 284 in 
> qdr_connection_process()
> /home/gmurthy/opensource/dispatch/src/router_core/connections.c: 284 in 
> qdr_connection_process()
> 
> *** CID 142339:(USE_AFTER_FREE)
> /home/gmurthy/opensource/dispatch/src/router_core/connections.c: 284 in 
> qdr_connection_process()
> 278 if (link_work->work_type == QDR_LINK_WORK_DELIVERY && 
> link_work->value > 0) {
> 279 DEQ_INSERT_HEAD(link->work_list, link_work);
> 280 link_work = 0; // Halt work processing
> 281 } else {
> 282 qdr_error_free(link_work->error);
> 283 free_qdr_link_work_t(link_work);
> >>> CID 142339:(USE_AFTER_FREE)
> >>> Dereferencing freed pointer "link".
> 284 link_work = DEQ_HEAD(link->work_list);
> 285 if (link_work)
> 286 DEQ_REMOVE_HEAD(link->work_list);
> 287 }
> 288 sys_mutex_unlock(conn->work_lock);
> 289 event_count++;
> /home/gmurthy/opensource/dispatch/src/router_core/connections.c: 284 in 
> qdr_connection_process()
> 278 if (link_work->work_type == QDR_LINK_WORK_DELIVERY && 
> link_work->value > 0) {
> 279 DEQ_INSERT_HEAD(link->work_list, link_work);
> 280 link_work = 0; // Halt work processing
> 281 } else {
> 282 qdr_error_free(link_work->error);
> 283 free_qdr_link_work_t(link_work);
> >>> CID 142339:(USE_AFTER_FREE)
> >>> Dereferencing freed pointer "link".
> 284 link_work = DEQ_HEAD(link->work_list);
> 285 if (link_work)
> 286 DEQ_REMOVE_HEAD(link->work_list);
> 287 }
> 288 sys_mutex_unlock(conn->work_lock);
> 289 event_count++;
> ** CID 142338:  Resource leaks  (RESOURCE_LEAK)
> /home/gmurthy/opensource/dispatch/src/failoverlist.c: 103 in 
> qd_failover_list()
> 
> *** CID 142338:  Resource leaks  (RESOURCE_LEAK)
> /home/gmurthy/opensource/dispatch/src/failoverlist.c: 103 in 
> qd_failover_list()
> 97 char *cursor = list->text;
> 98 char *next;
> 99 do {
> 100 next = qd_fol_next(cursor, ",");
> 101 qd_failover_item_t *item = qd_fol_item(cursor, error);
> 102 if (item == 0)
> >>> CID 142338:  Resource leaks  (RESOURCE_LEAK)
> >>> Variable "list" going out of scope leaks the storage it points to.
> 103 return 0;
> 104 DEQ_INSERT_TAIL(list->item_list, item);
> 105 cursor = next;
> 106 } while (cursor && *cursor);
> 107
> 108 return list;
> ** CID 142337:  Null pointer dereferences  (FORWARD_NULL)
> /home/gmurthy/opensource/dispatch/src/server.c: 564 in decorate_connection()
> 
> *** CID 142337:  Null pointer dereferences  (FORWARD_NULL)
> /home/gmurthy/opensource/dispatch/src/server.c: 564 in decorate_connection()
> 558 if (config && config->inter_router_cost > 1) {
> 559 pn_data_put_symbol(pn_connection_properties(conn),
> 560
> pn_bytes(strlen(QD_CONNECTION_PROPERTY_COST_KEY), 
> QD_CONNECTION_PROPERTY_COST_KEY));
> 561

Re: Review Request 57662: PROTON-1438: C proactor listening behavior

2017-03-16 Thread Alan Conway 


> On March 16, 2017, 3:27 p.m., Andrew Stitcher wrote:
> > I've looked this over, and I can't see anything obviously wrong. But 
> > there's a lot of detailed churn in this change, and I'm not so familiar 
> > with libuv, so I'm not confident enough to say "ship it". But I agree with 
> > the overall direction.

That'll do :) Churn was hard to avoid since the previous code assumed 
socket==work item. To have multi-socket listeners I needed to make the 
distinction and rename to keep it clear which touched everything unfortunately. 
We'll sort out bugs as we find them...


- Alan


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


On March 15, 2017, 8:35 p.m., Alan Conway wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57662/
> ---
> 
> (Updated March 15, 2017, 8:35 p.m.)
> 
> 
> Review request for qpid, Andrew Stitcher and Cliff Jansen.
> 
> 
> Bugs: PROTON-1438
> https://issues.apache.org/jira/browse/PROTON-1438
> 
> 
> Repository: qpid-proton-git
> 
> 
> Description
> ---
> 
> (also available on https://github.com/alanconway/qpid-proton/tree/ipv4-ipv6)
> 
> Improved listening behavior for pn_proactor_listen to allow selective 
> listening by protocol (ipv4/v6) or portable "listen to everything".
> 
> Host can be a host name, IPV4 or IPV6 literal, or the empty string/NULL 
> (treated the same). The empty string listens on all local addresses. A host 
> name listens on all addresses associated with the name. An IPV6 literal 
> address (or wildcard '[::]') listens only for IPV6. An IPV4 literal address 
> (or wildcard '0.0.0.0') listens only for IPV4.
> 
> - pn_proactor_listen may listen on more than one socket for ipv6/v4 or for 
> DNS names with multiple address records.
> 
> - the 'backlog' applies to *each* socket
> 
> - an error on any socket will close all the sockets of the listener,  
> PN_LISTERN_CLOSE event indicates all sockets are closed and provides the 
> error that triggered the close.
> 
> PROTON-1438: added pn_event_condition convenience function
> 
> A convenience function to make it easier to write generic error handling
> functions for events.
> 
> /*
>  * If the event context object has a condition and the condition is set
>  * return it, otherwise return NULL.
>  * If the event context object has remote and local conditions,
>  * try the remote condition first, then the local.
>  */
> PN_EXTERN struct pn_condition_t *pn_event_condition(pn_event_t *event);
> 
> PROTON-1438: c libuv proactor - separate pn_connection_t on free
> 
> Separate pn_connection_t from proactor internal data structures when the
> proactor frees the connection - in case the application is using refcounting
> to pin the connection.
> 
> 
> Diffs
> -
> 
>   proton-c/include/proton/cid.h 2d688964cbf2cf17850ee2f4f93eb6c85c7eb1a8 
>   proton-c/include/proton/event.h 6f93cd4d33c121d9265649814f7770a99d61cd45 
>   proton-c/include/proton/listener.h 2038c064a8a4fd621f584fd02db93a6e4593b708 
>   proton-c/include/proton/proactor.h 43b8ccb85525631818b8393c5e7f9b07ae0b348d 
>   proton-c/src/core/engine.c 8c2aeb0d27a06384b7b1dc3488d9bb122dda7bd7 
>   proton-c/src/proactor/libuv.c 102fcdd8a30d2dd57d9545552bcfd695a251a66d 
>   proton-c/src/tests/proactor.c beba46e84c75fb36677576b645fd2f39bb238827 
>   proton-c/src/tests/test_tools.h 9fe679c4ce99f8bd8446343ea180ad10a9a60c7c 
> 
> 
> Diff: https://reviews.apache.org/r/57662/diff/1/
> 
> 
> Testing
> ---
> 
> Passes proton tests, including new proactor.c tests for ipv4/v6 listening and 
> connecting
> 
> 
> Thanks,
> 
> Alan Conway
> 
>

Inconsistent behaviour during performance testing

2017-03-16 Thread Vyborny Antonin 
Hi,

I have run some performance testing measuring the throughput for sending, 
receiving and also both in parallel. Please see the image I attached (sending).
I have measured with three different message sizes (1024, 10240 and 102400 
bytes). I am using from 1 to 20 threads for sending and the weird behaviour 
occurs when sending 102400 bytes messages. You can clearly see from the image 
that when I use 1-10 threads it is too slow and then suddenly it became much 
faster.
The strange is that this was not just one test case, I run it multiple times.
The same testing I performed on different brokers, but only Java broker has 
this behaviour.

Is there anything I might be missing? Any misconfiguration? I already tried to 
play with JVM memory and it looks like it has some impact to it...  When I 
increased the memory it became faster since 3rd thread...

Please note I was using asynchronous sending + non persistent delivery mode.

Best Regards

Antonin Vyborny


-
Diese E-Mail enthaelt vertrauliche oder rechtlich geschuetzte Informationen.
Wenn Sie nicht der beabsichtigte Empfaenger sind, informieren Sie bitte
sofort den Absender und loeschen Sie diese E-Mail. Das unbefugte Kopieren
dieser E-Mail oder die unbefugte Weitergabe der enthaltenen Informationen
ist nicht gestattet.

The information contained in this message is confidential or protected by
law. If you are not the intended recipient, please contact the sender and
delete this message. Any unauthorised copying of this message or
unauthorised distribution of the information contained herein is prohibited.

Legally required information for business correspondence/
Gesetzliche Pflichtangaben fuer Geschaeftskorrespondenz:
http://deutsche-boerse.com/letterhead

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

[jira] [Commented] (QPID-7691) Qpid Python 1.36.0 release tasks

2017-03-16 Thread ASF subversion and git services (JIRA) 

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

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

Commit f9334dbff806b62ead01733c744d7a9d319467b3 in qpid-python's branch 
refs/heads/1.36.x from [~jr...@redhat.com]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-python.git;h=f9334db ]

QPID-7691: Update the version after release


> Qpid Python 1.36.0 release tasks
> 
>
> Key: QPID-7691
> URL: https://issues.apache.org/jira/browse/QPID-7691
> Project: Qpid
>  Issue Type: Task
>  Components: Python Client, Python Test Suite
>Reporter: Justin Ross
>Assignee: Justin Ross
> Fix For: qpid-python-1.36.0
>
>




--
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-1440) pn_connection_wake to return bool status

2017-03-16 Thread Andrew Stitcher (JIRA) 

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

Andrew Stitcher commented on PROTON-1440:
-

Oh, good point about the lack of thread safety. Shame!
It works for me, because I'm effectively only running a single thread at thte 
moment.

> pn_connection_wake to return bool status
> 
>
> Key: PROTON-1440
> URL: https://issues.apache.org/jira/browse/PROTON-1440
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: 0.17.0
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: 0.18.0
>
>
> pn_connection_wake() allows any thread to send a PN_CONNECTION_WAKE event to 
> a proactor-managed connection. Currently it does not return any value, and 
> the application must ensure it is not called after the PN_TRANSPORT_CLOSED 
> event is processed for that connection.
> This is tricky for the application to synchronize and inconsistent with other 
> pn_connection_ functions. If refcounts are used to keep a pn_connection_t in 
> memory after the TRANSPORT_CLOSED, then calling wake() is an error even 
> though the pn_connection_t is valid.
> Change wake to be safe as long as the pn_connection_t is valid. It returns 
> true if the connection will be woken, false if it is too late.



--
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 57662: PROTON-1438: C proactor listening behavior

2017-03-16 Thread Andrew Stitcher 

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



I've looked this over, and I can't see anything obviously wrong. But there's a 
lot of detailed churn in this change, and I'm not so familiar with libuv, so 
I'm not confident enough to say "ship it". But I agree with the overall 
direction.

- Andrew Stitcher


On March 15, 2017, 8:35 p.m., Alan Conway wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57662/
> ---
> 
> (Updated March 15, 2017, 8:35 p.m.)
> 
> 
> Review request for qpid, Andrew Stitcher and Cliff Jansen.
> 
> 
> Bugs: PROTON-1438
> https://issues.apache.org/jira/browse/PROTON-1438
> 
> 
> Repository: qpid-proton-git
> 
> 
> Description
> ---
> 
> (also available on https://github.com/alanconway/qpid-proton/tree/ipv4-ipv6)
> 
> Improved listening behavior for pn_proactor_listen to allow selective 
> listening by protocol (ipv4/v6) or portable "listen to everything".
> 
> Host can be a host name, IPV4 or IPV6 literal, or the empty string/NULL 
> (treated the same). The empty string listens on all local addresses. A host 
> name listens on all addresses associated with the name. An IPV6 literal 
> address (or wildcard '[::]') listens only for IPV6. An IPV4 literal address 
> (or wildcard '0.0.0.0') listens only for IPV4.
> 
> - pn_proactor_listen may listen on more than one socket for ipv6/v4 or for 
> DNS names with multiple address records.
> 
> - the 'backlog' applies to *each* socket
> 
> - an error on any socket will close all the sockets of the listener,  
> PN_LISTERN_CLOSE event indicates all sockets are closed and provides the 
> error that triggered the close.
> 
> PROTON-1438: added pn_event_condition convenience function
> 
> A convenience function to make it easier to write generic error handling
> functions for events.
> 
> /*
>  * If the event context object has a condition and the condition is set
>  * return it, otherwise return NULL.
>  * If the event context object has remote and local conditions,
>  * try the remote condition first, then the local.
>  */
> PN_EXTERN struct pn_condition_t *pn_event_condition(pn_event_t *event);
> 
> PROTON-1438: c libuv proactor - separate pn_connection_t on free
> 
> Separate pn_connection_t from proactor internal data structures when the
> proactor frees the connection - in case the application is using refcounting
> to pin the connection.
> 
> 
> Diffs
> -
> 
>   proton-c/include/proton/cid.h 2d688964cbf2cf17850ee2f4f93eb6c85c7eb1a8 
>   proton-c/include/proton/event.h 6f93cd4d33c121d9265649814f7770a99d61cd45 
>   proton-c/include/proton/listener.h 2038c064a8a4fd621f584fd02db93a6e4593b708 
>   proton-c/include/proton/proactor.h 43b8ccb85525631818b8393c5e7f9b07ae0b348d 
>   proton-c/src/core/engine.c 8c2aeb0d27a06384b7b1dc3488d9bb122dda7bd7 
>   proton-c/src/proactor/libuv.c 102fcdd8a30d2dd57d9545552bcfd695a251a66d 
>   proton-c/src/tests/proactor.c beba46e84c75fb36677576b645fd2f39bb238827 
>   proton-c/src/tests/test_tools.h 9fe679c4ce99f8bd8446343ea180ad10a9a60c7c 
> 
> 
> Diff: https://reviews.apache.org/r/57662/diff/1/
> 
> 
> Testing
> ---
> 
> Passes proton tests, including new proactor.c tests for ipv4/v6 listening and 
> connecting
> 
> 
> Thanks,
> 
> Alan Conway
> 
>

[jira] [Commented] (PROTON-1440) pn_connection_wake to return bool status

2017-03-16 Thread Alan Conway (JIRA) 

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

Alan Conway commented on PROTON-1440:
-

Your fix isn't thread safe unfortunately, as zeroing and reading the pointer 
can happen concurrently which means freeing and using the pointer also can 
happen concurrently. I'm working to fix that now, basically it's the moral 
equivalent of your fix but instead of zeroing the pointer, we atomically mark 
the pconnection_t as closed and keep it around till the pn_connection_t 
expires. Adding the bool return is a nice bonus. 

> pn_connection_wake to return bool status
> 
>
> Key: PROTON-1440
> URL: https://issues.apache.org/jira/browse/PROTON-1440
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: 0.17.0
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: 0.18.0
>
>
> pn_connection_wake() allows any thread to send a PN_CONNECTION_WAKE event to 
> a proactor-managed connection. Currently it does not return any value, and 
> the application must ensure it is not called after the PN_TRANSPORT_CLOSED 
> event is processed for that connection.
> This is tricky for the application to synchronize and inconsistent with other 
> pn_connection_ functions. If refcounts are used to keep a pn_connection_t in 
> memory after the TRANSPORT_CLOSED, then calling wake() is an error even 
> though the pn_connection_t is valid.
> Change wake to be safe as long as the pn_connection_t is valid. It returns 
> true if the connection will be woken, false if it is too late.



--
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] [Comment Edited] (PROTON-1440) pn_connection_wake to return bool status

2017-03-16 Thread Andrew Stitcher (JIRA) 

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

Andrew Stitcher edited comment on PROTON-1440 at 3/16/17 2:55 PM:
--

Currently the app *can* call it on any valid connection (assuming my fix to 
zero out the PROACTOR context object to a connection on pconnection 
destruction), but it won't do anything if the connection is not being serviced 
by a proactor.

So this behaviour is safe-ish, but the app doesn't know that its wake won't do 
anything.

I do like the idea of returning a bool though to say whether anything happened


was (Author: astitcher):
Currently the app *can* call it on any valid connection (assuming my fix to 
zero out the PROACTOR context object to a connection on pconnection 
destruction), but it won't do anything if the connection is not being serviced 
by a proactor.

So this behaviour is safe-ish, but the app doesn't know that its wake won't do 
anything.

> pn_connection_wake to return bool status
> 
>
> Key: PROTON-1440
> URL: https://issues.apache.org/jira/browse/PROTON-1440
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: 0.17.0
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: 0.18.0
>
>
> pn_connection_wake() allows any thread to send a PN_CONNECTION_WAKE event to 
> a proactor-managed connection. Currently it does not return any value, and 
> the application must ensure it is not called after the PN_TRANSPORT_CLOSED 
> event is processed for that connection.
> This is tricky for the application to synchronize and inconsistent with other 
> pn_connection_ functions. If refcounts are used to keep a pn_connection_t in 
> memory after the TRANSPORT_CLOSED, then calling wake() is an error even 
> though the pn_connection_t is valid.
> Change wake to be safe as long as the pn_connection_t is valid. It returns 
> true if the connection will be woken, false if it is too late.



--
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-1440) pn_connection_wake to return bool status

2017-03-16 Thread Andrew Stitcher (JIRA) 

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

Andrew Stitcher commented on PROTON-1440:
-

Currently the app *can* call it on any valid connection (assuming my fix to 
zero out the PROACTOR context object to a connection on pconnection 
destruction), but it won't do anything if the connection is not being serviced 
by a proactor.

So this behaviour is safe-ish, but the app doesn't know that its wake won't do 
anything.

> pn_connection_wake to return bool status
> 
>
> Key: PROTON-1440
> URL: https://issues.apache.org/jira/browse/PROTON-1440
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: 0.17.0
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: 0.18.0
>
>
> pn_connection_wake() allows any thread to send a PN_CONNECTION_WAKE event to 
> a proactor-managed connection. Currently it does not return any value, and 
> the application must ensure it is not called after the PN_TRANSPORT_CLOSED 
> event is processed for that connection.
> This is tricky for the application to synchronize and inconsistent with other 
> pn_connection_ functions. If refcounts are used to keep a pn_connection_t in 
> memory after the TRANSPORT_CLOSED, then calling wake() is an error even 
> though the pn_connection_t is valid.
> Change wake to be safe as long as the pn_connection_t is valid. It returns 
> true if the connection will be woken, false if it is too late.



--
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-7711) [Java Broker] Set correct Content-Encoding in REST response (6.0.x)

2017-03-16 Thread Lorenz Quack (JIRA) 

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

Lorenz Quack updated QPID-7711:
---
Summary: [Java Broker] Set correct Content-Encoding in REST response 
(6.0.x)  (was: [Java Broker] Set correct Content-Encoding)

> [Java Broker] Set correct Content-Encoding in REST response (6.0.x)
> ---
>
> Key: QPID-7711
> URL: https://issues.apache.org/jira/browse/QPID-7711
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.0.6
>Reporter: Lorenz Quack
> Fix For: qpid-java-6.0.7
>
>
> Currently the message preview in the web management console is broken but the 
> culprit seems to be the broker.
> When trying to preview a TextMessage the broker replys with a gzip compressed 
> response but without setting the Content-Encoding to gzip. this results in a 
> garbled message preview on the client side.
> As a workaround one can disable compression for the httpManagement plugin.



--
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] (QPID-7711) [Java Broker] Set correct Content-Encoding

2017-03-16 Thread Lorenz Quack (JIRA) 
Lorenz Quack created QPID-7711:
--

 Summary: [Java Broker] Set correct Content-Encoding
 Key: QPID-7711
 URL: https://issues.apache.org/jira/browse/QPID-7711
 Project: Qpid
  Issue Type: Bug
  Components: Java Broker
Affects Versions: qpid-java-6.0.6
Reporter: Lorenz Quack
 Fix For: qpid-java-6.0.7


Currently the message preview in the web management console is broken but the 
culprit seems to be the broker.
When trying to preview a TextMessage the broker replys with a gzip compressed 
response but without setting the Content-Encoding to gzip. this results in a 
garbled message preview on the client side.
As a workaround one can disable compression for the httpManagement plugin.



--
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-7696) [Java Broker] Deletion of a temporary queue can crash the broker with certain ACLs

2017-03-16 Thread Lorenz Quack (JIRA) 

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

Lorenz Quack updated QPID-7696:
---
Priority: Critical  (was: Major)

> [Java Broker] Deletion of a temporary queue can crash the broker with certain 
> ACLs
> --
>
> Key: QPID-7696
> URL: https://issues.apache.org/jira/browse/QPID-7696
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.1.1
>Reporter: Lorenz Quack
>Priority: Critical
> Fix For: qpid-java-6.0.7, qpid-java-6.1.2
>
> Attachments: 
> QPID-7696-remove-queue-bindings-on-queue-deletion-regardless-availability-unbind-acl-rule.diff
>
>
> ACL:
> {noformat}
> ACL ALLOW-LOG testUser CREATE QUEUE temporary="true"
> ACL ALLOW-LOG testUser DELETE QUEUE temporary="true"
> ACL ALLOW-LOG testUser ACCESS ALL
> ACL ALLOW-LOG admin ALL ALL
> ACL DENY-LOG ALL ALL
> {noformat}
> client code:
> {code}
> /* create connection */
> Session session = connection.createSession(true, 
> Session.SESSION_TRANSACTED);
> TemporaryQueue temporaryQueue = session.createTemporaryQueue();
> temporaryQueue.delete();
>/* cleanup */
> {code}
> This crashes the broker v6.1.1
> {noformat}
> 
> #
> # Unhandled Exception java.security.AccessControlException: Permission DELETE 
> is denied for : Binding 'TempQueuec64ba00d-9b7c-44f2-9217-80c954234ce4' on 
> Queue 'TempQueuec64ba00d-9b7c-44f2-9217-80c954234ce4' Exchange 'amq.direct' 
> in Thread IO-/127.0.0.1:53477
> #
> # Exiting
> #
> 
> java.security.AccessControlException: Permission DELETE is denied for : 
> Binding 'TempQueuec64ba00d-9b7c-44f2-9217-80c954234ce4' on Queue 
> 'TempQueuec64ba00d-9b7c-44f2-9217-80c954234ce4' Exchange 'amq.direct'
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject.authorise(AbstractConfiguredObject.java:2959)
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject.authorise(AbstractConfiguredObject.java:2891)
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject.authoriseSetAttributes(AbstractConfiguredObject.java:2970)
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject$15.execute(AbstractConfiguredObject.java:1659)
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject$15.execute(AbstractConfiguredObject.java:1629)
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject$2.execute(AbstractConfiguredObject.java:632)
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject$2.execute(AbstractConfiguredObject.java:625)
>   at 
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$TaskLoggingWrapper.execute(TaskExecutorImpl.java:240)
>   at 
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$CallableWrapper$1.run(TaskExecutorImpl.java:312)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at javax.security.auth.Subject.doAs(Subject.java:360)
>   at 
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$CallableWrapper.call(TaskExecutorImpl.java:305)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> Process finished with exit code 1
> {noformat}
> I have not tested with other versions of the broker, yet.



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