Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"Cannot remove extraneous deployment marker file" leads to strange behavior #17

Closed
lmsurpre opened this issue Apr 15, 2021 · 3 comments · Fixed by #19
Closed

"Cannot remove extraneous deployment marker file" leads to strange behavior #17

lmsurpre opened this issue Apr 15, 2021 · 3 comments · Fixed by #19

Comments

@lmsurpre
Copy link

lmsurpre commented Apr 15, 2021

I enabled the experimental testcontainers "withReuse" option and, after my tests completed, I went to check out the still-running container.

What I found is general flakiness. For example, after login, it would say the admin console page doesn't exist / couldn't be found. Then, after a refresh, it would work pretty well. Occasionally I would see an intermittent error on the UI, but it was still usage.

I dug into the logs to look for errors and I found the following output was repeated over and over again, basically drowning everything else out:

22:27:55,896 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-4) WFLYSRV0027: Starting deployment of "-495401560-extensions.jar" (runtime-name: "-495401560-extensions.jar")
22:27:55,971 WARN  [org.jboss.as.dependency.private] (MSC service thread 1-3) WFLYSRV0018: Deployment "deployment.-495401560-extensions.jar" is using a private module ("org.keycloak.keycloak-services") which may be changed or removed in future versions without notice.
22:27:55,976 INFO  [org.keycloak.subsystem.server.extension.KeycloakProviderDeploymentProcessor] (MSC service thread 1-3) Deploying Keycloak provider: -495401560-extensions.jar
22:27:55,990 WARN  [org.keycloak.services] (MSC service thread 1-3) KC-SERVICES0047: audience-validator (org.alvearie.keycloak.AudienceValidatorFactory) is implementing the internal SPI authenticator. This SPI is internal and may change without notice
22:27:55,991 WARN  [org.keycloak.services] (MSC service thread 1-3) KC-SERVICES0047: auth-select-patient (org.alvearie.keycloak.PatientSelectionFormFactory) is implementing the internal SPI authenticator. This SPI is internal and may change without notice
22:27:56,063 WARN  [org.keycloak.services] (MSC service thread 1-3) KC-SERVICES0047: oidc-patient-prefix-usermodel-attribute-mapper (org.alvearie.keycloak.PatientPrefixUserAttributeMapper) is implementing the internal SPI protocol-mapper. This SPI is internal and may change without notice
22:27:56,063 WARN  [org.keycloak.services] (MSC service thread 1-3) KC-SERVICES0047: oidc-usermodel-attribute-mapper-with-token-response-support (org.alvearie.keycloak.UserAttributeMapper) is implementing the internal SPI protocol-mapper. This SPI is internal and may change without notice
22:27:56,199 INFO  [org.jboss.as.server] (DeploymentScanner-threads - 1) WFLYSRV0016: Replaced deployment "-495401560-extensions.jar" with deployment "-495401560-extensions.jar"
22:27:56,200 WARN  [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 2) WFLYDS0002: Cannot remove extraneous deployment marker file /opt/jboss/keycloak/standalone/deployments/-495401560-extensions.jar.dodeploy
22:28:01,225 INFO  [org.keycloak.subsystem.server.extension.KeycloakProviderDeploymentProcessor] (MSC service thread 1-6) Undeploying Keycloak provider: -495401560-extensions.jar
22:28:01,245 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-4) WFLYSRV0028: Stopped deployment -495401560-extensions.jar (runtime-name: -495401560-extensions.jar) in 23ms
22:28:01,246 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-3) WFLYSRV0027: Starting deployment of "-495401560-extensions.jar" (runtime-name: "-495401560-extensions.jar")
22:28:01,318 WARN  [org.jboss.as.dependency.private] (MSC service thread 1-6) WFLYSRV0018: Deployment "deployment.-495401560-extensions.jar" is using a private module ("org.keycloak.keycloak-services") which may be changed or removed in future versions without notice.
22:28:01,323 INFO  [org.keycloak.subsystem.server.extension.KeycloakProviderDeploymentProcessor] (MSC service thread 1-6) Deploying Keycloak provider: -495401560-extensions.jar
22:28:01,336 WARN  [org.keycloak.services] (MSC service thread 1-6) KC-SERVICES0047: audience-validator (org.alvearie.keycloak.AudienceValidatorFactory) is implementing the internal SPI authenticator. This SPI is internal and may change without notice
22:28:01,336 WARN  [org.keycloak.services] (MSC service thread 1-6) KC-SERVICES0047: auth-select-patient (org.alvearie.keycloak.PatientSelectionFormFactory) is implementing the internal SPI authenticator. This SPI is internal and may change without notice
22:28:01,396 WARN  [org.keycloak.services] (MSC service thread 1-6) KC-SERVICES0047: oidc-patient-prefix-usermodel-attribute-mapper (org.alvearie.keycloak.PatientPrefixUserAttributeMapper) is implementing the internal SPI protocol-mapper. This SPI is internal and may change without notice
22:28:01,397 WARN  [org.keycloak.services] (MSC service thread 1-6) KC-SERVICES0047: oidc-usermodel-attribute-mapper-with-token-response-support (org.alvearie.keycloak.UserAttributeMapper) is implementing the internal SPI protocol-mapper. This SPI is internal and may change without notice
22:28:01,488 INFO  [org.jboss.as.server] (DeploymentScanner-threads - 1) WFLYSRV0016: Replaced deployment "-495401560-extensions.jar" with deployment "-495401560-extensions.jar"
22:28:01,491 WARN  [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 2) WFLYDS0002: Cannot remove extraneous deployment marker file /opt/jboss/keycloak/standalone/deployments/-495401560-extensions.jar.dodeploy
...

