EAP 7 does not detect JSP file change by Undertow/XNIO file watch service when the JSP file is updated by mv command from the different filesystem

Environment

• Red Hat JBoss Enterprise Application Platform (EAP)
  • 7.x
• Updating JSP file in the exploded deployment

Issue

EAP 7 does not detect JSP file change by Undertow/XNIO file watch service when the JSP file is updated by using mv command from the different filesystem or from the different quota.

Resolution

This is a bug reported in the following JIRAs. This has been fixed in JBoss EAP 7.2.4 or later.

• EAP 7.2.x: This content is not included.JBEAP-17308
• XNIO: This content is not included.XNIO-344)

Until the fix is included, you can work around this issue by either of the followings:

• Manually execute touch command to update the file after moving (= using "mv" command) the file between the different filesystems or different quota.

• Copy the JSP file to the same filesystem and the same quota, then move (= rename by using "mv" command) the copied file to the actual destination JSP file. For example:

  $ cp /tmp/newcontents/test.jsp /path/to/jboss/standalone/deployments/test.war/test.jsp.new
  $ mv /path/to/jboss/standalone/deployments/test.war/test.jsp.new /path/to/jboss/standalone/deployments/test.war/test.jsp
  

Root Cause

• This content is not included.JBEAP-17308 - (7.2.z) Undertow/XNIO file watch service has a possibility to prune all file change events and miss to invoke FileChangeCallback
• This content is not included.XNIO-344 - WatchServiceFileSystemWatcher has a possibility to prune all file change events and miss to invoke FileChangeCallback)
• When an existing file is updated by using "mv" command from the different filesystem or the different directories having different quota settings, three events StandardWatchEventKinds.ENTRY_DELETE (REMOVED in XNIO), StandardWatchEventKinds.ENTRY_CREATE (ADDED in XNIO) and StandardWatchEventKinds.ENTRY_MODIFY (MODIFIED in XNIO) happen for the updated file at the same time. XNIO WatchServiceFileSystemWatcher prunes the duplicated events and it can remove all file change events when the three events happen for the same file at the same time. Hence, any file change event is not notified to Undertow layer and JSP re-compilation does not happen in this scenario.

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.