Re: [VOTE] merge the proton mailing list into the users/dev lists
+1 On 03/30/2016 06:25 AM, Robbie Gemmell wrote: Hello folks, Many moons ago, a seperate mailing list was established for Proton, back when it was purely a protocol engine other components would use. Its scope has since expanded beyond that and the separate mailing list has I feel been an increasing source of confusion and hassle of late more than anything else. Collapsing it into the other larger existing lists we have (that the traffic would otherwise have been on) seems to me like it would be an improvement across the board, and as such I have called this vote. I would propose that discussion (such as this) would head to the users@q.a.o list to join the similar/related/duplicate traffic already present, with remaining things going to the dev@q.a.o list as consistent with that list (e.g JIRA, GitHub integration mails, ReviewBoard, though the latter was never actually directed to proton@ to begin with..). Whilst redirecting JIRA etc emails should be easy enough (has been done before), I dont know what the precise options are regarding existing mail subscriptions to the list. There are significantly more subscribers to users@ than proton@, and many are duplicates, but some are not. I'd need to discuss options with infra, but first things first, the vote. I have gone straight to a vote on this because I feel this has already been discussed enough previously over time that many people will have already thought about it enough to quickly vote one way or the other, and it is past time to act on it if things head that way. Obviously things can be further discusssed at this point also if desired. Note that both users@ and proton@ are in the recipients. I expect the thread will splinter when someone forgets to reply-all, as almost all cross-posted thread on the lists do, but at least it can start on both for visibility to all. Robbie . -- Tim Bish twitter: @tabish121 blog: http://timbish.blogspot.com/
Re: Qpid Proton set session id
On 03/24/2016 10:04 PM, arkain wrote: Hello, I have a question about connecting to ActiveMQ. I'm trying to connect multiple consumers to a queue, by changing the session id. I'm not sure how to do that with qpid-proton According to http://activemq.apache.org/multiple-consumers-on-a-queue.html, my consumer's need to have unique sessions, but I have no idea how to accomplish this. I'm developing in python, but any help would be appreciated. Thanks, Kai -- View this message in context: http://qpid.2158936.n2.nabble.com/Qpid-Proton-set-session-id-tp7640698.html Sent from the Apache Qpid Proton mailing list archive at Nabble.com. Be careful here when trying to apply documentation written for the ActiveMQ JMS clients to proton based clients. This documentation is referring specifically to the requirements that each JMS Session created from a given JMS Connection must dispatch messages to consumers created from the session in a single dedicated session dispatch thread. Because of this if you want to have concurrent consumption you need multiple JMS Sessions open an create consumers from the sessions based on your needs for concurrent consumption. In your case since you are creating multiple connections this limitation wouldn't even matter were it a JMS client since each connection would have sessions that dispatched from their own internal dispatch thread disjoint from any of the other connection / session pairs. -- Tim Bish twitter: @tabish121 blog: http://timbish.blogspot.com/
[jira] [Created] (PROTON-1147) Add OSGi bundle metadata to the proton-j jar manifest
Timothy Bish created PROTON-1147: Summary: Add OSGi bundle metadata to the proton-j jar manifest Key: PROTON-1147 URL: https://issues.apache.org/jira/browse/PROTON-1147 Project: Qpid Proton Issue Type: Improvement Components: proton-j Affects Versions: 0.12.0 Reporter: Timothy Bish Assignee: Timothy Bish Fix For: 0.13.0 Add OSGi bundle metadata to the proton-j module using the maven BND plugin. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-1145) Move the python shim code to the test module where it is used.
[ https://issues.apache.org/jira/browse/PROTON-1145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved PROTON-1145. -- Resolution: Fixed > Move the python shim code to the test module where it is used. > -- > > Key: PROTON-1145 > URL: https://issues.apache.org/jira/browse/PROTON-1145 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-j >Affects Versions: 0.12.0 >Reporter: Timothy Bish > Assignee: Timothy Bish > Fix For: 0.13.0 > > > The proton-j project embeds the python binding code used in the tests module > which can result in breakages when other maven tooling attempts to > interoperate with the proton-j jar. Since the shim code is only currently > used in the tests module we should relocate it there. If there is some > demand to have have these python modules available outside the test module we > could create a new proton-j-bindings module that produces a jar with only > those files inside. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-1145) Move the python shim code to the test module where it is used.
Timothy Bish created PROTON-1145: Summary: Move the python shim code to the test module where it is used. Key: PROTON-1145 URL: https://issues.apache.org/jira/browse/PROTON-1145 Project: Qpid Proton Issue Type: Improvement Components: proton-j Affects Versions: 0.12.0 Reporter: Timothy Bish Assignee: Timothy Bish Fix For: 0.13.0 The proton-j project embeds the python binding code used in the tests module which can result in breakages when other maven tooling attempts to interoperate with the proton-j jar. Since the shim code is only currently used in the tests module we should relocate it there. If there is some demand to have have these python modules available outside the test module we could create a new proton-j-bindings module that produces a jar with only those files inside. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-1141) Update JUnit Dependency and fix some warnings in the tests.
[ https://issues.apache.org/jira/browse/PROTON-1141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved PROTON-1141. -- Resolution: Fixed > Update JUnit Dependency and fix some warnings in the tests. > --- > > Key: PROTON-1141 > URL: https://issues.apache.org/jira/browse/PROTON-1141 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-j >Affects Versions: 0.12.0 >Reporter: Timothy Bish > Assignee: Timothy Bish > Fix For: 0.13.0 > > > Update to the latest JUnit dependency and fix some use of deprecated JUnit > assertions in the tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-1141) Update JUnit Dependency and fix some warnings in the tests.
Timothy Bish created PROTON-1141: Summary: Update JUnit Dependency and fix some warnings in the tests. Key: PROTON-1141 URL: https://issues.apache.org/jira/browse/PROTON-1141 Project: Qpid Proton Issue Type: Improvement Components: proton-j Affects Versions: 0.12.0 Reporter: Timothy Bish Assignee: Timothy Bish Fix For: 0.13.0 Update to the latest JUnit dependency and fix some use of deprecated JUnit assertions in the tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Help?!: Qpid JMS 0.6.0 HelloWorld example issue
On 02/19/2016 12:39 PM, Flores, Paul A. wrote: > Trying to get the HelloWorld example that is found with the QPID JMS 0.6.0 > Release to work. > > > > When I go to run it I am seeing the following. > > > > Can some one point me to a resolution? I am running out of hair to pull! > Try changing you URI in the jndi.properties to 'amqp://localhost:5672' not the 'amqp' is not capitalized. > > Thanks. > > > > Paul > > > > 2016-02-19 10:32:47,256 [main ] - ERROR ProviderFactory >- Failed to create Provider instance for AMQP, due to: > java.io.IOException: Provider scheme NOT recognized: [AMQP] > 2016-02-19 10:32:47,259 [main ] - ERROR JmsConnectionFactory >- Failed to create JMS Provider instance for: AMQP > Caught exception, exiting. > javax.jms.JMSException: Failed to create connection to: AMQP://localhost:5672 > at > org.apache.qpid.jms.exceptions.JmsExceptionSupport.create(JmsExceptionSupport.java:66) > at > org.apache.qpid.jms.JmsConnectionFactory.createConnection(JmsConnectionFactory.java:165) > at HelloWorld.main(HelloWorld.java:51) > Caused by: java.io.IOException: Provider scheme NOT recognized: [AMQP] > at > org.apache.qpid.jms.provider.ProviderFactory.findProviderFactory(ProviderFactory.java:104) > at > org.apache.qpid.jms.provider.ProviderFactory.create(ProviderFactory.java:70) > at > org.apache.qpid.jms.JmsConnectionFactory.createProvider(JmsConnectionFactory.java:221) > at > org.apache.qpid.jms.JmsConnectionFactory.createConnection(JmsConnectionFactory.java:161) > ... 1 more > Caused by: org.apache.qpid.jms.util.ResourceNotFoundException: Could not find > factory resource: META-INF/services/org/apache/qpid/jms/provider/AMQP > at > org.apache.qpid.jms.util.FactoryFinder$StandaloneObjectFactory.loadProperties(FactoryFinder.java:223) > at > org.apache.qpid.jms.util.FactoryFinder$StandaloneObjectFactory.create(FactoryFinder.java:164) > at > org.apache.qpid.jms.util.FactoryFinder.newInstance(FactoryFinder.java:122) > at > org.apache.qpid.jms.provider.ProviderFactory.findProviderFactory(ProviderFactory.java:102) > ... 4 more > -- Tim Bish twitter: @tabish121 blog: http://timbish.blogspot.com/
Re: [VOTE] Release RC 3 as Qpid Proton 0.12.0
On 02/10/2016 09:04 AM, Justin Ross wrote: > Hi, everyone. RC 2 had some embedded build output, which this RC removes. > Apart from that removal, it has the same content as RC 2. > > The proposed release artifacts: > > https://dist.apache.org/repos/dist/dev/qpid/proton/0.12.0-rc3/ > > Please indicate your vote below. If you favor releasing the 0.12.0 RC 3 > bits as 0.12.0 GA, vote +1. If you have reason to think RC 3 is not > ready for release, vote -1. > > Thanks, > Justin > +1 Tested ActiveMQ using the staged artifacts Tested Qpid JMS with the staged artifacts Built from source and ran the tests. -- Tim Bish twitter: @tabish121 blog: http://timbish.blogspot.com/
Re: [VOTE] Release Qpid Proton 0.12.0
+1 * Built and ran tests. * validated signatures and sums * Built ActiveMQ using the staged maven artifacts and ran all AMQP tests * Built Qpid-JMS using the staged maven artifacts and ran all the tests. On 02/03/2016 10:10 AM, Justin Ross wrote: > The artifacts proposed for release: > > https://dist.apache.org/repos/dist/dev/qpid/proton/0.12.0-rc/ > > Please indicate your vote below. If you favor releasing the 0.12.0 RC bits > as 0.12.0 GA, vote +1. If you have reason to think the RC is not ready for > release, vote -1. > > Thanks, > Justin > -- Tim Bish twitter: @tabish121 blog: http://timbish.blogspot.com/
Re: [VOTE] Release Qpid Proton 0.11.0
On 11/11/2015 07:53 AM, Justin Ross wrote: > The artifacts proposed for release are here: > > https://dist.apache.org/repos/dist/dev/qpid/proton/0.11.0-rc2/ > > Please indicate your vote below. If you favor releasing the 0.11.0 RC 2 > bits as 0.11.0 GA, vote +1. If you have reason to think RC 2 is not ready > for release, vote -1. > > Thanks! > Justin > +1 Tested ActiveMQ using the artifacts in staged maven repo Tested Qpid JMS using the staging repo Built from source and ran the tests, all passed Validated signature and sums Checked license an notice files -- Tim Bish Sr Software Engineer | RedHat Inc. tim.b...@redhat.com | www.redhat.com twitter: @tabish121 blog: http://timbish.blogspot.com/
[jira] [Commented] (PROTON-971) [proton-j] multi-frame deliveries may be broken when sent if buffered along with a futher delivery for the same link
[ https://issues.apache.org/jira/browse/PROTON-971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14987428#comment-14987428 ] Timothy Bish commented on PROTON-971: - Reviewed the changes, fix seems valid. > [proton-j] multi-frame deliveries may be broken when sent if buffered along > with a futher delivery for the same link > > > Key: PROTON-971 > URL: https://issues.apache.org/jira/browse/PROTON-971 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Affects Versions: 0.10, 0.11 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Critical > Fix For: 0.12.0 > > Attachments: PROTON-971_test.patch > > > Proton-j sends at most a single frame for a delivery in each call to > "processTransportWorkSender(DeliveryImpl delivery, SenderImpl snd)", which > occurs for each sent delivery on the 'transport work list' in turn during the > "processTransportWork" call. That call is made twice for each process of the > transport. As such, at most 2 frames for each delivery can be emitted for > each process of the transport. However, because all deliveries on the > connections 'transport work list' are processed in turn by > "processTransportWork", it is possible that interleaved transfer frames for > subsequent deliveries on the same link will also be emitted if there are > other buffered deliveries on the work list and the session window and frame > writer 'isFUll' checks permit it. > This in itself would already be illegal [1] even if the frames were otherwise > correct, but the erroenous transfer frames also get marked with the wrong > delivery-id since that is only incremented by the transport when a delivery > has been completed, so if it was not all sent yet then the > initial/interleaved transfer frames for the subsequent delivery are also > stamped with the same id. Proton-j uses the delivery-id while consitituting > received deliveries, and thus the mismatch results in interleaving of the > payload from the later delivery within that for the earlier delivery. > [1] > http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transport-v1.0-os.html#doc-idp484080 > "However, messages transferred along a single link MUST NOT be interleaved." -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Timeline to drop Java 6 support for Proton?
+1 for dropping Java 6 from future releases. On 07/08/2015 09:59 AM, Robbie Gemmell wrote: Epic bump. As per https://issues.apache.org/jira/browse/PROTON-935 the build is currently broken again on Java 6. We need to either update it to compile on Java 6, since that is still the builds compiler source/target, or alternatively drop support for Java 6 and require Java 7. I'd do the latter given that noone except the CI box seems to be testing it, Java 7 is already EOL itself, and most if not all of the dependent proejcts that I am aware of using proton-j already require Java 7 themselves now. Robbie On 24 September 2014 at 15:24, Robbie Gemmell robbie.gemm...@gmail.com wrote: The compilation issue I missed in the patch was test-only this time, but it could have as easily been in non-test code. The other tests now failing might actually point to some functionality under test not working under Java 6 at runtime though, which is more of an issue. If the tests showing it didnt exist, or the CI job had been using either the current or previous major Java release, then that might not have been noticed prior to release. Whether it compiles or not isnt the only reason to drop support. Releasing new versions that people can continue deploying to EOL plaforms in years to come isnt necessarily helping anyone if we aren't in fact properly ensuring it really works there. If we dont tuly support it, we should probably cut it. Whether we do it now, or later, I just think it would be a good idea to actually decide on a timeline. Robbie On 24 September 2014 14:11, Clebert Suconic csuco...@redhat.com wrote: This is just testing... can't you have a java7 tests folder? you would be able to still have java7 specific tests. On Sep 24, 2014, at 7:13 AM, Robbie Gemmell robbie.gemm...@gmail.com wrote: Hi all, With Qpid 0.30 we have made the move to requiring Java 7+. Currently, proton still allows for use of Java 6, so I wonder what peoples thoughts are on the timing of a similar move for Proton? I'd personally like to do it soon since Java 6 is EOL, but if not then I think we should at least decide when we will. Robbie Background: I committed a patch yesterday which contained some Java 7 API usage in its tests, and subsequently broke the ASF Jenkins jobs that are still using Java 6 (I'm using 8). Having now noticed this I updated the test to make it compile and run on Java 6, unfortunately having to disable use of some of the input aimed at testing the defect in question. Everything now compiles and the test in question passes, but the overall test run is still failing because it turns out some other new changes in recent days mean there are now a couple of URL tests which fail on Java 6 (but work on Java 8). -- Tim Bish Sr Software Engineer | RedHat Inc. tim.b...@redhat.com | www.redhat.com twitter: @tabish121 blog: http://timbish.blogspot.com/
Re: [Resending] - Proton-J engine and thread safety
On 06/10/2015 10:18 AM, Kritikos, Alex wrote: Hi Alan, thanks for your response. We also use an engine per connection however there are different read and write threads interacting with it and the issues only occur under load. I guess we should try to create a repro case. Thanks, Alex Kritikos Software AG On 10 Jun 2015, at 16:50, aconway acon...@redhat.com wrote: To my knowledge there is not expectation the Proton-J is any more thread safe than Proton-C. In both the new QPid JMS client and in the ActiveMQ broker that uses Proton-J we serialize access to the engine for that reason. On Wed, 2015-06-10 at 09:34 +, Kritikos, Alex wrote: [Resending as it ended up in the wrong thread] Hi all, is the proton-j engine meant to be thread safe? The C engine is definitely NOT meant to be thread safe. Unless you have found an explicit written declaration that the java engine is supposed to be AND a bunch of code to back that up I wouldn't rely on it. The way we use proton in the C++ broker and in the upcoming Go binding is to create an engine per connection and serialize the action on each connection. In principle you can read and write from the OS connection concurrently but it's debatable how much you gain, you are likely just moving OS buffers into app buffers which is not a big win. The inbound and outbound protocol state *for a single connection* is pretty closely tied together. Proton is probably taking the right approach by assuming both are handled in a single concurrency context. The engine state for separate connections is *completely independent* so it's safe to run engines for separate connections in separte contexts. The recent reactor extensions to proton are interesting but not thread friendly. They force the protocol handling for multiple connections into a single thread context, which is great for single threaded apps but IMO the wrong way to go for concurrent apps. The go binding uses channels to pump data from connection read/write goroutines to a proton engine event loop goroutine per connection. The C++ broker predates the reactor and does it's own polling with read/write activity on an FD handled dispatched sequentially to worker threads so the proton engine for a connection is never used concurrently. There may be something interesting we can do at the proton layer to help with this pattern or it may be better to leave concurrency above the binding to be handled by the languages own concurrency tools, I am not sure yet. We have been experiencing some sporadic issues where under load, the engine sends callbacks to registered handlers with null as the event. We do not have a standalone repro case yet but just wondered what other people’s experience is as well as what are the recommendations around thread safety. Thanks, Alex Kritikos Software AG This communication contains information which is confidential and may also be privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s), please note that any distribution, copying, or use of this communication or the information in it, is strictly prohibited. If you have received this communication in error please notify us by e-mail and then delete the e-mail and any copies of it. Software AG (UK) Limited Registered in England Wales 1310740 - http://www.softwareag.com/uk This communication contains information which is confidential and may also be privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s), please note that any distribution, copying, or use of this communication or the information in it, is strictly prohibited. If you have received this communication in error please notify us by e-mail and then delete the e-mail and any copies of it. Software AG (UK) Limited Registered in England Wales 1310740 - http://www.softwareag.com/uk -- Tim Bish Sr Software Engineer | RedHat Inc. tim.b...@redhat.com | www.redhat.com twitter: @tabish121 blog: http://timbish.blogspot.com/
Re: [VOTE]: Release Proton 0.9.1-rc1 as 0.9.1
On 04/29/2015 03:34 PM, Rafael Schloming wrote: Hi Everyone, I've put out an RC for 0.9.1 in the usual places. Source artifacts are here: https://people.apache.org/~rhs/qpid-proton-0.9.1-rc1/ Java binaries are here: https://repository.apache.org/content/repositories/orgapacheqpid-1033 Please check them out and register your vote: [ ]: Yes, release Proton 0.9.1-rc1 as 0.9.1 [ ]: No, ... --Rafael +1 * Built and ran tests from the source bundle * Tested ActiveMQ using the staging artifacts -- Tim Bish Sr Software Engineer | RedHat Inc. tim.b...@redhat.com | www.redhat.com twitter: @tabish121 blog: http://timbish.blogspot.com/
Re: New release?
On 04/23/2015 06:39 AM, Robbie Gemmell wrote: Hi folks, I would like to propose doing a new release. There have been quite a few important fixes or changes since 0.9, mainly in proton-j, that I would like to see made available for use in dependent projects such as the JMS client. These include things such as preventing a few memory leaks, some changes to stop erroneous attach frames being sent, and some updates in the new heartbeat support to align its timing behaviour with proton-c. I dont think there is anything on master specific to proton-j that I wouldnt include currently, however it seems likely the same isn't true for proton-c right now, e.g with the large SASL changes having just had their initial landing this week and given that the next release was probably not expected to be for a noticable period of time. As a result I would propose doing a point release based on 0.9, branching from the 0.9 tag (e.g to 0.9.x) and then cherry picking any desired changes to include. Thoughts? Robbie +1 a quick point release would be good given the nature of those Proton-J fixes. -- Tim Bish Sr Software Engineer | RedHat Inc. tim.b...@redhat.com | www.redhat.com twitter: @tabish121 blog: http://timbish.blogspot.com/
[jira] [Resolved] (PROTON-845) Proton-J: Potential NPE in proton-jms outbound native transformer
[ https://issues.apache.org/jira/browse/PROTON-845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved PROTON-845. - Resolution: Fixed Fix Version/s: 0.10 Added check and create of Header instance if none was present in the original Message. Proton-J: Potential NPE in proton-jms outbound native transformer - Key: PROTON-845 URL: https://issues.apache.org/jira/browse/PROTON-845 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.7, 0.8 Reporter: Timothy Bish Assignee: Timothy Bish Priority: Minor Fix For: 0.10 The AMQPOutboundNativeTransformer attempt to set a header value when transforming the stored message with a JMSXDeliveryCount value set but if the original message had no headers section the code will throw an NPE. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-845) Proton-J: Potential NPE in proton-jms outbound native transformer
Timothy Bish created PROTON-845: --- Summary: Proton-J: Potential NPE in proton-jms outbound native transformer Key: PROTON-845 URL: https://issues.apache.org/jira/browse/PROTON-845 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.8, 0.7 Reporter: Timothy Bish Assignee: Timothy Bish Priority: Minor The AMQPOutboundNativeTransformer attempt to set a header value when transforming the stored message with a JMSXDeliveryCount value set but if the original message had no headers section the code will throw an NPE. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [VOTE]: Proton 0.9-rc-3
On 03/16/2015 04:42 PM, Rafael Schloming wrote: [ ] Yes, release Proton 0.9-rc-3 as 0.9 final [X] Yes, release Proton 0.9-rc-3 as 0.9 final -- Tim Bish Sr Software Engineer | RedHat Inc. tim.b...@redhat.com | www.redhat.com skype: tabish121 | twitter: @tabish121 blog: http://timbish.blogspot.com/
Re: Please can we get rid of the trunk branch (or make it a symlink to master)
On 02/16/2015 03:02 PM, Rafael Schloming wrote: I'm not much of a git expert, so I don't know what the preferred option would be, but I'm +1 for killing it in one form or another. --Rafael You can submit a request to INFRA to drop it, the only caveat is that there is no enforcement to prevent someone from accidentally recreating it so you might have to do it once or twice until everyone gets used to things being on master instead of trunk. On Mon, Feb 16, 2015 at 2:32 PM, Alan Conway acon...@redhat.com wrote: I work on a mix of SVN and GIT-based projects so I switch between trunk and master a lot. Proton used to be an SVN based project. I repeatedly stub my toe on the old trunk branch which has been left lying around with some random commit at it's head. Can we please do any one of the following: - delete it. - rename it to something else. - make it a symbolic reference to master. I don't care which, I'm just tired of typing git checkout trunk by reflex and being allowed to continue down the rat-hole till some ancient proton bug crops up and I have another DOH! moment. Cheers, Alan. -- Tim Bish Sr Software Engineer | RedHat Inc. tim.b...@redhat.com | www.redhat.com skype: tabish121 | twitter: @tabish121 blog: http://timbish.blogspot.com/
Re: [VOTE]: migrate the proton repo to use git
[ X ] Yes, migrate the proton repo over to git. On 10/30/2014 06:59 AM, Rafael Schloming wrote: Hi Everyone, I'm planning on updating the release script for 0.9 to automate the last few details of the release process and to do proper branching. Given that the release script must make use of the canonical repo to work properly, it occurs to me that if we're going to switch over to git then now would be a good time so that I only need to update the release script once. I'd therefore like to call for a formal vote to approve the switch. [ ] Yes, migrate the proton repo over to git. [ ] No, keep it in svn. --Rafael -- Tim Bish Sr Software Engineer | RedHat Inc. tim.b...@redhat.com | www.redhat.com skype: tabish121 | twitter: @tabish121 blog: http://timbish.blogspot.com/
Re: VOTE: Release Proton 0.8 RC5 as 0.8 final
[X] Yes, release Proton 0.8 RC5 as 0.8 final Proton-J side still works for AMQ. On 10/27/2014 09:51 PM, Rafael Schloming wrote: Hi Everyone, Sorry for the delay, there seemed to be some kind of Nexus outage today, so I was unable to generate the java binaries until just now. I've posted RC5 in the usual places. The only difference from RC4 is a one line delta that replaces the assertion failure when we receive out-of-sequence ids with a connection shutdown error. Please have a look and register your vote. Source code can be found here: http://people.apache.org/~rhs/qpid-proton-0.8rc5/ Java binaries are here: https://repository.apache.org/content/repositories/orgapacheqpid-1021 [ ] Yes, release Proton 0.8 RC5 as 0.8 final [ ] No, because ... --Rafael -- Tim Bish Sr Software Engineer | RedHat Inc. tim.b...@redhat.com | www.redhat.com skype: tabish121 | twitter: @tabish121 blog: http://timbish.blogspot.com/
Re: VOTE: Release Proton 0.8 RC4 as 0.8 final
[ X ] Yes, release Proton 0.8 RC4 as 0.8 final. Tested Proton-J with ActiveMQ and the new JMS client and found no issues, On 10/23/2014 12:21 PM, Rafael Schloming wrote: Hi Everyone, I've put together RC4. This is pretty much the same as RC3 with a number of fixes to disable those SSL versions that are vulnerable to attack. The sources are available here: - http://people.apache.org/~rhs/qpid-proton-0.8rc4/ Java binaries are here: - https://repository.apache.org/content/repositories/orgapacheqpid-1020/ Changes since RC3: - PROTON-724: make sure to pop any pending output in pn_transport_close_head() - PROTON-720: [Windows IO] fix format specifier to print string - added dispatch utility - fixed error message - fixed Collector.put - PROTON-719 : prevent ssl3 connections in Windows with schannel - PROTON-717: disable SSLv3 - PROTON-717: mitigate the CRIME SSL vulnerability - PROTON-716: reject connections using SSLv3 - it is insecure Please check the sources out and register your vote: [ ] Yes, release Proton 0.8 RC4 as 0.8 final. [ ] No, because... --Rafael -- Tim Bish Sr Software Engineer | RedHat Inc. tim.b...@redhat.com | www.redhat.com skype: tabish121 | twitter: @tabish121 blog: http://timbish.blogspot.com/
[jira] [Updated] (PROTON-508) Use of Sasl auth results in a large performance hit.
[ https://issues.apache.org/jira/browse/PROTON-508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish updated PROTON-508: Attachment: (was: PROTON-508.txt) Use of Sasl auth results in a large performance hit. Key: PROTON-508 URL: https://issues.apache.org/jira/browse/PROTON-508 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.6 Reporter: Timothy Bish Fix For: 0.7 Attachments: PROTON-508.txt Using proton engine in ActiveMQ to implement AMQP 1.0 support we noticed that a send from broker to the QPid JMS client is terribly slow for large messages. After some debugging it appears that the SaslImpl class imposes a pretty big penalty due to the way it wraps the input and output processors of the TransportImpl class. When sasl() method of TransportImpl is called to get hold of the Sasl impl for authentication the transport init method is called and buffers are allocated. In the SaslImpl class the result is that the output buffer is allocated with the default value of the remote max frame size since there hasn't been any negotiation yet. After the SASL handshake completes and the TransportImpl has updated itself to reflect the QPid client's preferred 64k max frame size, the SaslImpl instance still continues on with it's internal output buffer of 512 bytes. The end result of this is that as we attempt to send out a larger message we end up in a situation where we are draining the underlying transport output buffer 512 bytes at a time. I attached a patch that takes a stab at making the SaslImpl become a passive entity after it completes the handshake. In testing on ActiveMQ we go from sending out a 10mb message in 35+ seconds to around 300ms. Unfortunately some of the tests in the proton tests suite are now failing with this so it's not quite right. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (PROTON-508) Use of Sasl auth results in a large performance hit.
[ https://issues.apache.org/jira/browse/PROTON-508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish updated PROTON-508: Attachment: PROTON-508.txt New patch that resolves the issue and keeps tests passing. Problem found in ConnectionImpl prevented pending data from being written on blocked channel. Use of Sasl auth results in a large performance hit. Key: PROTON-508 URL: https://issues.apache.org/jira/browse/PROTON-508 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.6 Reporter: Timothy Bish Fix For: 0.7 Attachments: PROTON-508.txt Using proton engine in ActiveMQ to implement AMQP 1.0 support we noticed that a send from broker to the QPid JMS client is terribly slow for large messages. After some debugging it appears that the SaslImpl class imposes a pretty big penalty due to the way it wraps the input and output processors of the TransportImpl class. When sasl() method of TransportImpl is called to get hold of the Sasl impl for authentication the transport init method is called and buffers are allocated. In the SaslImpl class the result is that the output buffer is allocated with the default value of the remote max frame size since there hasn't been any negotiation yet. After the SASL handshake completes and the TransportImpl has updated itself to reflect the QPid client's preferred 64k max frame size, the SaslImpl instance still continues on with it's internal output buffer of 512 bytes. The end result of this is that as we attempt to send out a larger message we end up in a situation where we are draining the underlying transport output buffer 512 bytes at a time. I attached a patch that takes a stab at making the SaslImpl become a passive entity after it completes the handshake. In testing on ActiveMQ we go from sending out a 10mb message in 35+ seconds to around 300ms. Unfortunately some of the tests in the proton tests suite are now failing with this so it's not quite right. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (PROTON-508) Use of Sasl auth results in a large performance hit.
[ https://issues.apache.org/jira/browse/PROTON-508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish updated PROTON-508: Attachment: PROTON-508.txt Use of Sasl auth results in a large performance hit. Key: PROTON-508 URL: https://issues.apache.org/jira/browse/PROTON-508 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.6 Reporter: Timothy Bish Fix For: 0.7 Attachments: PROTON-508.txt, PROTON-508.txt Using proton engine in ActiveMQ to implement AMQP 1.0 support we noticed that a send from broker to the QPid JMS client is terribly slow for large messages. After some debugging it appears that the SaslImpl class imposes a pretty big penalty due to the way it wraps the input and output processors of the TransportImpl class. When sasl() method of TransportImpl is called to get hold of the Sasl impl for authentication the transport init method is called and buffers are allocated. In the SaslImpl class the result is that the output buffer is allocated with the default value of the remote max frame size since there hasn't been any negotiation yet. After the SASL handshake completes and the TransportImpl has updated itself to reflect the QPid client's preferred 64k max frame size, the SaslImpl instance still continues on with it's internal output buffer of 512 bytes. The end result of this is that as we attempt to send out a larger message we end up in a situation where we are draining the underlying transport output buffer 512 bytes at a time. I attached a patch that takes a stab at making the SaslImpl become a passive entity after it completes the handshake. In testing on ActiveMQ we go from sending out a 10mb message in 35+ seconds to around 300ms. Unfortunately some of the tests in the proton tests suite are now failing with this so it's not quite right. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (PROTON-508) Use of Sasl auth results in a large performance hit.
[ https://issues.apache.org/jira/browse/PROTON-508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish updated PROTON-508: Attachment: (was: PROTON-508.txt) Use of Sasl auth results in a large performance hit. Key: PROTON-508 URL: https://issues.apache.org/jira/browse/PROTON-508 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.6 Reporter: Timothy Bish Fix For: 0.7 Attachments: PROTON-508.txt Using proton engine in ActiveMQ to implement AMQP 1.0 support we noticed that a send from broker to the QPid JMS client is terribly slow for large messages. After some debugging it appears that the SaslImpl class imposes a pretty big penalty due to the way it wraps the input and output processors of the TransportImpl class. When sasl() method of TransportImpl is called to get hold of the Sasl impl for authentication the transport init method is called and buffers are allocated. In the SaslImpl class the result is that the output buffer is allocated with the default value of the remote max frame size since there hasn't been any negotiation yet. After the SASL handshake completes and the TransportImpl has updated itself to reflect the QPid client's preferred 64k max frame size, the SaslImpl instance still continues on with it's internal output buffer of 512 bytes. The end result of this is that as we attempt to send out a larger message we end up in a situation where we are draining the underlying transport output buffer 512 bytes at a time. I attached a patch that takes a stab at making the SaslImpl become a passive entity after it completes the handshake. In testing on ActiveMQ we go from sending out a 10mb message in 35+ seconds to around 300ms. Unfortunately some of the tests in the proton tests suite are now failing with this so it's not quite right. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (PROTON-508) Use of Sasl auth results in a large performance hit.
Timothy Bish created PROTON-508: --- Summary: Use of Sasl auth results in a large performance hit. Key: PROTON-508 URL: https://issues.apache.org/jira/browse/PROTON-508 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.6 Reporter: Timothy Bish Fix For: 0.7 Attachments: PROTON-508.txt Using proton engine in ActiveMQ to implement AMQP 1.0 support we noticed that a send from broker to the QPid JMS client is terribly slow for large messages. After some debugging it appears that the SaslImpl class imposes a pretty big penalty due to the way it wraps the input and output processors of the TransportImpl class. When sasl() method of TransportImpl is called to get hold of the Sasl impl for authentication the transport init method is called and buffers are allocated. In the SaslImpl class the result is that the output buffer is allocated with the default value of the remote max frame size since there hasn't been any negotiation yet. After the SASL handshake completes and the TransportImpl has updated itself to reflect the QPid client's preferred 64k max frame size, the SaslImpl instance still continues on with it's internal output buffer of 512 bytes. The end result of this is that as we attempt to send out a larger message we end up in a situation where we are draining the underlying transport output buffer 512 bytes at a time. I attached a patch that takes a stab at making the SaslImpl become a passive entity after it completes the handshake. In testing on ActiveMQ we go from sending out a 10mb message in 35+ seconds to around 300ms. Unfortunately some of the tests in the proton tests suite are now failing with this so it's not quite right. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (PROTON-474) Incorrect mapping of TTL to JMSExpiration in JMS InboundTransformer
Timothy Bish created PROTON-474: --- Summary: Incorrect mapping of TTL to JMSExpiration in JMS InboundTransformer Key: PROTON-474 URL: https://issues.apache.org/jira/browse/PROTON-474 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.5 Reporter: Timothy Bish Fix For: 0.6 The inbound message transformation of AMQP message to JMS message incorrectly sets the JMSExpiration to message TTL which is defined in milliseconds while the JMSExpiration value is a sum of the Message Timestamp and the producers TTL. The transformation should probably map the message creation time + the TTL to the setJMSExpiration method. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (PROTON-474) Incorrect mapping of TTL to JMSExpiration in JMS InboundTransformer
[ https://issues.apache.org/jira/browse/PROTON-474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish updated PROTON-474: Attachment: JMSExpiration-patch.txt Proposed patch for this issue. Incorrect mapping of TTL to JMSExpiration in JMS InboundTransformer --- Key: PROTON-474 URL: https://issues.apache.org/jira/browse/PROTON-474 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.5 Reporter: Timothy Bish Fix For: 0.6 Attachments: JMSExpiration-patch.txt The inbound message transformation of AMQP message to JMS message incorrectly sets the JMSExpiration to message TTL which is defined in milliseconds while the JMSExpiration value is a sum of the Message Timestamp and the producers TTL. The transformation should probably map the message creation time + the TTL to the setJMSExpiration method. -- This message was sent by Atlassian JIRA (v6.1#6144)
