Multithreading

Ask general questions here.
pere
Posts: 12
Joined: Mon May 25, 2009 3:32 pm
Location: Barcelona

Multithreading

Post by pere » Mon May 25, 2009 3:50 pm

Hi,
I am trying to automate some operations on a web. In summary, these operations are exposed through a WCF service (free threading) hosted in a WinForms (otherwise there's no way to use Ranorex, as it seems that there must be a running Form within the proces...). Every time a clients calls the WCF service, an STA thread is taken from a pool and used to perform automation tasks on a IE browser. This seems to work only if I have previously retrieved the DOM Document from the UI thread. If I try to get the DOM document from another thread (even one of the pool, where Ranorex operations work perfectly) the application hangs indefinitely.
The issue is that I am starting to implement too much thread to thread jumping and synchronization...
The question is, is there any way to achieve multithreading in a Ranorex application easily, each thread automating one window? Am I missing something? Is there any limitation regarding multithreading? I haven't found any topic in the documentation regarding to this.

Thanks!

User avatar
Support Team
Site Admin
Site Admin
Posts: 12145
Joined: Fri Jul 07, 2006 4:30 pm
Location: Houston, Texas, USA
Contact:

Post by Support Team » Mon May 25, 2009 4:57 pm

Usually, there should be no problems as long as you dont try and use Mouse/Keyboard operations concurrently. If you only work on the (different) DOMs directly (getting/setting attributes and using PerformClick()) it *should* work correctly.

I tried to reproduce your problem with a console application and 4 concurrent STA threads, which automate 4 different IE windows; Unfortunately, this worked for me, so currently I can only guess what might be wrong:

1) Is your executing process running as a service ? This might have problems interacting with the UI if not configured correctly.

2) Ranorex does not require an open Form to work. As long as code executes in an STA thread things should run fine. What is the behavior of your automation code when you dont have an UI thread running ?

3) What thread pool are you using to dispatch the Ranorex jobs ?

4) If you are self-hosting the WCF ServiceHost you want to try this on your service implementation ..

[ServiceBehavior(UseSynchronizationContext=false)]

.. because if you create the ServiceHost in your Main() then the incoming requests are synchronized on the UI thread (i guess?)

Michael
Ranorex Team

pere
Posts: 12
Joined: Mon May 25, 2009 3:32 pm
Location: Barcelona

Post by pere » Mon May 25, 2009 5:26 pm

Thanks for your quick reply. Let me give you some more information:
1 and 2. Regarding these, I couldn't get Ranorex to work from a service, even if it was running as LocalSystem with desktop interaction allowed. I was getting strange behaviors, so I'm launching a WinForms process and monitor it from the service to ensure that there's always an instance running. The behavior I got if not running from UI thread was the same I'm having now, the call to obtain the DOM blocks indefinitely:
WebDocument = Ranorex.Host.Local.FindSingle(domTitle, TimeSpan.FromSeconds(2));

3. I have implemented a 'Session' class and I have a pool of instances, each instance with its own STA thread.

4. The service behavior is configured as this:
[ServiceBehavior(ConcurrencyMode=ConcurrencyMode.Multiple, UseSynchronizationContext=false, InstanceContextMode=InstanceContextMode.Single)]

When the WCF server receives a call, issues a command to a 'session' instance taken from the pool, and then waits for a completion event, in order to return a response to the WCF client.

In the meantime I have been investigating further (I've been with this for 2 days, trying different approaches), I think that I know what's happening. I want the WCF server to be able to serve concurrent calls, but being synchronous. I just tried to make the calls OneWay, so the client Form is not blocked... and now it works... I've experienced issues also when playing with the Spy and the debugger stopping and freezing a form, so probably the problem is that some operations on Ranorex are not allowed when a form has it's UI thread blocked?

I will change the client to use worker threads and not block the UI to see what happens.

Thanks again!

pere
Posts: 12
Joined: Mon May 25, 2009 3:32 pm
Location: Barcelona

Post by pere » Mon May 25, 2009 5:45 pm

Hi,
I just tried making the synchronous calls from a non UI thread in the client, and now it works... Bad luck I didn't realize this on las friday... :(

Thanks!

User avatar
Support Team
Site Admin
Site Admin
Posts: 12145
Joined: Fri Jul 07, 2006 4:30 pm
Location: Houston, Texas, USA
Contact:

Post by Support Team » Tue May 26, 2009 8:32 am

There are operations in Ranorex that involve sending window messages to other applications and getting window messages from these applications in return. If the UI thread of the application using Ranorex is blocked, the Ranorex operations might as well be blocked. You should either perform the Ranorex actions on the UI thread or make sure that the UI thread is not blocked.
In general, it's not good to block the UI thread of a Windows application as Windows will consider the application non-responsive.

Regards,
Alex
Ranorex Support Team

pere
Posts: 12
Joined: Mon May 25, 2009 3:32 pm
Location: Barcelona

Post by pere » Tue May 26, 2009 8:41 am

Well, the UI thread of the application using Ranorex is never blocked. The UI thread that gets blocked in my prototype is the thread of the client application making a synchronous call through WCF. I agree that is not a good design, but because it was for test purposes I did not think in this situation.
Anyway, the WCF client will be a workflow, so this situation won't happen as I will never have any UI blocked. However, I am afraid that any non-responding application could affect Ranorex. We'll see what happens, maybe I'll have to monitor the processes that I will be launching for being automated...

Thanks for your help, you have a great product!