[jira] [Created] (PROTON-803) Message codec improvements
Rajith Attapattu created PROTON-803: --- Summary: Message codec improvements Key: PROTON-803 URL: https://issues.apache.org/jira/browse/PROTON-803 Project: Qpid Proton Issue Type: Improvement Components: proton-j Affects Versions: 0.8 Reporter: Rajith Attapattu Assignee: Rajith Attapattu Fix For: 0.9 This JIRA covers improvements made to the codec, especially lists and maps. The work is based on https://github.com/rhs/qpid-proton-old/tree/codec/proton-j/src/main/java/org/apache/qpid/proton/codec2 The above referenced code, is quite an improvement with respect to writing lists, maps and strings over the existing codec. Simply put the writeList and writeMap methods in the old encorder is about ~10 times slower than the new encorder. If I run with a sufficiently large set of strings, the old encorder is about ~2 times slower than the new encorder. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-594) In tree builds with cmake causes issues when running python based tests
Rajith Attapattu created PROTON-594: --- Summary: In tree builds with cmake causes issues when running python based tests Key: PROTON-594 URL: https://issues.apache.org/jira/browse/PROTON-594 Project: Qpid Proton Issue Type: Bug Components: proton-c Reporter: Rajith Attapattu Assignee: Rafael H. Schloming Fix For: 0.8 If we do an in-tree build it causes path issues when trying to run the python based tests against the java code. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (PROTON-594) In tree builds with cmake causes issues when running python based tests
[ https://issues.apache.org/jira/browse/PROTON-594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14018873#comment-14018873 ] Rajith Attapattu commented on PROTON-594: - Rafi could you please create a new component for the cmake build system. I just temporarily assigned this JIRA to proton-c to create the JIRA as it doesn't allow to leave it blank. In tree builds with cmake causes issues when running python based tests --- Key: PROTON-594 URL: https://issues.apache.org/jira/browse/PROTON-594 Project: Qpid Proton Issue Type: Bug Components: proton-c Reporter: Rajith Attapattu Assignee: Rafael H. Schloming Fix For: 0.8 If we do an in-tree build it causes path issues when trying to run the python based tests against the java code. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (PROTON-589) Implement passive mode for proton-j messenger
Rajith Attapattu created PROTON-589: --- Summary: Implement passive mode for proton-j messenger Key: PROTON-589 URL: https://issues.apache.org/jira/browse/PROTON-589 Project: Qpid Proton Issue Type: Improvement Components: proton-j Reporter: Rajith Attapattu Assignee: Rajith Attapattu Fix For: 0.8 Passive mode allows the file descriptors for messenger to be serviced by an external loop. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (PROTON-543) Frame Parser error if input stream is read before SASL is initialized in the transport
Rajith Attapattu created PROTON-543: --- Summary: Frame Parser error if input stream is read before SASL is initialized in the transport Key: PROTON-543 URL: https://issues.apache.org/jira/browse/PROTON-543 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.6, 0.5 Reporter: Rajith Attapattu Assignee: Rajith Attapattu If the input stream is read and passed into the transport, before the sasl() method of TransportImpl.java is called then the _inputProcessor defaults to FrameParser instead of being wrapped by the SASL frame parser. This causes a Frame Parsing error as it expects '0' as per the regular header but instead finds '3' which is the correct format if the process is the SASL frame parser. As per the discussion on @proton we decide to throw an exception if sasl is set after the input stream has been processed. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (PROTON-65) Provide a AMQP 1.0 Message to JMS Message mapping logic/module
[ https://issues.apache.org/jira/browse/PROTON-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13472449#comment-13472449 ] Rajith Attapattu commented on PROTON-65: Hiram, One of the goals of proton is to be as as dependency free as possible, so it can be used in as many environments as possible. From that pov I don't think this is a good idea at all. For example, having the jms library as a dependency will be a big issue in using proton-j in Android (or similar environments). On the other hand if we can make this as a separate optional jar (maybe thats what you are doing in this patch, and I haven't messed with maven for ages) then that maybe acceptable. But still I'm not too comfortable with the idea. I'm not too sure if proton is the place to do so. I would like to see comments from other interested parties about this. Regards, Rajith Provide a AMQP 1.0 Message to JMS Message mapping logic/module -- Key: PROTON-65 URL: https://issues.apache.org/jira/browse/PROTON-65 Project: Qpid Proton Issue Type: New Feature Components: proton-j Reporter: Hiram Chirino Attachments: PROTON-65.patch Having a easy/consistent way to transform a JMS message to an AMQP message and back would be super handy. Having that logic live in proton would help make that mapping more standardized as different client and sever implementations can just re-use the logic. -- 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-65) Provide a AMQP 1.0 Message to JMS Message mapping logic/module
[ https://issues.apache.org/jira/browse/PROTON-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13472540#comment-13472540 ] Rajith Attapattu commented on PROTON-65: Hiram, First of all, thx for confirming that it's indeed a separate jar. I figured it was the case, but wasn't too sure given that I haven't messed with mvn for long. I certainly see the value of having a mapping btw the AMQP message --- JMS Message and make it available for other folks to use it. But I'm not sure if proton is the right place to have it. Now to be fair to you, this is a discussion that goes beyond this particular issue. We have to make a clear statement about what proton is and what proton is not. Based on the discussions we had so far about the goals of proton, this doesn't seem to fit in well. IMO this is something that is best housed at Qpid (or even ActiveMQ for the time being). Again this is only my opinion. I would talk to other folks as well to see what they think about this. Regards, Rajith Provide a AMQP 1.0 Message to JMS Message mapping logic/module -- Key: PROTON-65 URL: https://issues.apache.org/jira/browse/PROTON-65 Project: Qpid Proton Issue Type: New Feature Components: proton-j Reporter: Hiram Chirino Attachments: PROTON-65.patch Having a easy/consistent way to transform a JMS message to an AMQP message and back would be super handy. Having that logic live in proton would help make that mapping more standardized as different client and sever implementations can just re-use the logic. -- 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-66) Driver implementation for proton-j
Rajith Attapattu created PROTON-66: -- Summary: Driver implementation for proton-j Key: PROTON-66 URL: https://issues.apache.org/jira/browse/PROTON-66 Project: Qpid Proton Issue Type: New Feature Reporter: Rajith Attapattu Provide an implementation for the Driver API. This consists of 3 interfaces. Connector, Listener and Driver. -- 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-16) addTransportWork and addWork methods in ConnectionImpl.java could cause an infinite loop
[ https://issues.apache.org/jira/browse/PROTON-16?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13450062#comment-13450062 ] Rajith Attapattu commented on PROTON-16: I plan to cherry-pick the following commit to trunk to fix the above issue. http://svn.apache.org/viewvc?view=revisionrevision=1366219 addTransportWork and addWork methods in ConnectionImpl.java could cause an infinite loop Key: PROTON-16 URL: https://issues.apache.org/jira/browse/PROTON-16 Project: Qpid Proton Issue Type: Bug Reporter: Rajith Attapattu When adding a head or tail with non null pointers for next and previous the resulting link list will loop infinitely. -- 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
