From Punched Cards to Java 11--airhacks.fm podcast

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

The #209 airhacks.fm episode with Glenn Holmer (@gholmer) about:
the transition from punched cards over assembly, servlets, enterprise java to Java 11+.
is available for

Debugging Incoming Headers with jwebserver

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:

JCon 2022 Conference Keynote: Thinking About Persistence for Serverless Java

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!"

GraalVM: Meta Circularity on Different Levels--airhacks.fm podcast

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

The #208 airhacks.fm episode with Fabio Niephaus (@fniephaus) about:
various ways for language interoperability on GraalVM and GraalVM developer tools
is available for

Mission Critical Transactions--airhacks.fm podcast

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

The #207 airhacks.fm episode with Alejandro Pablo Revilla (@apr) about:
mission critical Java, transactions and POS, dependency management, open source vs. managed services in the clouds
is available for

Closing JAX-RS Response with try-with-resources

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.

Migrations, Transactions, Retries, Long URIs, JPA, JSON-B, HTTP/2--102nd airhacks.tv

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.

Java EE Upgrades, NetBeans, Bean Validation, Transactions, HTTP/2, 414--102nd 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.

Java 19: Millions of Threads in No Time--airhacks.fm podcast

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

The #206 airhacks.fm episode with Nicolai Parlog (@nipafx) about:
Java 19, Project Loom, structured concurrency and reactive programming
is available for

Quarkus, Hanging MP REST Client and the Solution

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.

Online Workshops
...the last 150 posts
...the last 10 comments
License