0

I am using Quarkus 2.10.2 and reactive rest clients. One of the rest clients (pas2clabService) is created using the RestClientBuilder and closed after the request in the IntegrationController has finished.

@RequestScoped
public class IntegrationController {

    PAS2CLabService pas2clabService;

    @PostConstruct
    void postConstruct() {
        this.pas2clabService = RestClientBuilder.newBuilder().baseUri(URI.create(integration.getUrl()))
                    .build(PAS2CLabService.class);
    }

    @PreDestroy
    void preDestroy() {
        this.pas2clabService.close();
    }

    public Uni<Optional<OverviewDocument>> getPAS2CLabOverview(String labCode) {
        return pas2clabService.getWorklist()
                .onItem().transform(response -> translatePAS2CLabWorklistResponse(response, labCode))
                .onFailure().recoverWithItem(this::translatePAS2CLabWorklistResponse);
    }
}

@RegisterRestClient(configKey = Integrations.PAS2CLAB_API)
@RegisterClientHeaders(PAS2CLabHeaderFactory.class)
@RegisterProvider(PASRestClientExceptionMapper.class)
public interface PAS2CLabService extends AutoCloseable {

    @GET
    @Path("/v1/worklist")
    @Produces("application/json")
    Uni<PAS2CLabWorklistResponse> getWorklist();
}

This approach has worked greatly with Quarkus 2.9.2 and older version, but since 2.10.2 the rest client is already closed when I invoke it via getPAS2CLabOverview. I can work around the problem by using @Singleton or @ApplicationScoped in the IntegrationController as this postpones the @PreDestroy event. I would however like to understand why I cannot use the @RequestScoped anymore and @PreDestroy is triggered before the Uni received an item.

  • The request context is likely terminated sooner than it should be, but the code you show doesn't really tell why that might happen. How is the `IntegrationController.getPAS2CLabOverview()` method used, and especially its return value? – Ladicek Jul 20 '22 at 09:26
  • The method is being called as a part of a cascade to several rest endpoints. After all responses have been received and processed the outcome is stored in a database (via reactive mongo transaction) The whole cascade uses Uni instances to allow non-blocking IO and support the long-running execution. Maybe I did not use the mutiny classes in the right way. Unfortunately, I am not allowed to post you all the source code here or give you access to it. Eventually, I changed the scope of the affected classes to Singleton or ApplicationScoped which fixed the issue. Your comment still helped me. – Marc Woerner Jul 25 '22 at 09:23
  • That's a good point. If a bean doesn't contain "per request" state, `@Singleton` or `@ApplicationScoped` is probably more appropriate. – Ladicek Jul 25 '22 at 09:29

0 Answers0