Forgot to set component information

Can you verify that it does NOT hang when the e-mail is set to bobby@example.com? The code does not extend any special treatment for email addresses; it's just another field in the perforce response.

Also please ensure that all your perforce jobs are correctly configured, not just the one you are running.

I can verify it does not hang with other users who have matching usernames and email addresses. eg,

$ p4 user -o bbassett
...
Email: bbassett@example.com
...

Neither users have configuration records in HUDSON_HOME/users/${USERNAME}/config.xml.

All Perforce jobs appear to be configured correctly. They sync correctly from the depot when triggered; if there is a different definition to "correctly configured", I'd appreciate knowing

I forgot to mention this in the original report, but this configuration worked with version 1.0.15 of the Perforce plugin. Updating to 1.0.16 caused the issue to appear.

Our Perforce server is not named "perforce"; it is instead named "seaperforce.example.com", since the company I work for was acquired and the new company already had a "perforce.example.com". This issue regularly trips up our users, and might be a possible cause here.

As long as all the jobs can sync properly then that's fine. The MailAddressResolver classes cannot be tied to jobs, so it's forced to go through the perforce configurations one by one until it finds the user it's looking for (this includes disabled jobs as well, apparently). If a job isn't correctly configured, that could result in a hang (though really it should time out after a while).

In any case, I can't reproduce this behavior at all using 1.0.16 on hudson 1.318, or 1.0.18 on hudson 1.339.

It looks like the reason that it 'worked' in 1.0.15 is because the mail resolver was outright disabled. It looks like another user was running into the same issue, and just commented the entire thing out instead of trying to fix it.

One thing that comes to mind is that while perforce commands are run on the slave during a build, mail resolution actually takes place on the master. If the perforce server is reachable from the slaves, but not the master, then that would produce exactly the behavior you are seeing.

I'm having the exact same issue, it doesn't appear to timeout either, I let it go about 16 hours, and it was still hung. You also can't kill the job, I have to restart the Hudson master. A bit more info

Hudson 1.345 and 1.343
Perforce plugin 1.0.18
Perforce 2009.1(the api did change with 2009.1 so this may be something to look at)

It does work for users where the username and email match, but if any of the submitters don't match it hangs.

A bit more info. I'm running the hudson master on a windows box, as a service, using the localsystem account. Even though I create a p4ticket file(as a daemon user), it looks like the perforce plugin is having a hard time accessing it. I was playing with the tek42 api's and I couldn't access my server using my daemon p4 account. Once I switched to my local account, then I could switch back to the daemon account, and everything was fine. So

try {
                   Depot depot = new Depot();
                    depot.setUser("daemonuser");
       
                    depot.setPassword("daemonuserspassword");

                    depot.setPort("perforce:1666");
                    System.out.println("de: "+ depot.info());
                    com.tek42.perforce.model.User pu =depot.getUsers().getUser("ARealUser");

                    if (pu.getEmail() != null && !pu.getEmail().equals(""))
                        System.out.println("em" + pu.getEmail());

                } catch (Exception e) {
                    System.out.println("Could not get email address from Perforce: "+e.getMessage());
                }

This failed, the p4 info worked, but I couldn't get the email. Once I changed the depot.setusername to ARealUser, then I could get the email. Changing the depot.setusername back to daemonuser worked after that. Logging into p4v doesn't seem to fix anything.

So for valid testing it looks like you need to remove your ticket file.

bbassett: are you also running hudson on a windows server? Is it running as a service?

As a quick note, p4 info doesn't require a valid login (or even a username for that matter) in order to run, so it may not be the best test.

Tested with:
Hudson 1.345
Perforce Plugin 1.0.18
email-ext 2.5
p4 client 2009.1
p4d server 2009.2
Perforce security level 3

Removing the tickets file doesn't reproduce the problem on my end.

I've made some changes to the perforce email resolver that will make it a bit more robust. They'll be in 1.0.19, so please test again using that release.

No. We are running on a Linux master with both Linux and Windows slaves experiencing the issue.