Our Jenkins server was on 100% CPU usage.
4 threads were very busy with sending an email.
All 4 thread had the same stacktrace, see screenshot.
Looks like that lookup of emailadresses is consuming too much CPU.
E-mail address revolvers are other plugins, the email-ext plugin just uses the core Jenkins address revolver functionality so I'm not sure how to handle this issue in the plugin itself.
If this is an API of Jenkins Core, then you might transfer it to Core.
When will this API be used? In all situations or when certains settings are done for sending the email?
It will be used when a user's email address needs to be resolved.
1) Do you use svn?
2) what svn plugin version?
3) what jenkins version?
4) what email-ext version?
5) Can you paste thread dump as text here?
6) How long email is sending?
I post my small debug story to #JENKINS-14285 maybe it helps you.
imho it's not a blocker.
Please attach one of the xml files for the svn changeset.
Lately we did not face this issue anymore.
We faced this issue with a very large sync-merge (after a very large drop-merge of another team).
The commit message of the sync-merge drop-merge contained all committed in the branch.
The size of the commit message was more the 1Mb.
I guess that change history XML is parsed and that took a lot of time.
Maybe it is possible to create a change XML without commit messages itself (only committer info). That makes parsing of the XML much faster.
We use SVN.
Only thread information I have is in the screenshot attached to this ticket.
That would be up to the scm plugin developers. Email-ext uses the MailAddressResolver functionality of the core, which tries all of the available classes that inherit from MailAddressResolver.