I'm not sure if the constantly reloading is a feature or a bug, but when I dug in I found that the reason it cannot delete the deployment marker file is that this file is a direct mount point.

When I fixed it locally, by mounting a directory instead of just the file, the container started to behave perfectly...no more wonkiness.

lmsurpre added a commit to lmsurpre/testcontainers-keycloak that referenced this issue Apr 15, 2021
By mounting its parent directory instead of just the specific file, then
marking it writeable for others.

I also upgraded it to Keycloak 12.0.4, but I can easilly revert that if
you want.
@dasniko
Copy link
Owner

dasniko commented Apr 20, 2021

Thanks @lmsurpre for reporting, I'll have a look into this.

@thomasdarimont can you pls also have a look at it, as this extension was contributed by you. Thanks.

lmsurpre added a commit to lmsurpre/testcontainers-keycloak that referenced this issue Apr 20, 2021
Apparently mounting a temporary directory to the same location as the
target classes was not working on Fedora with Podman.

The new approach is to add the `.dodeploy` file directly to the
extensionClassFolder which already has a volume mount at this location.
lmsurpre added a commit to lmsurpre/testcontainers-keycloak that referenced this issue Apr 20, 2021
Apparently mounting a temporary directory to the same location as the
target classes was not working on Fedora with Podman.

The new approach is to add the `.dodeploy` file directly to the
extensionClassFolder which already has a volume mount at this location.
thomasdarimont added a commit to thomasdarimont/testcontainers-keycloak that referenced this issue Apr 20, 2021
lmsurpre added a commit to lmsurpre/testcontainers-keycloak that referenced this issue Apr 20, 2021
Copy the deploymentTriggerFile to the container instead of setting up a
bindMount for it.
lmsurpre added a commit to lmsurpre/testcontainers-keycloak that referenced this issue Apr 20, 2021
Copy the deploymentTriggerFile to the container instead of setting up a
bindMount for it.
thomasdarimont added a commit to thomasdarimont/testcontainers-keycloak that referenced this issue Apr 20, 2021
lmsurpre added a commit to lmsurpre/testcontainers-keycloak that referenced this issue Apr 20, 2021
Copy the deploymentTriggerFile to the container instead of setting up a
bindMount for it.
thomasdarimont added a commit to thomasdarimont/testcontainers-keycloak that referenced this issue Apr 20, 2021
We now trigger deployment of exploded extensions folders
during container start by copying a dynamically generated ".dodeploy"
file.

Previously we mounted an external ".dodeploy" file into the container
which did not work on some operating systems (OSX) when container
reuse was used.

Fixes dasniko#17
thomasdarimont added a commit to thomasdarimont/testcontainers-keycloak that referenced this issue Apr 20, 2021
We now trigger deployment of exploded extensions folders
during container start by copying a dynamically generated ".dodeploy"
file.

Previously we mounted an external ".dodeploy" file into the container
which did not work on some operating systems (OSX) when container
reuse was used.

Fixes dasniko#17
thomasdarimont added a commit to thomasdarimont/testcontainers-keycloak that referenced this issue Apr 20, 2021
We now trigger deployment of exploded extensions folders
during container start by copying a dynamically generated ".dodeploy"
file.

Previously we mounted an external ".dodeploy" file into the container
which did not work on some operating systems (OSX) when container
reuse was used.

Fixes dasniko#17
thomasdarimont added a commit to thomasdarimont/testcontainers-keycloak that referenced this issue Apr 20, 2021
We now trigger deployment of exploded extensions folders
during container start by copying a dynamically generated ".dodeploy"
file.

Previously we mounted an external ".dodeploy" file into the container
which did not work on some operating systems (OSX) when container
reuse was used.

Fixes dasniko#17

(cherry picked from commit 1e95cb6)
@thomasdarimont
Copy link
Contributor

@dasniko I think I have a sound fix for this issue now, would you mind having a look? :)

thomasdarimont added a commit to thomasdarimont/testcontainers-keycloak that referenced this issue Apr 20, 2021
We now trigger deployment of exploded extensions folders
during container start by copying a dynamically generated ".dodeploy"
file.

Previously we mounted an external ".dodeploy" file into the container
which did not work on some operating systems (OSX) when container
reuse was used.

Fixes dasniko#17

(cherry picked from commit 1e95cb6)
@dasniko
Copy link
Owner

dasniko commented Apr 21, 2021

Thanks @thomasdarimont and @lmsurpre for figuring out and having a solution which works on all tested platforms.
I'll review and merge the next hours/days.

dasniko pushed a commit that referenced this issue Apr 23, 2021
We now trigger deployment of exploded extensions folders
during container start by copying a dynamically generated ".dodeploy"
file.

Previously we mounted an external ".dodeploy" file into the container
which did not work on some operating systems (OSX) when container
reuse was used.

Fixes #17

(cherry picked from commit 1e95cb6)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants