Re: [PROPOSAL] Change java thrift code gen

2016-01-28 Thread John Sirois 
On Thu, Jan 28, 2016 at 8:26 AM, John Sirois  wrote:

> On Thu, Jan 28, 2016 at 6:45 AM, Jake Farrell  wrote:
>
> > +1 to making this apart of Thrift, i'm happy to help shepard this on the
> > Thrift side and get it in as soon as its ready
> >
>
> I've filed https://issues.apache.org/jira/browse/THRIFT-3583 to use as the
> basis for discussion of this feature over in the Apache Thrift project.
> I looked at the problem a bit and noted some challenges.
>

And started a d...@thrift.apache.org thread here if anyone wants to follow
along or participate: http://markmail.org/message/mlxyyauyvlvuxjsf


>
>
> >
> > -Jake
> >
> > On Wed, Jan 27, 2016 at 8:08 PM, Maxim Khutornenko 
> > wrote:
> >
> >> I am +1 to making immutable thrift objects solely based on perf numbers.
> >>
> >> My biggest concern though is maintenance of a pretty intricate codebase,
> >> especially when it comes to upgrading any of the frameworks involved.
> >> Bill's suggestion to explore paths to make this a part of Apache Thrift
> >> sounds great to me.
> >>
> >> On Wed, Jan 27, 2016 at 5:00 PM, Bill Farner 
> wrote:
> >>
> >> > Tony - this would not be a technical fork so much as a spiritual fork.
> >> > While we would have our own bugs to work out, the only upstream
> exposure
> >> > would be IDL or wire format changes.
> >> >
> >> > On Wed, Jan 27, 2016 at 4:58 PM, Tony Dong  >
> >> > wrote:
> >> >
> >> > > Awesome performance numbers! I don't particularly know the logistics
> >> of
> >> > > upstreaming a change like this, but optimistically I would suggest
> >> > > upstreaming it to Apache Thrift if possible.
> >> > >
> >> > > As someone that maintains a fork of a thrift compiler(fork of
> >> scrooge), I
> >> > > have to say that it's not that fun. There's a lot of custom code
> that
> >> > needs
> >> > > to be maintained and a bunch of work to rebase the code
> periodically.
> >> > >
> >> > >
> >> > >
> >> > > On Wed, Jan 27, 2016 at 4:51 PM, Bill Farner 
> >> wrote:
> >> > >
> >> > > > Firstly - thanks for the clean organization and delineation of
> >> steps in
> >> > > > this change.  Top notch work!
> >> > > >
> >> > > > Some of the performance improvements are very nice; and in a
> >> > particularly
> >> > > > hot code path.  I will wager a guess that the majority of the
> >> savings
> >> > is
> >> > > in
> >> > > > avoiding what amounts to copy constructors between mutable and
> >> > immutable
> >> > > > types.  I further wager there are alternative approaches we could
> >> weigh
> >> > > to
> >> > > > achieve those performance improvements.  As an example - you note
> >> above
> >> > > > that we could provide a patch to Apache Thrift.  Depending how
> much
> >> > > > performance inspires our decision here, it will be prudent to
> >> evaluate
> >> > > > alternatives.
> >> > > >
> >> > > > I think there are (at least) two major issues worth discussing -
> >> code
> >> > > > volume (which you note) and an increase in logical complexity.
> This
> >> > will
> >> > > > leave us with a bifurcation in code generation tooling
> (custom+swift
> >> > for
> >> > > > Java, Apache Thrift for python and js).  It's difficult to
> quantify
> >> the
> >> > > > downside of that, but it seems like an unfortunate state with
> >> potential
> >> > > for
> >> > > > compatibility risks.
> >> > > >
> >> > > >
> >> > > > On Wed, Jan 27, 2016 at 2:45 PM, Zameer Manji 
> >> > wrote:
> >> > > >
> >> > > > > Some high level comments without looking at the code.
> >> > > > >
> >> > > > > I'm in favor from abandoning the thrift generated java code in
> >> favor
> >> > of
> >> > > > > immutable objects. I think it is easier to reason about and will
> >> > ensure
> >> > > > we
> >> > > > > have less errors in our code. If I understand correctly, the
> >> ProtoBuf
> >> > > > > format does this by default, so there some precedent for this
> >> style
> >> > of
> >> > > > code
> >> > > > > generation already.
> >> > > > >
> >> > > > > I think using Facebook's swift is the best approach here. I
> would
> >> be
> >> > > > > hesitant to accept any custom code generation that involved us
> >> > parsing
> >> > > > > thrift IDL files or thrift formats over the wire because I
> poses a
> >> > very
> >> > > > > high maintenance burden.
> >> > > > >
> >> > > > > I also think generating the MyBatis mutable classes is superior
> to
> >> > our
> >> > > > > current strategy of manually creating them.
> >> > > > >
> >> > > > > Finally, the performance improvements look fantastic. As an
> >> operator
> >> > > of a
> >> > > > > large cluster I am excited to see wholesale performance
> >> improvements
> >> > > as I
> >> > > > > am always concerned that my cluster is approaching the limits of
> >> what
> >> > > > > Aurora can handle safely.
> >> > > > >
> >> > > > > Overall, I think this change merits a serious discussion from
> all
> >> > >

