[jira] [Resolved] (PROTON-55) NullPointerException when a Flow is received /w a null delivery count
[ https://issues.apache.org/jira/browse/PROTON-55?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Godfrey resolved PROTON-55. --- Resolution: Fixed This should now be fixed - the code was not correctly handling the case where the receiver provides credit before it has received the attach from the sender NullPointerException when a Flow is received /w a null delivery count - Key: PROTON-55 URL: https://issues.apache.org/jira/browse/PROTON-55 Project: Qpid Proton Issue Type: Bug Components: proton-j Reporter: Hiram Chirino Assignee: Rob Godfrey Caused by: java.lang.NullPointerException at org.apache.qpid.proton.type.UnsignedInteger.add(UnsignedInteger.java:124) at org.apache.qpid.proton.engine.impl.TransportSender.handleFlow(TransportSender.java:45) at org.apache.qpid.proton.engine.impl.TransportSession.handleFlow(TransportSession.java:287) at org.apache.qpid.proton.engine.impl.TransportImpl.handleFlow(TransportImpl.java:991) at org.apache.qpid.proton.engine.impl.TransportImpl.handleFlow(TransportImpl.java:59) at org.apache.qpid.proton.type.transport.Flow.invoke(Flow.java:318) at org.apache.qpid.proton.engine.impl.TransportImpl.input(TransportImpl.java:1081) at org.apache.qpid.proton.engine.impl.FrameParser.input(FrameParser.java:409) at org.apache.qpid.proton.engine.impl.TransportImpl.input(TransportImpl.java:156) -- 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 engine api naming proposal
On 4 October 2012 23:56, Justin Ross jr...@redhat.com wrote: On Wed, 3 Oct 2012, Justin wrote: On Wed, 3 Oct 2012, Rafael Schloming wrote: I believe the convention I'm following is actually the norm (for a good reason). The get/set_foo pattern is used for passive slots, i.e. it's a strong signal that if you call set_foo with a given value then get_foo will return that same value until set_foo is called again. Whereas dynamic/computed/derived values (something where it would never make sense to have a setter) are generally not prefixed by get. Some examples in Java would be things like Collection.size(), Object.hashCode(), Map.values(). I think this is a pretty valuable convention as it is a signal that I agree that's a common convention in java. It's not the norm: counterexamples are Thread.getState(), Integer.getInteger(s), File.getFreeSpace(). In any case, it's arguably a good convention. It has one particular practical problem, more collisions. This problem is exhibited right now in pn_link_drained. What does that do? It *looks like* it is a dynamic predicate, but it isn't. If in the future you want to add such a predicate, you'll have a collision. _get_ keeps things cleanly separated. (In the case of pn_link_drained, I think that just needs a better name.) I'm pleased we're discussing this. Can we discuss it (and all the other things worth discussing, imo) before we set down changes in the code? I've updated the proposal again. I've also adjusted the Java naming to match the C naming in the main. Of course, they needn't work the same necessarily, but for instance, I figured that if we're going to distinguish between computed/derived and passive attributes in C, we ought to as well in Java. So... personally I don't have quite the horror of extra characters that certain others do... and I think prepending an is on methods that are returning a boolean is a reasonable deviation from the pattern established in the C. I can buy that there are certain methods where the get/set pairing doesn't really imply the actual semantics that the methods have. In general for the count type variables that cannot directly be set, I think getXxxCount() also works, but I'm also happy with the current xxx() style. There are a couple of areas where I think the naming definitely needs work, in particular hostname: The local hostname is actually the hostname that is desired to be chosen at the remote endpoint, while the remote hostname is the hostname that the remote endpoint desires at the local side. Of the proposals, I think Delivery.update is less wrong than acknowledge ... the update may not be an acknowledgement but some other form of state change. Also rescind_credit is not really the semantics of drain (if there are messages available then the peer should send them, not simply cancel the credit). Source and Target - currently the API is incomplete here - a proper definition of these types is needed which is why in the Java I've currently got these as Source/Target Address. The Source and Target types should be properly defined with APIs which allow for the setting of other attributes than just the address. -- Rob Justin
[jira] [Assigned] (PROTON-49) Attach frames improperly encoded.
[ https://issues.apache.org/jira/browse/PROTON-49?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Godfrey reassigned PROTON-49: - Assignee: Rob Godfrey Attach frames improperly encoded. - Key: PROTON-49 URL: https://issues.apache.org/jira/browse/PROTON-49 Project: Qpid Proton Issue Type: Bug Components: proton-j Reporter: Hiram Chirino Assignee: Rob Godfrey Attachments: PROTON-49.patch SwitfMQ client fails to decode Attach frames encoded with proton-j that have the target or source fields set. -- 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-50) Add accessors for different sections to the Message class
Rob Godfrey created PROTON-50: - Summary: Add accessors for different sections to the Message class Key: PROTON-50 URL: https://issues.apache.org/jira/browse/PROTON-50 Project: Qpid Proton Issue Type: Improvement Components: proton-j Reporter: Rob Godfrey Assignee: Rob Godfrey Priority: Minor -- 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-50) Add accessors for different sections to the Message class
[ https://issues.apache.org/jira/browse/PROTON-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Godfrey resolved PROTON-50. --- Resolution: Fixed Add accessors for different sections to the Message class - Key: PROTON-50 URL: https://issues.apache.org/jira/browse/PROTON-50 Project: Qpid Proton Issue Type: Improvement Components: proton-j Reporter: Rob Godfrey Assignee: Rob Godfrey Priority: Minor -- 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-41) Transport tests failing against Proton-j
Rob Godfrey created PROTON-41: - Summary: Transport tests failing against Proton-j Key: PROTON-41 URL: https://issues.apache.org/jira/browse/PROTON-41 Project: Qpid Proton Issue Type: Bug Components: proton-j Reporter: Rob Godfrey Assignee: Rob Godfrey Implement the necessary functionality to get the TransportTest tests passing against proton-j -- 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-41) Transport tests failing against Proton-j
[ https://issues.apache.org/jira/browse/PROTON-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Godfrey resolved PROTON-41. --- Resolution: Fixed Transport tests failing against Proton-j Key: PROTON-41 URL: https://issues.apache.org/jira/browse/PROTON-41 Project: Qpid Proton Issue Type: Bug Components: proton-j Reporter: Rob Godfrey Assignee: Rob Godfrey Implement the necessary functionality to get the TransportTest tests passing against proton-j -- 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-42) Maven supriously reporting failure against unit tests
[ https://issues.apache.org/jira/browse/PROTON-42?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Godfrey resolved PROTON-42. --- Resolution: Fixed Patch applied (magically before it was even posted ;-) ) Maven supriously reporting failure against unit tests - Key: PROTON-42 URL: https://issues.apache.org/jira/browse/PROTON-42 Project: Qpid Proton Issue Type: Bug Components: proton-j Reporter: Rob Godfrey Assignee: Rob Godfrey The JUnit test being run by the java build is failing because an exception is thrown from within Jython when sys.exit(0) is called. An exception should only be thrown if the underlying python tests have actually experienced failures -- 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-34) JythonTest.java not executing the jython tests missing
[ https://issues.apache.org/jira/browse/PROTON-34?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Godfrey reassigned PROTON-34: - Assignee: Rob Godfrey JythonTest.java not executing the jython tests missing -- Key: PROTON-34 URL: https://issues.apache.org/jira/browse/PROTON-34 Project: Qpid Proton Issue Type: Bug Components: proton-j Reporter: Hiram Chirino Assignee: Rob Godfrey Attachments: PROTON-34.patch -- 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-34) JythonTest.java not executing the jython tests missing
[ https://issues.apache.org/jira/browse/PROTON-34?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Godfrey resolved PROTON-34. --- Resolution: Fixed patch applied JythonTest.java not executing the jython tests missing -- Key: PROTON-34 URL: https://issues.apache.org/jira/browse/PROTON-34 Project: Qpid Proton Issue Type: Bug Components: proton-j Reporter: Hiram Chirino Assignee: Rob Godfrey Attachments: PROTON-34.patch -- 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-13) Add JUnit test to proton-j that executes the python unit tests
[ https://issues.apache.org/jira/browse/PROTON-13?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Godfrey resolved PROTON-13. --- Resolution: Fixed Patch applied Add JUnit test to proton-j that executes the python unit tests -- Key: PROTON-13 URL: https://issues.apache.org/jira/browse/PROTON-13 Project: Qpid Proton Issue Type: Test Components: proton-j Reporter: Hiram Chirino Assignee: Rob Godfrey Attachments: PROTON-13-v2.patch -- 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] [Commented] (PROTON-21) Extract the logical AMQP frame handling to an AbstractConnectionHandler
[ https://issues.apache.org/jira/browse/PROTON-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13464703#comment-13464703 ] Rob Godfrey commented on PROTON-21: --- I'm holding off on applying this until the work in moving the Java API over to the new design for Transport is in place to bring it into line with the C. At that point the way to integrate with code which requires a frame level transport should be clearer and hopefully provided in such a way as to be identical between the Java engine and the C engine. I'm hoping to get the API stuff up to date in the next few days. Overall I think the goal here is to ensure that the Java and C provide identical interfaces and not to create APIs which are Java specific. Apologies for my tardiness in this, have been distracted by other day job issues, but should have more time available going forward Extract the logical AMQP frame handling to an AbstractConnectionHandler --- Key: PROTON-21 URL: https://issues.apache.org/jira/browse/PROTON-21 Project: Qpid Proton Issue Type: Improvement Reporter: Hiram Chirino Attachments: PROTON-21-v3.patch Right now all the logic that handles logical AMQP frame events is inside of the TransportImpl class. That interface only allows you to pump bytes in and out of the connection. If we extract all the handling logic to an AbstractConnectionHandler you should be able to use that directly and pump logical AMQP frames and avoid the frame encoding/decoding phase that the TransportImpl also does. -- 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-37) Fix failing python tests for Proton-J
Rob Godfrey created PROTON-37: - Summary: Fix failing python tests for Proton-J Key: PROTON-37 URL: https://issues.apache.org/jira/browse/PROTON-37 Project: Qpid Proton Issue Type: Bug Components: proton-j Reporter: Rob Godfrey Assignee: Rob Godfrey Of the tests running against the engine, the following are currently failing even though the functionality should be complete: proton_tests.engine.CreditTest.testDrainFlow proton_tests.engine.CreditTest.testDrainZero proton_tests.engine.LinkTest.test_multiple proton_tests.engine.PipelineTest.test -- 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-14) addModified method in ConnectionImpl can cause infinite loop
[ https://issues.apache.org/jira/browse/PROTON-14?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Godfrey resolved PROTON-14. --- Resolution: Fixed This appears to have been applied addModified method in ConnectionImpl can cause infinite loop Key: PROTON-14 URL: https://issues.apache.org/jira/browse/PROTON-14 Project: Qpid Proton Issue Type: Bug Components: proton-j Reporter: Rajith Attapattu When adding a new Head, you need to clear any pointers that it has to it's next and prev and also when adding an item to the tail it should clear it's next. The above bug resulted in infinite loops. -- 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: Engine API
On 25 September 2012 21:57, Chuck Rolke cro...@redhat.com wrote: - Original Message - From: Rob Godfrey rob.j.godf...@gmail.com To: proton@qpid.apache.org Sent: Tuesday, September 25, 2012 3:19:23 PM Subject: Re: Engine API On 25 September 2012 19:05, Rafael Schloming r...@alum.mit.edu wrote: Ken already wrote a bunch of documentation on this, perhaps he could post a link? Also, if you run 'make docs' you can see all the doxygen for the engine APIs. While I agree we need more documentation, keeping the C and Java impls in sync is a separate matter. Documentation as a functional spec is really only useful if it reaches the level of a formal specification that never changes, however that's just not realistic for us. Besides, we already have a much much more powerful tool for keeping the implementations in sync. We have the python test suite that will run against both implementations and tell us precisely where they differ. I really would like this test suite to be the formal spec, and like everything else it could certainly use more documentation, but it's quite capable of keeping the implementations in sync without that, and more importantly unlike a static document, we can drive changes in the functional spec that might be motivated by either the C or Java or JS impl back into this test suite and spread them to the other implementations much more quickly than we can with just a document. If there are problems with that model, or if the test suite is somehow insufficient, I'd really like to know. I know Rob has mentioned that the tests need to be more granular, some of them are a bit monolithic because they are trying to reproduce a very specific set of behaviour. For the new stuff I've been adding I've been trying to keep things as granular as possible. To expand here a little... I think defining the functional spec via the tests is both sensible and powerful. However, for this to work, each test need to clearly correspond to a single piece of functionality that should be common across all implementations; and the tests must be *much* more comprehensive than they are currently. Moreover we should be developing the tests in advance of actually implementing in either C or Java (or - when we get to it - JavaScript). In general I feel that we should first be agreeing the scope of functionality on the list, then agreeing the API / detailed functional spec via the definition of tests in the Python test suite (with reasonably comprehensive documentation as to the functional requirement behind each test), and only then attempting to implement across the various languages. I feel like we are currently defining behaviour via implementation which may be sustainable in the short term, but probably doesn't scale if we are expecting a larger community to be contributing to the project. -- Rob The reason the python tests *won't* work as a spec are precisely because they cannot correspond to a piece of functionality. I'm not sure that you have put forward a case that they can not only that they do not. I agree that the current tests are a fair way from meeting the requirements of a functional spec, but fundamentally there should be a 1:1 correspondence between a functional spec and a test suite. Whether one defines the spec explicitly (and then writes an implicit test suite) or implicitly (via the mechanism of a well defined set of tests) is really a style issue I think. The tests are really good at what they do: verifying that functions work as expected. Keep them coming. Actually I disagree. The tests currently aren't all that great. When trying to get the tests to pass against the Java codebase there's really no help in trying to work out what the tests are supposed to do (though some - such as against the message API are much better by having a much clearer definition of what it is that they are testing). But the tests are lousy at specifying what can be done. I pulled up messenger.py as a random example. 1. Not a single comment. +1 2. Magic numbers. +1 3. Magic process flow (setup, teardown part of some framework unrelated to messenger. What's with assert? What's the thread model?). +1 4. No enumeration of functions to call, function arg lists, arg defaults, arg units, and so on. Not sure exactly what you mean here, though if you are saying that the tests should in some way be categorized by which API function they are testing, then I completely agree. 5. What are prerequisites? As a counterexample to using tests as specs, take a look at cpp/src/tests/acl.py and tell me how C++ broker ACLs work. No amount of ACL python test code will be a decent spec from which users can understand and write ACL rules. I'm not sure that one can prove a negative
