로그인
Microsoft.com
 
Microsoft
 
 
 
Microsoft >
> 
> 
DurableSession.CreateSession apparently hangs with new cluster [SOLVED]

Unanswered DurableSession.CreateSession apparently hangs with new cluster [SOLVED]

  • 2011년 8월 25일 목요일 오후 3:15
     
     
    로그인하여 투표
    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?

     

     

모든 응답

  • 2011년 9월 6일 화요일 오후 3:37
     
     
    로그인하여 투표
    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?

     

     
  • 2011년 9월 6일 화요일 오후 7:26
     
     
    로그인하여 투표
    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.

     
  • 2011년 9월 6일 화요일 오후 7:58
     
     
    로그인하여 투표
    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?


    • 편집됨 wbradney 2011년 9월 6일 화요일 오후 7:59
    •  
     
  • 2011년 9월 14일 수요일 오후 3:17
     
     
    로그인하여 투표
    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

     
  • 2011년 9월 15일 목요일 오전 12:20
     
     
    로그인하여 투표
    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?


    • 편집됨 wbradney 2012년 5월 24일 목요일 오전 9:18
    •  
     
  • 2011년 9월 15일 목요일 오후 4:00
     
     
    로그인하여 투표
    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.

     
  • 2012년 5월 30일 수요일 오후 1:36
     
     
    로그인하여 투표
    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...
    • 편집됨 wbradney 2012년 5월 30일 수요일 오후 2:21
    •