Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixes #452 - supporting thrift 0.7 and 0.9 #455

Merged
merged 4 commits into from
Dec 17, 2015
Merged

Conversation

EugenCepoi
Copy link
Contributor

An attempt to #452 - support thrift 0.7 and 0.9+ by using separate source trees enabled via maven profiles.
By default the enabled profile is thrift7 to remain compatible with the current behaviour/use. Building against thrift 9 can be done by enabling thrift9 profile.

The code that is incompatible has been isolated so most future changes can benefit to both versions.
I have tested it against thrift 0.9.1 and 0.7.0.

What this doesn't handle yet is a dual release...this could be achieved using classifiers. But first I want to have those changes validated before attempting to make sure the release works properly.

@ianoc can you please have a look at this PR.

@@ -7,11 +7,16 @@ before_install:
- sudo apt-get update -qq
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can you change it so these are independent travis builds? it will keep the travis speeds up and isolate failures from one side to the other.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you mean by using travis matrix builds? will have a look

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Exactly. We use them in things like scalding/summingbird to try avoid single large builds

@ianoc
Copy link
Contributor

ianoc commented Nov 11, 2015

Sorry i've been away so little slow to get to this. Looks pretty much perfect to me, few minor comments only.

@EugenCepoi
Copy link
Contributor Author

Great thanks! About the releasing part. What do you think, should we add classifiers for thrift 7 and 9 and release both? I think it would be nicer for end users so they don't need to fork, build and deploy their specific version.

@ianoc
Copy link
Contributor

ianoc commented Nov 11, 2015

Yes i think classifiers would be awesome for releasing, can leave the default, but having thrift 9+ artifacts in maven central would make it much easier for new users

- mvn test -Dtest.library.path=$PWD/hadoop-lzo-native/lib -Drequire.lzo.tests=true -P hadoop2
- mvn test -Dthrift.cmd=/var/thrift-old/bin/thrift -Dtest.library.path=$PWD/hadoop-lzo-native/lib -Drequire.lzo.tests=true -P hadoop2
- echo ============ Build and test for thrift 0.9+ ================
- mvn clean test -Dthrift.cmd=/var/thrift-new/bin/thrift -Dtest.library.path=$PWD/hadoop-lzo-native/lib -Drequire.lzo.tests=true -P thrift9
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mhhh I think that the build against hadoop X and test against hadoop Y never worked. Running mvn test includes mvn compile. So can I just drop this?
The matrix would include following scenarios: hadoop 1 and thrift 0.7, hadoop 1 and thrift 0.9, hadoop 2 and thrift 0.7, hadoop 2 and thrift 0.9. Or should I remove one of the hadoop X and thrift Y assuming that the thrift code is compatible with any hadoop version?

@EugenCepoi
Copy link
Contributor Author

Ok so squashed all that into two commits, first one the feature it self second one the matrix build.
Will look now into releasing EB for both thrift versions.

@ianoc
Copy link
Contributor

ianoc commented Nov 12, 2015

Looks good to me once we get releasing down. Once you've that code in I'll just grab this branch to have a quick sense check with some local releases. Don't see anything else though. Any thoughts @isnotinvain or @rangadi

@EugenCepoi
Copy link
Contributor Author

After being busy with other stuff I finally found the time to give it a shot.

@ianoc I've updated the PR with automatic releases of the artifacts build for thrift 7 and 9. This was pretty tricky and I couldn't find anything else working from end to end using the std maven plugins. So I ended up doing some stuff via bash script. I tested it in on a ubuntu vagrant box with releases to a local repo (on the local fs), which worked for me.
So the main constraint is that this script can be run only from debian/ubuntu, not from a mac or a redhat distrib etc.

Let me know if you want me to explain my choices or if I need to update some doc to reflect this new release process.

@EugenCepoi
Copy link
Contributor Author

Something is strange not only the error is surprising but the project versions that I see in the build don't correspond to the actual code... in the travis logs we can see [INFO] Building Elephant Bird 4.11rc2-SNAPSHOT when my code is still with the older 4.11-SNAPSHOT version....

@EugenCepoi
Copy link
Contributor Author

Ok so the issue was related to travis who is experimenting with google cloud platform which in turn doesn't have an ip address associated to the local hostname which in turn hits some bug in the jvms native libnet.so...

I added a fix for it in the build, seems to work... ouf :p

The travis issue: travis-ci/travis-ci#1484

@EugenCepoi EugenCepoi changed the title Fixes #452 - supporting thrift 0.7 and 0.9 via multiple maven profiles Fixes #452 - supporting thrift 0.7 and 0.9 Dec 15, 2015
trans.reset(bytes, offset, len);
base.read(protocol);
}

protected void resetAndInitialize(TBinaryProtocol protocol, int newLength) {
protocol.reset();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this mean you are not setting the limits in Thrift 0.9? Is it not useful there?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you are talking about setReadLength, then yeah it has been removed from thrift 9.

@rangadi
Copy link
Contributor

rangadi commented Dec 17, 2015

@EugenCepoi thanks for the doing this. I came across this incompatibility today. Would love to get this in. I have one above about not setting length limits for Thrift 9.

@@ -0,0 +1,285 @@
#!/usr/bin/env bash
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does this do? We can avoid having to publish multiple versions of packages for thrift-0.7 & thrift-0.9. This is how we handle multiple hadoop versions (there the incompatibility is much greater). This is how it could work : the build could be either with thrift-0.7 or thrift-0.9 profile, but at runtime, ThriftCompat would detect which version of thrift is available and would handle the length limit appropriately.

This also most mean, we would have to move thrift dependency to 'provided' scope in mvn, which is fine.

@rangadi
Copy link
Contributor

rangadi commented Dec 17, 2015

Please hold off on this, I will have smaller patch (but bit more hacky, essentially read these the values through reflection). I will try to get this out on Saturday... currently busy with something else.

@EugenCepoi
Copy link
Contributor Author

Heh I can't hold off on this as everything is already done :(
Yeah the other option of doing everything at runtime through reflection would work too. It would avoid some of the boilerplate in the config/release process in exchange for some hack at runtime.

@EugenCepoi
Copy link
Contributor Author

I think you can still try this branch out to get a feel of how it works and choose between the different trade-offs.

ianoc added a commit that referenced this pull request Dec 17, 2015
Fixes #452 - supporting thrift 0.7 and 0.9
@ianoc ianoc merged commit 2c28929 into twitter:master Dec 17, 2015
@ianoc
Copy link
Contributor

ianoc commented Dec 17, 2015

Merged, talked with Raghu offline (who suggested I decide). I'm inclined to say this his a high quality contribution and seems like the pro-style most forward looking way to do this. (no runtime surprises).

Thanks for all the work in getting this right @EugenCepoi !

@EugenCepoi
Copy link
Contributor Author

Cool, I am glad if you guys find that it is the right way (hesitated a lot between the different solutions). You should try it out with a dummy release. I tested it but only with local fs repos so maybe there might be some subtleties using sonatypes repo. Thanks.

@rangadi rangadi mentioned this pull request Dec 17, 2015
@rangadi
Copy link
Contributor

rangadi commented Dec 17, 2015

I had already coded #458 before this was merged. I will close it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants