Subscribe to airhacks.fm podcast via: spotify| iTunes| RSS

jwebserver introduced with JEP 408 can be used for incoming header / user agent debugging.

Launching the web server in verbose mode with: jwebserver -o verbose, outputs the incoming headers after executing: curl http://localhost:8000:

> Accept: */*
> Host: localhost:8000
> User-agent: curl/7.79.1

The following Java HttpClient:

import java.net.http.HttpResponse.BodyHandlers;
import java.net.http.*;

var client = HttpClient.newHttpClient();
var request = HttpRequest.newBuilder(URI.create("http://localhost:8000"))
                .GET()
                .build();
var response = client.send(request,BodyHandlers.ofString())

generates these headers:

> Connection: Upgrade, HTTP2-Settings
> Http2-settings: AAEAAEAAAAIAAAABAAMAAABkAAQBAAAAAAUAAEAA
> Host: localhost:8000
> User-agent: Java-http-client/19
> Upgrade: h2c

See it in action and in less than 1 min:

Thanks for all the questions and interactions. This keynote was fun!

Abstract:

"Serverless Java applications are stateless and store their data in a range of cloud persistence stores, from relational databases, like Aurora, over file-based block storage like S3 to persistent event stores like Kinesis.

In this keynote, I will focus on the characteristics and challenges of serverless Lambda and Fargate Java application's data access layer and discuss the impact on authentication, authorization, connection handling or scalability, data mapping, portability, and costs. Your questions are highly welcome!"

Subscribe to airhacks.fm podcast via: spotify| iTunes| RSS

Subscribe to airhacks.fm podcast via: spotify| iTunes| RSS

A JAX-RS Response implements AutoCloseable. It can either be closed explicitly, or via try-with-resources:

import static org.junit.jupiter.api.Assertions.assertNotNull;
import javax.inject.Inject;
import org.eclipse.microprofile.rest.client.inject.RestClient;
import org.junit.jupiter.api.Test;
import io.quarkus.test.junit.QuarkusTest;

@QuarkusTest
public class AutocloseableResponseIT {

    @Inject
    @RestClient
    WebsiteClient client;

    @Test
    void closeExplicitly(){
        var response = this.client.getContent();
        var content = response.readEntity(String.class);
        response.close();
        assertNotNull(content);
    }

    @Test
    void autoClose(){
        try(var response = this.client.getContent()){
            var content = response.readEntity(String.class);
            assertNotNull(content);
        }
    }
}

The corresponding client (Rest Client for MicroProfile) used in this example is:

import javax.ws.rs.GET;
import javax.ws.rs.Produces;
import javax.ws.rs.core.MediaType;
import javax.ws.rs.core.Response;

import org.eclipse.microprofile.rest.client.inject.RegisterRestClient;

@RegisterRestClient(baseUri = "http://localhost:8080")
public interface WebsiteClient {
    
    @GET
    @Produces(MediaType.TEXT_PLAIN)
    Response getContent();
}

Too many "open" Responses may lead to blocking behavior.

The September edition of airhacks.tv with the following topics:

"J2EE, Java EE, Jakarta EE migration projects, NetBeans vs. VSC, custom Bean Validators, JPA and JSON-B data mapping, fault tolerance and retry-able transactions, HTTP/2 use cases, too long URIs"

is ready:

See you every first Monday of the month at https://airhacks.tv 8pm CET (UTC+1:00). Show is also announced at: meetup.com/airhacks.

Any questions left? Ask now: https://gist.github.com/AdamBien/877ce9c05f8eaeaf1dda2ba2df7eddd0 and get the answers at the next airhacks.tv.

Questions and topics for the 102nd airhacks.tv live stream (https://www.youtube.com/c/bienadam/):

1. The time machine or topics from 100 episodes ago (the 2nd airhacks.tv)
2. J2EE, Java EE and Jakarta EE upgrades
3. NetBeans and Visual Studio Code
4. The single Jakarta EE dependency
5. Installation of custom Bean Validators
6. Date conversions with JPA and JSON-B
7. The "retriable transaction" annotation
8. Use cases for http 2 server push
9. Dealing with 414 (Request-URI Too Large)

See you every first Monday of the month at https://airhacks.tv 8pm CET (UTC+1:00). Show is also announced at: meetup.com/airhacks.

Any questions left? Ask now: gist.github.com/AdamBien/49efb5c357b19ad2bdde82ea026db803 and get the answers at the next airhacks.tv.

Subscribe to airhacks.fm podcast via: spotify| iTunes| RSS

The following (Rest Client for MicroProfile) interface:

@RegisterRestClient(baseUri = "http://localhost:8000")
public interface WebsiteClient {
    
    @GET
    @Produces(MediaType.TEXT_PLAIN)
    Response getContent();
}

...injected to Quarkus JAX-RS resource:

import javax.inject.Inject;
import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.core.Response;

import org.eclipse.microprofile.rest.client.inject.RestClient;

@Path("website")
public class WebsiteResource {


    @Inject
    @RestClient
    WebsiteClient firstClient;

    @Inject
    @RestClient
    WebsiteClient secondClient;

    @GET
    public String injected() {
        for (int i = 0; i < 500; i++) {
            Response firstResponse = this.firstClient.getContent();
            Response secondResponse = this.secondClient.getContent();
            System.out.println(i);
        }
        return "+";
    }    
}

will block after 50 iterations.

Reason: the exhaustion of the underlying HTTP connection pool. See stack trace:

org.apache.http.pool.AbstractConnPool.getPoolEntryBlocking(AbstractConnPool.java:393)
org.apache.http.pool.AbstractConnPool.access$300(AbstractConnPool.java:70)
org.apache.http.pool.AbstractConnPool$2.get(AbstractConnPool.java:253)
org.apache.http.pool.AbstractConnPool$2.get(AbstractConnPool.java:198)
org.apache.http.impl.conn.PoolingHttpClientConnectionManager.leaseConnection(PoolingHttpClientConnectionManager.java:306)
org.apache.http.impl.conn.PoolingHttpClientConnectionManager$1.get(PoolingHttpClientConnectionManager.java:282)
org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:190)
org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:186)
org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89)
org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185)
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83)
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:56)
org.jboss.resteasy.client.jaxrs.engines.ManualClosingApacheHttpClient43Engine.invoke(ManualClosingApacheHttpClient43Engine.java:302)

The underlying resources are freed with the Response#close call, now all 500 iterations are performed without blocking:

@GET
public String injected() {
    for (int i = 0; i < 500; i++) {
        Response firstResponse = this.firstClient.getContent();
        firstResponse.close();
        Response secondResponse = this.secondClient.getContent();
        firstResponse.close();
        System.out.println(i);
    }
    return "+";
}    

The blocking behaviour depends on the JAX-RS / MicroProfile Rest Client implementation. RESTEasy requires an explicit Response#close call, Jersey does not.