Tinder cpu overheat

Our company had made some profiling of Openfire 3.9.3 instance under frequent messaging and presence requests and find out that current Tinder implementation waste cpu time.
We’ve made some refactor and update org.gnu.inet.libidn from 1.15 to 1.28, we’ve got this refactored implementation in production for couple of month, so we think that it is the time to contribute some… We are ready to post pull request to Tinder git repo but looks like better to get issue assigned first, so that is all about )

In short: 2 classes changed + updated pom with uploaded to JCenter new libidn version, author of libidn was asked to update it in maven central too, but it would require much time ([OSSRH-13173] Please create project for GNU Libidn JAVA port - Sonatype JIRA )

Here some screenshots of profiling results:

  1. Before any Tinder changes

  1. After refactoring Tinder

  1. Refactored Tinder and fresh libidn (1.28)

1 Like

That’s great!

Created TINDER-70, note that the latest libidn version appears to be 1.29 at the time of writing.

Could you ask Simon Josefsson to put this version ot OSS Sonatype, so that we can use the maven artifact instead of adding binaries to the repo?

Could you ask Simon Josefsson to put this version ot OSS Sonatype, so that we can use the maven artifact instead of adding binaries to the repo?
Never mind, I see this is already in progress at OSSRH-13173.

Cant predict how long it will take to update Maven Central, anyway may additional public repo (http://jcenter.bintray.com/) be used inside Tinder’s pom?

One more question: https://igniterealtime.org/issues/browse/TINDER-70created issue is about only libidn update, but not the last part is 2 refactored Tinder classes, should I upload pull request under the same brunch and issue?

1 Like

If the refactoring is a direct requirement from the libidn update then it goes in the same commit. If not I guess it’s ok if you use the same PR but use an extra commit, and I think no additional issue will be required…

I’ve talked to Simon and we will meet at FOSDEM 2015 and discuss the further steps to put the latest libidn on sonatype. It may be that we’ll be able to put the new version online before FOSDEM, which is in two weeks, but don’t count on it. I suggest to hold this back until FOSDEM then, as I don’t like to use a third party packaged artifact of libidn from jcenter if it’s likely that we have the latest version on OSS sonatype soon.

Ok, please ping me here if there will be some news

so that we can use the maven artifact instead of adding binaries to the repo?

Binaries are added to the repo anyway. Tinder and stringprep.jar are here:

Openfire/build/lib/merge at master · igniterealtime/Openfire · GitHub

Artifact versions are maintained in this file:

Openfire/versions.txt at master · igniterealtime/Openfire · GitHub

So there’s no need to wait until it’s available on Maven Central, because Openfire doesn’t use it anyway (unfortunately).

@Konstantin, you could therefore go ahead and prepare a pull request which contains the new stringprep.jar and an updated versions.txt.

If the new jar requires a Tinder update, you would also need to update Tinder first, make a PR for Tinder and then a PR for Openfire containing the new tinder.jar.

The problem is that I DO need update tinder codebase and it uses libidn artifact from Maven Central.
I suggested use JCenter repo in tinder coz we already published there 1.28 version of libidn.
Btw some review was done on JCenter side before let us publish.
So I was told to wait official release on Maven Central.
Without resolution from where I should use libidn I cant move on…

Ah I thought you only wanted to update Openfire.

If your your code changes to Tinder require the latest stringprep.jar, we have a problem, yes. (but only until it’s available on Central).

If your your code changes to Tinder run with an older version of stringprep.jar, everything is fine. You could update the code without updating strinprep.jar (and do that one later).

If you want to update only Openfire you could build tinder.jar locally with the latest stringprep.jar and then update Openfire with the new tinder.jar and stringprep.jar. I know this is very ugly and probably should better be avoided, but Openfire runs on a tinder-1.3.0-SNAPSHOT anyways and I think nobody knows which version (build) it actually is.

Looks like Tinder does not use stringprep.jar at all, it uses libidn.jar
We found CPU consumption first within Tinder and after fixing it found the same troubles inside old libidn.jar (1.15).
So we update tinder code AND update libidn.jar to 1.28 (see the first post with all 3 stages graphs: “before” - “only tinder” - “tinder and libidn”).
We did not touch stringprep.jar at all.
So I was going to update 2 libs inside Openfire to fix CPU consumption: tinder and libidn, not stringprep.
For now I’m thinking about PR to tinder with Bintray repo dependency inside - just to let team see what was changed and let update that PR or update it just on merge (if it will be merged) with official libidn Maven release later.
And we are going to setup Travis build for our Tinder branch and thus Opefire team will be able to get both jars just from public Bintray repo.

PR was uploaded to Tinder

2 libs may be updated in Openfire to apply this fix:

  1. libidn.jar to 1.28(1.29) version available on http://ftp.gnu.org/gnu/libidn/

  2. New tinder.jar from http://dl.bintray.com/kyakimov/maven/org/igniterealtime/tinder/1.3.0/ or wait for official libidn Maven release and build it after PR merge (if it will be accepted)

Any news?

I’ve created the ‘gradle’ branch in libidn, but need to get in contact with Simon again to get it included in upstream. As contributions to FSF projects tend to take a long time because of the paperwork (so I was told), I think we could go with an in-official libidn version in tinder until an official version has been published to Maven Central.

Github PR TINDER-70 contains libidn 1.28 that was pushed to bintray repo, you may use it till official one…

Various (but not all) improvements have been applied to Tinder 2.0.0.