[jira] [Resolved] (PROTON-772) Remove all direct printing to stdout and stderr.
[ https://issues.apache.org/jira/browse/PROTON-772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway resolved PROTON-772. Resolution: Fixed Fix Version/s: 0.3 > Remove all direct printing to stdout and stderr. > > > Key: PROTON-772 > URL: https://issues.apache.org/jira/browse/PROTON-772 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.8 >Reporter: Alan Conway >Assignee: Alan Conway > Fix For: 0.3 > > > A library should never, ever print anything directly to stdout/stderr unless > explicitly requested to do so, as it may be linked with programs that need to > control what they output to stdout/err or programs that have no stdout/err at > all. > Failures should be raised via the API error mechanism with appropriate > message strings that the caller can display as they see fit. Informational > log messages should be logged in a way that the caller can send them where > they want or turn them off if they want. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-772) Remove all direct printing to stdout and stderr.
[ https://issues.apache.org/jira/browse/PROTON-772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14243625#comment-14243625 ] ASF subversion and git services commented on PROTON-772: Commit 9a72a30cd2762aaa1920300db8298cad30bf7201 in qpid-proton's branch refs/heads/master from [~aconway] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=9a72a30 ] PROTON-772: Remove all direct printing to stdout and stderr. Added a simple log facility in log.h. Former printfs to stderr, stout now use pn_logf(). Output is enabled by setting envionment variable PN_TRACE_LOG=ON or by calling: pn_log_init(); pn_log_enable(true); Default is output to stderr, can provide replacement log function via pn_log_logger() > Remove all direct printing to stdout and stderr. > > > Key: PROTON-772 > URL: https://issues.apache.org/jira/browse/PROTON-772 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.8 >Reporter: Alan Conway >Assignee: Alan Conway > > A library should never, ever print anything directly to stdout/stderr unless > explicitly requested to do so, as it may be linked with programs that need to > control what they output to stdout/err or programs that have no stdout/err at > all. > Failures should be raised via the API error mechanism with appropriate > message strings that the caller can display as they see fit. Informational > log messages should be logged in a way that the caller can send them where > they want or turn them off if they want. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Fixing the merge commit in the git repo?
> On Dec 11, 2014, at 5:11 PM, Darryl L. Pierce wrote: > > On Thu, Dec 11, 2014 at 04:16:29PM -0500, Clebert Suconic wrote: >> Rebasing and pushing is not a good option IMO. We have been using pull >> requests from GitHub and pushing them through Apache. It's working very well >> for us. >> >> Committing directly to Apachea may get you these issues. >> >> We can provide you guys more information on how we are doing on activemq6 if >> you are interested. > > Additionally, while working on a task branch, to resynch with master do > a rebase: > > $ rebase -i master > > rather than merging master down onto your task branch. I saw a *lot* of > that while examining the merge commits. Rebasing is by far one of the > most awesome features of git. Right but you can’t ever push -f on an apache branch. you can rebase as much as you like .. and it’s awesome I agree… But others would lose reference if you rebased and pushed -f.. that’s why it’s forbidden at the apache git. And that’s why we are very careful on merging commits.
Re: Fixing the merge commit in the git repo?
We do a slightly different approach. If you guys are doing git I really think you guys should consider it. > 1. create a task branch : git checkout -b my-working-branch > 2. create that voodoo that you do > 3. when done, rebase your task branch on master : git rebase -i master 4. push to your github fork 5. send a github Pull Request towards the github fork of the apache project 6. Someone else (yeah… someone who was not the original committer) should merge it after review 7 That someone else will do: git merge --no-ff github/pr/PRNumber ( We ellected to have merge committs with our committs, so we always have two people to blame in case things go wrong) If you elect to not have the merge commit like we have, you can simply use git pull.. and that should presever the Hashes from the original commit. 8. The apache bot will close the PR unless you rebased the commit (which you are not supposed to) Why we do that? I - to avoid merge errors like it just happened II - it increases community iii - we have a theory that everyone will do stupid things eventually... this is an extra layer of protection :) You could look at our README for more information: We are still getting started with it and we have based this on how other apache projects are using git and github: https://github.com/apache/activemq-6/blob/master/README.md
Re: Observations on the performance of the proton event model
- Original Message - > From: "Rafael Schloming" > To: proton@qpid.apache.org > Sent: Wednesday, December 10, 2014 5:41:20 PM > Subject: Re: Observations on the performance of the proton event model > > On Wed, Dec 10, 2014 at 11:23 AM, Ken Giusti wrote: > > > Hi, > > > > I've been working on a simple patch to qpidd that ports the AMQP 1.0 > > module to the new event interface provided by proton 0.8. See > > https://issues.apache.org/jira/browse/QPID-6255 for the patch. > > > > With the above patch, I've noticed a pretty consistent small drop in > > overall qpidd performance as gauged by qpid-cpp-benchmark (see comments in > > above jira). Turns out the event loop is doing a lot more work when > > compared to the polled approach for the same message load. > > > > Digging around a bit, there are a couple of issues that result in qpidd > > doing a lot of unnecessary work: > > > > 1) the PN_TRANSPORT event isn't needed by this driver - pending output is > > manually checked at a later point. In my test, approximately 25% of the > > total events are PN_TRANSPORT events, which the driver simply discards > > > > 2) A more serious issue - I get a PN_LINK_FLOW event for _every_ message > > transfer! Turns out that PN_LINK_FLOW is being issued for two different > > events (IMHO): when a flow frame is received (yay) and each time a transfer > > is done and credit is consumed (ugh). > > > > Item #2 seems like a bug - these two events have different semantic > > meaning and would likely result in different processing paths in the driver > > (in the case of qpidd, the credit consumed case would be ignored). > > > > It's not a bug, it was added intentionally since there are circumstances > where you get stalls if you don't have it. Each time a message is sent you > are actually updating the credit values on the link, and so if you don't > generate the event at that point, you need some fairly complex/subtle code > in your handlers to compensate. (You may actually have a bug yourself now > depending on how you've integrated the engine.) > Yes, I can see your point - processing a series of "credit added"/"credit removed" events doesn't really make sense. In the end you're really just concerned with the credit level at the point where you're servicing the link. > The event shouldn't be generated for every message though, just once for > each batch of messages. In other words if I stuff a bunch of messages into > the engine at the same time, there should be only one flow event produced > once the engine has finished writing messages to the wire. If you're > actually observing one flow per message then either there is a bug in the > logic that elides duplicate events, or you're stuffing one message into the > engine at a time. > Hmmm... AFAIKT, it would seem that the existing broker code iterates over each consuming link, and issues one message per link. Total conjecture here, but I thought that was desired, esp. in the case of multiple consumers on a shared queue. Gordon could possibly shed some light on this. In any case, if an application is load balancing messages across several outgoing links, won't each send result in a FLOW event? IOW - certain legitimate messaging patterns will result in that 1 Flow for every send. Or am I missing something? > > > > > I propose we fix #2 by breaking up that event into two separate events, > > something like PN_LINK_REMOTE_FLOW for when flow is granted, and > > PN_LINK_LOCAL_FLOW when credit is consumed (not in love with these names > > btw, they seem consistent with the endpoint states) > > > > Furthermore, I think the event API would benefit from a way to 'opt-in' to > > specific events. For example, for qpidd we would not want to receive > > PN_TRANSPORT nor PN_LINK_LOCAL_FLOW events. > > > > I've hacked my proton library to avoid generating PN_TRANSPORT and > > PN_LINK_FLOW on local credit consumption and that results in performance > > parity with the existing polled approach. > > > > Does this make sense? Other ideas? > > > I don't think it makes sense to introduce a new event type. The two events > mean very much the same thing, i.e. credit levels have changed. A distinct > event type would only make sense if there were common cases where you > wanted to react to the two different events differently, and having them be > the same made that difficult or cumbersome. Of course that doesn't preclude > us from adding some configuration to the engine that lets us control when > the flow event is produced, however as Andrew points out that isn't very > compatible with the whole "event bus" model of engine use. > > I think it's worth investigating exactly why you're getting so many of them > since I wouldn't expect there to be one per message unless you are somehow > forcing only one message to go through the engine at a time. It would also > probably be good to look at exactly why ignored events are so expensive, > perhaps isolate/measure h
Re: Fixing the merge commit in the git repo?
On Thu, Dec 11, 2014 at 04:16:29PM -0500, Clebert Suconic wrote: > Rebasing and pushing is not a good option IMO. We have been using pull > requests from GitHub and pushing them through Apache. It's working very well > for us. > > Committing directly to Apachea may get you these issues. > > We can provide you guys more information on how we are doing on activemq6 if > you are interested. Additionally, while working on a task branch, to resynch with master do a rebase: $ rebase -i master rather than merging master down onto your task branch. I saw a *lot* of that while examining the merge commits. Rebasing is by far one of the most awesome features of git. -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ pgpeYfzyU3P0t.pgp Description: PGP signature
Re: Fixing the merge commit in the git repo?
On Thu, Dec 11, 2014 at 04:16:29PM -0500, Clebert Suconic wrote: > Rebasing and pushing is not a good option IMO. We have been using pull > requests from GitHub and pushing them through Apache. It's working very well > for us. > > Committing directly to Apachea may get you these issues. > > We can provide you guys more information on how we are doing on activemq6 if > you are interested. So if we don't want to go back and fix history (which is fine) can we take steps to avoid pushing merge commits in future? It's just an ugly and confusing situation to get into with them. For anybody who's not familiar with a good git workflow: 1. create a task branch : git checkout -b my-working-branch 2. create that voodoo that you do 3. when done, rebase your task branch on master : git rebase -i master 4. checkout master and merge : git checkout master; git merge my-working-branch 5. make sure master is up to date : git pull --rebase 6. push your changes 7. profit! This way we don't have those ugly diamonds in the gitg graph and issues like this in future. -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ pgpHx0DDTzxNY.pgp Description: PGP signature
Re: Fixing the merge commit in the git repo?
Rebasing and pushing is not a good option IMO. We have been using pull requests from GitHub and pushing them through Apache. It's working very well for us. Committing directly to Apachea may get you these issues. We can provide you guys more information on how we are doing on activemq6 if you are interested. > On Dec 11, 2014, at 16:13, Darryl L. Pierce wrote: > >> On Thu, Dec 11, 2014 at 02:35:05PM -0500, Rafael Schloming wrote: >> Can you provide a bit more detail? I'm not the most expert git user, so I'm >> not sure exactly what you're asking for, much less how to do it. > > In my case, my usual workflow is to do small changes and commit them > locally. If a change goes with a commit a few back I'll do: > > $ git commit -a --fixup=[early commit's hash] > > Then, when I'm ready to commit I'll do: > > $ git rebase -i HEAD~[# of commits to process] --autosquash > > and git will put the commits in the right order so I can squash them > down. > > Normally I just do "HEAD~25" rather than counting the commits since we > usually had a nice, linear stream of commits in our old repo that was > cloned from Subversion. But when I did it this time that the commits > overlapped with this merge commit: > > ===[snip]=== > commit e8029597b825e49ee5ab2b7c8bd5d042e57321bb > Merge: db437cf a5cb27e > Author: Rafael Schloming > Date: Fri Nov 28 08:43:03 2014 -0500 > >Merge branch 'javascript' > ===[snip]=== > > This made git them try to rebase all of those changes, which numbered up > to about 60 or so commits that are out of sequence. So I had to abort > that rebase and count the commits instead and do it again. > > When merging branches, etc. we can avoid this if, before merging branch > A into master we go to branch A and rebase it on master. That way we > avoid merge commits like this. > > To fix it, you would need to: > > 1. git rebase -i HEAD~[# of commits to the merge above] > 2. when it pops up the list of commits, just save (you're not going to > re-order them at that point) > 3. check for any merge commits, dual adds or deletes with "git status" > 4. fix any issues that you see: fix merges, etc. > 5. git add (or del) files as needed > 6. git rebase --continue > 7. go to 3 as needed until all is fixed > > -- > Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. > Delivering value year after year. > Red Hat ranks #1 in value among software vendors. > http://www.redhat.com/promo/vendor/ >
Re: Fixing the merge commit in the git repo?
On Thu, Dec 11, 2014 at 02:35:05PM -0500, Rafael Schloming wrote: > Can you provide a bit more detail? I'm not the most expert git user, so I'm > not sure exactly what you're asking for, much less how to do it. In my case, my usual workflow is to do small changes and commit them locally. If a change goes with a commit a few back I'll do: $ git commit -a --fixup=[early commit's hash] Then, when I'm ready to commit I'll do: $ git rebase -i HEAD~[# of commits to process] --autosquash and git will put the commits in the right order so I can squash them down. Normally I just do "HEAD~25" rather than counting the commits since we usually had a nice, linear stream of commits in our old repo that was cloned from Subversion. But when I did it this time that the commits overlapped with this merge commit: ===[snip]=== commit e8029597b825e49ee5ab2b7c8bd5d042e57321bb Merge: db437cf a5cb27e Author: Rafael Schloming Date: Fri Nov 28 08:43:03 2014 -0500 Merge branch 'javascript' ===[snip]=== This made git them try to rebase all of those changes, which numbered up to about 60 or so commits that are out of sequence. So I had to abort that rebase and count the commits instead and do it again. When merging branches, etc. we can avoid this if, before merging branch A into master we go to branch A and rebase it on master. That way we avoid merge commits like this. To fix it, you would need to: 1. git rebase -i HEAD~[# of commits to the merge above] 2. when it pops up the list of commits, just save (you're not going to re-order them at that point) 3. check for any merge commits, dual adds or deletes with "git status" 4. fix any issues that you see: fix merges, etc. 5. git add (or del) files as needed 6. git rebase --continue 7. go to 3 as needed until all is fixed -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ pgpGCgaCe_wBM.pgp Description: PGP signature
Re: Fixing the merge commit in the git repo?
If you pushed invalid commits the easier way is to revert them. If you really want commits out then you will need someone from infra to push -f as forced is disabled at Apache repos. > On Dec 11, 2014, at 15:36, Rafael Schloming wrote: > > Can you provide a bit more detail? I'm not the most expert git user, so I'm > not sure exactly what you're asking for, much less how to do it. > > --Rafael > > On Thu, Dec 11, 2014 at 11:30 AM, Darryl L. Pierce > wrote: >> >> Would it be possible for someone (Rafi?) to fix the merge commits in the >> Git repo? I'm working on some stuff and, when I tried to do a rebase I >> accidentally went a few commits further back and git wanted to then >> rebase 65 commits... >> >> On our individual ends, once it's done, we should be able to just do: >> >> $ git pull --rebase >> >> and have our individual repos fixed as a result. >> >> -- >> Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. >> Delivering value year after year. >> Red Hat ranks #1 in value among software vendors. >> http://www.redhat.com/promo/vendor/ >> >>
Re: Fixing the merge commit in the git repo?
Can you provide a bit more detail? I'm not the most expert git user, so I'm not sure exactly what you're asking for, much less how to do it. --Rafael On Thu, Dec 11, 2014 at 11:30 AM, Darryl L. Pierce wrote: > > Would it be possible for someone (Rafi?) to fix the merge commits in the > Git repo? I'm working on some stuff and, when I tried to do a rebase I > accidentally went a few commits further back and git wanted to then > rebase 65 commits... > > On our individual ends, once it's done, we should be able to just do: > > $ git pull --rebase > > and have our individual repos fixed as a result. > > -- > Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. > Delivering value year after year. > Red Hat ranks #1 in value among software vendors. > http://www.redhat.com/promo/vendor/ > >
[jira] [Updated] (PROTON-756) add a new/simpler setup.py for python bindings
[ https://issues.apache.org/jira/browse/PROTON-756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darryl L. Pierce updated PROTON-756: Attachment: 0001-PROTON-756-Add-the-proton-directory-to-the-install-p.patch Appends "proton" the Python install path for the bindings. > add a new/simpler setup.py for python bindings > -- > > Key: PROTON-756 > URL: https://issues.apache.org/jira/browse/PROTON-756 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Reporter: Rafael H. Schloming >Assignee: Ken Giusti >Priority: Blocker > Fix For: 0.9 > > Attachments: > 0001-PROTON-756-Add-the-proton-directory-to-the-install-p.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-756) add a new/simpler setup.py for python bindings
[ https://issues.apache.org/jira/browse/PROTON-756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated PROTON-756: Priority: Blocker (was: Major) > add a new/simpler setup.py for python bindings > -- > > Key: PROTON-756 > URL: https://issues.apache.org/jira/browse/PROTON-756 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Reporter: Rafael H. Schloming >Assignee: Ken Giusti >Priority: Blocker > Fix For: 0.9 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Fixing the merge commit in the git repo?
Would it be possible for someone (Rafi?) to fix the merge commits in the Git repo? I'm working on some stuff and, when I tried to do a rebase I accidentally went a few commits further back and git wanted to then rebase 65 commits... On our individual ends, once it's done, we should be able to just do: $ git pull --rebase and have our individual repos fixed as a result. -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ pgpsO2YbjQg7u.pgp Description: PGP signature
Re: Next realease of qpid-proton
Thank you Rafael -- View this message in context: http://qpid.2158936.n2.nabble.com/Next-realease-of-qpid-proton-tp7617393p7617395.html Sent from the Apache Qpid Proton mailing list archive at Nabble.com.
Re: Next realease of qpid-proton
We are currently working towards the 0.9 release in the upcoming weeks. The roadmap is here: - http://qpid.apache.org/proton/development.html --Rafael On Thu, Dec 11, 2014 at 9:11 AM, xavier wrote: > Hi all, > > Do you where can I find the roadmap for qpid-proton library? > > Regards > > > > -- > View this message in context: > http://qpid.2158936.n2.nabble.com/Next-realease-of-qpid-proton-tp7617393.html > Sent from the Apache Qpid Proton mailing list archive at Nabble.com. >
Next realease of qpid-proton
Hi all, Do you where can I find the roadmap for qpid-proton library? Regards -- View this message in context: http://qpid.2158936.n2.nabble.com/Next-realease-of-qpid-proton-tp7617393.html Sent from the Apache Qpid Proton mailing list archive at Nabble.com.
