Threads per deployment

[gazonkfoo]

Hi,

we are facing issues with large amounts of threads and inotify instances created by wildfly.

Wildfly 8.2 seems to create 3 threads as well as an inotify listener for each deployment and subdeployment.

We have a requirement to run quite a lot of deployments (about 100 EARs, containing 2-3 WARs each) and didn't face those issues with JBoss AS 7.1.

In the attached thread dump you'll see about 500 threads apparently created for the file watchers (named "xnio-file-watcher[Watcher for..." and "Thread-...at sun.nio.fs.LinuxWatchService.poll...") and 246 weld-worker threads.

Now i'm looking for a way to disable the file watchers and reduce the number of weld-workers.

We do not have a requirement to modify deployments on-the-fly because we use the management interface for deployment.

Thanks!

[gazonkfoo]

Weld apparently creates Runtime.getRuntime().availableProcessors() bootstrap threads for each deployment (but not sub-deployment).

(see http://docs.jboss.org/weld/reference/latest/en-US/html/configure.html#d0e6387)

I managed to find an easy way to disable this behavior by adding the require-bean-descriptor="true" attribute to the weld section of the standalone.xml:

This way not a single thread is created for weld.

However i'm still looking for a way to get rid of the file-watcher threads.

I had a look at the source and apparently a file watcher is created for all exploded deployments.

But actually my deployments are not exploded but wildfly seems to treat the extracted deployments below the tmp/vfs folder as exploded.

I don't see a reason why a file watcher is needed for those (why should anyone modify the files below tmp/vfs from outside?).

[mkouba]

Note that it's also possible to configure the Weld thread pool - see also Chapter 19. Configuration.

[gazonkfoo]

Thanks Martin for you help.

I have created a jira issue to make the thread pools wildfly global: https://issues.jboss.org/browse/WFLY-4653

Stuart Douglas has helped me to clarify the filewatcher problem and apparently it's a bug that the extracted deployments below tmp are marked as exploded internally.

He has created an issue for it (and submitted a pull request already): https://issues.jboss.org/browse/WFCORE-706

Unfortunately there is no workaround for the issue so i think we have to patch wildfly to resolve this.