Avoid JVM DNS Caching Problems in AWS

Certain older versions of JDK have forever caching by default. This poses a problem if you have a Java application that calls ELB/ALB or ElasticSearch Clusters. When any action is made to modify a setting in AWS ElasticSearchService or an update happens the cluster doubles in size, the shards are replicated to the new nodes and the old nodes are removed. Queue up the dramatic music and a Java application in trouble.

To avoid this issue simply set the java.security ttl as per the following AWS link: https://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/java-dg-jvm-ttl.html

By setting $JAVA_HOME/jre/lib/security/java.security file to networkaddress.cache.ttl=60 your application will now play nice with ELB/ALB IP changes and ElasticSearch cluster node replacements.

Nginx Requests Not Being Gzipped on CDN Pass-Through

A couple months ago I ran into a curious situation. Requests from Nginx were being gzipped as expected and requests from CDN were being gzipped. My Nginx settings for compression looked like this:


gzip on;
gzip_comp_level 6;
gzip_http_version 1.1;
gzip_min_length 0;
gzip_types application/json application/x-javascript application/javascript text/plain text/css text/javascript text/xml;
gzip_vary on;
gzip_disable "MSIE [1-6]\."; 

Reproducing the behavior was simple enough. If you hit the URI at CDN and append a cache busting string to the end of the URI such as \?2342343243 the headers would return without the Content-Encoding: gzip header. Another test to confirm this was to use a curl statement passing the via header with any value such as below

 

curl -v -H “Accept-Encoding: gzip” -H “Via: 1.1 akamai.net(ghost) (AkamaiGHost)”  "http://youruri.com” 

A simple explanation of this issue is that when request hits the CDN and the object is not cached, the request is then passed to origin using the via header. Unless the Nginx gzip directive of gzip_proxied any; is included this request will always be sent uncompressed. To resolve add this line to your nginx.conf file. Below is the same example shown earlier but including this directive:


gzip  on;
gzip_comp_level 6;
gzip_http_version 1.1;
gzip_min_length 0;
gzip_types application/json application/x-javascript application/javascript text/plain text/css text/javascript text/xml;
gzip_proxied any;
gzip_vary on;
gzip_disable "MSIE [1-6]\.";

Passed AWS Solutions Architect Professional!

Greetings! Apologies the blog hasn’t been more active recently, but it’s been a pretty busy time at work and I just finished a long few months of studying and practicing for the AWS Solutions Architect Professional Exam. I sat the exam on April 06, 2018 and passed with a 70%. This was hands down one of the most difficult tests I have ever taken for a certification. I think the trickiest bit is to pay attention to what is being asked rather than what the best technical answer is, as some questions are looking for the most cost effective solution rather than the most technically accurate or resilient solution.

 

Resources:

When I sat my first AWS test back in 2016 it was for the Solutions Architect Associate. As I prepare for that I had gone through the Linux Academy course as well as the A Cloud Guru course. For the professional I went back to A Cloud Guru as I found their training to be through. Training can be found at their site here.

I also found the WhizLab practice exams to be very close to what you can expect to see on the test. They have 5 exams and each provides answer remediation with links to whitepapers. This was helpful in identifying areas where additional study is needed, as well as linking directly to the resources to study with. You can find a link to their page here.

 

Other Info:

That’s all I have on the test. Stick around for some posts in the next few months where I’ll be talking about some interesting Azure Infrastructure as Code with ARM templates, service fabric, and Windows containers.