Continual re-deploy when tryng to use Global DIrectories (26.1.2.Final)

[Brian Chandley]

Hi all.

I am trying setup the artifacts I deploy in Wildfly to share dependencies. I have a number of artifacts that use the same version of  aws java jdk and I'd like the artifacts to use the same version.

I can modules are an options, but configuration of the 14 modules and managing all their dependencies would pose a barrier to upgrading the sdk versions.

After sorting through class loader issues.. I come to the phase where Wildfly deploys e application. shuts it down then redeploys it indefinitely.  I am triyng to find in the TRACE logs  the reason for this.  I think I am missing a key detail to how a Global DIrectory should be used.

I am currently attempting to use a Global Directory.

I am running wildfly in docker.

step 0: Starting point: I have my artifacts working properly 
Step 1: Create the directoryL
      mkdir /opt/jboss/wildfly/lib
Step 2:
       copy the deplendecy  and all of the jars the dependency requires into the global 
Step 2:  Configure the global directory:
       bash /opt/jboss/wildfly/bin/jboss-cli.sh -c "/subsystem=ee/global-directory=globaLib:add(path=lib, relative-to=jboss.home.dir)"

Step 3:   stop/start docker container
       my application works
Step 4. Manually remove the jar that the application has locally that I want to be pulled from the global directory.
       The artifact is started up: I can see startup operation logged. Then immediately shut down. I can see the teardown steps being logged. 

I turned on trace and I see this: What I can not find is the reason the update action is found.



18:41:12,549 DEBUG [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 2) Deployment scan of [/opt/jboss/wildfly/standalone/deployments] found update action [{
    "operation" => "full-replace-deployment",
    "address" => [],
    "name" => "services-integrations-1.0-SNAPSHOT.ear",
    "content" => [{"url" => "file:/opt/jboss/wildfly/standalone/deployments/services-integrations -1.0-SNAPSHOT.ear"}],
    "persistent" => false,
    "owner" => [
        ("subsystem" => "deployment-scanner"),
        ("scanner" => "default")
    ],
    "enabled" => true
}]

I did notice a message that I did not understand:

the result of AuthorizeAttributeReadHandler was false

18:41:12,407 TRACE [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 2) Final response for step handler org.jboss.as.controller.operations.global.ReadAttributeHandler$AuthorizeAttributeReadHandler@46d0d025 handling read-attribute in address [("deployment" => "services-publisher-integrations-swfactivity-1.0-SNAPSHOT.ear")] is {
    "outcome" => "success",
    "result" => false
}

Has anyone used global directories in this way? Am I missing a step?

When trouble shooting issues like this: Are there specific log levels that are useful to turn up: I am new to this and setting the root logger's Level to TRACE.

[Valerii Pekarskyi]

Seen similar continuous redeploy with Wildfly 18 to 24 (maybe other versions are affected too). I am building the EAR artifact on Windows machine, then copy it to the folder mounted to /opt/jboss/wildfly/standalone/deployments of official Wildfly Docker image (like jboss/wildfly:24.0.0.Final), and application is continuously redeploys.

After digging into the Wildfly sources I have found that different system calls return different modification times of the artifact, one truncated to seconds, other having milliseconds precision, making the code think artifact was changed during the deployment. The place was somewhere inside artifact scanner code, I don't have exact class and lines involved.

My fix to the continuous redeploys was to update modification time to the artifact  side truncated to seconds on the Windows build system. Gradle code was:

            def target = wildFlyDir.absolutePath + "/standalone/deployments/" + ear.archiveFileName.get()
            file(target).setLastModified(LocalDateTime.now().withNano(0).atZone(ZoneId.systemDefault()).toInstant().toEpochMilli())  

I have also found potentially related https://bugs.openjdk.org/browse/JDK-8177809 that should have been fixed in Java 10+ but my setup was working on Java 11 and still reproduced the issue.

Best,

Valerii

[Miha Štemberger]

Not sure about global directories but this seems to be a similar issue where deployment timestamps are "corrupted": https://github.com/jboss-dockerfiles/wildfly/issues/144.

I believe that a workaround used at that time was to first copy wanted deployabled from the host into the docker container /tmp/deployables folder. From there they were moved to their final destination with a script before wildfly startup(custom docker entrypoint)

Br,

Miha

V V pet., 23. jun. 2023 ob 09:39 je oseba Valerii Pekarskyi <pekarski...@gmail.com> napisala:

--
You received this message because you are subscribed to the Google Groups "WildFly" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wildfly+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/wildfly/29e1da51-f34d-4a5e-a136-190f49cc7e42n%40googlegroups.com.

[Brian Chandley]

Thank you both!

This helps me narrow my investigation!

[Shraddha Jadhav]

Hi Brian, 
    I am facing the same issue. Have you been able to find a solution for this?
A little Background about My issue:
1) I am using Wildfly 18 and Eclipse Temurin JDK11.  My ear file goes into continuous redeployment.
whereas wildfly18 and JDk8 work smoothly with the same source code
also if I create an ear file via build and deploy it from the Management console. this also works.
but I need a hot deploy of code for developer setup.
2) We are basically upgrading from JDK8 to JDK11. 

CONFIDENTIALITY NOTICE: This email and any attachments are confidential and may be privileged. If you are not the intended recipient, please notify the sender immediately, and do not disclose, copy, distribute, or retain this email or any part of it. Also, please delete it from your system and destroy any copies immediately. Thank you.

[Emmanuel Hugonnet]

IIRC the Eclipse plugin has an 'experimental' feature on the connector using exploded deployments and management operations to update the
files in the deployment without relying on the filesystem nor on the scanner. Maybe it would help to use that.
Emmanuel

> <https://groups.google.com/d/msgid/wildfly/29e1da51-f34d-4a5e-a136-190f49cc7e42n%40googlegroups.com?utm_medium=email&utm_source=footer>.
>
>
> *CONFIDENTIALITY NOTICE: *This email and any attachments are confidential and may be privileged. If you are not the intended recipient,

> please notify the sender immediately, and do not disclose, copy, distribute, or retain this email or any part of it. Also, please delete
> it from your system and destroy any copies immediately. Thank you.

> --
> You received this message because you are subscribed to the Google Groups "WildFly" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to wildfly+u...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/wildfly/b0e784bc-8dd4-4fc9-83cf-f233c614f2f6n%40googlegroups.com
> <https://groups.google.com/d/msgid/wildfly/b0e784bc-8dd4-4fc9-83cf-f233c614f2f6n%40googlegroups.com?utm_medium=email&utm_source=footer>.