How to leverage Java 10’s Thread-Local Handshakes for performance tuning

By I Wayan Saryada in Java 10 0 Comment

Java 10 introduced Thread-Local Handshakes as a powerful feature in the JVM, designed to improve the performance and responsiveness of applications, especially in scenarios involving thread-based operations and garbage collection.

Here’s what you need to know about Thread-Local Handshakes and how to leverage them for performance tuning:

1. What are Thread-Local Handshakes?

Thread-Local Handshakes allow a thread to execute a callback function locally without stopping all threads. This contrasts with traditional global safepoints in Java, where all threads must come to a safe state before any work can be done, such as garbage collection or code deoptimization.

In other words:

  • A handshake is a mechanism to perform operations on a subset of threads (or even individual threads) without stopping the entire JVM.
  • This is useful for operations that don’t require a global JVM safepoint, improving responsiveness and reducing latency.

2. Benefits of Thread-Local Handshakes

  • Avoids Global Safepoints: Operations can target some threads or a single thread, meaning other threads continue their work unaffected.
  • Reduces Latency: No need to pause all threads, improving performance for multithreaded applications.
  • Fine-Grained Control: Perform thread-specific tasks like flushing thread-specific memory buffers, deoptimizing code for just one thread, or collecting specific thread-local objects without interrupting the entire JVM.

3. Use Cases

Here are some scenarios where Thread-Local Handshakes can be beneficial:

  • Garbage Collection
    Garbage collectors rely on safepoints to pause threads while managing memory. Thread-Local Handshakes can isolate such operations to only the threads that need it, reducing pause times and improving application throughput.

  • Code Deoptimization
    This happens during just-in-time (JIT) compilation when compiled code needs to revert to interpreted mode. Utilizing handshakes allows deoptimization to occur on specific threads, minimizing the impact on other threads.

  • Thread-Specific Profiling and Debugging
    A developer or monitoring agent can perform profiling or diagnostic tasks on a single thread without disturbing other threads.

  • Thread-Specific Resource Cleanup
    Thread-local data structures can be cleaned up or flushed for specific threads, optimally managing system resources.

4. How Thread-Local Handshakes Work Internally

Thread-Local Handshakes introduce thread-specific “safepoints.” When a request is initiated:

  1. The JVM signals specific threads to execute a callback function (like releasing resources or processing pending tasks).
  2. Unlike global safepoints, only the targeted thread(s) pause and execute the operation.
  3. Once the operation is complete, the thread resumes execution.

This makes operations more granular and non-blocking at the JVM level.

5. Leveraging Thread-Local Handshakes in Performance Tuning

Although Thread-Local Handshakes are implemented at the JVM level, you can indirectly leverage them for performance tuning in the following ways:

  1. Tuning for Garbage Collection
    If you’re using a garbage collector like G1GC or ZGC, you can reduce garbage collection pauses since these collectors take advantage of handshakes to avoid halting all threads during certain operations.

    • How to Monitor: Use tools like Java Mission Control (JMC), VisualVM, or JVM logging to monitor GC pause times and ensure thread-local synchronization is being effectively utilized.

    Relevant JVM Options:

    • -XX:+UseG1GC (or any GC of choice) to enable advanced garbage collection strategies.
    • Use -Xlog:gc to monitor GC logs and observe pauses.
  2. Reducing Latency in Thread-Sensitive Applications
    If your application uses many threads (e.g., for handling requests or background tasks), Thread-Local Handshakes reduce overall latency by targeting specific threads instead of pausing all threads unnecessarily.

    Best practices:

    • Profile your application for thread contention and safepoints using tools like Async Profiler or JFR (Java Flight Recorder).
    • Optimize thread management through thread pools (using ForkJoinPool, ThreadPoolExecutor, etc.) to prevent thread starvation and maximize throughput.
  3. Tuning Thread-Specific Tasks
    For tasks that manipulate thread-local data or thread-specific settings:

    • Optimize performance by ensuring the work is allocated to specific threads that need operations (e.g., specific callbacks).
    • Reduce contention by designing operations that leverage locality (thread-local memory, caches, etc.).

