[
https://issues.jboss.org/browse/WFLY-6251?page=com.atlassian.jira.plugin....
]
Mathieu Lachance commented on WFLY-6251:
----------------------------------------
I'm working on a legacy application which is writing inside the exploded war at
runtime (yes indeed, this is pretty bad), hence explaining the exploded format.
That application is also servicing a lot of static content files spread across many
folders (yes indeed a web server should have been used for that). To make things worse, we
are using one big server machine, which host multiple jboss process which will then host
multiple time that exploded war (one war per tenant).
All of this combined, make it hard on the OS.
Having a system property configuration would allow us to smoothly transition to non
exploded war format without having to patch undertow meanwhile.
Hope this better help you understand the use case.
Add configuration to disable systematic file watch in
ServletResourceManager
----------------------------------------------------------------------------
Key: WFLY-6251
URL:
https://issues.jboss.org/browse/WFLY-6251
Project: WildFly
Issue Type: Feature Request
Components: Web (Undertow)
Affects Versions: 10.0.0.Final
Environment: Oracle JDK 8u74 on CentOs
Reporter: Mathieu Lachance
Assignee: Stuart Douglas
Our application is deployed multiple time in production as an exploded war.
Eventually we are running into "User limit of inotify watches reached":
{code}
ERROR [io.undertow] (MSC service thread 1-6) UT005024: Could not register resource change
listener for caching resource manager, automatic invalidation of cached resource will not
work: java.lang.RuntimeException: java.io.IOException: User limit of inotify watches
reached
at
org.xnio.nio.WatchServiceFileSystemWatcher.watchPath(WatchServiceFileSystemWatcher.java:179)
at
io.undertow.server.handlers.resource.FileResourceManager.registerResourceChangeListener(FileResourceManager.java:161)
[undertow-core-1.1.0.Final.jar:1.1.0.Final]
at
org.wildfly.extension.undertow.deployment.ServletResourceManager.registerResourceChangeListener(ServletResourceManager.java:80)
at
io.undertow.server.handlers.resource.CachingResourceManager.<init>(CachingResourceManager.java:64)
[undertow-core-1.1.0.Final.jar:1.1.0.Final]
at
org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.createServletConfig(UndertowDeploymentInfoService.java:525)
at
org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.start(UndertowDeploymentInfoService.java:256)
at
org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
at
org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[rt.jar:1.8.0_45]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[rt.jar:1.8.0_45]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_45]
Caused by: java.io.IOException: User limit of inotify watches reached
at sun.nio.fs.LinuxWatchService$Poller.implRegister(LinuxWatchService.java:264)
[rt.jar:1.8.0_45]
at sun.nio.fs.AbstractPoller.processRequests(AbstractPoller.java:260) [rt.jar:1.8.0_45]
at sun.nio.fs.LinuxWatchService$Poller.run(LinuxWatchService.java:329)
[rt.jar:1.8.0_45]
... 1 more
{code}
From what I'm seeing in:
https://github.com/wildfly/wildfly/blob/master/undertow/src/main/java/org...
https://github.com/undertow-io/undertow/blob/master/core/src/main/java/io...
https://github.com/undertow-io/undertow/blob/master/core/src/main/java/io...
there's no way to disable the file resource watch at the sole exception of using
non-exploded war deployment.
We will eventually switch to a non-exploded war but I think having a configuration
(either within the standalone.xml or via system property) to completly turn off that
feature would be a nice addition / improvement.
In the meanwhile, as a workaround we have increased the inotify watch on the OS and will
most likely patch either undertow and/or wildfly-undertow to not add any watch at all.
Thanks
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)