Forem: Siben Nayak

Garbage Collection in Java - What is GC and How it Works in the JVM

Siben Nayak — Sat, 23 Jan 2021 16:29:38 +0000

Garbage Collection is the process of reclaiming the runtime unused memory by destroying the unused objects.

In languages like C and C++, the programmer is responsible for both the creation and destruction of objects. Sometimes, the programmer may forget to destroy useless objects, and the memory allocated to them is not released. The used memory of the system keeps on growing and eventually there is no memory left in the system to allocate. Such applications suffer from “memory leaks”.

Java Garbage Collection is the process by which Java programs perform automatic memory management. Java programs compile into bytecode that can be run on a Java Virtual Machine (JVM).

Garbage collection makes Java memory-efficient because it removes the unreferenced objects from heap memory and makes free space for new objects.

The Java Virtual Machine has many types of garbage collectors.

In these videos, I’ve discussed the Garbage Collection in Java, how it works, and the various types of collectors available.

Please subscribe to the channel and like the video if you find it helpful.

JVM Tutorial - Java Virtual Machine Architecture Explained for Beginners

Siben Nayak — Sun, 17 Jan 2021 18:08:41 +0000

Whether you have used Java to develop programs or not, you might have heard about the Java Virtual Machine (JVM) at some point or another.

JVM is the core of the Java ecosystem, and makes it possible for Java-based software programs to follow the “write once, run anywhere” approach. You can write Java code on one machine, and run it on any other machine using the JVM.

JVM was initially designed to support only Java. However, over time, many other languages such as Scala, Kotlin, and Groovy were adopted on the Java platform. All of these languages are collectively known as JVM languages.

In this video, I’ve discussed the JVM, how it works, and the various components that it is made of. Please subscribe to the channel and like the video if you find it helpful.

How to Build a Serverless Application Using AWS Chalice

Siben Nayak — Tue, 20 Oct 2020 18:27:32 +0000

I recently came across AWS Chalice and was fascinated by the simplicity and usability it offers.

AWS Chalice is a serverless framework that allows you to build serverless applications using Python, and deploy them on AWS using Amazon API Gateway and AWS Lambda.

I decided to play around with it and was actually able to create and deploy a sample REST API on AWS within a few minutes.

In this article, I will walk you through the steps required to build and deploy a serverless application that gets the latest news from Google News using Chalice.

Prerequisites

This tutorial requires an AWS account. If you don’t have one already, go ahead and create one. Our application is going to use only the free-tier resources, so cost shouldn’t be an issue.

You also need to configure security and create users and roles for your access.

How to Configure AWS Credentials

Chalice uses the AWS Command Line Interface (CLI) behind the scenes to deploy the project. If you haven’t used AWS's CLI before to work with AWS resources, you can install it by following the guidelines here.

Once installed, you need to configure your AWS CLI to use the credentials from your AWS account.

$ aws configure                       
AWS Access Key ID [****************OI3G]:
AWS Secret Access Key [****************weRu]:
Default region name [us-west-2]:
Default output format [None]:

How to Install Chalice

Next, you need to install Chalice. We will be using Python 3 in this tutorial, but you can use any version of Python supported by AWS Lambda.

Verify Python Installation

$ python3 --version
Python 3.8.6

Install Chalice

$ python3 -m pip install chalice

Verify Chalice Installation

$ chalice --version
chalice 1.20.0, python 3.8.6, darwin 19.6.0

How to Create a Project

Next, run the chalice new-project command to create a new project.

$ chalice new-project daily-news

This will create a daily-news folder in your current directory. You can see that Chalice has created several files in this folder. We'll be working with the app.py and requirements.txt files only in this article.

Let’s take a look at the contents of app.py file:

The new-project command created a sample app daily-news. It defines a single view /, that returns the JSON body {"hello": "world"} when called. You can now modify this template and add more code to read news from Google.

We will be using Google’s RSS feed to get our news. Since RSS feeds consist of data in XML format, we will need a Python library called Beautiful Soup for parsing the XML data.

You can install Beautiful Soup and its XML parsing library using pip, like this:

$ python3 -m pip install bs4
$ python3 -m pip install lxml

Next add the following imports to app.py. This essentially adds imports from urllib to make HTTP calls and bs4 to parse XML.

Next, you need to add a method to fetch the RSS feed from Google. We will use urllib to make an HTTP call to Google's RSS endpoint and get the response. You can then parse the response to extract the news title and publication date, and create a list of news items.

To do this, add the following code to your app.py:

Update the index method in app.py to invoke this method and return the list of news items as a result.

Note that you installed a few dependencies to make the code work. These dependencies were installed locally, and will not be available to the AWS Lambda container at runtime.

To make them available to AWS Lambda, you will need to package them along with your code.

To do that, add the following to the requirements.txt file. Chalice packs these dependencies as part of your code during build and uploads them as part of the Lambda function.

How to Deploy the Project

Let’s deploy this app. From the daily-news folder, run the chalice deploy command.

This deploys your API on Amazon API Gateway and creates a new function on AWS Lambda.

Let's try accessing the API now. You can use curl to invoke the API Gateway URL that you received during chalice deploy. The response of the API call would return a list of news items as shown below.

How to Clean Up Resources

You can also use the chalice delete command to delete all the resources created when you ran the chalice deploy command.

Conclusion

Congratulations! You just deployed a serverless application on AWS using Chalice. It wasn’t too hard, was it?

You can now go ahead and make any modifications to your app.py file and rerun chalice deploy to redeploy your changes.

You can also use Chalice to integrate your serverless app with Amazon S3, Amazon SNS, Amazon SQS, and other AWS services. Take a look at the tutorials and keep exploring. The full source code for this tutorial can be found here.

Thank you for staying with me so far. Hope you liked the article. You can connect with me on LinkedIn where I regularly discuss technology and life. Also take a look at some of my other articles on Medium. Happy reading 🙂

Microservice Observability - Metrics

Siben Nayak — Sat, 03 Oct 2020 16:29:00 +0000

In my previous article, I talked about the importance of logs and the differences between structured and unstructured logging. Logs are easy to integrate in your application and provide the ability to represent any type of data in the form of strings.

Metrics, on the other hand, are a numerical representation of data. These are often used to count or measure a value, and are aggregated over a period of time. Metrics give us insights about the historical and current state of a system. Since they are just numbers, they can also be used to perform statistical analysis and predictions about the system behaviour in future. Metrics are also used to trigger alerts and notify about issues in system behaviour.

Logs vs Metrics

Format

Logs are represented as strings. They can be simple texts, JSON payloads, or key value pairs (like we discussed in structured logging).

Metrics are represented as numbers. They measure something (like CPU usage, number of errors, etc.) and are numeric in nature.

Resolution

Logs contain high-resolution data. This includes complete information about an event, and can be used to correlate the flow (or path) that the event took through the system. In case of errors, logs contain the entire stack trace of the exception, which allows us to view and debug issues originating from downstream systems as well. In short, logs can tell you what happened in the system at a certain time.

Metrics contain low-resolution data. This may include count of parameters (such as requests, errors, etc.) and measures of resources (such as CPU and memory utilization). In short, metrics can give you a count of something that happened in the system at a certain time.

Cost

Logs are expensive to store. The storage overhead of logs also increases over time and is directly proportional to the increase in traffic.

Metrics have a constant storage overhead. The cost of storage and retrieval of metrics does not increase too much with increase in traffic. It is however, dependent on the number of variables we emit with each metric.

Cardinality

Metrics are identified by two key pieces of information:

A metric name
A set of key value pairs called tags or labels

A permutation of these values provides the metric its cardinality. For e.g. if we are measuring the CPU Utilization of a system with 3 hosts, the metric has a cardinality value of 3, and can have the following 3 values:

(name=pod.cpu.utilization, host=A)
(name=pod.cpu.utilization, host=B)
(name=pod.cpu.utilization, host=C)