6. Practical Tips for Developers

While Thread-Local Handshakes are managed by the JVM, the following tips help you align your code and architecture to take full advantage:

  1. Choose Modern JVMs: Use JDK 10 or later for applications where fine-grained thread optimization matters. Newer garbage collectors like ZGC or Shenandoah optimize handshakes even further.

  2. Monitor Safepoints and Utilization:

    • Safepoint statistics can be enabled using -XX:+PrintSafepointStatistics to understand how your threads interact with JVM-managed resources.
    • Use tools like JFR to detect safepoint delays or thread-local handshake activity.
  3. Minimize Global Syncs in Application Code:
    • Avoid global thread synchronization where possible.
    • Use thread-local structures (e.g., ThreadLocal API) for thread-scoped data.
  4. Benchmark Your Application:
    Profile how your code interacts with the JVM and threads. Use tools like JMH (Java Microbenchmark Harness) for thread and synchronization benchmarking.

7. Example: Monitoring Thread Safepoints

java -XX:+PrintSafepointStatistics -XX:PrintSafepointStatisticsCount=1 -XX:+LogVMOutput -XX:LogFile=safepoints.log -jar YourApp.jar

This will output safepoint-related logs, showing where Thread-Local Handshakes may improve performance by reducing pauses.

8. Conclusion

Thread-Local Handshakes represent an evolutionary step in how the JVM manages thread interactions, replacing costly global operations with thread-targeted approaches. While you may not directly invoke or control handshakes, you can optimize your application and JVM configuration to reap their benefits:

  • Select JVM options and garbage collection strategies that leverage handshakes.
  • Profile and diagnose thread safepoints to find opportunities for performance tuning.

These adjustments ensure better efficiency, reduced latency, and improved performance in multithreaded applications.

How do I use JSch with strict host key checking and known_hosts validation?

By I Wayan Saryada in JSch 0 Comment

When using JSch (Java Secure Channel) to connect to an SSH server, you can enable strict host key checking and validate the server against a known_hosts file. By default, strict host key checking ensures that your application will only connect to SSH servers that are already listed in the known_hosts file. If the server’s key is not present or doesn’t match, the connection will fail.

Here’s how you can implement strict host key checking and configure the use of a known_hosts file with JSch:

Step 1: Enable Strict Host Key Checking and Set Known Hosts

Below is an example of how to configure JSch with strict host key checking:

package org.kodejava.jsch;

import com.jcraft.jsch.JSch;
import com.jcraft.jsch.Session;

import java.util.Properties;

public class JSchStrictHostKeyCheckingExample {
   public static void main(String[] args) {
      String username = "username";
      String host = "example.com";
      int port = 22; // default SSH port
      String privateKeyPath = "/path/to/your/private/key";
      String knownHostsPath = "/path/to/your/known_hosts";

      try {
         // Initialize JSch
         JSch jsch = new JSch();

         // Set private key if authentication requires it
         jsch.addIdentity(privateKeyPath);

         // Set the known_hosts file for host key verification
         jsch.setKnownHosts(knownHostsPath);

         // Create SSH session
         Session session = jsch.getSession(username, host, port);

         // Set session properties for strict host key checking
         Properties config = new Properties();
         config.put("StrictHostKeyChecking", "yes"); // Enables strict host key checking
         session.setConfig(config);

         // Connect to the SSH server
         session.connect();

         System.out.println("Connected securely with strict host key checking.");

         // Perform your operations (e.g., execute commands, transfer files, etc.)

         // Disconnect from the SSH server
         session.disconnect();
         System.out.println("Disconnected from server.");

      } catch (Exception e) {
         e.printStackTrace();
      }
   }
}

Explanation:

  1. StrictHostKeyChecking:
    • Setting the StrictHostKeyChecking property to "yes" will enforce strict validation of the host’s key against the known_hosts file.
    • If the host is not in the known_hosts file or if the key does not match, the connection will fail.
  2. Known Hosts File:
    • Use jsch.setKnownHosts(knownHostsPath) to specify the path to the known_hosts file. This file stores the public host keys of remote servers that you trust.
  3. Private Key:
    • If the SSH server requires private key authentication, use jsch.addIdentity(privateKeyPath) to add your private key.
  4. Session Configuration:
    • Other common configuration options (set in Properties) may include:
      • PreferredAuthentications: Specify the preferred authentication methods (e.g., publickey,password,keyboard-interactive).
      • UserKnownHostsFile: Alternative way to point to the known_hosts file.
  5. Error Handling:
    • If the server’s host key is not present in the known_hosts file or does not match, you will encounter an error similar to:
    com.jcraft.jsch.JSchException: reject HostKey: your-host

    This means the server’s public key either needs to be added to the known_hosts file or matches an incorrect entry.

Step 2: Generating/Updating the known_hosts File

To manually add a host key to the known_hosts file:

Run the following command on any system with SSH installed:

ssh-keyscan -H your-host >> /path/to/known_hosts
  • -H: Hashes the hostname before storing it in the known_hosts file.
  • Replace your-host with the actual hostname or IP address of the server.

Common Issues and Debugging

  1. Host Key Verification Failed:
    • Ensure the server’s public key exists in the known_hosts file.
    • Ensure the correct knownHostsPath is specified in your code.
  2. Permission Denied:
    • Check your username, private key path, and associated permissions.
    • Make sure your private key is readable and properly associated with the user on the server.
  3. Logging Debug Information:
    JSch provides detailed logs for debugging. You can enable verbose logging as below:

    JSch.setLogger(new com.jcraft.jsch.Logger() {
      public boolean isEnabled(int level) { return true; }
      public void log(int level, String message) { System.out.println(message); }
  });

By following this approach, you can securely connect to an SSH server while leveraging strict host key checking and known_hosts validation.

Maven Dependencies

<dependency>
    <groupId>com.jcraft</groupId>
    <artifactId>jsch</artifactId>
    <version>0.1.55</version>
</dependency>

Maven Central

How do I transfer files with resume support over SFTP using JSch?

By I Wayan Saryada in JSch 0 Comment

When transferring files over SFTP using JSch, resuming partially transferred files (either uploads or downloads) can be implemented by handling offsets for files that are already partially transferred.

This guide explains how to:

  • Resume downloads by continuing from the last transferred byte of a local file.
  • Resume uploads by appending to a remote file.

Handling Download with Resume Support

To resume a download:

  1. Check the current size of the local file.
  2. Skip already downloaded bytes from the remote file using InputStream.skip().
  3. Append remaining content to the local file.

Code for Resuming Download

package org.kodejava.jsch;

import com.jcraft.jsch.*;
import java.io.*;

public class SFTPResumeDownload {

   public static void main(String[] args) {
      String host = "sftp.example.com";
      String username = "user";
      String password = "password";
      String localFile = "local/path/to/file.txt";
      String remoteFile = "/remote/path/to/file.txt";

      JSch jsch = new JSch();
      Session session = null;
      ChannelSftp sftpChannel = null;

      try {
         // Setup SFTP connection
         session = jsch.getSession(username, host, 22);
         session.setPassword(password);
         session.setConfig("StrictHostKeyChecking", "no"); // Disable key checking
         session.connect();

         Channel channel = session.openChannel("sftp");
         channel.connect();
         sftpChannel = (ChannelSftp) channel;

         // Resume download logic
         File file = new File(localFile);
         long localFileSize = file.exists() ? file.length() : 0;
         long remoteFileSize = sftpChannel.lstat(remoteFile).getSize();

         if (localFileSize >= remoteFileSize) {
            System.out.println("File already fully downloaded.");
            return;
         }

         try (InputStream inputStream = sftpChannel.get(remoteFile);
              OutputStream outputStream = new FileOutputStream(file, true)) {
            inputStream.skip(localFileSize); // Skip downloaded portion

            byte[] buffer = new byte[1024];
            int bytesRead;
            while ((bytesRead = inputStream.read(buffer)) != -1) {
               outputStream.write(buffer, 0, bytesRead);
            }

            System.out.println("Download resumed and completed.");
         }
      } catch (Exception e) {
         e.printStackTrace();
      } finally {
         if (sftpChannel != null) sftpChannel.disconnect();
         if (session != null) session.disconnect();
      }
   }
}

Handling Upload with Resume Support

To resume an upload:

  1. Check the size of the remote file.
  2. Skip already uploaded bytes from the local file.
  3. Use the ChannelSftp.APPEND flag to append remaining bytes to the remote file.

Code for Resuming Upload

public static void resumeUpload(ChannelSftp sftpChannel, String localFile, String remoteFile) throws SftpException, IOException {
    File file = new File(localFile);
    long remoteFileSize = 0;

    try {
        remoteFileSize = sftpChannel.lstat(remoteFile).getSize(); // Check remote file size
    } catch (SftpException e) {
        System.out.println("Remote file does not exist. Starting upload from the beginning.");
    }

    System.out.println("Resuming upload from byte: " + remoteFileSize);

    try (InputStream inputStream = new FileInputStream(file)) {
        inputStream.skip(remoteFileSize); // Skip already uploaded bytes

        // Append mode upload
        sftpChannel.put(inputStream, remoteFile, ChannelSftp.APPEND);
        System.out.println("Resume upload completed.");
    }
}

Explanation of Key Steps

  1. Session Setup:
    • A secure session is established with the SFTP server using user credentials.
    • StrictHostKeyChecking is disabled for simplicity, but proper key validation is recommended for production.
  2. Resume Logic:
    • Download: The remote file is read as an InputStream, skipping already downloaded bytes. The local file is opened in append mode.
    • Upload: The local file is read as an InputStream, skipping already uploaded bytes, and the put method with ChannelSftp.APPEND is used to continue the upload.
  3. Error Handling:
    • If the remote file or local file does not exist, appropriate error handling ensures either the upload/download starts from the beginning or exits gracefully.
  4. File Integrity: To ensure file integrity, consider validating the file with hash checks or checksums after transfer.

Notes

  • Increase the buffer size (byte[] buffer = new byte[1024]) for better performance for larger files.
  • Consider implementing retries or reconnect logic if the SFTP session disconnects during a transfer.
  • Always confirm proper permissions for writing to the destination and reading from the source.

Conclusion

The above solution demonstrates how to implement resumable file transfer via SFTP using JSch. It ensures efficient and reliable file transfers by avoiding redundant retransmission of already transferred data.

Maven Dependencies

<dependency>
    <groupId>com.jcraft</groupId>
    <artifactId>jsch</artifactId>
    <version>0.1.55</version>
</dependency>

Maven Central

How do I secure API requests with OAuth2 using Java 11 HttpClient?

By I Wayan Saryada in HttpClient, Java 11 0 Comment

Securing API requests with OAuth2 using Java 11’s HttpClient involves obtaining an access token from the OAuth2 provider and including it in the header of your HTTP requests. Here’s a step-by-step guide:

1. Understand OAuth2 Flow

OAuth2 involves several flows (e.g., Authorization Code, Client Credentials, etc.). For simplicity, we’ll focus on the Client Credentials Grant flow where your application (client) authenticates with the OAuth2 provider and retrieves an access token for API calls.

2. Dependencies

You don’t need external dependencies unless you choose to use a library (like Spring Security). Java 11’s HttpClient can directly process token requests.

3. Steps to Secure API Requests

Obtain Access Token

To obtain an access token, make a POST request to the OAuth2 token endpoint with the required parameters:

  • client_id: Your application’s client ID.
  • client_secret: Your application’s secret key.
  • grant_type: For example, client_credentials.

Use the Access Token in API Requests

Once you have the access token, include it in the Authorization header of your requests.

4. Sample Code

Here’s an example of how to secure API requests with OAuth2 using Java 11’s HttpClient:

package org.kodejava.net.http;

import java.net.URI;
import java.net.http.HttpClient;
import java.net.http.HttpRequest;
import java.net.http.HttpResponse;
import java.net.URLEncoder;
import java.nio.charset.StandardCharsets;

public class OAuth2HttpClient {

   public static void main(String[] args) throws Exception {
      // OAuth2 Token Endpoint and Client Details
      String tokenEndpoint = "https://your-oauth2-provider.com/token";
      String clientId = "your-client-id";
      String clientSecret = "your-client-secret";
      String scope = "your-api-scope";

      // Step 1: Obtain Access Token
      String accessToken = getAccessToken(tokenEndpoint, clientId, clientSecret, scope);

      // Step 2: Use Access Token for API Request
      String apiEndpoint = "https://api.example.com/secure-resource";
      sendSecureApiRequest(apiEndpoint, accessToken);
   }

   private static String getAccessToken(String tokenEndpoint, String clientId, String clientSecret, String scope) throws Exception {
      // Create request body
      String requestBody = "grant_type=client_credentials" +
                           "&client_id=" + URLEncoder.encode(clientId, StandardCharsets.UTF_8) +
                           "&client_secret=" + URLEncoder.encode(clientSecret, StandardCharsets.UTF_8) +
                           "&scope=" + URLEncoder.encode(scope, StandardCharsets.UTF_8);

      // Create HttpClient and HttpRequest
      HttpClient client = HttpClient.newHttpClient();
      HttpRequest request = HttpRequest.newBuilder()
              .uri(URI.create(tokenEndpoint))
              .header("Content-Type", "application/x-www-form-urlencoded")
              .POST(HttpRequest.BodyPublishers.ofString(requestBody))
              .build();

      // Send request and parse response
      HttpResponse<String> response = client.send(request, HttpResponse.BodyHandlers.ofString());
      if (response.statusCode() == 200) {
         // Extract access token from JSON response
         String responseBody = response.body();
         return extractAccessToken(responseBody);
      } else {
         throw new RuntimeException("Failed to get access token. Status: " + response.statusCode() + ", Body: " + response.body());
      }
   }

   private static String extractAccessToken(String responseBody) {
      // Parse JSON response to extract the "access_token" (you can use a library like Jackson or Gson)
      // For simplicity, assume the response contains: {"access_token":"your-token"}
      int startIndex = responseBody.indexOf("\"access_token\":\"") + 16;
      int endIndex = responseBody.indexOf("\"", startIndex);
      return responseBody.substring(startIndex, endIndex);
   }

   private static void sendSecureApiRequest(String apiEndpoint, String accessToken) throws Exception {
      // Create HttpClient and HttpRequest
      HttpClient client = HttpClient.newHttpClient();
      HttpRequest request = HttpRequest.newBuilder()
              .uri(URI.create(apiEndpoint))
              .header("Authorization", "Bearer " + accessToken)
              .GET()
              .build();

      // Send request and print response
      HttpResponse<String> response = client.send(request, HttpResponse.BodyHandlers.ofString());
      System.out.println("API Response Status: " + response.statusCode());
      System.out.println("API Response Body: " + response.body());
   }
}

5. Explanation

  1. Obtaining Access Token:
    • A POST request is sent to the token endpoint with appropriate parameters in the body.
    • The response typically returns an access token in JSON format.
  2. Secure API Request:
    • Include the token in the Authorization header as Bearer <token> in subsequent requests to the secured API.
  3. Error Handling:
    • If the token request or API request fails, handle the error gracefully (e.g., retry or log).

6. Security Tip

  • Never hardcode client_id or client_secret in your code. Store them securely (e.g., environment variables or a secrets manager).
  • If you handle sensitive data, ensure your OAuth2 provider supports HTTPS.

How do I log request and response details using Java 11 HttpClient?

By I Wayan Saryada in HttpClient, Java 11 0 Comment

