[JBoss JIRA] (WFCORE-1138) Operation ("clean-obsolete-content") failed NPE
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1138?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on WFCORE-1138:
-------------------------------------------------
Petr Jurak <pjurak(a)redhat.com> changed the Status of [bug 1404553|https://bugzilla.redhat.com/show_bug.cgi?id=1404553] from POST to MODIFIED
> Operation ("clean-obsolete-content") failed NPE
> -----------------------------------------------
>
> Key: WFCORE-1138
> URL: https://issues.jboss.org/browse/WFCORE-1138
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.2.Final
> Environment: Centos 6.7, OpenJDK 1.7, Wildfly 9.0.1.Final, nginx-plus
> Domain, Full-ha, 2 nodes, one war
> Reporter: nathan dennis
> Assignee: ehsavoie Hugonnet
> Labels: nullpointerexception
> Fix For: 2.0.2.Final
>
>
> NPE happens randomly knocking the instance off line and has to be restarted.
> [Server:server-one] 13:03:37,900 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 1) WFLYCTL0013: Operation ("clean-obsolete-content") failed - address: ([]): java.lang.NullPointerException
> [Server:server-one] at org.jboss.as.repository.ContentRepository$Factory$ContentRepositoryImpl.listLocalContents(ContentRepository.java:428)
> [Server:server-one] at org.jboss.as.repository.ContentRepository$Factory$ContentRepositoryImpl.cleanObsoleteContent(ContentRepository.java:390)
> [Server:server-one] at org.jboss.as.server.mgmt.domain.RemoteFileRepositoryService.cleanObsoleteContent(RemoteFileRepositoryService.java:160)
> [Server:server-one] at org.jboss.as.server.operations.CleanObsoleteContentHandler.execute(CleanObsoleteContentHandler.java:76)
> [Server:server-one] at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:803)
> [Server:server-one] at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:601)
> [Server:server-one] at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:354)
> [Server:server-one] at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:330)
> [Server:server-one] at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1183)
> [Server:server-one] at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:362)
> [Server:server-one] at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:205)
> [Server:server-one] at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:626)
> [Server:server-one] at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:616)
> [Server:server-one] at org.jboss.as.server.deployment.ContentRepositoryCleaner.cleanObsoleteContent(ContentRepositoryCleaner.java:132)
> [Server:server-one] at org.jboss.as.server.deployment.ContentRepositoryCleaner$ContentRepositoryCleanerTask.run(ContentRepositoryCleaner.java:67)
> [Server:server-one] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> [Server:server-one] at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304)
> [Server:server-one] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
> [Server:server-one] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> [Server:server-one] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> [Server:server-one] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> [Server:server-one] at java.lang.Thread.run(Thread.java:745)
> [Server:server-one] at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> [Server:server-one]
> [Server:server-one] 13:03:37,931 ERROR [org.jboss.as.server] (ServerService Thread Pool -- 1) WFLYSRV0216: Error cleaning obsolete content WFLYCTL0158: Operation handler failed: java.lang.NullPointerException
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-2301) Mount point not found exception raised by createTempFileWithAttributes on overlayfs [JDK-8165852]
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2301?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-2301:
------------------------------------------
Hi [~bjoernstuetztss]. It looks like the stack trace in the description is missing some items, as our code doesn't call LinuxFileStore.findMountEntry. Do you have the missing bits, and also what WildFly release they come from?
The Stack Overflow entry has that and it looks like the problem is a call to java.nio.files.File.getFileStore. But I'm not sure if that's the only thing that triggers this. But if that's the only trigger point then it may be easier to work around it.
> Mount point not found exception raised by createTempFileWithAttributes on overlayfs [JDK-8165852]
> -------------------------------------------------------------------------------------------------
>
> Key: WFCORE-2301
> URL: https://issues.jboss.org/browse/WFCORE-2301
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Environment: WildFly on Docker with overlayfs or overlayfs2 as storage driver
> # docker info | grep -i storage
> aufs: works (e.g., boot2docker, legacy minikube)
> overlay (e.g., CoreOS, current minikube): problem
> devicemapper (e.g., CentOS): works
> overlay2 (e.g., Docker for Mac): problem
> Reporter: Bjoern Stuetz
> Assignee: Brian Stansberry
>
> Mount point not found exception raised by createTempFileWithAttributes on overlayfs [JDK-8165852], i.e.,
> /opt/jboss/bin/jboss-cli.sh --file=/opt/jboss/jboss-config.cli
> inside a Docker container running on overlayfs as storage driver
> causes:
> {code:java}
> java.io.IOException: Mount point not foundImage
> at sun.nio.fs.LinuxFileStore.findMountEntry(LinuxFileStore.java:91)
> at org.jboss.as.controller.persistence.FilePersistenceUtils.createTempFileWithAttributes(FilePersistenceUtils.java:117)
> at org.jboss.as.controller.persistence.FilePersistenceUtils.writeToTempFile(FilePersistenceUtils.java:104)
> {code}
> due to OpenJDK bug/overlayfs bug.
> We acknowledge that this is in fact an OpenJDK AND/OR overlayfs bug. However everything seems to run fine in WildFly except once the backup of the config is triggered, for example by using the cli. Hence WildFly is of limited functionality when the more and more popular overlayfs storage driver is used, and the WildFly team might be interested in providing a workaround on their side since there is no indication the OpenJDK bug will be promptly fixed. We are happy to help in any way, we are still trying to find a workaround on the Java or WildFly side; but we might need insights on why findMountEntry is invoked.
> Java Bug Overview:
> https://bugs.openjdk.java.net/browse/JDK-8165852
> http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8u...
> Wildfly Stack Overflow issue, not solved:
> https://stackoverflow.com/questions/41022393/mount-point-not-found
> Background Info:
> http://mail.openjdk.java.net/pipermail/nio-dev/2016-October/003915.html
> A) chroot environment [1]
> B) Docker container with overlay and overlay2 storage drivers [2]
> C) btrfs file system with an unmounted sub-volume [2]
> [1] https://bugs.openjdk.java.net/browse/JDK-8165323 - cannot get FileStore in chroot environment
> [2] https://bugs.openjdk.java.net/browse/JDK-8165852 - cannot get FileStore for a file in overlayfs in Docker
> Docker file system/storage driver:
> https://docs.docker.com/engine/userguide/storagedriver/selectadriver/)
> Yum yum-plugin-ovl, similar problem:
> https://github.com/CentOS/sig-cloud-instance-images/issues/15
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-2301) Mount point not found exception raised by createTempFileWithAttributes on overlayfs [JDK-8165852]
by Bjoern Stuetz (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2301?page=com.atlassian.jira.plugi... ]
Bjoern Stuetz updated WFCORE-2301:
----------------------------------
Description:
Mount point not found exception raised by createTempFileWithAttributes on overlayfs [JDK-8165852], i.e.,
/opt/jboss/bin/jboss-cli.sh --file=/opt/jboss/jboss-config.cli
inside a Docker container running on overlayfs as storage driver
causes:
{code:java}
java.io.IOException: Mount point not foundImage
at sun.nio.fs.LinuxFileStore.findMountEntry(LinuxFileStore.java:91)
at org.jboss.as.controller.persistence.FilePersistenceUtils.createTempFileWithAttributes(FilePersistenceUtils.java:117)
at org.jboss.as.controller.persistence.FilePersistenceUtils.writeToTempFile(FilePersistenceUtils.java:104)
{code}
due to OpenJDK bug/overlayfs bug.
We acknowledge that this is in fact an OpenJDK AND/OR overlayfs bug. However everything seems to run fine in WildFly except once the backup of the config is triggered, for example by using the cli. Hence WildFly is of limited functionality when the more and more popular overlayfs storage driver is used, and the WildFly team might be interested in providing a workaround on their side since there is no indication the OpenJDK bug will be promptly fixed. We are happy to help in any way, we are still trying to find a workaround on the Java or WildFly side; but we might need insights on why findMountEntry is invoked.
Java Bug Overview:
https://bugs.openjdk.java.net/browse/JDK-8165852
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8u...
Wildfly Stack Overflow issue, not solved:
https://stackoverflow.com/questions/41022393/mount-point-not-found
Background Info:
http://mail.openjdk.java.net/pipermail/nio-dev/2016-October/003915.html
A) chroot environment [1]
B) Docker container with overlay and overlay2 storage drivers [2]
C) btrfs file system with an unmounted sub-volume [2]
[1] https://bugs.openjdk.java.net/browse/JDK-8165323 - cannot get FileStore in chroot environment
[2] https://bugs.openjdk.java.net/browse/JDK-8165852 - cannot get FileStore for a file in overlayfs in Docker
Docker file system/storage driver:
https://docs.docker.com/engine/userguide/storagedriver/selectadriver/)
Yum yum-plugin-ovl, similar problem:
https://github.com/CentOS/sig-cloud-instance-images/issues/15
was:
Mount point not found exception raised by createTempFileWithAttributes on overlayfs [JDK-8165852], i.e.,
/opt/jboss/bin/jboss-cli.sh --file=/opt/jboss/jboss-config.cli
inside a Docker container running on overlayfs as storage driver
causes:
{code:java}
java.io.IOException: Mount point not foundImage
at sun.nio.fs.LinuxFileStore.findMountEntry(LinuxFileStore.java:91)
at org.jboss.as.controller.persistence.FilePersistenceUtils.createTempFileWithAttributes(FilePersistenceUtils.java:117)
at org.jboss.as.controller.persistence.FilePersistenceUtils.writeToTempFile(FilePersistenceUtils.java:104)
{code}
due to OpenJDK bug/overlayfs bug.
We acknowledge that this is in fact an OpenJDK AND/OR overlayfs bug. However everything seems to run fine in WildFly except once the backup of the config is triggered, for example by using the cli. Hence WildFly is of limited functionality when the more and more popular overlayfs storage driver is used, and the WildFly team might be interested in providing a workaround on their side since there is no indication the OpenJDK bug will be promptly fixed. We are happy to help in any way, we are still trying to find a workaround on Java or WildFly side; but might need insights on why findMountEntry is invoked.
Java Bug Overview:
https://bugs.openjdk.java.net/browse/JDK-8165852
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8u...
Wildfly Stack Overflow issue, not solved:
https://stackoverflow.com/questions/41022393/mount-point-not-found
Background Info:
http://mail.openjdk.java.net/pipermail/nio-dev/2016-October/003915.html
A) chroot environment [1]
B) Docker container with overlay and overlay2 storage drivers [2]
C) btrfs file system with an unmounted sub-volume [2]
[1] https://bugs.openjdk.java.net/browse/JDK-8165323 - cannot get FileStore in chroot environment
[2] https://bugs.openjdk.java.net/browse/JDK-8165852 - cannot get FileStore for a file in overlayfs in Docker
Docker file system/storage driver:
https://docs.docker.com/engine/userguide/storagedriver/selectadriver/)
Yum yum-plugin-ovl, similar problem:
https://github.com/CentOS/sig-cloud-instance-images/issues/15
> Mount point not found exception raised by createTempFileWithAttributes on overlayfs [JDK-8165852]
> -------------------------------------------------------------------------------------------------
>
> Key: WFCORE-2301
> URL: https://issues.jboss.org/browse/WFCORE-2301
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Environment: WildFly on Docker with overlayfs or overlayfs2 as storage driver
> # docker info | grep -i storage
> aufs: works (e.g., boot2docker, legacy minikube)
> overlay (e.g., CoreOS, current minikube): problem
> devicemapper (e.g., CentOS): works
> overlay2 (e.g., Docker for Mac): problem
> Reporter: Bjoern Stuetz
> Assignee: Brian Stansberry
>
> Mount point not found exception raised by createTempFileWithAttributes on overlayfs [JDK-8165852], i.e.,
> /opt/jboss/bin/jboss-cli.sh --file=/opt/jboss/jboss-config.cli
> inside a Docker container running on overlayfs as storage driver
> causes:
> {code:java}
> java.io.IOException: Mount point not foundImage
> at sun.nio.fs.LinuxFileStore.findMountEntry(LinuxFileStore.java:91)
> at org.jboss.as.controller.persistence.FilePersistenceUtils.createTempFileWithAttributes(FilePersistenceUtils.java:117)
> at org.jboss.as.controller.persistence.FilePersistenceUtils.writeToTempFile(FilePersistenceUtils.java:104)
> {code}
> due to OpenJDK bug/overlayfs bug.
> We acknowledge that this is in fact an OpenJDK AND/OR overlayfs bug. However everything seems to run fine in WildFly except once the backup of the config is triggered, for example by using the cli. Hence WildFly is of limited functionality when the more and more popular overlayfs storage driver is used, and the WildFly team might be interested in providing a workaround on their side since there is no indication the OpenJDK bug will be promptly fixed. We are happy to help in any way, we are still trying to find a workaround on the Java or WildFly side; but we might need insights on why findMountEntry is invoked.
> Java Bug Overview:
> https://bugs.openjdk.java.net/browse/JDK-8165852
> http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8u...
> Wildfly Stack Overflow issue, not solved:
> https://stackoverflow.com/questions/41022393/mount-point-not-found
> Background Info:
> http://mail.openjdk.java.net/pipermail/nio-dev/2016-October/003915.html
> A) chroot environment [1]
> B) Docker container with overlay and overlay2 storage drivers [2]
> C) btrfs file system with an unmounted sub-volume [2]
> [1] https://bugs.openjdk.java.net/browse/JDK-8165323 - cannot get FileStore in chroot environment
> [2] https://bugs.openjdk.java.net/browse/JDK-8165852 - cannot get FileStore for a file in overlayfs in Docker
> Docker file system/storage driver:
> https://docs.docker.com/engine/userguide/storagedriver/selectadriver/)
> Yum yum-plugin-ovl, similar problem:
> https://github.com/CentOS/sig-cloud-instance-images/issues/15
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-2301) Mount point not found exception raised by createTempFileWithAttributes on overlayfs [JDK-8165852]
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2301?page=com.atlassian.jira.plugi... ]
Brian Stansberry moved WFLY-8133 to WFCORE-2301:
------------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-2301 (was: WFLY-8133)
Component/s: Domain Management
(was: CLI)
> Mount point not found exception raised by createTempFileWithAttributes on overlayfs [JDK-8165852]
> -------------------------------------------------------------------------------------------------
>
> Key: WFCORE-2301
> URL: https://issues.jboss.org/browse/WFCORE-2301
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Environment: WildFly on Docker with overlayfs or overlayfs2 as storage driver
> # docker info | grep -i storage
> aufs: works (e.g., boot2docker, legacy minikube)
> overlay (e.g., CoreOS, current minikube): problem
> devicemapper (e.g., CentOS): works
> overlay2 (e.g., Docker for Mac): problem
> Reporter: Bjoern Stuetz
> Assignee: Jason Greene
>
> Mount point not found exception raised by createTempFileWithAttributes on overlayfs [JDK-8165852], i.e.,
> /opt/jboss/bin/jboss-cli.sh --file=/opt/jboss/jboss-config.cli
> inside a Docker container running on overlayfs as storage driver
> causes:
> {code:java}
> java.io.IOException: Mount point not foundImage
> at sun.nio.fs.LinuxFileStore.findMountEntry(LinuxFileStore.java:91)
> at org.jboss.as.controller.persistence.FilePersistenceUtils.createTempFileWithAttributes(FilePersistenceUtils.java:117)
> at org.jboss.as.controller.persistence.FilePersistenceUtils.writeToTempFile(FilePersistenceUtils.java:104)
> {code}
> due to OpenJDK bug/overlayfs bug.
> We acknowledge that this is in fact an OpenJDK AND/OR overlayfs bug. However everything seems to run fine in WildFly except once the backup of the config is triggered, for example by using the cli. Hence WildFly is of limited functionality when the more and more popular overlayfs storage driver is used, and the WildFly team might be interested in providing a workaround on their side since there is no indication the OpenJDK bug will be promptly fixed. We are happy to help in any way, we are still trying to find a workaround on Java or WildFly side; but might need insights on why findMountEntry is invoked.
> Java Bug Overview:
> https://bugs.openjdk.java.net/browse/JDK-8165852
> http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8u...
> Wildfly Stack Overflow issue, not solved:
> https://stackoverflow.com/questions/41022393/mount-point-not-found
> Background Info:
> http://mail.openjdk.java.net/pipermail/nio-dev/2016-October/003915.html
> A) chroot environment [1]
> B) Docker container with overlay and overlay2 storage drivers [2]
> C) btrfs file system with an unmounted sub-volume [2]
> [1] https://bugs.openjdk.java.net/browse/JDK-8165323 - cannot get FileStore in chroot environment
> [2] https://bugs.openjdk.java.net/browse/JDK-8165852 - cannot get FileStore for a file in overlayfs in Docker
> Docker file system/storage driver:
> https://docs.docker.com/engine/userguide/storagedriver/selectadriver/)
> Yum yum-plugin-ovl, similar problem:
> https://github.com/CentOS/sig-cloud-instance-images/issues/15
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-2301) Mount point not found exception raised by createTempFileWithAttributes on overlayfs [JDK-8165852]
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2301?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFCORE-2301:
----------------------------------------
Assignee: Brian Stansberry (was: Jason Greene)
> Mount point not found exception raised by createTempFileWithAttributes on overlayfs [JDK-8165852]
> -------------------------------------------------------------------------------------------------
>
> Key: WFCORE-2301
> URL: https://issues.jboss.org/browse/WFCORE-2301
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Environment: WildFly on Docker with overlayfs or overlayfs2 as storage driver
> # docker info | grep -i storage
> aufs: works (e.g., boot2docker, legacy minikube)
> overlay (e.g., CoreOS, current minikube): problem
> devicemapper (e.g., CentOS): works
> overlay2 (e.g., Docker for Mac): problem
> Reporter: Bjoern Stuetz
> Assignee: Brian Stansberry
>
> Mount point not found exception raised by createTempFileWithAttributes on overlayfs [JDK-8165852], i.e.,
> /opt/jboss/bin/jboss-cli.sh --file=/opt/jboss/jboss-config.cli
> inside a Docker container running on overlayfs as storage driver
> causes:
> {code:java}
> java.io.IOException: Mount point not foundImage
> at sun.nio.fs.LinuxFileStore.findMountEntry(LinuxFileStore.java:91)
> at org.jboss.as.controller.persistence.FilePersistenceUtils.createTempFileWithAttributes(FilePersistenceUtils.java:117)
> at org.jboss.as.controller.persistence.FilePersistenceUtils.writeToTempFile(FilePersistenceUtils.java:104)
> {code}
> due to OpenJDK bug/overlayfs bug.
> We acknowledge that this is in fact an OpenJDK AND/OR overlayfs bug. However everything seems to run fine in WildFly except once the backup of the config is triggered, for example by using the cli. Hence WildFly is of limited functionality when the more and more popular overlayfs storage driver is used, and the WildFly team might be interested in providing a workaround on their side since there is no indication the OpenJDK bug will be promptly fixed. We are happy to help in any way, we are still trying to find a workaround on Java or WildFly side; but might need insights on why findMountEntry is invoked.
> Java Bug Overview:
> https://bugs.openjdk.java.net/browse/JDK-8165852
> http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8u...
> Wildfly Stack Overflow issue, not solved:
> https://stackoverflow.com/questions/41022393/mount-point-not-found
> Background Info:
> http://mail.openjdk.java.net/pipermail/nio-dev/2016-October/003915.html
> A) chroot environment [1]
> B) Docker container with overlay and overlay2 storage drivers [2]
> C) btrfs file system with an unmounted sub-volume [2]
> [1] https://bugs.openjdk.java.net/browse/JDK-8165323 - cannot get FileStore in chroot environment
> [2] https://bugs.openjdk.java.net/browse/JDK-8165852 - cannot get FileStore for a file in overlayfs in Docker
> Docker file system/storage driver:
> https://docs.docker.com/engine/userguide/storagedriver/selectadriver/)
> Yum yum-plugin-ovl, similar problem:
> https://github.com/CentOS/sig-cloud-instance-images/issues/15
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8133) Mount point not found exception raised by createTempFileWithAttributes on overlayfs [JDK-8165852]
by Bjoern Stuetz (JIRA)
Bjoern Stuetz created WFLY-8133:
-----------------------------------
Summary: Mount point not found exception raised by createTempFileWithAttributes on overlayfs [JDK-8165852]
Key: WFLY-8133
URL: https://issues.jboss.org/browse/WFLY-8133
Project: WildFly
Issue Type: Bug
Components: CLI
Environment: WildFly on Docker with overlayfs or overlayfs2 as storage driver
# docker info | grep -i storage
aufs: works (e.g., boot2docker, legacy minikube)
overlay (e.g., CoreOS, current minikube): problem
devicemapper (e.g., CentOS): works
overlay2 (e.g., Docker for Mac): problem
Reporter: Bjoern Stuetz
Assignee: Jason Greene
Mount point not found exception raised by createTempFileWithAttributes on overlayfs [JDK-8165852], i.e.,
/opt/jboss/bin/jboss-cli.sh --file=/opt/jboss/jboss-config.cli
inside a Docker container running on overlayfs as storage driver
causes:
{code:java}
java.io.IOException: Mount point not foundImage
at sun.nio.fs.LinuxFileStore.findMountEntry(LinuxFileStore.java:91)
at org.jboss.as.controller.persistence.FilePersistenceUtils.createTempFileWithAttributes(FilePersistenceUtils.java:117)
at org.jboss.as.controller.persistence.FilePersistenceUtils.writeToTempFile(FilePersistenceUtils.java:104)
{code}
due to OpenJDK bug/overlayfs bug.
We acknowledge that this is in fact an OpenJDK AND/OR overlayfs bug. However everything seems to run fine in WildFly except once the backup of the config is triggered, for example by using the cli. Hence WildFly is of limited functionality when the more and more popular overlayfs storage driver is used, and the WildFly team might be interested in providing a workaround on their side since there is no indication the OpenJDK bug will be promptly fixed. We are happy to help in any way, we are still trying to find a workaround on Java or WildFly side; but might need insights on why findMountEntry is invoked.
Java Bug Overview:
https://bugs.openjdk.java.net/browse/JDK-8165852
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8u...
Wildfly Stack Overflow issue, not solved:
https://stackoverflow.com/questions/41022393/mount-point-not-found
Background Info:
http://mail.openjdk.java.net/pipermail/nio-dev/2016-October/003915.html
A) chroot environment [1]
B) Docker container with overlay and overlay2 storage drivers [2]
C) btrfs file system with an unmounted sub-volume [2]
[1] https://bugs.openjdk.java.net/browse/JDK-8165323 - cannot get FileStore in chroot environment
[2] https://bugs.openjdk.java.net/browse/JDK-8165852 - cannot get FileStore for a file in overlayfs in Docker
Docker file system/storage driver:
https://docs.docker.com/engine/userguide/storagedriver/selectadriver/)
Yum yum-plugin-ovl, similar problem:
https://github.com/CentOS/sig-cloud-instance-images/issues/15
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-1047) Rollback of undeploy and deployment remove will fail
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1047?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on WFCORE-1047:
-------------------------------------------------
Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1409644|https://bugzilla.redhat.com/show_bug.cgi?id=1409644] from MODIFIED to ON_QA
> Rollback of undeploy and deployment remove will fail
> ----------------------------------------------------
>
> Key: WFCORE-1047
> URL: https://issues.jboss.org/browse/WFCORE-1047
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.0.Final, 2.0.0.CR6
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Critical
> Fix For: 2.0.0.CR7
>
>
> This looks like a problem that's been around since Sept 2012.
> The rollback handling in DeploymentHandlerUtil.undeploy and in DeploymentRemoveHandler both try to read the deployment's management name from the deployment resource, but since [1] it hasn't been stored there. So rollback will fail with something like this:
> {code}
> [Server:main-one] 15:58:54,894 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 2) WFLYCTL0190: Step handler org.jboss.as.server.deployment.DeploymentHandlerUtil$5@2a0a9f3f for operation {"operation" => "undeploy","address" => [("deployment" => "broken.jar")],"operation-headers" => {}} at address [("deployment" => "broken.jar")] failed handling operation rollback -- java.util.NoSuchElementException: No child 'name' exists: java.util.NoSuchElementException: No child 'name' exists
> [Server:main-one] at org.jboss.dmr.ModelValue.requireChild(ModelValue.java:377) [jboss-dmr-1.3.0.Final.jar:1.3.0.Final]
> [Server:main-one] at org.jboss.dmr.ObjectModelValue.requireChild(ObjectModelValue.java:299) [jboss-dmr-1.3.0.Final.jar:1.3.0.Final]
> [Server:main-one] at org.jboss.dmr.ModelNode.require(ModelNode.java:870) [jboss-dmr-1.3.0.Final.jar:1.3.0.Final]
> [Server:main-one] at org.jboss.as.server.deployment.DeploymentHandlerUtil$5$1.handleResult(DeploymentHandlerUtil.java:331) [wildfly-server-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> [Server:main-one] at org.jboss.as.controller.AbstractOperationContext$Step.invokeResultHandler(AbstractOperationContext.java:1384) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> [Server:main-one] at org.jboss.as.controller.AbstractOperationContext$Step.handleResult(AbstractOperationContext.java:1366) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> [Server:main-one] at org.jboss.as.controller.AbstractOperationContext$Step.finalizeInternal(AbstractOperationContext.java:1328) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> [Server:main-one] at org.jboss.as.controller.AbstractOperationContext$Step.finalizeStep(AbstractOperationContext.java:1311) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> [Server:main-one] at org.jboss.as.controller.AbstractOperationContext$Step.access$300(AbstractOperationContext.java:1185) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> [Server:main-one] at org.jboss.as.controller.AbstractOperationContext.executeResultHandlerPhase(AbstractOperationContext.java:767) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> [Server:main-one] at org.jboss.as.controller.AbstractOperationContext.executeDoneStage(AbstractOperationContext.java:753) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> [Server:main-one] at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:680) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> [Server:main-one] at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> [Server:main-one] at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1336) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> [Server:main-one] at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> [Server:main-one] at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> [Server:main-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler.internalExecute(TransactionalProtocolOperationHandler.java:234) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> [Server:main-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler.doExecute(TransactionalProtocolOperationHandler.java:173) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> [Server:main-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:136) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> [Server:main-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:132) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> [Server:main-one] at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0_45]
> [Server:main-one] at javax.security.auth.Subject.doAs(Subject.java:360) [rt.jar:1.8.0_45]
> [Server:main-one] at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:81) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> [Server:main-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:152) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> [Server:main-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:148) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> [Server:main-one] at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0_45]
> [Server:main-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2.execute(TransactionalProtocolOperationHandler.java:148) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> [Server:main-one] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$ManagementRequestContextImpl$1.doExecute(AbstractMessageHandler.java:364) [wildfly-protocol-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> [Server:main-one] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:466) [wildfly-protocol-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> [Server:main-one] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_45]
> [Server:main-one] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_45]
> [Server:main-one] at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_45]
> [Server:main-one] at org.jboss.threads.JBossThread.run(JBossThread.java:320) [jboss-threads-2.2.1.Final.jar:2.2.1.Final]
> {code}
> [1] https://github.com/wildfly/wildfly-core/commit/f38b37#diff-2dbd1fc9261de7...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months