1231232 - Unable to create WebWorkers when Firefox thread count gets over 100

Status: RESOLVED DUPLICATE of bug 1052398

(Core :: DOM: Workers, defect)

Description

[tryggve]

Attachment: test.html

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.86 Safari/537.36

Steps to reproduce:

1. Start a new WebWorker.
2. Send a message to it.
3. Have the worker post a message back.
4. Reapeat for as long as Firefox let you.


Actual results:

When the thread count for Firefox exceeds 100 it will fail silently. So I expect that firefox cant't even create the WebWorker any longer.

I watch the thread count in the Activity Monitor in OSX.

Additional findings:
In the provided example, the code doesn't terminate the worker. The most test runs ends after 20 workers. In some tests it is able to catch it's breath and create a new set of 20 workers after a while. Sometimes it creates 4 sets of 20 workers before giving up, other tests ends at 3 sets of 20 workers.

When adding code to terminate the worker after the message is sent, Firefox is able to create new Workers, but there is a magnificent delay before it does so. For some reason it also managed to do 20 workers at a time before it has to catch it's breath.

The example also creates Workers with a 'window.SetInterval', the result is the same if you create them manually - let's say by binding a click event to a button in the DOM.


Expected results:

I expect that workers continue to be created.

Comment 1

[Paul Oiegas [:poiegas], PM for (Ecosystem QA, Services QA, WebCompat QA, Hubs QA teams)]

Attachment: Screen Shot 2015-12-11 at 7.10.43 PM.png

Hi tryggve,

I have used your test case to test the issue on latest Nightly build (45.0a1-20151211030207) and I don't think it reproduces. The page continued to create workers, with long breaks between but it doesn't stops (see attached screenshot).
Tested this also on latest Firefox release (42.0) and indeed the workers creation stops at 100.

Also I have tested the same html page on Chrome browser. The workers creation works faster but crashes after a short while displaying "Aw, snap! Something went wrong while displaying this webpage". This usually happens after 1k-2k workers.   

Can you please test this also on the latest Nightly build (https://nightly.mozilla.org/) and report the results found ? When doing this, please use a new and clean Firefox profile.

If you still think this is not the right behavior, we can assign a component for the issue after, and ask for an opinion from developers. 


Thanks,
Paul.

Comment 2

[tryggve]

Hello Paul,

I have run the app in Nightly (46.0a1 (2015-12-16)) and my results can reproduce the results from my Firefox test runs, Perhaps it is a slight better endurance in Nightly, it can in time generate more workers than I was able to in Firefox. But my overall impression is that the behavior is the same. After a first batch of 20 workers, the browser needs to catch it's breath before it can generate a new set of workers. I have run the app for 10 minutes and Nightly has been able to produce 200 workers. I would consider this a faulty behavor.

I noticed that Nightly uses a process named 'Nightly Web Content' which seems to do the hard work when creating web workers, this is different from the Firefox release.

Also, the example app is using a fast interval to create workers, but when manually creating workers with more time between each instantiation the problem appears still. Im my real world application, when I found this problem out, I use pdf.js to render pdf pages. When the user swipes between pdf pages and suddenly doesn't get the page rendered is a bad user experience. As app developer to not get any notice/error is a problem as well.

I am happy to provide additional information or performing tests for you if it may be of any help.

Comment 3

[Paul Oiegas [:poiegas], PM for (Ecosystem QA, Services QA, WebCompat QA, Hubs QA teams)]

Thanks for your tests Tryggve. In this case I will mark it as new and assign a component to it in order to make it visible for the development team. Let's see what is their opinion on this.

If someone thinks that the assigned component is not the right one, please feel free to change it to a more appropriate one.


Thanks,
Paul

Comment 4

[Ben Kelly [:bkelly, not reviewing]]

We explicitly throttle workers at 20 per origin.  There is discussion about relaxing this restriction.  See bug 1052398.