[jira] [Updated] (QPID-6265) [Java Broker] Improve generation of system test outputs

2014-12-09 Thread Alex Rudyy (JIRA) 

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

Alex Rudyy updated QPID-6265:
-
Attachment: 0001-QPID-6265-Change-system-tests-to-have-one-log-per-fi.patch

> [Java Broker] Improve generation of system test outputs
> ---
>
> Key: QPID-6265
> URL: https://issues.apache.org/jira/browse/QPID-6265
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Tests
>Affects Versions: 0.30
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
> Attachments: 
> 0001-QPID-6265-Change-system-tests-to-have-one-log-per-fi.patch, 
> 0001-WIP-Refactor-QBTC-logging.patch
>
>
> Refactor system test framework to allow for the test logs from failed tests 
> to be collected easily by CI. This task must include the outstanding issue 
> whereby some tests fail to generate test output for the client or the test 
> itself (such as the MultiNodeTest).
> We said that our system test output should be:
> single log file per test method
> output from test/client/broker(s) combined into the single log with 
> output from each easily recognisable
> method for Jenkins to archive output files from those tests that fail
> It would also be desirable if we can start to reduce the responsibilities of 
> the QBTC.
> We have some tests (the logging tests) that parse the output of the test log 
> looking for operation log messages etc. In the long term these tests will be 
> remove, however, this is not in scope for this task. Instead, we might want 
> to do something simple to allow the test to continue to operate (such as 
> defining a custom appender)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (DISPATCH-2) Adhere to the AMQP Management Specification for remote management

2014-12-09 Thread Alan Conway (JIRA) 

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

Alan Conway commented on DISPATCH-2:


Implements all of the AMQP management working draft 9.

> Adhere to the AMQP Management Specification for remote management
> -
>
> Key: DISPATCH-2
> URL: https://issues.apache.org/jira/browse/DISPATCH-2
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Management Agent
>Affects Versions: 0.1
>Reporter: Ted Ross
>Assignee: Alan Conway
> Fix For: 0.3
>
>
> Qpid Dispatch should adhere as closely as possible to the emerging Management 
> specification from the AMQP technical committee. This issue will track work 
> and comments related to compliance with the specification.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Resolved] (DISPATCH-2) Adhere to the AMQP Management Specification for remote management

2014-12-09 Thread Alan Conway (JIRA) 

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

Alan Conway resolved DISPATCH-2.

Resolution: Fixed

> Adhere to the AMQP Management Specification for remote management
> -
>
> Key: DISPATCH-2
> URL: https://issues.apache.org/jira/browse/DISPATCH-2
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Management Agent
>Affects Versions: 0.1
>Reporter: Ted Ross
>Assignee: Alan Conway
> Fix For: 0.3
>
>
> Qpid Dispatch should adhere as closely as possible to the emerging Management 
> specification from the AMQP technical committee. This issue will track work 
> and comments related to compliance with the specification.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (DISPATCH-56) Implement Create/Read/Update/Delete operations in the agent

2014-12-09 Thread ASF subversion and git services (JIRA) 

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

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

Commit 1644319 from [~aconway] in branch 'dispatch/trunk'
[ https://svn.apache.org/r1644319 ]

DISPATCH-56: Add get-mgmt-nodes operation to qdmanage tool.

> Implement Create/Read/Update/Delete operations in the agent
> ---
>
> Key: DISPATCH-56
> URL: https://issues.apache.org/jira/browse/DISPATCH-56
> Project: Qpid Dispatch
>  Issue Type: Sub-task
>  Components: Management Agent
>Reporter: Ted Ross
>Assignee: Alan Conway
> Fix For: 0.3
>
>
> Implement the CRUD-style commands in the management agent and use them to 
> access waypoints, address-prefixes, self, etc.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Resolved] (DISPATCH-56) Implement Create/Read/Update/Delete operations in the agent

2014-12-09 Thread Alan Conway (JIRA) 

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

Alan Conway resolved DISPATCH-56.
-
Resolution: Fixed

> Implement Create/Read/Update/Delete operations in the agent
> ---
>
> Key: DISPATCH-56
> URL: https://issues.apache.org/jira/browse/DISPATCH-56
> Project: Qpid Dispatch
>  Issue Type: Sub-task
>  Components: Management Agent
>Reporter: Ted Ross
>Assignee: Alan Conway
> Fix For: 0.3
>
>
> Implement the CRUD-style commands in the management agent and use them to 
> access waypoints, address-prefixes, self, etc.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (DISPATCH-56) Implement Create/Read/Update/Delete operations in the agent

