The email-ext plugin uses the MailAddressResolver functionality which
is in Jenkins core. It finds all of the classes that extend
MailAddressResolver , iterates through them and calls the resolve
address function on each one. What I am saying is that the plugin
knows nothing about LDAP or SVN or anything like that, it just uses
the core's address resolution mechanism.
On Tue, Jul 3, 2012 at 3:09 AM, vprasad79 <venkat.ibmi...@gmail.com> wrote:
> Thanks Nathan for Analysis.
> Yes even believe issue could be with subversion blame plugin.
>
> If user not found in LDAP simply the plugin can use default email prefix
> instead iterating all projects latest build?
> Please can anyone help us on this.
>
> Thanks,
> Venkat
>
>
> On Monday, 2 July 2012 00:25:52 UTC+5:30, slide wrote:
>>
>> ldap
>> MIME-Version: 1.0
>> Content-Type: text/plain; charset="utf-8"
>> Content-Transfer-Encoding: quoted-printable
>>
>> Forwarding for the list's benefit. This looks like something that we
>> would need to visit in the core email address resolution code.
>>
>> Sent from my Windows Phone
>> From: nathan.grunzw...@hp.com
>> Sent: 7/1/2012 12:16 PM
>> To: slide.o....@gmail.com
>> Subject: reason for jenkins hanging at email sending in email-ext and
>> ldap
>> hi,
>>
>> i tried to post in groups, but couldn't.
>>
>> below is an email i sent to my supervisors after investigating the issue
>> on=
>> our production jenkins:
>>
>>
>> Hello,=20
>>
>> sorry for interrupting, but i'm having the same problem and i've reached
>> di=
>> fferent conclusions.
>> i thought i'd share with you (i even registered especially for this!).
>>
>> this is an email to my bosses of my analysis of the problem...
>>
>> Hi,
>>
>> i think that...
>> The problem is not with LDAP.
>> It Is with fallback logic of getting the user email from svn.
>>
>> When ldap fails to determine the user =E2=80=93 all of Jenkins projects
>> are=
>> iterated. In each one, all of previous builds are iterated. In each one,
>> e=
>> very commit is iterated.=20
>> We have a lot of projects and a lot of builds and a lot of commits.
>> This takes a while=E2=80=A6
>> It=E2=80=99s also why things became worse =E2=80=93 more jobs more builds
>> e=
>> tc=E2=80=A6 It=E2=80=99s also why it doesn=E2=80=99t replicate in staging
>> o=
>> r testing environment =E2=80=93 not that many jobs/builds/commits=E2=80=A6
>> =
>> It=E2=80=99s that simple=E2=80=A6 unfortunately there is no logging for
>> thi=
>> s, so we didn=E2=80=99t know this is the problem and instead blamed LDAP
>> be=
>> cause we only get here if there's an LDAP failure of some sort in extended
>> =
>> email plugin, which does log stuff so we see it....
>>
>> Also, I=E2=80=99ve known for quite a while that our ldap is configured
>> inco=
>> rrectly =E2=80=93 meaning it won=E2=80=99t actually ever find the
>> users=E2=
>> =80=A6 so we=E2=80=99ll always get here=E2=80=A6 I can configure it
>> correct=
>> ly so that it does find the users =E2=80=93 and the problem will be
>> solved.=
>> No code changes and private versions of Jenkins open source
>> plugins=E2=80=
>> =A6
>>
>> Once LDAP resolver fails we get to the following code:
>>
>> public String findMailAddressFor(User u) {
>> for (AbstractProject<?,?> p : u.getProjects()) {
>>
>> i suspect u.getProjects() performance is to blame.
--
Website: http://earl-of-code.com