Similarly, if we introduced another tag in the metric which determined the AWS region of the hosts (say us-west-1 and us-west-2), we will now have a metric with a cardinality value of 6.

Types of Metrics

Golden Signals

Golden signals are an effective way of monitoring the overall state of the system and identify problems.

Availability: state of your system measured from the perspective of clients, for e.g. percentage of errors on total requests
Health: state of your system measured using periodic pings
Request Rate: the rate of incoming requests to the system.
Saturation: how free or loaded is the system. For e.g. queue depth or available memory.
Utilization: how busy is the system. For e.g. CPU load or memory usage. This is represented in percentage.
Error Rate: the rate of errors being produced in the system.
Latency: the response time of the system, usually measured in the 95th or 99th percentile.

Resource Metrics

Resource metrics are almost always made available by default from the infrastructure provider (AWS CloudWatch or Kubernetes metrics) and are used to monitor infrastructure health.

CPU/Memory Utilization: usage of core resources of the system
Host Count: number of hosts/pods that are running your system (used to detect availability issues due to pod crashes)
Live Threads: threads spawned your service (used to detect issues in multi-threading)
Heap Usage: heap memory usage statistics (can help debug memory leaks)

Business Metrics

Business metrics can be used to monitor granular interaction with core APIs or functionality in your services.

Request Rate: rate of requests to the APIs
Error Rate: rate of errors being thrown by the APIs
Latency: time taken to process requests by the APIs

Dashboards and Alerts

Since metrics are stored in a time-series database, it’s more efficient and reliable to run queries against them for measuring the state of the system.

These queries can be used to build dashboards for representing the historical state of the system.

They can also be used to trigger alerts when there is an issue with the system, for e.g. an increase in number of errors observed, or a sudden spike in CPU utilization.

Due to their numeric nature, we can also create complex mathematical queries (such as X% of errors in last Y minutes) to monitor system health.

Conclusion

In this article, we saw the differences between metrics and logs, and how metrics can help us monitor the health of our system more efficiently. Metrics can also be used to create dashboards and alerts using monitoring software like Wavefront and Grafana.

The biggest challenge, however, in handling metrics is deciding the right amount of cardinality that makes the metric useful, while also keeping its costs in control. It is necessary to use both metrics and logs in coordination to accurately detect and debug issues.

Note

This is the second part of my Microservice Observability Series. The first part has been posted here. I’ll be adding links to the next articles when they go live. Stay tuned!!

Microservice Observability - Logs

Siben Nayak — Sun, 27 Sep 2020 06:27:14 +0000

Logs are one of the most important parts of software systems. Whether you have just started working on a new piece of software, or your system is running in a large scale production environment, you'll always find yourself seeking help from log files. Logs are the first thing developers look for when something goes wrong, or something doesn't work as expected.

Logging the right information in the right way makes the life of developers so much easier. Two things that developers need to be aware of to get better at logging are what and how to log. In this article, we'll take a look at the some of the basic logging etiquettes that can get us the best out of our logs.

The What and How of Logging

Let's take the example of an e-commerce system and take a look at logging in Order Management Service (OMS).

Suppose a customer order fails due to an error from Inventory Management Service (IMS), a downstream service that OMS uses to verify the available inventory.

Let's assume that OMS has already accepted an order, but during the final verification step, IMS returns the following error because the product is no longer available in the inventory.

404 Product Not Available

What to Log

Normally, you would log the error in this way

log.error("Exception in fetching product information - {}", ex.getResponseBodyAsString())

This will output a log in the following format

[2020-09-27T18:54:41,500+0530]-[ERROR]-[InventoryValidator]-[13] Exception in fetching product information - Product Not Available

Well, there isn't much information available in this log statement, is it? A log like this doesn't serve much purpose because it lacks any contextual information about about the error.

Can we add more information to this log to make it more relevant for debugging? How about adding the Order Id and Product Id?

log.error("Exception in processing Order #{} for Product #{} due to exception - {}", orderId, productId, ex.getResponseBodyAsString())

This will output a log in the following format

[2020-09-27T18:54:41,500+0530]-[ERROR]-[InventoryValidator]-[13] Exception in processing Order #182726 for Product #21 due to exception - Product Not Available

Now this makes a lot of sense!! Looking at the logs, we can understand that an error occurred while processing Order #182726 because Product #21 was not available.

How to Log

While the above log makes perfect sense for us humans, it may not be the the best format for machines. Let's take an example to understand why.

Suppose there is some issue in the availability of a certain product (say Product #21) due to which all orders containing that product are failing. You have been assigned the task to find all the failed orders for this product.

You happily do a grep for Product #21 in your logs and excitedly wait for the results. When the search completes, you get something like this

[2020-09-27T18:54:41,500+0530]-[ERROR]-[InventoryValidator]-[13] Exception in processing Order #182726 for Product #21 due to exception - Product Not Available
[2020-09-27T18:53:29,500+0530]-[ERROR]-[InventoryValidator]-[13] Exception in processing Order #972526 for Product #217 due to exception - Product Not Available
[2020-09-27T18:52:34,500+0530]-[ERROR]-[InventoryValidator]-[13] Exception in processing Order #46675754 for Product #21 due to exception - Product Not Available
[2020-09-27T18:52:13,500+0530]-[ERROR]-[InventoryValidator]-[13] Exception in processing Order #332254 for Product #2109 due to exception - Product Not Available

Not quite something that we were expecting right? So how can we improve this? Structured logging to the rescue.

Structured Logging

Structured logging solves these common problems and allows log analysis tools to provide additional capabilities. Logs written in a structured format are more machine-friendly, i.e. they can be easily parsed by a machine. This can be helpful in the following scenarios:

Developers can search logs and correlate events, which is invaluable both during development as well as for troubleshooting production issues.
Business teams can parse these logs and perform analysis over certain fields (for e.g. unique product count per day) by extracting and summarising these fields.
You can build dashboards (both business and technical) by parsing the logs and performing aggregates over relevant fields.

Let's use our earlier log statement and make a small change to make it structured.

log.error("Exception in processing OrderId={} for ProductId={} due to Error={}", orderId, productId, ex.getResponseBodyAsString())

This will output a log in the following format

[2020-09-27T18:54:41,500+0530]-[ERROR]-[InventoryValidator]-[13] Exception in processing OrderId=182726 for ProductId=21 due to Error=Product Not Available

Now this log message can be easily parsed by the machine by using "=" as a delimiter to extract the OrderId, ProductId and Error fields. We can now do an exact search over ProductId=21 to accomplish our task.

This also allows us to perform more advanced analytics on the logs, such as preparing a report of all the orders that failed such errors.

If you use a log management system like Splunk, the query Error="Product Not Available" | stats count by ProductId can now produce the following result

+-----------+-------+
| ProductId | count |
+-----------+-------+
| 21        | 5     |
| 27        | 12    |
+-----------+-------+

We could also use a JSON layout to print our logs in the JSON format

{
  "timestamp":"2020-09-27T18:54:41,500+0530"
  "level":"ERROR"
  "class":"InventoryValidator"
  "line":"13"
  "OrderId":"182726"
  "ProductId":"21"
  "Error":"Product Not Available"
}

It's important to understand the approach behind structured logging. There is no fixed standard for the same and it can be done in many different ways.

Conclusion

In this article, we saw the pitfalls of unstructured logging and the benefits and advantages offered by structured logging. Log management systems such as Splunk are hugely benefited by a well structured log message and can offer easy search and analytics on log events.

The biggest challenge however, when it comes to structured logging, is establishing a standard set of fields for your software. This can be achieved by following a custom logging model or centralised logging which ensures that all developers use the same fields in their log messages.

Note

This is the first part of my Microservice Observability Series. I'll be adding links to the next articles when they go live. Stay tuned!!

10-Step Guide to GitHub Contributions

Siben Nayak — Mon, 31 Aug 2020 12:58:05 +0000

You've finally decided to make your first GitHub contribution and want to quickly start making changes. Whether it's an Open Source Software (OSS) on public GitHub or your organization's internal project on GitHub Enterprise, there's a well-defined process for contributing that makes your life easier and keeps your codebase clean. In this article, I'll give you ten simple steps to ensure a quick and clean GitHub contribution.

The Contribution Lifecycle

1. Fork the main repository

Forking the repository creates a copy of it in your account. You can make changes and push any code to this fork, without worrying about messing up the original code base. Click on the fork button at the top of the page to create a new fork.

The forked repository will now be available in the "Repositories" section in your account.

2. Clone the forked repository to your machine

Now we need to clone the forked repository to our machine so that we have a local copy of the code. Click on the clipboard icon next to the SSH or HTTPS URL of your forked repository to copy it.

Now open a terminal on your machine and run the following command to clone the forked repository:

git clone git@github.com:theawesomenayak/guava.git

3. Create a feature branch

While making any change to the code, a best practice is to create a new feature branch for the changes we need to make.

This ensures that we keep the master branch clean, and are able to simply revert our code or make updates when necessary.

Switch to the directory that was created after you cloned the forked repository:

cd guava

Create a new feature branch with a name that identifies with the changes you are planning to do. For example:

git checkout -b fix-npe-issue

4. Commit your changes to the feature branch

If you have created any new files as part of your change, you will need to add it to the branch you just created.

git add <filename>

For all the changes made, you have to commit them to the branch. Make sure you add a valid commit message (as per the conventions of the project):

git commit -m "Fixed the NPE issue due to a null key used in cache"

5. Push the feature branch to your fork

Now it's time to push your commit to your forked repository:

git push origin fix-npe-issue

6. Raise a Pull Request against the main repository

Once you have pushed your code to your forked repository, it's time to raise a PR against the main repository. Click on the "Pull Request" button to start a new PR.

This takes you to a screen where the changes in your forked repository are compared with the code in the main repository. You can review the changes and provide a valid description of your changes before submitting them.

7. Address review comments and get your PR merged

The code maintainers will often come back with certain comments around the changes you have made. These could either propose functional changes, or cosmetic changes such as formatting, etc. Once you make these changes, simply push them to your branch and the PR will be automatically updated.

Once the changes are good, a maintainer will merge them to the main repository.

Congratulations!!! You are now officially an open-source contributor.

8. Add the main repository as an upstream to your cloned repository

Many other developers, apart from you, also keep merging their code into the main repository. We need to continuously sync our forked repository with it to get the latest code available.

Your cloned repository is linked to your forked repository.

To keep your fork in sync with the main repository, you'll need to connect them by adding the main repository as an upstream in your cloned repository.

git remote add upstream git@github.com:google/guava.git

Verify that the upstream has been set correctly using the following command:

git remote -v

It should display the following values to confirm that the origin and upstream are pointing to the correct repositories:

origin  git@github.com:theawesomenayak/guava.git (fetch)
origin  git@github.com:theawesomenayak/guava.git (push)
upstream        git@github.com:google/guava.git (fetch)
upstream        git@github.com:google/guava.git (push)

9. Update your master branch from upstream

Once the upstream is set, you can pull in changes that have been done in the main repository by other developers. This updates the cloned repository on your local machine:

git pull upstream master

10. Push the master branch to your fork

Once you have all the updates on your local machine, you will need to push them to your forked repository so that it's in sync with the main repository:

git push origin master

(Optional) Delete your feature branch

Once the feature has been merged into the main repository, it's no longer needed and can be deleted:

git branch -d fix-npe-issue

You can also delete the remote branch from your forked repository:

git push origin --delete fix-npe-issue

Finish Line

Contributing to GitHub projects can be tricky depending on how many developers are concurrently working on it. Hopefully, this article clears the air around the process of making GitHub contributions and makes your development cycle a bit easier.

Thank you for spending your time reading my article. Keep building!