Re: [VOTE] Release Apache Aurora 0.12.0 RC2

2016-01-28 Thread Maxim Khutornenko 
-1. Found a blocking UI bug:
https://issues.apache.org/jira/browse/AURORA-1604

On Thu, Jan 28, 2016 at 4:01 PM, John Sirois  wrote:

> All,
>
> I propose that we accept the following release candidate as the official
> Apache Aurora 0.12.0 release.
>
> Aurora 0.12.0-rc2 includes the following:
> ---
> The NEWS for the release is available at:
>
> https://git-wip-us.apache.org/repos/asf?p=aurora.git=NEWS=rel/0.12.0-rc2
>
> The CHANGELOG for the release is available at:
>
> https://git-wip-us.apache.org/repos/asf?p=aurora.git=CHANGELOG=rel/0.12.0-rc2
>
> The tag used to create the release candidate is:
>
> https://git-wip-us.apache.org/repos/asf?p=aurora.git;a=shortlog;h=refs/tags/rel/0.12.0-rc2
>
> The release candidate is available at:
>
> https://dist.apache.org/repos/dist/dev/aurora/0.12.0-rc2/apache-aurora-0.12.0-rc2.tar.gz
>
> The MD5 checksum of the release candidate can be found at:
>
> https://dist.apache.org/repos/dist/dev/aurora/0.12.0-rc2/apache-aurora-0.12.0-rc2.tar.gz.md5
>
> The signature of the release candidate can be found at:
>
> https://dist.apache.org/repos/dist/dev/aurora/0.12.0-rc2/apache-aurora-0.12.0-rc2.tar.gz.asc
>
> The GPG key used to sign the release are available at:
> https://dist.apache.org/repos/dist/dev/aurora/KEYS
>
> Please download, verify, and test.
>
> The vote will close on Sun Jan 31 16:52:39 MST 2016
>
> [ ] +1 Release this as Apache Aurora 0.12.0
> [ ] +0
> [ ] -1 Do not release this as Apache Aurora 0.12.0 because...
> ---
> Reminder: you can verify the release candidate as I have via:
>
>   ./build-support/release/verify-release-candidate 0.12.0-rc2
>
> If you can deploy the RC to a test cluster and evaluate it there, even
> better.
>

Re: [VOTE] Release Apache Aurora 0.12.0 RC0

2016-01-28 Thread John Sirois 
On Thu, Jan 28, 2016 at 3:12 PM, Joshua Cohen  wrote:

> Changing my vote to -1. We just found a critical bug with Maxim's commit:
>
> https://github.com/apache/aurora/commit/fee5943a95c4f08e148dc5f1366486a8c23d5773
> .
> This version is not suitable for release (or deploy for that matter).
>

Thanks for everyone for testing, especially Twitter.  Willingness to do
cluster tests is invaluable and very much appreciated!

I'm closing this release candidate vote as having failed and starting an
RC1 VOTE with the revert in-place.


