Introduction to Amazon Code Pipeline with Java part 19: the job worker initialisation and the job poller interface


In the previous post we first discussed the idea of a daemon thread. A daemon thread is most often used to initiate a long running task on its own thread so that the main executing thread is not blocked. A daemon thread is a good candidate to execute the Code Pipeline monitoring task. It will run in the background after executing the servlet initiator class which in turn is run automatically upon application start-up. We also saw how the daemon thread is started in code. However, we still know very little about the class that implements the daemon thread.

We’ll dive into that in this post.

Job worker daemon

Recall the following bit of code from the web context initialiser:

Daemon jobAgentDaemon = new JobWorkerDaemon(Executors.newScheduledThreadPool(1),
                            properties, new CentralLogger(properties), 
                            new LtpApiClientTokenProvider(codePipelineService), jobProcessor);

The Daemon interface comes from the org.apache.commons.daemon package and represents a daemon thread. It has 4 methods related to thread handling: init, start, stop and destroy that are all called at the corresponding stages in the thread lifetime. In our case it is implemented by the JobWorkerDaemon class. Here’s the constructor and the private fields:

public class JobWorkerDaemon implements Daemon

    private final ScheduledExecutorService executorService;
    private List<JobPoller> jobPollers;
    private final Properties properties;
    private long pollingIntervalInMs;
    private final LoggerService logger;
    private final ClientTokenProvider clientTokenProvider;
    private final JobProcessor jobProcessor;
    public JobWorkerDaemon(final ScheduledExecutorService executorService,
            final Properties properties, final LoggerService logger, 
            final ClientTokenProvider clientTokenProvider, JobProcessor jobProcessor)
        this.executorService = executorService;
        this.logger = logger; = properties;
        this.clientTokenProvider = clientTokenProvider;
        this.jobProcessor = jobProcessor;

We mentioned the object dependencies in the previous post so we won’t do that again. The private fields hold a reference to these dependencies. The JobPoller class is a new concept though and we’ll come back to it in a short time. Let’s instead look at the initConfiguration method as it has a couple of important actions:

private void initConfiguration(final Properties properties)
        long pollIntervalMillis = Long.parseLong(properties.getProperty(ConfigKeys.POLL_INTERVAL_MILLIS_KEY, "30000"));
        String delimitedCodePipelineEndpoints = properties.getProperty(ConfigKeys.CODE_PIPELINE_ENDPOINTS_KEY, "");
        JobWorkerConfiguration jobWorkerConfiguration = 
                new ApicaLoadtestJobWorkerConfiguration(properties, delimitedCodePipelineEndpoints, 
                        this.logger, this.clientTokenProvider, this.jobProcessor);
        this.jobPollers = jobWorkerConfiguration.jobPollers(this.logger);
        this.pollingIntervalInMs = pollIntervalMillis;

The ConfigKeys class holds the keys of the configuration key-value pairs, here’s a short excerpt:

public class ConfigKeys
    public static final String POLL_INTERVAL_MILLIS_KEY = "pollIntervalMillis";
    public static final String WORKER_THREADS_KEY = "workerThreads";
    public static final String POLL_BATCH_SIZE_KEY = "pollBatchSize";
    public static final String CODE_PIPELINE_ENDPOINTS_KEY = "codePipelineEndpoints";    

The properties file follows the generic Java properties file format, here’s an example:


The first line in the initConfiguration function is therefore easy: we try to read the property value with the key name pollIntervalMillis. If it’s present then we assign its value to the variable pollIntervalMillis, otherwise assign the default 10 seconds. This is the interval with which we’re monitoring the Code Pipeline endpoint. The endpoint, or endpoints to be monitored is stored in the property called “codePipelineEndpoints”. It is possible and feasible that a single CP agent instance will monitor more than one CP endpoint. We actually don’t have that case in our solution, so at present this is just a placeholder in case we ever need it.

JobWorkerConfiguration is an interface for the worker configuration and has two methods:

package com.apica.awscodepipelinebuildrunner.configuration;

import com.apica.awscodepipelinebuildrunner.JobPoller;
import java.util.List;
import com.apica.awscodepipelinebuildrunner.logging.LoggerService;

public interface JobWorkerConfiguration
    public List<JobPoller> jobPollers(LoggerService logger);
    public long getPollingIntervalInMs();

The JobWorkerConfiguration implementation, i.e. in turn leads to a number of other new classes so let’s not go there yet otherwise we’re risking to get lost. Instead we’ll finish looking at the initConfiguration method.

After declaring the ApicaLoadtestJobWorkerConfiguration class we let it return the list of job pollers and also store the monitoring interval in a private field.

We can now turn our attention to the JobPoller. It is actually a very simple interface:

package com.apica.awscodepipelinebuildrunner;

public interface JobPoller
    void execute();

The execute method is invoked in a regular polling interval by the daemon, where the interval is 10 seconds in our example. It polls for jobs, acknowledges them and reports back the status. The function implementation will have a lot to go through which is best to discuss in a dedicated post later on.

The next post in this series will concentrate on the ApicaLoadtestJobWorkerConfiguration class.

View all posts related to Amazon Web Services and Big Data here.


About Andras Nemes
I'm a .NET/Java developer living and working in Stockholm, Sweden.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


A great site

iReadable { }

.NET Tips & Tricks

Robin Sedlaczek's Blog

Developer on Microsoft Technologies

HarsH ReaLiTy

A Good Blog is Hard to Find

Softwarearchitektur in der Praxis

Wissenswertes zu Webentwicklung, Domain-Driven Design und Microservices

the software architecture

thoughts, ideas, diagrams,enterprise code, design pattern , solution designs

Technology Talks

on Microsoft technologies, Web, Android and others

Software Engineering

Web development

Disparate Opinions

Various tidbits

chsakell's Blog

Anything around ASP.NET MVC,WEB API, WCF, Entity Framework & AngularJS

Cyber Matters

Bite-size insight on Cyber Security for the not too technical.

Guru N Guns's

OneSolution To dOTnET.

Johnny Zraiby

Measuring programming progress by lines of code is like measuring aircraft building progress by weight.

%d bloggers like this: