make ThreadTimer not singleton again

[Ladicek]

This is for multi-deployment environments, like WildFly, where multiple applications may exist and each will have its own timer.

Fixes #1047

[Ladicek]

@rhusar Here's the fix for singleton Timer. If you could test this with WildFly, that would be great!

[rhusar]

@rhusar Here's the fix for singleton Timer. If you could test this with WildFly, that would be great!

Thanks, I ll have a look and report back.

[Ladicek]

Hi @rhusar, any news?

[rhusar]

@Ladicek TBH having a bit of a problem reproducing this, can you elaborate the conditions that are necessary to trigger this? Basically I have 2 concurrent deployment both using a Retry, but that doesn't trigger the problem.

[Ladicek]

Humm, OK, that's weird. Did you try to call the @Retry method in both apps? There's certain level of laziness.

[rhusar]

Humm, OK, that's weird. Did you try to call the @Retry method in both apps? There's certain level of laziness.

Yes. I am starting to think there is another condition required to trigger the Lazy resolution bit.. Also, in the user report this appears to not require calling the methods since this happens in WeldStartService.

[Ladicek]

Ah right, good point. The timer is created eagerly. Well, then I don't know what's the issue...

[mmusenbr]

Orignal Issue-Reporter in zulip here: We have bound the Retry to a reactive-Messaging channel, I can try to strip that down to a sharable example, but I do not have the time to do that today (CEST timezone).

[rhusar]

Orignal Issue-Reporter in zulip here: We have bound the Retry to a reactive-Messaging channel, I can try to strip that down to a sharable example, but I do not have the time to do that today (CEST timezone).

Thanks @mmusenbr, that would be immensely helpful (the reactive messaging subsystem was added after integrating MP Fault Tolerance so I guess that's why we don't have this covered in WildFly test suite better..)

[Ladicek]

So I'm not exactly sure what I'm doing wrong, but I can deploy 2 apps using SmallRye Fault Tolerance without a problem. It is only when I call both applications when I'm getting the exception. Not what I would have expected, but good enough I guess.

The reproducer is the simplest webapp you can imagine, I don't really feel like creating a GitHub repo, so just a listing of files here:

pom.xml:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>cz.ladicek</groupId>
    <artifactId>fttest</artifactId>
    <version>1.0-SNAPSHOT</version>

    <packaging>war</packaging>

    <properties>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <maven.compiler.release>17</maven.compiler.release>
    </properties>

    <dependencies>
        <dependency>
            <groupId>jakarta.enterprise</groupId>
            <artifactId>jakarta.enterprise.cdi-api</artifactId>
            <version>4.0.1</version>
            <scope>provided</scope>
        </dependency>
        <dependency>
            <groupId>jakarta.ws.rs</groupId>
            <artifactId>jakarta.ws.rs-api</artifactId>
            <version>3.1.0</version>
            <scope>provided</scope>
        </dependency>
        <dependency>
            <groupId>org.eclipse.microprofile.fault-tolerance</groupId>
            <artifactId>microprofile-fault-tolerance-api</artifactId>
            <version>4.0</version>
            <scope>provided</scope>
        </dependency>
    </dependencies>
</project>

src/main/java/cz/ladicek/fttest/MyApplication.java:

package cz.ladicek.fttest;

import jakarta.ws.rs.ApplicationPath;
import jakarta.ws.rs.core.Application;

@ApplicationPath("/")
public class MyApplication extends Application {
}

src/main/java/cz/ladicek/fttest/MyBean.java:

package cz.ladicek.fttest;

import jakarta.enterprise.context.ApplicationScoped;
import org.eclipse.microprofile.faulttolerance.Retry;

@ApplicationScoped
public class MyBean {
    @Retry
    public String hello() {
        return "hello";
    }
}

src/main/java/cz/ladicek/fttest/MyResource.java:

package cz.ladicek.fttest;

import jakarta.inject.Inject;
import jakarta.ws.rs.GET;
import jakarta.ws.rs.Path;

@Path("/")
public class MyResource {
    @Inject
    MyBean bean;

    @GET
    public String get() {
        return bean.hello();
    }
}

src/main/webapp/WEB-INF/beans.xml: empty file

src/main/webapp/WEB-INF/web.xml:

<web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"
         version="3.1">
</web-app>

Running mvn clean package and then deploying the resulting WAR twice into WildFly 33.0.2 running with the standalone-microprofile.xml configuration.

[Ladicek]

With this PR, the exception no longer occurs. Looks good enough to me.

[rhusar]

With this PR, the exception no longer occurs. Looks good enough to me.

Sounds good. I was packaging these in an EAR (to avoid some test fwk limitations) so perhaps that has an effect too and some sharing is going on in an EAR, even though it does "start" SR FT twice as per logs. I ll update the test now.

[Ladicek]

Oh I have no idea how that works in an EAR. Two separately deployed WARs certainly trigger the problem.

[rhusar]

@Ladicek Just rewritten the test to use separate top-level deployments = they fail and pass with the fix. So clearly, there is some context sharing going on in an EAR that doesn't trigger this.

Excellent, now we will just wait for 6.4.1 whenever we can get it ;-)

FYI @mmusenbr no need for the reproducer, thx!

[fabiobrz]

@Ladicek Just rewritten the test to use separate top-level deployments = they fail and pass with the fix. So clearly, there is some context sharing going on in an EAR that doesn't trigger this.

Excellent, now we will just wait for 6.4.1 whenever we can get it ;-)

FYI @mmusenbr no need for the reproducer, thx!

Sorry to be joining the party too late. We do have a failing test which is a good reproducer, here: https://github.com/jboss-eap-qe/eap-microprofile-test-suite/blob/master/microprofile-fault-tolerance/src/test/java/org/jboss/eap/qe/microprofile/fault/tolerance/UndeployDeployTest.java#L125

@rhusar do we have a WFLY tracking this issue (and one for the required version bump, BTW)?

[rhusar]

If only it ran on CI ;-)

Yes, the issues are:
https://issues.redhat.com/browse/WFLY-19747 (might split to a test one as well for tomorrows 'hackaton')
https://issues.redhat.com/browse/WFLY-19782

[fabiobrz]

If only it ran on CI ;-)

Eh... we're working on it 🥲

Yes, the issues are:

Thanks!