In my job I was confronted with the problem of testing concurrent use of a remote-object by client applications residing in different application-domains and/or computers. Some requests require locking mechanisms that have to be tested.
I have to devise a method to control client-applications in such a way that it is (almost) certain that they fire requests at the remote-object at the same time.
Although I have a few ideas of my own, I wonder whether anyone knows of existing solutions for this, especially those that DON'T require the aquisition of extra software-tools, but can be implemented using standard features of Visual Studio 2005 (C#).

Can you explain what the applications are doing in more detail? That may help us to provide an answer.

Disclaimer: I'm no remoting expert, but here's what I'd do:

If you know the clients that are going to be simultaneously connected I suppose you could use some kind of call blocking mechanism. Each client makes a call to some method on the remote class, this method forces a thread block while it waits for something (such as a ManualResetEvent). Some logic called by that method would check that all clients are present, then you "set" the reset event which unblocks all waiting threads. This reset event would need to live in a singleton class (or possibly a static member of a single call class) in order to work between the remote consumer threads.

For more:
http://msdn2.microsoft.com/en-us/lib...esetevent.aspx

Alternatively, the WaitHandle.WaitAll static method might work for you too:
http://msdn2.microsoft.com/en-us/lib...e.waitall.aspx

-Peter

Hi Peter,

Maybe I should explain the situation in some more detail.

A long living remote object (System.MarshallByRef) provides services for several client-applications thru Tcp and/or Http.
It provides an interface for an extensive logic-engine (a so called "facade").

The logic-engine contains collections of objects for several purposes. The whole engine is re-initialized every day.

In some cases the first time a contained object participates in a client-request it has to do some processing that changes its state.

Subsequent client-requests on the same object use the results of that initial processing.
The reason for this is that the processing involved is quite extensive and should not be done unnecessary. Once done it should not have te be repeated (lazy evaluation).

Client-requests are concurrent. Only one client-request may lead to a change of state of an object. Other client-requests can only be handled if the very first request is completed so sometimes a client request has to wait.
This is very easy to implement because the object that might have to change its state can us a "lock" on itself.

As far as the locking-mechanism is concerned this is a very simple situation, but there are far more intricate possibilities.

The problem is to find mechanism to test locking-mechanisms (and synchronization) using Visual Studio and have the logic-engine running in "debug"-mode. So what I want to do is:

Start a console application in debug-mode that hosts the remote-object (logic-engine)
Start processes that fire the requests to be tested. however they must fire the requests as simultaneously as possible so they are blocked until all released by another process.
Start a process that releases all other processes resulting in a non determined sequence od (more or less) concurrent requests.

Most locking mechanisms are local (same AppDomain), however in this situation every process can run in a different AppDomain.
I have a few ideas of my own, but I'm interested if this problem has been addressed before and I don't have to waste time on
re-inventing.

I guess I reacted to hastily. Your suggestion clearly resembles my own ideas on this matter.

Secondly, I often hear from .NET-experts that they know little about .NET Remoting. I'm under the impression that this part of .NET is undervalued.

Nico

Your consumers are all running in different app domains, but they are all connecting to a single program that is hosting the remote class. While each remoting call from the consumer may be in different thread, those threads are still within the context of the same app domain. This is the point of the lock or WaitHandle mechanism: to allow different threads in the same app domain to interact and influence each other.

From a standpoint of testing this behavior, could you introduce some manual overrides to the remote class behavior such that you could forcibly delay processing to simulate the simultaneous consumer calls? For example, put a "Console.ReadLine()" call in the process. Your console app that hosts the remote object would wait at this line until keyboard entry. That way you can fire up the multiple test clients to simulate processing delay to show that the thread blocking is working. Once you hit a key in the test host the threads should finish and the consumer will be released.


Hardly. I think that remoting is phenomenal! The hard part (personally) is finding applications for it. I work primarily doing ASP.NET web applications so I don't have a regular occasion to work with remoting. If you build an application that is distributed then you are far more likely to have a solid use for it.

-Peter

Exactly my thoughts, every invocation of a method in a remote object generates a new thread. This thread is dedicated to a process in another Appdomain, but still it is a local thread for the remote object (or service) so "local" locking mechanisms can be used.

It doesn't have to be a console application that hosts the remote object. That is only convenient for debugging purposes.
Normally I would use IIS hosting or a windows service.
For simulating processing I use "Thread.Sleep()" combined with "Console.WriteLine()" for trace-information.

I've done some testing in the meantime and it works very well when one or more "WaitHandles" are owned by a remote object (not necessarily the same as the engine) that are accessible to all client-processes as properties or through methods. What I've found out so far is that you can define specialized remote "schedule"-objects that implement synchronizing mechanisms that work cross-domain and even over a LAN, simply by publishing waithandles like AutoResetEvent and ManualResetEvent (Monitor is a static class and therefore less easy to use).
The fun of it is that it can be used over IPC TCP and HTTP.
Remember me mentioning "lazy-evaluation". This technique and other related techniques require statefull (even perpetual-state) objects. Remoting is i.m.o. the easiest way to implement this kind of objects. Especially applications that incorporate extensive logic rather than data-access (e.g. mathematical models) are best implmented as remote-objects, aside from specific security issues. You can allways define web-services as a gateway to the (preferably state-less) web-world.