Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

The State of Bootique, Early 2018  ( Part 2)

DZone's Guide to

The State of Bootique, Early 2018  ( Part 2)

As we continue our journey into the state of Bootique, let's see the changes coming to health checks, metrics, and new support for JDBC.

· Java Zone ·
Free Resource

Verify, standardize, and correct the Big 4 + more– name, email, phone and global addresses – try our Data Quality APIs now at Melissa Developer Portal!

Let’s continue on the “state of Bootique” story started here. We discussed the core already. In this installment, I’ll cover changes across various standard modules.

Health Checks, Metrics and Transaction Ids

The application health and statistics monitoring API (bootique-metrics) is finally getting some love. It started as a basic integration of Dropwizard metrics. It is now evolving into a framework in its own right. As of 0.25, we are still somewhat in the middle of the road, and there will be significant updates in the future releases. But let’s go through what we have so far.

There is support for parallel execution of multiple health checks. Which is handy as, by their nature, health checks may get stuck if the system being checked is unresponsive. Now you can run each check in parallel threads and optionally limit the total execution time with a timeout:

@Inject
HealthCheckRegistry registry;
ExecutorService pool = Executors.newCachedThreadPool();
Map<String, HealthCheckOutcome> result = 
   registry.runHealthChecks(pool, 5, TimeUnit.SECONDS);


There’s also a new “heartbeat” API that runs periodic health checks for you based on the above approach, freeing you from dealing with thread pools and scheduling. Application heartbeat is configured via YAML with scheduling parameters and an optional health checks list (if no explicit health checks are specified, all available checks will be executed):

heartbeat:
  initialDelayMs: 3
  fixedDelayMs: 100
  threadPoolSize: 2
  healthCheckTimeoutMs: 2000
  healthChecks:
     - hc1
     - hc2


To enable application heartbeat, the app needs to be started with a HeartbeatCommand . But heartbeat is only an auxiliary function (the app is run to perform some useful task, not just to send its heartbeat), so HeartbeatCommand  is usually not invoked directly, but is rather activated as a decorator of another command (command decorators were discussed in the first part of this blog). E.g.:

CommandDecorator heartbeat =    
   CommandDecorator.alsoRun(HeartbeatCommand.class);
BQCoreModule.extend(binder)
   .decorateCommand(ServerCommand.class, heartbeat);


Once the app heartbeat is configured and enabled, we still need to capture the results. For this you can register a custom listener to log the results or send them to a monitoring system, etc.:

HealthCheckModule.extend(binder)
   .addHeartbeatListener(MyHeartbeatProcessor.class);


Another piece of health check puzzle, HealthCheckOutcome, is no longer just a boolean (“passed” or “failed”). It can report more fine-grained statuses, namely OK, WARNING, CRITICAL, UNKNOWN, mirroring how status reporting is done in Nagios. This way it allows to detect problematic situations before the hard failures occur. Will be taking full advantage of theses new statuses in the next release of Bootique, allowing apps to define warning and critical thresholds for various metrics, and then running a generic health check comparing a value of a given metric with those thresholds. This code is already available on master.

The next feature, “business transaction id”, is not about health checks or metrics at all, but instead helps to tie together various related execution pieces when investigating application problems. E.g. to diagnose an issue in a web application it is useful to look at all SQL queries, service logs and metrics separately for each web request. To that end “instrumented” versions of bootique-jetty   and  bootique-job  would now automatically generate a distinct “transaction id” for each request or job execution and store it in the SLF4J MDC context. If you are using  bootique-logback , it can be logged with a format like this:

log:
  logFormat: '%X{txid:-?}: %m%n%ex'


 %X{txid:-?}  is the piece that will output transaction id in the log.

If this is not enough and you decide to generate ids on your own, an injectable  TransactionIdGenerator  can be used for that purpose, while injectable TransactionIdMDC  can will bind them to the SLF4J MDC. The generator does not attempt to be truly random, or even fully unique (though the number of possible combinations is large enough, so this is not a practical concern). Transaction id purpose is to provide simple labeling of related logs. So the algorithm focuses on id generation speed instead of randomness or uniqueness.

JDBC

Until now, the only database connection pool provider in Bootique was Tomcat (which is a great production-quality pool). Now we’ve also added another high-performance implementation —  HikariCP. It is your choice now which one to use. For Tomcat you’d add the following dependency:

<dependency>
    <groupId>io.bootique.jdbc</groupId>
    <artifactId>bootique-jdbc-tomcat</artifactId>
    <scope>compile</scope>
</dependency>


And for Hikari:

<dependency>
    <groupId>io.bootique.jdbc</groupId>
    <artifactId>bootique-jdbc-hikaricp</artifactId>
    <scope>compile</scope>
</dependency>


JDBC integration test API has matured significantly, with many more options to manage datasets and many more value types supported. To give a taste of how this works, here is a simple database test:

Table t1 = dataManager.getTable(Table1.class);
t1.matcher().assertNoMatches();
t1.insert(1, 2, 3);
t1.matcher().assertOneMatch();


HTTP Client

 bootique-jersey-client  (Bootique HTTP client) module previously only allowed to configure “clients”, leaving the actual endpoint creation up to the application code. Now it allows to declare named HTTP “targets” (i.e. external service URLs) in the app configuration with parameters like authentication, TLS truststore, etc. Externalizing HTTP targets into the Bootique config layer is extremely useful, as it allows switching the URLs without rebuilding the app. Here is an example:

jerseyclient:
  auth:
    myauth:
      type: oauth2
      ...
  targets:
    mytarget:
      url: "https://example.org"
      auth: myauth


Now in Java you can inject HttpTargets , find preconfigured “mytarget” and call HTTP methods on it:

@Inject
HttpTargets targets;
Response r1 = targets.newTarget("mytarget").request().get();


Not coincidentally the YAML example above includes “oauth2” authenticator. While it was available in the previous releases, now it is actually production-quality, supporting token refresh, etc.

This covers the main highlights of the last few releases of Bootique.io. Stay tuned for the upcoming 1.0 release of the framework and the modules!

Developers! Quickly and easily gain access to the tools and information you need! Explore, test and combine our data quality APIs at Melissa Developer Portal – home to tools that save time and boost revenue. Our APIs verify, standardize, and correct the Big 4 + more – name, email, phone and global addresses – to ensure accurate delivery, prevent blacklisting and identify risks in real-time.

Topics:
java ,bootique ,open source ,metrics

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}