> On Thu, Jan 28, 2016 at 2:49 PM, Bill Farner  wrote:
>
> > (moved off private list)
> >
> > +1 (binding)
> >
> > Successfully verified using
> > ./build-support/release/verify-release-candidate  0.12.0-rc0
> >
> > On Wed, Jan 27, 2016 at 11:21 PM, John Sirois 
> wrote:
> >
> > > All,
> > >
> > > I propose that we accept the following release candidate as the
> official
> > > Apache Aurora 0.12.0 release.
> > >
> > > Aurora 0.12.0-rc0 includes the following:
> > > ---
> > > The NEWS for the release is available at:
> > >
> > >
> >
> https://git-wip-us.apache.org/repos/asf?p=aurora.git=NEWS=rel/0.12.0-rc0
> > >
> > > The CHANGELOG for the release is available at:
> > >
> > >
> >
> https://git-wip-us.apache.org/repos/asf?p=aurora.git=CHANGELOG=rel/0.12.0-rc0
> > >
> > > The tag used to create the release candidate is:
> > >
> > >
> >
> https://git-wip-us.apache.org/repos/asf?p=aurora.git;a=shortlog;h=refs/heads/rel/0.12.0-rc0
> > >
> > > The release candidate is available at:
> > >
> > >
> >
> https://dist.apache.org/repos/dist/dev/aurora/0.12.0-rc0/apache-aurora-0.12.0-rc0.tar.gz
> > >
> > > The MD5 checksum of the release candidate can be found at:
> > >
> > >
> >
> https://dist.apache.org/repos/dist/dev/aurora/0.12.0-rc0/apache-aurora-0.12.0-rc0.tar.gz.md5
> > >
> > > The signature of the release candidate can be found at:
> > >
> > >
> >
> https://dist.apache.org/repos/dist/dev/aurora/0.12.0-rc0/apache-aurora-0.12.0-rc0.tar.gz.asc
> > >
> > > The GPG key used to sign the release are available at:
> > > https://dist.apache.org/repos/dist/dev/aurora/KEYS
> > >
> > > Please download, verify, and test.
> > >
> > > The vote will close on Tue Feb 2 00:21:29 MST 2016
> > >
> > > [ ] +1 Release this as Apache Aurora 0.12.0
> > > [ ] +0
> > > [ ] -1 Do not release this as Apache Aurora 0.12.0 because...
> > >
> > > ---
> > > Reminder: you can verify the release candidate as I have via:
> > >
> > >   ./build-support/release/verify-release-candidate 0.12.0-rc0
> > >
> > > If you can deploy the RC to a test cluster and evaluate it there, even
> > > better.
> > >
> >
>

Re: [VOTE] Release Apache Aurora 0.12.0 RC0

2016-01-28 Thread Jake Farrell 
+1, tested with verify-release-candidate

-Jake

On Thu, Jan 28, 2016 at 2:21 AM, John Sirois  wrote:

> All,
>
> I propose that we accept the following release candidate as the official
> Apache Aurora 0.12.0 release.
>
> Aurora 0.12.0-rc0 includes the following:
> ---
> The NEWS for the release is available at:
>
> https://git-wip-us.apache.org/repos/asf?p=aurora.git=NEWS=rel/0.12.0-rc0
>
> The CHANGELOG for the release is available at:
>
> https://git-wip-us.apache.org/repos/asf?p=aurora.git=CHANGELOG=rel/0.12.0-rc0
>
> The tag used to create the release candidate is:
>
> https://git-wip-us.apache.org/repos/asf?p=aurora.git;a=shortlog;h=refs/heads/rel/0.12.0-rc0
>
> The release candidate is available at:
>
> https://dist.apache.org/repos/dist/dev/aurora/0.12.0-rc0/apache-aurora-0.12.0-rc0.tar.gz
>
> The MD5 checksum of the release candidate can be found at:
>
> https://dist.apache.org/repos/dist/dev/aurora/0.12.0-rc0/apache-aurora-0.12.0-rc0.tar.gz.md5
>
> The signature of the release candidate can be found at:
>
> https://dist.apache.org/repos/dist/dev/aurora/0.12.0-rc0/apache-aurora-0.12.0-rc0.tar.gz.asc
>
> The GPG key used to sign the release are available at:
> https://dist.apache.org/repos/dist/dev/aurora/KEYS
>
> Please download, verify, and test.
>
> The vote will close on Tue Feb 2 00:21:29 MST 2016
>
> [ ] +1 Release this as Apache Aurora 0.12.0
> [ ] +0
> [ ] -1 Do not release this as Apache Aurora 0.12.0 because...
>
> ---
> Reminder: you can verify the release candidate as I have via:
>
>   ./build-support/release/verify-release-candidate 0.12.0-rc0
>
> If you can deploy the RC to a test cluster and evaluate it there, even
> better.
>

