[MAGNOLIA-7049] Property m.r.f.o.excludedDirectories does not exclude inner directories Created: 30/May/17  Updated: 27/Jun/17  Resolved: 27/Jun/17

Status: Closed
Project: Magnolia
Component/s: None
Affects Version/s: 5.5.4
Fix Version/s: 5.5.5

Type: Bug Priority: Neutral
Reporter: Magnolia International Assignee: Maxime Michel
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates
causality
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Sprint: Basel 100, Basel 101, Basel 102
Story Points: 5

 Description   

A directory defined in m.r.f.o.excludedDirectories is not properly excluded of the tree traversal.

Example:
We want to exclude rsyncstagingdir from the tree traversal because it is a temporary directory used while we refresh the light module from GIT

-Dmagnolia.resources.filesystem.observation.excludedDirectories=META-INF,WEB-INF,cache,docroot,logs,repositories,tmp,rsyncstagingdir

In Magnolia we have those exceptions where we can clearly see the directorywatcher trying to access the directory rsyncstagingdir

2017-05-30 06:25:52,396 WARN  info.magnolia.dirwatch.DirectoryWatcher           : Unable to register all subdirectories because of the following exception:
java.nio.file.AccessDeniedException: /var/lib/magnolia/resources/btk/webresources-sources/scss/.sass-cache/36c1b40a9aeec4dde941708c1332c8da0c87e3da/rsyncstagingdir
	at sun.nio.fs.UnixException.translateToIOException(UnixException.java:84)
	at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
	at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
	at sun.nio.fs.UnixFileSystemProvider.newDirectoryStream(UnixFileSystemProvider.java:427)
	at java.nio.file.Files.newDirectoryStream(Files.java:457)
	at java.nio.file.FileTreeWalker.visit(FileTreeWalker.java:300)
	at java.nio.file.FileTreeWalker.walk(FileTreeWalker.java:322)
	at java.nio.file.Files.walkFileTree(Files.java:2662)
	at info.magnolia.dirwatch.DirectoryWatcher.registerRecursively(DirectoryWatcher.java:168)
	at info.magnolia.dirwatch.DirectoryWatcher.run(DirectoryWatcher.java:230)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)

Full logs: https://jira.magnolia-cms.com/secure/attachment/39398/2017-05-30-06-25-50_Magnolia_server.log

In our context, the light module is being updated form GIT, so we expect the light module to be partially loaded, or not loaded at all. Apparently, right now, when this happens, it puts the instance in an unreachable state, leading to some incoming requests to be simply interrupted. We expect the Magnolia instance still reachable and able to handle that case gracefully.

More details in this ticket: https://jira.magnolia-cms.com/browse/ONDEMAND-1044


Generated at Mon Feb 12 04:20:15 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.