Code changed in jenkins
User: Jesse Glick
Path:
changelog.html
core/src/main/java/hudson/model/View.java
http://jenkins-ci.org/commit/jenkins/c757e65431ad1aec9a3bebe81ac919577e51ac58
Log:
JENKINS-16342 Improving responsiveness of asynchPeople when Gravatar plugin is in use.
This change does not necessarily improve total performance, since the avatar is still computed.
But (1) the computation is correctly done in the work thread, not in the HTTP response thread;
(2) the computation is done just once for a given User, which could reduce load when many AJAX checks are done.

Some things remain to be done to make UserAvatarResolver consistently quick:

• SubversionMailAddressResolverImpl should probably be rewritten to perform its calculations in a long-running process and cache them. Or maybe this should just be deleted and the problem solved in a different way.
• UserGravatarResolver should be rewritten to never block the API call waiting on an HTTP response; should initiate these asynchronously.

And until then, or even afterwards in case other plugins will reintroduce similar bugs:

• May be better for asynchPeople to list all users in a first pass, then go back and resolve avatars in a second pass.
• HudsonPrivateSecurityRealm/index.jelly and similar pages should avoid asking for the avatar synchronously in the HTTP handling thread. Can use ProgressiveRendering or perform the avatar calculation in the URL handler for the <img> rather than when producing the page.

Integrated in jenkins_main_trunk #2191
JENKINS-16342 Improving responsiveness of asynchPeople when Gravatar plugin is in use. (Revision c757e65431ad1aec9a3bebe81ac919577e51ac58)

Result = SUCCESS
Jesse Glick : c757e65431ad1aec9a3bebe81ac919577e51ac58
Files :

• core/src/main/java/hudson/model/View.java
• changelog.html

Serious enough to potentially merit backport to 1.480.x.

Gravatar plugin could probably take advantage of new resolveFast.

> SubversionMailAddressResolverImpl should probably be rewritten to perform its calculations in a long-running process and cache them. Or maybe this should just be deleted and the problem solved in a different way.

Absolutely +1 for deleting this - as well as in all other SCM plugin where something analogue is implemented!
These MailAddressResolvers are implemented in a so ridiculous inefficient way and their usefulness is IMHO very very limited.

+1 to remove MailAddressResolvers or at least make them optional

@kutzi, @vjuranek: see JENKINS-16437.

Code changed in jenkins
User: Jesse Glick
Path:
changelog.html
core/src/main/java/hudson/model/View.java
http://jenkins-ci.org/commit/jenkins/bd03abbcc0078c2f250c2e3ee2c8d3c4a9d210ca
Log:
JENKINS-16342 Improving responsiveness of asynchPeople when Gravatar plugin is in use.
This change does not necessarily improve total performance, since the avatar is still computed.
But (1) the computation is correctly done in the work thread, not in the HTTP response thread;
(2) the computation is done just once for a given User, which could reduce load when many AJAX checks are done.(cherry picked from commit c757e65431ad1aec9a3bebe81ac919577e51ac58)

Conflicts:
changelog.html

Compare: https://github.com/jenkinsci/jenkins/compare/cb6f200e8663...bd03abbcc007

Now that JENKINS-15440 is fixed, I think this can be closed, too.

@kutzi I think there is still work to be done in making UserGravatarResolver nonblocking (independently of MailAddressResolver) and/or making various UI elements displaying avatars not block rendering on the result. But these things do not need to be tracked in this issue I suppose.