How does FlexyPool support both Connection proxies and decorators

Proxies

FlexyPool monitors connection pool usage and so it needs to intercept the connection close method call.
For simplicity sake, the first version was relying on dynamic proxies for this purpose:

private static class ConnectionInvocationHandler 
    implements InvocationHandler {

    public static final String CLOSE_METHOD_NAME = "close";

    private final Connection target;
    private final ConnectionCallback callback;

    public ConnectionInvocationHandler(
        Connection target, 
        ConnectionCallback callback) {
        this.target = target;
        this.callback = callback;
    }

    @Override
    public Object invoke(
        Object proxy, 
        Method method, 
        Object[] args) throws Throwable {
        if (CLOSE_METHOD_NAME.equals(method.getName())) {
            callback.close();
        }
        return method.invoke(target, args);
    }
}

As straightforward as it may be, a proxy invocation is slower than a decorator, which calls the target method using a direct invocation.
Because all connection pools use proxies anyway, adding another proxy layer only adds more call-time overhead and so now FlexyPool supports connection decorators as well.

Continue reading “How does FlexyPool support both Connection proxies and decorators”

Advertisements

How does FlexyPool support the Dropwizard Metrics package renaming

Introduction

FlexyPool relies heavily on Dropwizard (previously Codahale) Metrics for monitoring the connection pool usage. Being integrated into Dropwizard, the package name was bound to be renamed.

So instead of com.codahale.metrics the 4.0.0 release will use the io.dropwizard.metrics package name.

Continue reading “How does FlexyPool support the Dropwizard Metrics package renaming”

How to monitor a Java EE DataSource

Introduction

FlexyPool is an open-source framework that can monitor a DataSource connection usage. This tool come out of necessity, since we previously lacked support for provisioning connection pools.

FlexyPool was initially designed for stand-alone environments and the DataSource proxy configuration was done programmatically. Using Spring bean aliases, we could even substitute an already configured DataSource with the FlexyPool Metrics-aware proxy alternative.

Continue reading “How to monitor a Java EE DataSource”

Professional connection pool sizing with FlexyPool

Introduction

I previously wrote about the benefits of connection pooling and why monitoring it is of crucial importance. This post will demonstrate how FlexyPool can assist you in finding the right size for your connection pools.

Know your connection pool

The first step is to know your connection pool settings. My current application uses XA transactions, therefore we use Bitronix transaction manager, which comes with its own connection pooling solution.

Accord to the Bitronix connection pool documentation we need to use the following settings:

  • minPoolSize: the initial connection pool size
  • maxPoolSize: the maximum size the connection pool can grow to
  • maxIdleTime: the maximum time a connection can remain idle before being destroyed
  • acquisitionTimeout: the maximum time a connection request can wait before throwing a timeout. The default value of 30s is way too much for our QoS

Continue reading “Professional connection pool sizing with FlexyPool”

FlexyPool, reactive connection pooling

Introduction

When I started working on enterprise projects we were using J2EE and the pooling data source was provided by the application server.

EnterpriseApplicationServer

Scaling up meant buying more powerful hardware to support the increasing request demand. The vertical scaling meant that for supporting more requests, we would have to increase the connection pool size accordingly.

Horizontal scaling

Our recent architectures shifted from scaling up to scaling out. So instead of having one big machine hosting all our enterprise services, we now have a distributed service network.

EnterpriseArchitecture

This has numerous advantages:

  • Each JVM is tuned according to the hosted service intrinsic behaviour. Web nodes employ the concurrent low pause collector, while batch services use the throughput collector
  • Deploying a batch service doesn’t affect the front services
  • If one service goes down it won’t affect the rest

Continue reading “FlexyPool, reactive connection pooling”