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

Optimizations to REST API #1323

Merged
merged 22 commits into from
Aug 17, 2017
Merged

Optimizations to REST API #1323

merged 22 commits into from
Aug 17, 2017

Conversation

i386
Copy link
Contributor

@i386 i386 commented Aug 14, 2017

Description

Serving this request took 75ms. It now takes 30ms.

before

after

Submitter checklist

  • Link to JIRA ticket in description, if appropriate.
  • Change is code complete and matches issue description
  • Appropriate unit or acceptance tests or explanation to why this change has no tests
  • Reviewer's manual test instructions provided in PR description. See Reviewer's first task below.

Reviewer checklist

  • Run the changes and verified the change matches the issue description
  • Reviewed the code
  • Verified that the appropriate tests have been written or valid explanation given

@i386 i386 requested a review from vivek August 14, 2017 06:57
@i386 i386 changed the title Topic/micro opts Optimizations Aug 14, 2017
@i386 i386 changed the title Optimizations Optimizations to REST API Aug 14, 2017
@i386
Copy link
Contributor Author

i386 commented Aug 14, 2017

@vivek I am not sure how to interpret the failure here - is it just saying I need more tests?

@vivek
Copy link
Collaborator

vivek commented Aug 14, 2017

@i386 look in ${project.build.directory}/code-coverage/report, there should be index.html, that should give you details.

@@ -44,12 +44,26 @@
/*package*/ final Map<Class, Model> models = new ConcurrentHashMap<Class, Model>();

public <T> Model<T> get(Class<T> type) throws NotExportableException {
if (type.getAnnotation(ExportedBean.class) == null) {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Directly updating stapler imported code? This can leave us with pain later on, better to submit PR on stapler then we import them over here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

try {
model = owner.get(d.getClass(), parent.type, name);
} catch (NotExportableException e) {
if (d.getClass().getAnnotation(ExportedBean.class) == null) {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Same as above, lets not update stapler code directly here. Please open a PR on stapler.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

See above

Copy link
Collaborator

Choose a reason for hiding this comment

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

Changes in Property.java in this PR is different from the ones in PR. I think its cleaner to remove changes from here and merge stapler changes in separate PR, after stapler PR is merged. This way we can merge this PR without waiting for stapler changes and get immediate perf benefits.

@@ -53,7 +56,7 @@

/** Date String format */
public static final String DATE_FORMAT_STRING = "yyyy-MM-dd'T'HH:mm:ss.SSSZ";

public static final DateTimeFormatter DATE_FORMAT = DateTimeFormat.forPattern("yyyy-MM-dd'T'HH:mm:ss.SSSZ");
Copy link
Collaborator

Choose a reason for hiding this comment

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

Can we move joda specific code to AbstractRunImpl? This will also result in to blue-rest module not to depend on specific data time library.

@@ -23,6 +23,10 @@
<groupId>io.jenkins.blueocean.rest.annotation</groupId>
<artifactId>capability-annotation</artifactId>
</dependency>
<dependency>
Copy link
Collaborator

Choose a reason for hiding this comment

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

See my other comment, we should avoid depending on specific date time library in models.

@@ -97,6 +96,21 @@ public Date getEndTime() {
}

@Override
public String getStartTimeString() {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Maybe declare these as abstract? default implementation returning null can be misleading.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

WDYM?

Copy link
Collaborator

Choose a reason for hiding this comment

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

Ignore that comment, for some reason I mistook it as one of the model class. All good here:)

@michaelneale
Copy link
Member

Not sure about the build failure, is this a test coverage failure?

[WARNING] Rule violated for bundle blueocean-rest-impl: classes missed count is 3.00, but expected maximum is 0.00

?? (jacoco seems annoying in every single way, except that it does enforce coverage levels)

@vivek
Copy link
Collaborator

vivek commented Aug 16, 2017

@michaelneale it means there are 3 classes without test coverage. Reports are in that modules target/code-coverage/report directory. Guess time to write Jacoco HTML publisher:)

@i386
Copy link
Contributor Author

i386 commented Aug 16, 2017

@vivek the only class I can see that does not have coverage is BlueJUnitTestResult. Would you mind taking a look? I am stumped :(

Copy link
Collaborator

@vivek vivek left a comment

Choose a reason for hiding this comment

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

Other than stapler changes, rest of the code looks good. There was a minor comment I left to log error message in case of loading value from callable.

Maybe we should remove stapler enhancement from here if we don't want to wait for stapler PR to merge and deal with it in separate PR?

try {
model = owner.get(d.getClass(), parent.type, name);
} catch (NotExportableException e) {
if (d.getClass().getAnnotation(ExportedBean.class) == null) {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Changes in Property.java in this PR is different from the ones in PR. I think its cleaner to remove changes from here and merge stapler changes in separate PR, after stapler PR is merged. This way we can merge this PR without waiting for stapler changes and get immediate perf benefits.

@@ -97,6 +96,21 @@ public Date getEndTime() {
}

@Override
public String getStartTimeString() {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Ignore that comment, for some reason I mistook it as one of the model class. All good here:)

}
}).orNull();
} catch (ExecutionException e) {
return null;
Copy link
Collaborator

Choose a reason for hiding this comment

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

should log error message or else the checked exception thrown by value loaded callable will be silently ignored.

@vivek
Copy link
Collaborator

vivek commented Aug 16, 2017

@i386 since we don't have coverage report archived, if you build that module locally (Where its reporting coverage error) you should be able to see the index.html (target/code-coverage/report/index.html) and see which classes lack coverage (it includes anonymous inner classes as well).

@i386
Copy link
Contributor Author

i386 commented Aug 16, 2017

@vivek I have removed the stapler changes from here. We can add them back when jenkinsci/stapler#127 is merged.

Copy link
Collaborator

@vivek vivek left a comment

Choose a reason for hiding this comment

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

LGTM 🐝

@i386 i386 merged commit 15fff7a into master Aug 17, 2017
@i386 i386 deleted the topic/micro-opts branch October 9, 2017 02:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants