[jira] [Created] (PROTON-224) Python test framework: treat ProtonUnsupportedOperationException automatically as a skipped test
Keith Wall created PROTON-224: - Summary: Python test framework: treat ProtonUnsupportedOperationException automatically as a skipped test Key: PROTON-224 URL: https://issues.apache.org/jira/browse/PROTON-224 Project: Qpid Proton Issue Type: Bug Components: proton-j Reporter: Keith Wall Priority: Minor Fix For: 0.4 Refactor test framework to arrange from proton_test (the python test runner) to treat ProtonUnsupportedOperationException (the exception used by the Java stacks to signal an unimplemented Proton feature) automatically as a skipped test. direct dependency between -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (PROTON-225) Redesign Transport interface such that Transport owns the in/out buffers rather than its client
Philip Harvey created PROTON-225: Summary: Redesign Transport interface such that Transport owns the in/out buffers rather than its client Key: PROTON-225 URL: https://issues.apache.org/jira/browse/PROTON-225 Project: Qpid Proton Issue Type: Improvement Affects Versions: 0.3 Reporter: Philip Harvey Fix For: 0.5 This issue is intended to cover the Transport API redesign proposed on the mailing list (http://qpid.2158936.n2.nabble.com/transport-interface-changes-td7588099.html) as part of discussions around PROTON-222. The redesign is being tracked under this new because we probably want to implement it on a different timescale to the PROTON-222 bug fix. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: transport interface changes
FYI I've raised PROTON-225 to cover the API redesign so that we have the option of implementing it separately from the PROTON-222 bug fix. On 7 February 2013 16:43, Phil Harvey p...@philharveyonline.com wrote: My 2 cents on the naming issue: I'm not convinced that a single queue is the best metaphor for the Transport, even if qualified by the term transforming. The meaning of the input and output data is surely so different that calling it a queue masks the essence of what the engine does. To me, a transforming queue suggests something that spits out something semantically identical to its input. For example, a byte queue whose head is a UTF-8-encoded transformation of its UTF-8 tail. I don't think Transport falls into this category, therefore my preference would be for the words input and output to appear in the function names. Phil On 7 February 2013 14:23, Ken Giusti kgiu...@redhat.com wrote: What we've got here is failure to communicate. There aren't necessarily distinct input/output buffer objects, rather the whole transport interface itself is really just single structure (a [transforming] byte queue) with push/peek/pop corresponding exactly to any standard queue interface. Aha! Well, that explains it - I've always though that the transport was composed of two separate buffers - one for input, the other for output. At least, that's my interpretation of the existing API. A transforming byte queue didn't immediately pop into my mind when reading these new APIs. You may want to add a bit of documentation to that patch explaining this meme before the APIs are described. Would be quite useful to anyone attempting to implement a driver. -K - Original Message - Looks like the attachement didn't make it. Here's the link to the patch on JIRA: https://issues.apache.org/jira/secure/attachment/12568408/transport.patch --Rafael On Thu, Feb 7, 2013 at 8:10 AM, Rafael Schloming r...@alum.mit.edu wrote: Here's a patch to engine.h with updated docs/naming. I've documented what I believe would be future lifecycle semantics, however as I said before I think an initial patch would need to be more conservative. I think these names would also work with input/output prefixes, although as the interface now pretty much exactly matches a circular buffer (i.e. a byte queue), I find the input/output prefixes a bit jarring. --Rafael On Thu, Feb 7, 2013 at 5:53 AM, Rafael Schloming r...@alum.mit.edu wrote: On Wed, Feb 6, 2013 at 5:12 PM, Rafael Schloming r...@alum.mit.eduwrote: On Wed, Feb 6, 2013 at 2:13 PM, Ken Giusti kgiu...@redhat.com wrote: Rafi, I agree with the rational behind these changes. /** Return a pointer to a transport's input buffer. This pointer may * change when calls into the engine are made. I think we'll need to be a little more liberal with the lifecycle guarantee of these buffer pointers. Drivers based on completion models (rather than sockets) could be forced to do data copies rather than supplying the pointer directly to the completion mechanism. That sentence was actually supposed to be deleted. The sentences after that describes the intended lifecycle policy for the input buffer: Calls to ::pn_transport_push may change the value of this pointer and the amount of free space reported by ::pn_transport_capacity. Could we instead guarantee that pointers (and space) returned from the transport remain valid until 1) the transport is released or 2) the push/pop call is made against the transport? That is in fact what I intended for push. For pop this would place a lot more restrictions on the engine implementation. Say for example peek is called and then the top half is used to write message data. Ideally there should actually be more data to write over the network, which means that the transport may want to grow (realloc) the output buffer, and this of course is more complex if the external pointer needs to stay valid. Given that at worst this will incur an extra copy that is equivalent to what we're currently doing, I figured it would be safer to start out with more conservative semantics. We can always relax them later when we have had more time to consider the implementation. Or perhaps a reference count-based interface would be safer? Once the driver determines there is capacity/pending, it reserves the buffer and is required to push/pop to release it? Oh, and those names absolutely stink. ;) It's unclear from the function names what components of the transport they are affecting. I'd rather something more readable: pn_transport_capacity() -- pn_transport_input_capacity() pn_transport_buffer() -
[jira] [Updated] (PROTON-224) Python test framework: treat ProtonUnsupportedOperationException automatically as a skipped test
[ https://issues.apache.org/jira/browse/PROTON-224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated PROTON-224: -- Issue Type: Improvement (was: Bug) Python test framework: treat ProtonUnsupportedOperationException automatically as a skipped test Key: PROTON-224 URL: https://issues.apache.org/jira/browse/PROTON-224 Project: Qpid Proton Issue Type: Improvement Components: proton-j Reporter: Keith Wall Assignee: Keith Wall Priority: Minor Fix For: 0.4 Refactor test framework to arrange from proton_test (the python test runner) to treat ProtonUnsupportedOperationException (the exception used by the Java stacks to signal an unimplemented Proton feature) automatically as a skipped test. direct dependency between -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (PROTON-224) Python test framework: treat ProtonUnsupportedOperationException automatically as a skipped test
[ https://issues.apache.org/jira/browse/PROTON-224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall reassigned PROTON-224: - Assignee: Keith Wall Python test framework: treat ProtonUnsupportedOperationException automatically as a skipped test Key: PROTON-224 URL: https://issues.apache.org/jira/browse/PROTON-224 Project: Qpid Proton Issue Type: Bug Components: proton-j Reporter: Keith Wall Assignee: Keith Wall Priority: Minor Fix For: 0.4 Refactor test framework to arrange from proton_test (the python test runner) to treat ProtonUnsupportedOperationException (the exception used by the Java stacks to signal an unimplemented Proton feature) automatically as a skipped test. direct dependency between -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Building proton-c: cc1: error: unrecognized command line option -Wvla (RHEL 5.3)
On 5 February 2013 17:38, Cliff Jansen cliffjan...@gmail.com wrote: Hmmm. You raise a good point. On the one hand, we want people to be policed by these flags if they are contributing to the proton-c work. However, we don't want proton to be difficult to build for anybody else. I will raise a JIRA to have the CMakeLists.txt only set the flags if the gcc version can handle it, and print some inspirational message otherwise. Thanks Cliff, that sounds perfect. Do you have a target date in mind for this? We are currently having to patch the new flag out in order to build on our Redhat Tikanga boxes.
[jira] [Commented] (PROTON-196) Automate the running of system tests on Apache CI
[ https://issues.apache.org/jira/browse/PROTON-196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13574482#comment-13574482 ] Keith Wall commented on PROTON-196: --- We now have the following Proton jobs set up on Apache Jenkins CI: ttps://builds.apache.org/view/M-R/view/Qpid/job/Qpid-proton-c/ # Build proton-c and test with Python system tests. https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-proton-j/# Build proton-j and test with Python/Java system tests https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-proton-jni/ # Build proton-c and JNI bindings and test with Python/Java system tests https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-proton-j-Deploy/ # Deploy proton-j snapshot artefacts Automate the running of system tests on Apache CI - Key: PROTON-196 URL: https://issues.apache.org/jira/browse/PROTON-196 Project: Qpid Proton Issue Type: Task Reporter: Keith Wall Assignee: Keith Wall Setup the build and execution of proton system tests on Apache CI. Tests profiles will exercise proton-c/proton-c, proton-j/proton-j, and proton-j/proton-c combinations. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (PROTON-196) Automate the running of system tests on Apache CI
[ https://issues.apache.org/jira/browse/PROTON-196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall resolved PROTON-196. --- Resolution: Fixed Fix Version/s: 0.4 Automate the running of system tests on Apache CI - Key: PROTON-196 URL: https://issues.apache.org/jira/browse/PROTON-196 Project: Qpid Proton Issue Type: Task Reporter: Keith Wall Assignee: Keith Wall Fix For: 0.4 Setup the build and execution of proton system tests on Apache CI. Tests profiles will exercise proton-c/proton-c, proton-j/proton-j, and proton-j/proton-c combinations. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (PROTON-196) Automate the running of system tests on Apache CI
[ https://issues.apache.org/jira/browse/PROTON-196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13574482#comment-13574482 ] Keith Wall edited comment on PROTON-196 at 2/8/13 1:38 PM: --- We now have the following Proton jobs set up on Apache Jenkins CI: https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-proton-c/ # Build proton-c and test with Python system tests. https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-proton-j/# Build proton-j and test with Python/Java system tests https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-proton-jni/ # Build proton-c and JNI bindings and test with Python/Java system tests https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-proton-j-Deploy/ # Deploy proton-j snapshot artefacts was (Author: k-wall): We now have the following Proton jobs set up on Apache Jenkins CI: ttps://builds.apache.org/view/M-R/view/Qpid/job/Qpid-proton-c/ # Build proton-c and test with Python system tests. https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-proton-j/# Build proton-j and test with Python/Java system tests https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-proton-jni/ # Build proton-c and JNI bindings and test with Python/Java system tests https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-proton-j-Deploy/ # Deploy proton-j snapshot artefacts Automate the running of system tests on Apache CI - Key: PROTON-196 URL: https://issues.apache.org/jira/browse/PROTON-196 Project: Qpid Proton Issue Type: Task Reporter: Keith Wall Assignee: Keith Wall Setup the build and execution of proton system tests on Apache CI. Tests profiles will exercise proton-c/proton-c, proton-j/proton-j, and proton-j/proton-c combinations. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Proton CI jobs on Apache Jenkins (PROTON-196)
That's excellent - thanks! -K - Original Message - Just to let you know we now have the following jobs configured on the Apache Jenkins CI instances: Builds proton-c and executes the Python system tests: https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-proton-c/ Builds proton-j and executes the Python/Java system tests: https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-proton-j/ Builds proton-c and executes the Python/Java system tests via the Java Bindings (JNI): https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-proton-jni The three build jobs are triggered by svn commit. Publishes proton-j snapshot artefacts: https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-proton-j-Deploy The deploy job runs once per day (3AM UTC). All jobs report build or test failures to notificati...@qpid.apache.org. The test results (including the Python test results) are wired into the job's front page. HTH, Keith Wall.
[jira] [Assigned] (PROTON-222) pn_messenger_send returns before message data has been written to the wire
[ https://issues.apache.org/jira/browse/PROTON-222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti reassigned PROTON-222: - Assignee: Ken Giusti (was: Rafael H. Schloming) pn_messenger_send returns before message data has been written to the wire -- Key: PROTON-222 URL: https://issues.apache.org/jira/browse/PROTON-222 Project: Qpid Proton Issue Type: Bug Components: proton-c, proton-j Affects Versions: 0.3 Reporter: Rafael H. Schloming Assignee: Ken Giusti Fix For: 0.4 Attachments: transport.patch Currently, pn_messender_send will block until the engine reports there are no queued messages being held. The problem arises because the queued message count only reports message data that is being held by the engine due to insufficient credit to send the messages. Messages may also be sitting in the transport's encoded frame buffer waiting to be written to the wire, and messages may also be held by the driver itself. This latter possibly is problematic given the current transport interface because there is no way for an application using the engine (in this case messenger) to know whether data is being held by the driver without introducing an undesirable coupling between the application and the driver implementation. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (PROTON-226) Porting Issue -- Heap Corruption using Visual Studio when running client/server proton in debug mode.
Mary hinton created PROTON-226: -- Summary: Porting Issue -- Heap Corruption using Visual Studio when running client/server proton in debug mode. Key: PROTON-226 URL: https://issues.apache.org/jira/browse/PROTON-226 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.4 Environment: Windows using Visual Studio 2010 Reporter: Mary hinton Code changes for windows port were added (MinGW and Visual Studio) to the proton codebase recently. Using the new codebase and some additional changes, I ran the proton executable using the Visual Studio toolset as both a server and client. When the client exits, a Windows popup displays: Windows has triggered a breakpoint in proton.exe. This may be due to a corruption of the heap, which indicates a bug in proton.exe or any of the DLLs it has loaded. Still tracking this problem down. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