Re: [VOTE] Release Apache Aurora 0.12.0 RC0

2016-01-28 Thread Bill Farner 
(moved off private list)

+1 (binding)

Successfully verified using
./build-support/release/verify-release-candidate  0.12.0-rc0

On Wed, Jan 27, 2016 at 11:21 PM, John Sirois  wrote:

> All,
>
> I propose that we accept the following release candidate as the official
> Apache Aurora 0.12.0 release.
>
> Aurora 0.12.0-rc0 includes the following:
> ---
> The NEWS for the release is available at:
>
> https://git-wip-us.apache.org/repos/asf?p=aurora.git=NEWS=rel/0.12.0-rc0
>
> The CHANGELOG for the release is available at:
>
> https://git-wip-us.apache.org/repos/asf?p=aurora.git=CHANGELOG=rel/0.12.0-rc0
>
> The tag used to create the release candidate is:
>
> https://git-wip-us.apache.org/repos/asf?p=aurora.git;a=shortlog;h=refs/heads/rel/0.12.0-rc0
>
> The release candidate is available at:
>
> https://dist.apache.org/repos/dist/dev/aurora/0.12.0-rc0/apache-aurora-0.12.0-rc0.tar.gz
>
> The MD5 checksum of the release candidate can be found at:
>
> https://dist.apache.org/repos/dist/dev/aurora/0.12.0-rc0/apache-aurora-0.12.0-rc0.tar.gz.md5
>
> The signature of the release candidate can be found at:
>
> https://dist.apache.org/repos/dist/dev/aurora/0.12.0-rc0/apache-aurora-0.12.0-rc0.tar.gz.asc
>
> The GPG key used to sign the release are available at:
> https://dist.apache.org/repos/dist/dev/aurora/KEYS
>
> Please download, verify, and test.
>
> The vote will close on Tue Feb 2 00:21:29 MST 2016
>
> [ ] +1 Release this as Apache Aurora 0.12.0
> [ ] +0
> [ ] -1 Do not release this as Apache Aurora 0.12.0 because...
>
> ---
> Reminder: you can verify the release candidate as I have via:
>
>   ./build-support/release/verify-release-candidate 0.12.0-rc0
>
> If you can deploy the RC to a test cluster and evaluate it there, even
> better.
>

Build failed in Jenkins: aurora-packaging-nightly #176

2016-01-28 Thread Apache Jenkins Server 
See 

Changes:

[maxim] Improving job update query performance.

[wfarner] Remove deprecated fields made redundant by JobKey.

[jsirois] Fixup release-candidate script.

[jsirois] Updating CHANGELOG for 0.12.0 release.

[jsirois] Incrementing snapshot version to 0.13.0-SNAPSHOT.

[jsirois] Fixup RC email template tag URL.

[jsirois] Fixup RC VOTE email instructions.

[jcohen] Revert "Improving job update query performance."

[jsirois] Updating CHANGELOG for 0.13.0 release.

[jsirois] Incrementing snapshot version to 0.14.0-SNAPSHOT.

[jsirois] Updating CHANGELOG for 0.14.0 release.

[jsirois] Incrementing snapshot version to 0.14.1-SNAPSHOT.

[jsirois] Revert "Incrementing snapshot version to 0.14.1-SNAPSHOT."

[jsirois] Revert "Updating CHANGELOG for 0.14.0 release."

