DurableSession.CreateSession apparently hangs with new cluster [SOLVED]

Ask a question

Thursday, August 25, 2011 3:15 PM

0

I know this is probably just the way Windows Authentication behaves, but I just spent two hours going crazy over this.

I have an HPC service that's working fine in my own test lab.

I now have a new cluster that's just been set up for testing, and I've deployed my service to it. I run my test client and... nothing. The tests simply hang forever, it seems.

When I debug, it's clear that the test is hanging in DurableSession.CreateSession, with no apparent reason.

I switch my tests back to using the old cluster, and they work fine.

Eventually I go back to square one and run the EchoService sample test against the new cluster - same hang, but since this is a Console application, I notice the prompt "Enter password for [DOMAIN]\[user]:". After entering my password and answering "Y" for "Save password?", the EchoService responds. My tests also now work fine against the new cluster.

Obviously, authentication is required to access the new broker, but I'm concerned that when I roll out HPC support to my customers I'm going to get many calls out of the gate that the service doesn't respond. Shouldn't there be some kind of UI prompt when not running as a console app? In this case if I hadn't decided to go back to the EchoService I'd probably still be debugging this.

What can I do to prevent this for new clusters?
- Reply
- Quote

All Replies

Tuesday, September 06, 2011 3:37 PM

0

Argh. I just got burned by this again after my domain password reset. Does anyone have an idea about how to avoid this in production scenarios?
- Reply
- Quote
Tuesday, September 06, 2011 7:26 PM

0

I found another thread from a guy with the same problem: http://social.microsoft.com/Forums/en-US/windowshpcdevs/thread/d8a39951-a7f4-4192-8f76-5a11e0fa7dc3

That thread was closed out without a resolution.
- Reply
- Quote
Tuesday, September 06, 2011 7:58 PM

0
OK, I think I'm getting closer, but still not understanding the design rationale here. Now I've become aware of "cluscfg setcreds", I logged into the head node and ran this command in a HPC powershell, providing the headnode, my domain username, and password.

Now, when I run the CLIENT (console) I don't get prompted for the password.

I'm still concerned about how this is intended to work in a corporate production environment, with the session/broker client "embedded" in a desktop application. If I have not previously run "cluscfg setcreds" on the head node for the user who runs the desktop application, that application will appear to hang while credentials are being silently requested.

I don't know, I was kinda expecting that if the domain user running the app (invoking the service) is in the AD group of users that are "Cluster users", that the authentication challenge would be unneccessary.

Am I supposed to have every user login to the headnode and run "cluscfg setcreds" before they start using my application (and thereafter every time AD policy insists that they change their password)?

What am I missing?
- Edited by wbradney Tuesday, September 06, 2011 7:59 PM
- Reply
- Quote
Wednesday, September 14, 2011 3:17 PM

0

Hi wbradney,

Take a look at the Session.SetInterfaceMode method (http://msdn.microsoft.com/en-us/library/microsoft.hpc.scheduler.session.session.setinterfacemode%28VS.85%29.aspx).

We use it like this

Session.SetInterfaceMode(false, (System.IntPtr)0);

to open a dialog window in a GUI application for a user to enter their credentials in case they are not already cached.

Derek
- Reply
- Quote
Thursday, September 15, 2011 12:20 AM

0
Hi wbradney,

Take a look at the Session.SetInterfaceMode method (http://msdn.microsoft.com/en-us/library/microsoft.hpc.scheduler.session.session.setinterfacemode%28VS.85%29.aspx).

We use it like this

Session.SetInterfaceMode(false, (System.IntPtr)0);

to open a dialog window in a GUI application for a user to enter their credentials in case they are not already cached.

Derek

Thanks, Derek - I'll check that out.

I'm still not sure that my customers are going to be pleased by being asked to provide the same domain credentials twice, though, even if I can find a clean way to embed it into the workflow. Also, I wonder what happens with SetInterfaceMode when the credentials have already been cached, but have expired due to a domain password policy?
- Edited by wbradney Thursday, May 24, 2012 9:18 AM
- Reply
- Quote
Thursday, September 15, 2011 4:00 PM

0

If the password for the cached credentials has expired, then the next time that user tries to submit to HPC, the dialog will open allowing the user to enter the new password.

The dialog does allow it to remember the credentials, so it is not necessary for this dialog to appear every time.
- Reply
- Quote
Wednesday, May 30, 2012 1:36 PM

0
I finally got around to trying out Session.SetInterfaceMode and it works as described by Derek.

I'd still like to understand why a separate credential check is necessary for submitting HPC jobs, if I'm already logged in to Windows with the same domain credentials...
Also, this arrangement has the unfortunate consequence of requiring high-level application code to take a dependency on the HPC API in order to declare that they're either a console or UI application, even if they never actually get around to running a HPC job (in my case grid computing services are abstracted behind a provider model that offers several different grid platforms and can be used in console, UI or scripted apps). I'll probably punt on this and always assume that the HPC client is a UI...
- Edited by wbradney Wednesday, May 30, 2012 2:21 PM
- Reply
- Quote