Bug? Running Multiple Instances of an App

[tateu]

First of all, thanks for making this available for all of us to use. For the most part, it has been working very well for me.

So...I think I found a bug when running multiple instances of an application that uses wxWebConnect on a Windows machine. Somewhere between 15 and 45 minutes after starting two instances of "testapp.exe," the second instance uses 100% of a single CPU core (on a quad core machine this will be 25%, on a 16 core machine this will be 6.5%). If I close instance 1, the CPU usage of instance 2 immediately drops back down to 0%. This is also scalable to more than 2 instances. 15 to 45 minutes after starting four instances of "testapp.exe," instance 2, instance 3 and instance 4 are each using 100% of a single CPU core. If I close instance 1, the CPU usage of instance 2 immediately drops back down to 0% but instance 3 and 4 remain at 100%. If I then close instance 2, the CPU usage of instance 3 immediately drops back down to 0% but instance 4 remains at 100%. If I then close instance 3, the CPU usage of instance 4 immediately drops back down to 0%.

I have seen this on 3 different machines (single core running Windows XP, quad core running Windows XP and a 16 core running Windows 7). With wxWebConnect v1.1 I have seen it using XULRunner 1.9.2, XUL Runner 1.9.2.8pre and XULRunner 1.9.1.12pre. With wxWebConnect v1.0 I have seen it using XULRunner 1.9.2 but I have not been able to reproduce the problem with the XULRunner 1.8.1.3 version that ships with wxWebConnect v1.0 and I did not try XULRunner 1.9.2.8pre or XULRunner 1.9.1.12pre.

Steps to reproduce the problem:
1) Download and extract webconnect-1.1.zip.
2) Open task manager.
3) Run two instances of "testapp.exe" -- Both instances should be using 0% CPU.
4) Go away and come back to your computer in 15 to 45 minutes (it seems that it may only happen when the computer is idle, but I'm not absolutely sure about that...)
5) Check the CPU usage in task manager of "testapp.exe" instance 2. It is probably using 100% of a single core.
6) Close instance 1, the CPU usage of instance 2 should drop to 0% again.

Is this a bug in XULRunner since it only seems to happen with the 1.9.x series? Is it an incompatibility between wxWebConnect and the XULRunner 1.9.x series? Solving it is probably beyond my meager programming skills so I am bringing it up here and hoping that someone has some insight.


Thanks,

Josh

[jonmmorgan]

I don't have any suggestions as to how to fix this, but I can confirm that I see the issue.

[tateu]

Ok, solved...I didn't (but I really should have) realized that XULRunner uses user profiles...If you do not set one yourself, wxWebConnect creates one for you, always in the same folder in your temp directory (kwkh01.tmp). The excessive CPU usage issue must be caused by a sharing issue, most likely on the sqlite databases used by the XULRunner 1.9.x series to store user history (places.sqlite), etc. The XULRunner 1.8.x series does not uses sqlite databases and so does not suffer from this problem.

The solution is to use a different profile folder for each instance of your app. Before calling wxWebControl::InitEngine(xulrunner_path), you just need to create a different profile folder for each instance and set it with wxWebControl::SetProfilePath(profile_path).

Look at webcontrol.cpp (from wxWebConnect v1.1), line 1620 in the function GeckoEngine::Init() to see how it creates the default folder for you, if you do not set one yourself.

[jonmmorgan]

OK, that makes some amount of sense (certainly Firefox makes sure it only runs one instance, and this kind of profile contention might be part of the reason why). Thanks for looking into it.

I wonder if it's worth changing WebConnect to create a randomly named profile directory by default (and perhaps delete it on exit if it has not been set explicitly?) One of the things I would want to know first is how much time is taken up by creating the profile, and whether that amount of time is different if you are reusing an existing profile (I'll probably test it sometime). I certainly know a lot of the preferences and configuration FF would get from the profile directory and the preferences stored in the profile WebConnect will set up in code every time, so it might not make too much difference.

[jonmmorgan]

Just with some basic testing, very little is created in the profile directory, and it doesn't seem to have any noticeable difference creating a new profile directory rather than reusing an existing one.

[jonmmorgan]

I now create random profile directory names, and that works fine. However, I also found (what I should probably have expected) that trying to delete these profile directories on application shutdown fails because the files that are being deleted are still in use by XULRunner. Can anyone think of a good way around this?

It was suggested to me that you could run your application with a wrapper script that waited until the app shut down and then cleaned up the temporary profile directory. While possible, it seems a little inelegant.