locked
WCF service works on local/mixed cluster, not on Cloud cluster. RRS feed

  • Question

  • I have a test WCF Service Library DLL that initializes and runs a third-party application.  It does this via the CreateObject command currently.  I am playing with two cluster currently:  1) A local head node with a few local machines; I am able to burst to, or select only, Azure nodes without issue.  2) An Azure VM head node for a completely cloud-based cluster.  I am running the client application on the Azure VM.

    The DLL fails on the CreateObject command (It's in a try catch loop.  Exits with the error Cannot create ActiveX component).  As a test, I created a .vbs file with the same CreateObject command and ran it on the Azure nodes and it ran without issue. 

    As an added bit of weirdness, running the Client application on the virtual machine and watching the task manager on the nodes, I can see the application being repeatedly created on subsequent runs (the PIDs change), but each time it still throws the error message.

    The DLL itself was developed in VS2010 as a WCF Service Library.  I'm a bit stymied as to why the command works in some contexts (i.e. same machine in a script; on Azure nodes in mixed cluster with the same service DLL/Client App combo) and not the other; I want to know if there's something obvious I'm missing.  Diagnostics on the DLL in question work across the cluster and a separate function call (a built-in parametric sweep included in the same client application) returns the expected output.

    Wednesday, April 8, 2015 6:52 PM

All replies

  • Can you narrow down the problem a little bit? And below information may help:

    - Whether all CreateObject will fail

    - What ActiveX component are you referring, is it missing from the AureVM?

    - When you say .vbs file ran well on azure nodes, is it the burst nodes or just the Azure VM (The headnode in cloud)?


    Qiufang Shi

    Thursday, April 9, 2015 1:46 AM
  • 1)  All CreateObject located in the DLL fail with the error message I indicated above.

    2)  The ActiveX Component is located, and working, in the AzureVM.  I tested it by a) opening the application manually in a remote session and b) creating a .vbs file on each of the Azure nodes and opening the application via the script.  Further, when running the client application and keeping an eye on the task manager, the application can be seen.  Yet the code returns an error regarding the object's creation.

    3)  I was referring to the Azure nodes for the .vbs script.  I used remote desktop to access both Azure nodes after the failure to run the client application to verify the installation.  (the nodes were the only ones selected using RequestedNodes; the head node was not running the ActiveX component of the service). 

    Thursday, April 9, 2015 1:09 PM
  • Hi KWilliams1,

    How the CreateObject call is invoked by the WCF service host? Is the application with COM components 32-bit or 64-bit? You may want to check if the invoking host matches the bit version of the target.

    Best,

    Yutong

    Friday, April 10, 2015 4:03 PM
  • The COM object is 64-bit.  Stalking the task manager, I can see the application being created, but then shutting down a short while later.  I modified the SOA DLL to include logging the attempts to open the application.  Though the object appears to be up and running, it ends up in the catch portion of the try-catch.  Also odd: time stamps in the log show that when sending a single job to the cluster, it takes 2 minutes for the CreateObject to fail.  The code in question is effectively

    Try    
       Log(Time Stamp + attempt message )    
       CreateObject    
       Log(Time Stamp + success message)
    Catch    
       Log (Time stamp + error message)

    The log file shows the attempt message and the error message exactly 2 minutes apart (code is in a for-loop and breaks upon success of the CreateObject command)

    4/14/2015 3:05:44 PM: Opening APP
    4/14/2015 3:07:44 PM: Exception creating the APP application.  Attempt number 1
    Return value from CreateObject = Null
    Retrying to open application after attempt 1
    4/14/2015 3:07:44 PM: Opening APP
    4/14/2015 3:09:44 PM: Exception creating the APP application.  Attempt number 2
    Return value from CreateObject = Null <...>

    For the WSH test, I simply typed up a simple .vbs and ran it from the command line.  It is called in the exact same with the exception of the set keyword used in the script file [Handle = CreateObject(String) vs Set Handle = CreateObject(String)]

    Tuesday, April 14, 2015 4:07 PM
  • As another test I've had the DLL output the script as a .vbs file and use the Process.Start command.  The same behaviour results.  Running the SOA client, the application pops up and winks out after a few minutes.  Double-clicking (or running via command line) the script that was output and run by the dll and it runs to completion.  IS this a possible permissions issue with the Azure node?  I can run the scripts remoting into the node, but not via the head node.
    Tuesday, April 14, 2015 8:37 PM
  • Hi KWilliams1,

    The SOA service is running just under the job user account and this can be simple verified by Console.WriteLine(Environment.UserName); in your SOA service dll. Btw, when saying Azure Nodes, you are meaning Azure IaaS VMs, right? All the Head Node, Broker Nodes, Compute Nodes are on IaaS VM? If you are meaning PaaS workers for Azure bursting, the user account would be a local account corresponding to the real client user.

    Is there any detailed or inner error message besides 'Cannot create ActiveX component'? Would you check if running the vbscript from a normal batch job (under the same user account) instead of the SOA job works fine? Also make sure the COM is registed correcty as 64-bit, and the cscript.exe and service host are 64 bit as well.

    Best,

    Yutong


    Thursday, April 16, 2015 9:16 AM
  • Hi Yutong,

      Yes, I was referring IaaS VMs.  However, that seems to not be the issue.  I rolled back the version of the VMs and the code worked.  I am currently working with the vendor to determine why it works manually and not via the script.  Version X is working (same registration), while version X.1 is not.  I've verified this with the Burst configuration as well. 

      If you want to still work on the mystery, no, there is no detailed error message and the com was registered correctly.

    Thursday, April 16, 2015 7:53 PM