I need to develop a very simple class developed as a Windows Script Component that needs to work in a multi-threaded environment.
I am wondering just how thread safe Windows scripting Components are and the scripting engine that executes those components.
In VB6 if a compiled DLL was not compile with "Retain In Memory" and "Unattended Execution" set definately caused problems in a multi threaded environment, I experienced this 1st hand and spent weeks trying to locate the issue with a 3rd party DLL.
Would anyone happen to know what way Windows Scripting Component works, are they intrinsically thread safe (once we don't do anything non-thread safe in the components we write).
I realize that the Windows Script Components are COM Apartment threaded and may not be the most performant things in the world but I have no choice about this.
Kind Regards
Noel
we're found under exterme load testing that WSC components are perfectly thread safe.
Related
I work on a Classic ASP web application that uses several old COM components written in VB6. All of the VB6 components are registered in a COM+ application that run in their own dllhost process. A large majority of the application has been converted to .Net, but there are still a lot of legacy pages and components. COM Interop is used in both directions, calling some .Net assemblies from classic ASP and VB6 as well as calling VB6 components from ASP.Net. The application is running on Windows Server 2008 R2 (IIS 7.5) in the classic pipeline mode.
For the most part the application works fine. The transition to .Net effort was ultimately abandoned, with a new product being developed instead. In the meantime, the old product must be maintained in it's heterogeneous state.
I am having trouble tracking down an intermittent problem where the web application hangs. Users just see a blank screen while their browser waits and the server never responds. The hang persists until I manually kill the dllhost process that's hosting the VB6 components, so I believe the problem is buried there. Probably a memory leak or runaway circular loop.
There are thousands of users on the system daily, but the problem only happens once or twice a week. Fortunately we have a web farm that automatically pulls a server out when it stops responding, so the customer impact is zero. Still, I would like to figure out what's going on.
I have recompiled all of the VB6 components to include debugging symbols and redeployed to production. When the problem happens, I use the 32-bit task manager (c:\windows\syswow64\taskmgr.exe) to take a crash dump of the dllhost process. I end up with a dllhost.dmp file, which I bring down to my development workstation and open in VS2010. I have the .pdb symbol files that VB6 created in my symbols path. When I start the debugging session in VS2010, I can go to the Modules screen and see that indeed all of the symbols for my components are loaded.
Where to go from here? The call stack doesn't show any of my own components. It looks like this:
The disassembly at the top of the call stack looks like this:
Not sure what else I can do. I examined all of the locals at every frame of the call stack and it's gibberish to me. I don't see any references to any of my own components.
Perhaps WinDbg would yield more information? Not sure where to start with it.
I'm pretty sure that if I could just find what VB6 class/method was being called when the hang occurred that I could get to the bottom of it. I've tried adding some logging, and the results are inconsistent.
Perhaps there's nothing wrong with my VB6 components at all, but I'm hitting on some bug within Windows or IIS?
Any advice would be appreciated, but throwing away VB6 is not an option at this point. Thanks.
Not a complete answer, but CoRegisterSurrogateEx is documented to block as long as the surrogate process is running:
The CoRegisterSurrogateEx function is a blocking function. It does not
return until COM+ has determined that the process will be shut down.
Before calling this function, initialize COM on this thread as a
multi-threaded apartment (MTA).
So I don't think the error is on this call-stack. (You can see it was still blocking on a WaitForSingleObject call, most likely the mechanism it uses to block until the process is to be shut down).
In my understanding a process is,
"an operating system level concept used to describe a set of resources (such as external code
libraries and the primary thread) and the necessary memory allocations used by a running application.
For each *.exe loaded into memory, the OS creates a separate and isolated process for use during its
lifetime." -Andrew troelsen (pro c# 2010)
so each time we start an application a process is created with its own address space which cannot be shared by other process.
recently i have read in clr via c# that,
"The CLR does, in fact, offer the ability to execute multiple managed applications in a single
OS process. Each managed application executes in an AppDomain."
this says that multiple apps can run inside a single OS process, is there a difference between OS process and the process that is started when we run an application???
can someone shed light on this please.
The difference is that the primary running process is managed by the operating system. The CLR/Framework offers a completely different stack known as "application domains" that allows separate running instances of a program to be executed under the same system-level process but act as completely independent processes. Not being an expert on C#/.NET model of design, I cannot facilitate an example of where this might be useful other than scalability of large systems.
Note: I couldn't decide whether this was more appropriate for Stack Overflow or Serverfault, so if you have some insight into that, let me know.
Background: Recently, my server (Windows 2000, MS SQL 2005, IIS 5.0, ASP Classic) experienced a spike in traffic to a specific set of ASP pages. This spike caused a massive drain on the processor, spiking it at 100% and causing all kinds of timeout problems for the visitors.
We've actually handled larger volumes in traffic than this without error. The problem seemed to be that the specific ASP scripts being called were using a huge amount of processor time. Using the Process Explorer from Sysinternals, I found that dllhost.exe was taking up all of the processor time. Looking at its threads, the culprit was calls to COMSVCS.DLL, which seems to be COM+ objects.
So, it seems like my ASP pages are calling COM+ objects and it's killing my processor.
Here's the question: How do I determine which parts of my ASP scripts are calling the COM+ objects, and how would I begin to improve performance from these parts? I have basically no background in Windows programming, so I am at a loss of how to begin.
Thanks for your help.
Neither COM+ or DLLHOST are likely your problem, they are just the containers that the web site and COM objects are running in. The actual objects they are being "fed" are your issue and/or the ways/frequency they are being called by the web app.
A more productive way to isolate the problem would be to look at the IIS logs for the pages with the longest processing time and have a programmer analyze what is going on in that page and what objects are being called.
Specifically, check the "time-taken" column in the IIS log.
For determining what objects are being called, look for
<OBJECT ID=MyObject RUNAT=SERVER PROGID=MyDll.MyObject></OBJECT>
or
set myObject = server.createobject("MyDll.MyObject")
inside your ASP pages.
Beware that this could be calling standard DLL (not COM+ objects). The method for instantiation is the same for both types.
If you want to know what COM+ processes are you running, check out the Component Services app.
alt text http://img38.imageshack.us/img38/5062/capturerm.png
Since MS appears to have killed Managed JavaScript in the latest DLR for both server-side (ASP.NET Futures) and client-side (Silverlight), has anyone successfully used non-obsolete APIs to allow scripting of their application objects with JScript.NET and/or can explain how to do so? A Mono/JScript solution might also be acceptable, if it is stable and meets the requriements below.
We are interested in upgrading off of a script host which uses the Microsoft JScript engine and ActiveScript APIs to something with more performance and easier extensibility. We have over 16,000 server-side scripts weighing in at over 42MB of source, so rewriting into another scripting language is out of the question.
Our specific requirements are:
Noteably better performance than the Microsoft JScript (ActiveScript) engine
Better runtime performance and/or
Retention of pre-parsed or compiled scripts (don't reparse on every run)
Lower or equal memory consumption
Full ECMA-262 ECMAScript compatibility
a little porting can be tolerated
Injection of custom objects into the script namespace
.NET objects (not a hard requirement)
COM objects or COM objects wrapped in .NET
Instantiation of COM objects from Script
à la "new ActiveXObject(progid)"
Low priority given the preceeding
Include files
Pre-loading of "helper scripts" into a script execution context
An "include" function or statement (easy to create, given the above)
Support for code at global-scope
Execution of code the global scope
Retention of values initialized at global scope
Extraction of values from the global scope
Injection and replacement of values at the global scope
Calling of script-defined functions
with parameters
and with access to the previously initialized global scope
Source-level debugging
Commercial or Open Source Support
Non-obsolete APIs
I answered a similar question here. Have a look at IronJS, an implementation of JavaScript in F# running on the DLR.
Sooner or later, I imagine someone will write a DLR Javascript. I know that's not very convenient for you right now, but maybe you could start the project. I suspect it would have a better cost/benefit analysis to using JScript.NET.
If moving away from .NET and Microsoft is ok for you then you should try Mozilla's Rhino. It is an open-source implementation of JavaScript written entirely in Java. Alot of modern server side js libraries target this platform.
I have used CSScript.net as it will allow you to run C# as a scripting platform. From the site:
CS-Script combines the power and
richness of C# and FCL with the
flexibility of a scripting system.
CS-Script can be useful for system and
network administrators, developers and
testers. For any one who needs an
automation for solving variety of
programming tasks.
CS Script satisfies all the conditions that you laid out. I have used it in production as a substitute for Boo it has performed really well. You can see it in action here.
The use of Com interop means you are limited to an MS solution Java and Opensource want as little as possible to do with it.
I dont see any solution that supports all your requirements either you ditch all the COM/.NET stuff and go Java (Rhino) /Linux/Open source or you question the use of Javascript as your server language even in the Linux world we use PHP/Python/Ruby more on the server if we cant run Java. Your not going to see big performance gains with Java script as the language is the main barrier.
I wouldnt count on people writing a new DLR as server Java script is dying fast.
Considering you want performance ,what about F# , Microsoft will keep the Jscript engine supported for at least 5 years giving you time to create new stuff in F# while you slowly migrate the code.
Have you seen ROScript?
http://www.remobjects.com/script.aspx
Supports both PascalScript and ECMAScript (Javascript) syntax
The Jurrassic-Engine is alive and kicking.
From their codeplex site:
Supports all ECMAScript 3 and ECMAScript 5 functionality, including ES5 strict mode
Well tested - passes over five thousand unit tests (with over thirty thousand asserts)
Simple yet powerful API
Compiles JavaScript into .NET bytecode (CIL); not an interpreter
Deployed as a single .NET assembly (no native code)
Basic support for integrated debugging within Visual Studio
Uses light-weight code generation, so generated code is fully garbage collected
Tested on .NET 3.5, .NET 4 and Silverlight
I know .Net and C# pretty well, but never even looked at VB.
My problem is: our Win32 COM library is used by a number of clients, and we see that the number of failures is higher for those who use the library from VB (both VB and VB.NET) than for those who use C++, C# or Delphi. One thing about our library is that it is supposed to be used from one thread only - can some threading magic by VB be the cause of failures?
Clients tell us the do not create any extra threads on their own.
VB.NET = C# with a little different syntax. Seriously, you can translate VB.NET into C# line-for-line 99% of the time. Neither language creates threads under your nose without you knowing about it.
At most, if your clients are using VB.NET with Option Strict Off, then VB.NET's late-binding can cause more problems than it fixes -- its hard to know for sure without seeing the actual exceptions you're clients are reporting. In any case, chalk your clients failures up to less skillful programmers and bugs in their own library, not to your code or Microsofts implementation of VB.NET.
By magic, no. VB.Net will not do any extra threading under the hood. In this respect it's the same as C#.
VB6 and earlier can impact threading because all of it's objects will be STA COM objects. This won't add any threads to your program, but merely restrict the manner in which the VB6 objects can be accessed.
One case is Finalize methods. The CLR calls them from background thread(s) associated with the garbage collector part of the system. Most likely, your users should just not be calling your component from within Finalize.
Also watch for the BackgroundWorker or delegate BeginInvoke. Although the user does not create "any extra threads on their own", these mechanisms executes code on a thread pool thread separate from the main GUI thread.