If you are using Java 11’s HttpClient and want to log request and response details, you can achieve this by implementing a custom utility. Java 11’s HttpClient provides flexibility to log and inspect both requests and responses using its APIs. Here’s how you can log them:

Full Implementation for Logging Request and Response

Below is an example that demonstrates logging details such as HTTP headers, request body, response status, response headers, and response body.

package org.kodejava.net.http;

import java.net.URI;
import java.net.http.HttpClient;
import java.net.http.HttpRequest;
import java.net.http.HttpResponse;
import java.time.Duration;

public class HttpClientLogger {

   public static void main(String[] args) {
      try {
         // Create a sample HTTP GET request
         HttpClient httpClient = HttpClient.newHttpClient();

         HttpRequest request = HttpRequest.newBuilder()
                 .uri(URI.create("https://jsonplaceholder.typicode.com/posts/1"))
                 .GET()
                 .header("Accept", "application/json")
                 .timeout(Duration.ofSeconds(10))
                 .build();

         // Log Request Details
         logRequestDetails(request);

         // Send the request and receive a response
         HttpResponse<String> response = httpClient.send(request,
                 HttpResponse.BodyHandlers.ofString());

         // Log Response Details
         logResponseDetails(response);

      } catch (Exception e) {
         e.printStackTrace();
      }
   }

   private static void logRequestDetails(HttpRequest request) {
      System.out.println("---- HTTP Request Details ----");
      System.out.println("Method: " + request.method());
      System.out.println("URI: " + request.uri());
      System.out.println("Headers: " + request.headers().map());
      request.bodyPublisher().ifPresentOrElse(
              bodyPublisher -> {
                 System.out.println("Request Body: (BodyPublisher details not directly accessible, consider passing it explicitly)");
              },
              () -> System.out.println("Request Body: No body")
      );
      System.out.println("-------------------------------");
   }

   private static void logResponseDetails(HttpResponse<String> response) {
      System.out.println("---- HTTP Response Details ----");
      System.out.println("Status Code: " + response.statusCode());
      System.out.println("Headers: " + response.headers().map());
      System.out.println("Body: " + response.body());
      System.out.println("--------------------------------");
   }
}

Explanation of the Code

  1. Setting up HttpClient:
    • We create a HttpClient instance using HttpClient.newHttpClient().
  2. Building the HttpRequest:
    • Use the HttpRequest.Builder to construct the request. This includes setting the URI, method, headers, and a timeout.
  3. Logging HTTP Request Details:
    • Log details of the request by accessing:
      • HTTP Method: HttpRequest::method
      • URI: HttpRequest::uri
      • Headers: HttpRequest::headers
      • The request body can be logged if you manually supply it during the request creation since BodyPublisher doesn’t provide a content preview.
  4. Sending the Request:
    • Use HttpClient::send to perform the HTTP operation, and specify HttpResponse.BodyHandlers.ofString() to read the response as a string.
  5. Logging HTTP Response Details:
    • Log response information:
      • Status Code: HttpResponse::statusCode
      • Headers: HttpResponse::headers
      • Body: HttpResponse::body

Notes

  1. POST/PUT Requests with a Body:
    • If you are sending POST or PUT requests that include a body (e.g., JSON or a form), you should explicitly log the body content when building the request. Example: 
      HttpRequest request = HttpRequest.newBuilder()
      .uri(URI.create("https://jsonplaceholder.typicode.com/posts"))
      .POST(HttpRequest.BodyPublishers.ofString("{\"key\":\"value\"}"))
      .header("Content-Type", "application/json")
      .build();

      To log the request body, simply store it in a separate variable and print it in logRequestDetails.

  2. Production Logging:

    • Avoid directly printing details to the console in production.
    • Use proper logging libraries like SLF4J with an implementation (e.g., Logback or Log4j) to write logs at different levels like DEBUG, INFO, ERROR, etc.
  3. Sensitive Data:
    • Avoid logging sensitive details like authentication headers or personal data (e.g., Authorization tokens, passwords).

This approach provides a reusable template for logging HTTP requests and responses while using the Java 11+ HttpClient.