[jsirois] Revert "Incrementing snapshot version to 0.14.0-SNAPSHOT."

[jsirois] Revert "Updating CHANGELOG for 0.13.0 release."

[jsirois] Updating CHANGELOG for 0.12.0 release.

[jsirois] Incrementing snapshot version to 0.12.1-SNAPSHOT.

[jsirois] Revert "Incrementing snapshot version to 0.12.1-SNAPSHOT."

[jsirois] Revert "Updating CHANGELOG for 0.12.0 release."

[jsirois] Revert "Incrementing snapshot version to 0.13.0-SNAPSHOT."

[jsirois] Revert "Updating CHANGELOG for 0.12.0 release."

[jsirois] Updating CHANGELOG for 0.12.0 release.

[jsirois] Incrementing snapshot version to 0.12.1-SNAPSHOT.

--
[...truncated 1820 lines...]
Setting up python-apt-common (0.9.3.12) ...
Setting up rename (0.20-3) ...
update-alternatives: using /usr/bin/file-rename to provide /usr/bin/rename 
(rename) in auto mode
Setting up rsync (3.1.1-3) ...
invoke-rc.d: policy-rc.d denied execution of restart.
Setting up shared-mime-info (1.3-1) ...
Setting up strace (4.9-2) ...
Setting up unzip (6.0-16+deb8u2) ...
Setting up wdiff (1.2.2-1) ...
Setting up xauth (1:1.0.9-1) ...
Setting up xdg-user-dirs (0.15-2) ...
Setting up xml-core (0.13+nmu2) ...
Setting up equivs (2.0.9) ...
Setting up libkrb5-dev (1.12.1+dfsg-19+deb8u1) ...
Setting up libsvn-dev (1.8.10-6+deb8u2) ...
Setting up thrift-compiler (0.9.1-2) ...
Setting up python3 (3.4.2-2) ...
Setting up devscripts (2.15.3) ...
Setting up liblwp-protocol-https-perl (6.06-2) ...
Setting up python3-apt (0.9.3.12) ...
Setting up python3-pkg-resources (5.5.1-1) ...
Setting up python3-chardet (2.3.0-1) ...
Setting up python3-dbus (1.2.0-2+b3) ...
Setting up python3-six (1.8.0-1) ...
Setting up python3-debian (0.1.27) ...
Setting up python3-gi (3.14.0-1) ...
Setting up python3-magic (1:5.22+15-2+deb8u1) ...
Setting up unattended-upgrades (0.83.3.2+deb8u1) ...
update-rc.d: warning: start and stop actions are no longer supported; falling 
back to defaults
Setting up python3-software-properties (0.92.25debian1) ...
Setting up software-properties-common (0.92.25debian1) ...
Setting up dh-python (1.2014-2) ...
Setting up libwww-perl (6.08-1) ...
Setting up libparse-debcontrol-perl (2.005-4) ...
Setting up libxml-parser-perl (2.41-3) ...
Setting up libsoap-lite-perl (1.11-1) ...
Setting up libxmlrpc-lite-perl (0.717-1) ...
Processing triggers for systemd (215-17+deb8u3) ...
Processing triggers for libc-bin (2.19-18+deb8u2) ...
Processing triggers for ca-certificates (20141019+deb8u1) ...
Updating certificates in /etc/ssl/certs... 174 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.ddone.
Processing triggers for sgml-base (1.26+nmu4) ...
Processing triggers for dbus (1.8.20-0+deb8u1) ...
 ---> fdeade783450
Removing intermediate container 55104153b6d3
Step 6 : RUN apt-get -y -t jessie-backports install openjdk-8-jdk&& 
update-alternatives --set java /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java
 ---> Running in 7255f49668a4