2014-12-09 Thread ASF subversion and git services (JIRA) 

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

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

Commit 1644318 from [~aconway] in branch 'dispatch/trunk'
[ https://svn.apache.org/r1644318 ]

DISPATCH-56: Improve qdmanage tool, add man page generation for qdmanage and 
qdstat.

Got rid of JSON maps/lists on qdmanage command line. Use simple name=value 
arguments for attributes.
Still allow JSON with the --stdin flag.

Man page generation, from the doc/man/README:

Command line tools --help option provides a very brief usage and list of 
options.

Man pages should be more detailed, but we do not want to repeat the information
from --help as it will easily become out of date.

To solve this we generate man pages using the  help2man utility.
For each tool there should be a tool.htm with extra details for the man page.
help2man will combine this with the --help otuput of the tool to create the 
full man page.

See the help2man macro in CMakeLists.txt and the help2man documentation for 
more details.

For building distributions when help2man is not available, the generated man 
page for
each tool is checked in as "tool.8.in". When help2man is available, running make
will warn if the checked in version is not  up to date with the generated 
version.

To update the man page you MUST use help2man, do not edit the checked in file
as your edits will be lost.

> Implement Create/Read/Update/Delete operations in the agent
> ---
>
> Key: DISPATCH-56
> URL: https://issues.apache.org/jira/browse/DISPATCH-56
> Project: Qpid Dispatch
>  Issue Type: Sub-task
>  Components: Management Agent
>Reporter: Ted Ross
>Assignee: Alan Conway
> Fix For: 0.3
>
>
> Implement the CRUD-style commands in the management agent and use them to 
> access waypoints, address-prefixes, self, etc.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (DISPATCH-83) Error messages are not displayed if an error occurs when starting in deamon mode

2014-12-09 Thread Ernest Allen (JIRA) 
Ernest Allen created DISPATCH-83:


 Summary: Error messages are not displayed if an error occurs when 
starting in deamon mode 
 Key: DISPATCH-83
 URL: https://issues.apache.org/jira/browse/DISPATCH-83
 Project: Qpid Dispatch
  Issue Type: Bug
  Components: Router Node
Affects Versions: 0.2
Reporter: Ernest Allen
Priority: Minor


If qdrouterd is started in daemon mode and fails to start because of a bad 
value for a command line option, there is no log message that explains why it 
failed to start.

To reproduce, start qdrouterd with -d and with a bad value for -c, -U, -P, or 
-U. The router will fail to start, but no log entry is displayed. The only 
message that is displayed is:
"Error occurred during daemon initialization, please see logs.  [code=<>]"




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (QPID-6261) Federation with SSL is failing between two brokers

2014-12-09 Thread Brent Driskill (JIRA) 

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

Brent Driskill commented on QPID-6261:
--

Thank you Gordon. I will test out your suggestions above and let you know.




> Federation with SSL is failing between two brokers
> --
>
> Key: QPID-6261
> URL: https://issues.apache.org/jira/browse/QPID-6261
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker
>Affects Versions: 0.30
> Environment: CentOS 7
>Reporter: Brent Driskill
>Priority: Critical
> Attachments: qpidd1.conf, qpidd10002.conf
>
>
> I am unable to get federation to work between two brokers that are SSL 
> enabled with different SASL configurations.
> Reproduction Steps:
> 1. Deploy two separate brokers on the same machine. One has port 1 
> (destination broker) and one has port 10002 (source broker). The 
> configuration for both these brokers are attached. The acl file for broker 
> 1 has "acl allow all all" and the other has "acl allow all all" for a 
> specific user.
> 2. Execute python scripts to create the queues and exchanges
> 3. Execute the following qpid-route command to federate between the two:
> {noformat}
> qpid-route queue add amqps:///@:1 
> amqps:///@:10002   
>  -t ssl --ssl-certificate 
> {noformat}
> The qpid-route throws the following error:
> {noformat}
> Failed: ConnectionFailed - (None, 'connection aborted')
> {noformat}
> I see the following error in the logs for broker 1 around the same time 
> (not sure if it is related or not)
> {noformat}
> 2014-12-02 14:18:07 [System] error Connection 
> qpid.192.168.10.104:1-192.168.10.104:33642 No protocol received closing
> 2014-12-02 14:18:07 [System] debug DISCONNECTED 
> [qpid.192.168.10.104:1-192.168.10.104:33642]
> {noformat}
> If I disable SSL, everything works perfectly (with the sasl configurations 
> the same). The c++ clients are able to connect to both brokers correctly 
> using the pem file.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (QPID-6255) [amqp1.0] Migrate to the new Proton event API

2014-12-09 Thread Gordon Sim (JIRA) 

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

Gordon Sim commented on QPID-6255:
--

Do the numbers change for smaller message sizes? 1-2% is pretty small, I often 
see more variance than that between runs on the same codebase. I wouldn't be 
overly concerned if thats the worst case. The thing I would check is the batch 
sizes for the writes.

> [amqp1.0] Migrate to the new Proton event API
> -
>
> Key: QPID-6255
> URL: https://issues.apache.org/jira/browse/QPID-6255
> Project: Qpid
>  Issue Type: Improvement
>  Components: C++ Broker
>Affects Versions: 0.30
>Reporter: Ken Giusti
>Assignee: Ken Giusti
> Fix For: Future
>
>
> Proton version 0.8 introduced an event-based API.  The Qpid broker currently 
> uses the older API which requires a linear search of deliveries, links, and 
> sessions during event processing.  Migrating to the new API _should_ optimize 
> event processing, especially as the number of object instances scale.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (QPID-6261) Federation with SSL is failing between two brokers

2014-12-09 Thread Gordon Sim (JIRA) 

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

Gordon Sim commented on QPID-6261:
--

For the broker listening on 1 to connect to the broker listening on 10002, 
it must be able to verify the certificate of the server it is connecting to and 
check that it matches the correct hostname. How did you set up the certificate 
database for the brokers, and do the server certificates match the hostname/ip 
being used to connect?

That said, if qpid-route is throwing an error it may not even have successfully 
asked the inter-broker connection to be established. Try running qpid-config 
against the broker on 1 using the same ssl settings. Are you also using 
0.30 of the python libraries and tools? It sounds a little like 
https://issues.apache.org/jira/browse/QPID-5773, though that *should* be 
resolved in 0.30.

> Federation with SSL is failing between two brokers
> --
>
> Key: QPID-6261
> URL: https://issues.apache.org/jira/browse/QPID-6261
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker
>Affects Versions: 0.30
> Environment: CentOS 7
>Reporter: Brent Driskill
>Priority: Critical
> Attachments: qpidd1.conf, qpidd10002.conf
>
>
> I am unable to get federation to work between two brokers that are SSL 
> enabled with different SASL configurations.
> Reproduction Steps:
> 1. Deploy two separate brokers on the same machine. One has port 1 
> (destination broker) and one has port 10002 (source broker). The 
> configuration for both these brokers are attached. The acl file for broker 
> 1 has "acl allow all all" and the other has "acl allow all all" for a 
> specific user.
> 2. Execute python scripts to create the queues and exchanges
> 3. Execute the following qpid-route command to federate between the two:
> {noformat}
> qpid-route queue add amqps:///@:1 
> amqps:///@:10002   
>  -t ssl --ssl-certificate 
> {noformat}
> The qpid-route throws the following error:
> {noformat}
> Failed: ConnectionFailed - (None, 'connection aborted')
> {noformat}
> I see the following error in the logs for broker 1 around the same time 
> (not sure if it is related or not)
> {noformat}
> 2014-12-02 14:18:07 [System] error Connection 
> qpid.192.168.10.104:1-192.168.10.104:33642 No protocol received closing
> 2014-12-02 14:18:07 [System] debug DISCONNECTED 
> [qpid.192.168.10.104:1-192.168.10.104:33642]
> {noformat}
> If I disable SSL, everything works perfectly (with the sasl configurations 
> the same). The c++ clients are able to connect to both brokers correctly 
> using the pem file.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (QPID-6255) [amqp1.0] Migrate to the new Proton event API

2014-12-09 Thread Ken Giusti (JIRA) 

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

Ken Giusti commented on QPID-6255:
--

Well, the performance numbers don't look so great.   In general 
qpid-cpp-benchmark shows about 1-2% degradation in rx and tx performance when 
the event model is used.

I ran qpid-cpp-benchmark several times both with HAVE_PROTON_EVENTS defined and 
undefined (use the old polling method).  Using the best of N runs in each case 
I observed the event variant performing a little worse than the original polled 
approach.  For example:

 polled:

qpid-cpp-benchmark -s1 -r1 -m 100 --summarize 
--connection-options="{protocol:amqp1.0}"
send-tp recv-tp l-min   l-max   l-avg   total-tp
57592   54216   2.871196.82 631.21  54118

event:

qpid-cpp-benchmark -s1 -r1 -m 100 --summarize 
--connection-options="{protocol:amqp1.0}"
send-tp recv-tp l-min   l-max   l-avg   total-tp
56620   53157   2.561307.70 724.17  53065

send-tp = -1.688% 
recv-tp = -1.953%

The cpu utilization appears to be roughly the same, but simply eyeballing 'top' 
doesn't provide the granularity necessary to determine if the process is 
running 1-2% less frequently.  The only other conclusion I can draw is that the 
event model results in 1-2% more work per message transfer.   I'm going to run 
this under callgrind to see if that sheds more light on this.

> [amqp1.0] Migrate to the new Proton event API
> -
>
> Key: QPID-6255
> URL: https://issues.apache.org/jira/browse/QPID-6255
> Project: Qpid
>  Issue Type: Improvement
>  Components: C++ Broker
>Affects Versions: 0.30
>Reporter: Ken Giusti
>Assignee: Ken Giusti
> Fix For: Future
>
>
> Proton version 0.8 introduced an event-based API.  The Qpid broker currently 
> uses the older API which requires a linear search of deliveries, links, and 
> sessions during event processing.  Migrating to the new API _should_ optimize 
> event processing, especially as the number of object instances scale.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: Review Request 28770: Some engine examples and supporting library code

2014-12-09 Thread Gordon Sim 


> On Dec. 5, 2014, 10:24 p.m., Rafael Schloming wrote:
> > proton-c/bindings/python/proton/__init__.py, line 3542
> > 
> >
> > To expand on my question here, I'd also like to understand if this 
> > __getattr__ is just an expedient way of copying a specific set of 
> > attributes from the context into the event or if it is actually your intent 
> > to flatten any arbitrary context properties into the event object.
> 
> Gordon Sim wrote:
> What I want is a 'uniform' interface to an event. I.e. rather than the 
> event-type dependent context being the only thing directly exposed, I'd like 
> the connection property to be available for any event that is in any way 
> associated with a connection (even if it is say a delivery- or link- event), 
> likewise for sessions and links. So whether I'm handing an incoming message, 
> a change in credit, or perhaps even a change in endpoint state, I can get the 
> relevant objects via the same property rather than having deducing the 
> context type and figure out how to get what I want from that.
> 
> I'd like to be able to keep this same interface even for 'extended' 
> events created outside the core engine - e.g. perhaps a timer for retrying a 
> disconnected connection, or an application defined event indicating 
> availability of data to send on a given link. The extended events however may 
> additionally have some other properties.
> 
> So getting back to the question now the high level goal is (hopefully!) 
> explained, the context seems to me like an internal detail. What I care about 
> as a user is getting the connection or link or session or foo from the event. 
> The context is just the mechanism that makes this work via swig etc. As a 
> user I don't want to distinguish between context and the event itself.
> 
> Rafael Schloming wrote:
> If you don't want to distinguish between the context and the event, then 
> why pass the event around in the first place? I believe in an earlier 
> incarnation of the examples I had the dispatch mechanism set up to pass the 
> context directly into the handler rather than passing in the event. I believe 
> at the time you said you preferred passing around the event because it is 
> more flexible, e.g. we can pass in extra info without changing the signature 
> of the handler. This same argument would suggest to me that you do actually 
> do want to distinguish between the context and the event itsef.
> 
> To be clear I'm not against having convenience accessors as you describe, 
> however I don't think it's a good idea for the getattr to actually exposing 
> *everything* in the context onto the event. It makes it unclear to me whether 
> "Event" is actually exposed as a first class thing for users or not. If it's 
> not then I think it's better to eliminate it during the dispatch process and 
> just pass around the context. If it is then I think it's better to explicitly 
> define exactly what properties an event has for every given event type.
> 
> As you have it, the current shadowing behavior can lead to confusing 
> situations, e.g. I'm guessing you can probably write code that pretends the 
> event actually *is* the connection, e.g. do things like event.open(), 
> event.close(), etc, but stuff like event.hostname = "blah"; event.open() 
> would fail silently since the hostname attribute would get set on the event, 
> but the open method would get called from the connection. (Note I haven't 
> actually tried the previous example, so please correct me if I'm mistaken.)
> 
> Gordon Sim wrote:
> Clearly the event is different from the connection it occurred on, so my 
> choice of phrasing there was poor.
> 
> What I'm trying to explain is the difference between having to understand 
> what the context is for different events, versus just having some common 
> properties of an event that are used whenever that property is relevant. E.g. 
> event.connection vs. event.context, or event.context.connection or 
> event.context.session.connection. I like thinking of the associated 
> connection as simply a property of the event, one that is always there for 
> connection-relevant events.
> 
> I'm certainly open to better ways of accomplishing the same thing. The 
> uniformity is the most important aspect to me.

Updated patch no longer uses the __getattr__, but instead allows different 
types of event to be returned from the collector.


- Gordon


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


On Dec. 9, 2014, 11:56 a.m., Gordon Sim wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/28770/
>

Re: Review Request 28770: Some engine examples and supporting library code

2014-12-09 Thread Gordon Sim 

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

(Updated Dec. 9, 2014, 11:56 a.m.)


Review request for qpid and Rafael Schloming.


Changes
---

Added a README for the examples. Altered the manner in which the uniform event 
interface is implemented: (1) tidied up the extra properties on Event by adding 
connection and session properties to delivery, (2) split out a minial EventBase 
from the Event class, (3) altered the collector such that if the context popped 
extends this base class, it is treated as an Event itself. This allows 
applications to define their own event classes, which I use to allow an 
extended event that offers the same uniform interface as the core engine events 
but other implementations are equally possible. 


Repository: qpid-proton-git


Description
---

These are the current reactive examples using the engine API, that I have been 
evolving on the examples branch, alog with the utility code they depend on. I 
still need to evolve/rationalise the examples themselves as well as the utility 
code, but I believe it would be beneficial to all to do this from the master 
branch.


Diffs (updated)
-

  examples/engine/py/README PRE-CREATION 
  examples/engine/py/abstract_server.py PRE-CREATION 
  examples/engine/py/client.py PRE-CREATION 
  examples/engine/py/client_http.py PRE-CREATION 
  examples/engine/py/common.py PRE-CREATION 
  examples/engine/py/db_common.py PRE-CREATION 
  examples/engine/py/db_ctrl.py PRE-CREATION 
  examples/engine/py/db_recv.py PRE-CREATION 
  examples/engine/py/db_send.py PRE-CREATION 
  examples/engine/py/helloworld.py PRE-CREATION 
  examples/engine/py/helloworld_blocking.py PRE-CREATION 
  examples/engine/py/helloworld_direct.py PRE-CREATION 
  examples/engine/py/helloworld_direct_tornado.py PRE-CREATION 
  examples/engine/py/helloworld_tornado.py PRE-CREATION 
  examples/engine/py/proton_server.py PRE-CREATION 
  examples/engine/py/proton_tornado.py PRE-CREATION 
  examples/engine/py/recurring_timer.py PRE-CREATION 
  examples/engine/py/recurring_timer_tornado.py PRE-CREATION 
  examples/engine/py/selected_recv.py PRE-CREATION 
  examples/engine/py/server.py PRE-CREATION 
  examples/engine/py/server_tx.py PRE-CREATION 
  examples/engine/py/simple_recv.py PRE-CREATION 
  examples/engine/py/simple_send.py PRE-CREATION 
  examples/engine/py/sync_client.py PRE-CREATION 
  examples/engine/py/tx_recv.py PRE-CREATION 
  examples/engine/py/tx_recv_interactive.py PRE-CREATION 
  examples/engine/py/tx_send.py PRE-CREATION 
  examples/engine/py/tx_send_sync.py PRE-CREATION 
  proton-c/bindings/python/CMakeLists.txt 
6be421e237f86f2aa99c23ffbc08af821b5c8438 
  proton-c/bindings/python/proton/__init__.py 
fce3255bfce440dcae57457d259147a4ced8216e 
  proton-c/bindings/python/proton/handlers.py PRE-CREATION 
  proton-c/bindings/python/proton/reactors.py PRE-CREATION 
  proton-c/bindings/python/proton/utils.py PRE-CREATION 

Diff: https://reviews.apache.org/r/28770/diff/


Testing
---

All examples have been tested, note that the transactional examples require a 
couple of extra proton-c patches (available on respective JIRAs) in order to 
run correctly.


Thanks,

Gordon Sim