Reading package lists...
Building dependency tree...
Reading state information...
The following extra packages will be installed:
  ca-certificates-java dbus-x11 fontconfig fontconfig-config fonts-dejavu-core
  fonts-dejavu-extra gconf-service gconf2 gconf2-common gnome-mime-data
  hicolor-icon-theme java-common libasound2 libasound2-data libasyncns0
  libatk-wrapper-java libatk-wrapper-java-jni libatk1.0-0 libatk1.0-data
  libavahi-client3 libavahi-common-data libavahi-common3 libavahi-glib1
  libbonobo2-0 libbonobo2-common libcairo2 libcanberra0 libcups2 libdatrie1
  libdrm-intel1 libdrm-nouveau2 libdrm-radeon1 libdrm2 libelf1 libflac8
  libfontconfig1 libfreetype6 libgconf-2-4 libgconf2-4 libgdk-pixbuf2.0-0
  libgdk-pixbuf2.0-common libgif4 libgl1-mesa-dri libgl1-mesa-glx
  libglapi-mesa libgnome-2-0 libgnome2-0 libgnome2-bin libgnome2-common
  libgnomevfs2-0 libgnomevfs2-common libgnomevfs2-extra libgraphite2-3
  libgtk2.0-0 libgtk2.0-bin libgtk2.0-common libharfbuzz0b libice-dev libice6
  libjasper1 libjbig0 libjpeg62-turbo libjson-c2 liblcms2-2 libllvm3.5
  libltdl7 libnspr4 libnss3 libogg0 liborbit-2-0 libpango-1.0-0
  libpangocairo-1.0-0 libpangoft2-1.0-0

[VOTE] Release Apache Aurora 0.12.0 RC2

2016-01-28 Thread John Sirois 
All,

I propose that we accept the following release candidate as the official
Apache Aurora 0.12.0 release.

Aurora 0.12.0-rc2 includes the following:
---
The NEWS for the release is available at:
https://git-wip-us.apache.org/repos/asf?p=aurora.git=NEWS=rel/0.12.0-rc2

The CHANGELOG for the release is available at:
https://git-wip-us.apache.org/repos/asf?p=aurora.git=CHANGELOG=rel/0.12.0-rc2

The tag used to create the release candidate is:
https://git-wip-us.apache.org/repos/asf?p=aurora.git;a=shortlog;h=refs/tags/rel/0.12.0-rc2

The release candidate is available at:
https://dist.apache.org/repos/dist/dev/aurora/0.12.0-rc2/apache-aurora-0.12.0-rc2.tar.gz

The MD5 checksum of the release candidate can be found at:
https://dist.apache.org/repos/dist/dev/aurora/0.12.0-rc2/apache-aurora-0.12.0-rc2.tar.gz.md5

The signature of the release candidate can be found at:
https://dist.apache.org/repos/dist/dev/aurora/0.12.0-rc2/apache-aurora-0.12.0-rc2.tar.gz.asc

The GPG key used to sign the release are available at:
https://dist.apache.org/repos/dist/dev/aurora/KEYS

Please download, verify, and test.

The vote will close on Sun Jan 31 16:52:39 MST 2016

[ ] +1 Release this as Apache Aurora 0.12.0
[ ] +0
[ ] -1 Do not release this as Apache Aurora 0.12.0 because...
---
Reminder: you can verify the release candidate as I have via:

  ./build-support/release/verify-release-candidate 0.12.0-rc2

If you can deploy the RC to a test cluster and evaluate it there, even
better.

Re: [PROPOSAL] Change java thrift code gen

2016-01-28 Thread Jake Farrell 
+1 to making this apart of Thrift, i'm happy to help shepard this on the
Thrift side and get it in as soon as its ready

-Jake

On Wed, Jan 27, 2016 at 8:08 PM, Maxim Khutornenko  wrote:

> I am +1 to making immutable thrift objects solely based on perf numbers.
>
> My biggest concern though is maintenance of a pretty intricate codebase,
> especially when it comes to upgrading any of the frameworks involved.
> Bill's suggestion to explore paths to make this a part of Apache Thrift
> sounds great to me.
>
> On Wed, Jan 27, 2016 at 5:00 PM, Bill Farner  wrote:
>
> > Tony - this would not be a technical fork so much as a spiritual fork.
> > While we would have our own bugs to work out, the only upstream exposure
> > would be IDL or wire format changes.
> >
> > On Wed, Jan 27, 2016 at 4:58 PM, Tony Dong 
> > wrote:
> >
> > > Awesome performance numbers! I don't particularly know the logistics of
> > > upstreaming a change like this, but optimistically I would suggest
> > > upstreaming it to Apache Thrift if possible.
> > >
> > > As someone that maintains a fork of a thrift compiler(fork of
> scrooge), I
> > > have to say that it's not that fun. There's a lot of custom code that
> > needs
> > > to be maintained and a bunch of work to rebase the code periodically.
> > >
> > >
> > >
> > > On Wed, Jan 27, 2016 at 4:51 PM, Bill Farner 
> wrote:
> > >
> > > > Firstly - thanks for the clean organization and delineation of steps
> in
> > > > this change.  Top notch work!
> > > >
> > > > Some of the performance improvements are very nice; and in a
> > particularly
> > > > hot code path.  I will wager a guess that the majority of the savings
> > is
> > > in
> > > > avoiding what amounts to copy constructors between mutable and
> > immutable
> > > > types.  I further wager there are alternative approaches we could
> weigh
> > > to
> > > > achieve those performance improvements.  As an example - you note
> above
> > > > that we could provide a patch to Apache Thrift.  Depending how much
> > > > performance inspires our decision here, it will be prudent to
> evaluate
> > > > alternatives.
> > > >
> > > > I think there are (at least) two major issues worth discussing - code
> > > > volume (which you note) and an increase in logical complexity.  This
> > will
> > > > leave us with a bifurcation in code generation tooling (custom+swift
> > for
> > > > Java, Apache Thrift for python and js).  It's difficult to quantify
> the
> > > > downside of that, but it seems like an unfortunate state with
> potential
> > > for
> > > > compatibility risks.
> > > >
> > > >
> > > > On Wed, Jan 27, 2016 at 2:45 PM, Zameer Manji 
> > wrote:
> > > >
> > > > > Some high level comments without looking at the code.
> > > > >
> > > > > I'm in favor from abandoning the thrift generated java code in
> favor
> > of
> > > > > immutable objects. I think it is easier to reason about and will
> > ensure
> > > > we
> > > > > have less errors in our code. If I understand correctly, the
> ProtoBuf
> > > > > format does this by default, so there some precedent for this style
> > of
> > > > code
> > > > > generation already.
> > > > >
> > > > > I think using Facebook's swift is the best approach here. I would
> be
> > > > > hesitant to accept any custom code generation that involved us
> > parsing
> > > > > thrift IDL files or thrift formats over the wire because I poses a
> > very
> > > > > high maintenance burden.
> > > > >
> > > > > I also think generating the MyBatis mutable classes is superior to
> > our
> > > > > current strategy of manually creating them.
> > > > >
> > > > > Finally, the performance improvements look fantastic. As an
> operator
> > > of a
> > > > > large cluster I am excited to see wholesale performance
> improvements
> > > as I
> > > > > am always concerned that my cluster is approaching the limits of
> what
> > > > > Aurora can handle safely.
> > > > >
> > > > > Overall, I think this change merits a serious discussion from all
> > > > > contributors.
> > > > >
> > > > > On Tue, Jan 26, 2016 at 9:19 PM, John Sirois 
> > > wrote:
> > > > >
> > > > > > On Tue, Jan 26, 2016 at 8:47 PM, John Sirois  >
> > > > wrote:
> > > > > >
> > > > > > > Context: Aurora uses the official Apache Thrift compiler today
> > > plus a
> > > > > > > home-grown python code generator [1] for immutable "entity"
> (I*)
> > > > > > wrappers.
> > > > > > >
> > > > > > > The proposal is to switch from using the Apache Thrift code
> > > generator
> > > > > to
> > > > > > a
> > > > > > > home grown generator.  The proposal comes with a concrete
> example
> > > in
> > > > > the
> > > > > > > form of the actual RBs to effect this change:
> > > > > > > 1. A custom java thrift code generator:
> > > > > > > https://reviews.apache.org/r/42748/
> > > > > > > 2. A custom MyBatis binding code generator powered by 1 above:
> > > > > >