Saturday, September 28, 2013

Fix for Android phones running low on internal memory (without rooting)

The first, simplest and safest step is to delete dumpstate/logcat files.

Dumpstate, logcat files are stored on the /data/log partition that, unless you root the phone, you and none of the apps you install will have access to.

The following method does not require you to root the phone or install any apps and will probably free up more memory that any other method.

1. Dial *#9900# - This will bring up the following screen - Sysdump

2. Hit the 'Delete dumpstate/logcat' button. Hit OK on the confirmation dialog.
3. Scroll to the end of the screen and hit 'Exit'

That's it!

I've seen about 800MB freed the first time I used this.

As a next step I'd recommend the 'Clean Master' free app to manage your cache, data, moving files to SD card etc

Sunday, September 25, 2011

Heap Visualizer (web app)

You're having some heap-related issues (OOM, long GC pauses) in production and do not have the liberty to fire up jconsole or install glassbox (or something similar) to diagnose the situation. What do you do Jack?

I these situations, I wished that
  • I could have a view of the Heap and Non-Heap sections simultaneously. 
  • I could then drill down into either or both the sections and view details of the different heap generations and sections as the application progressed 
  • I could do this by simply dropping an app (.war) into the app server to monitor the heap. 
Luckily I didn't waste too much time wishing for more and just wrote the darn thing :)

JVM Memory (Heap and Non-Heap) Visualizer

Well, in keeping with the philosophy of this blog I thought I'd share it so that it might be useful to someone someday.
I normally deploy the app as 'heap.war' so I can reach it at http://[server]:[port]/heap
Here's what you see when you first access it:

The screen shows the overall used/committed/max values for the 'Heap' and 'Non Heap' sections of the memory used by the JVM.
The UI is minimal and the colors have been chosen to present a 'console' experience.
There are two graphs, a bullet graph that plots the used, committed and max values for the respective portion of memory, and a line graph that plots the relative movement of the 'used memory' values.

If you click on the 'details' link you'll see something like this:

As you can see, you'll be able to see drill-down details of the 'heap' and 'non-heap' memory components and their respective memory usage and utilization characteristics.

The next version have customizable refresh-rate (it's currently set at 2 seconds), an option to invoke a Garbage Collection and a way to look at the detailed properties of the current JVM

The code is at
You can get the source and the download (.war) from the menu on this page.

Do post your feedback and feature requests :)

Thursday, June 30, 2011

Technical Disclaimers

I just read an interesting document on software disclaimers by Jarek Zylinski which is, in short, more of an appeal to develop software using educated (read professionally trained) and ethical (read decent-human-beings) personnel. 

I took a few minutes to ponder on the impact this kind of thinking could have to so-called intermediate software artefacts/products created during a product's SLDC.

In today's multi-company development environments, this is especially important as experts from one company might create an overall architecture, while experts from another firm create high-level designs and integration specifications and another firm might actually realize the design into a tangible code. During this process, there are several software artefacts, especially documents, to be generated before the final product is realized, and at some level all of these artefacts could benefit from having a way of telling the audience what they are really about and what the audience should really focus on without getting caught up in the "letter" of the document.

You, as a producer of an artefact that is in the form of a document, need to have a way to declare upfront where you've directed your efforts and your wishes to ensure that the audience views the document as you do.
Here is, what I believe to be one of the clearest disclaimers to add to a technical document:

The contents of this document are believed to be accurate. This is not a legal document and should not be treated as such. The statements, information and recommendations mentioned in this document are intended to be read more in spirit than in letter. This document is intended to be objective. Any subjectivity or bias that has crept into this document must be considered unintentional and must be attributed to a human failing on the part of the author.
The author(s) of this document agree to the terms above.

I really don't recall where I got this from, but I do recall seeing something similar in a document I read on the internet. I might have, at the time edited it for relevance to my field of work but have lost the source of this inspiration.

If any reader that stumbles upon this post and has knowledge of its source, please comment and I shall take appropriate action.

Save encrypted PDF as plain / unencrypted PDF

Note: If you don't have the password for the PDF file, this post is not what you're looking for.

You have a PDF file that's encrypted and you already know the password.
Say you need to send this PDF file to someone without them needing to use a password to open it, or you just need to store it in an unencrypted format. How do you do this?

As always with software, there are options:
  1. Option 1: Buy an commercial product (like Adobe Acrobat or Foxit PhantomPDF )that is able to strip the encryption from the PDF file- Not for El Cheapo types (like me)
  2. Option 2: Use a product to save the file to JPEG (or any image) format, either manually (using screen prints) or using a free/commercial product (like SnagIT) that takes a screen shot of the entire document, not just the visible window. - Not for the lazy (like me)
  3. Option 3: The quick, simple and free and high quality way - Now that's what I like
As you guessed, I'm going for Option 3 :)

Option 3 - A surprisingly simple way of doing this while preserving the quality and format of the document:

  1. Install a free PDF Printer (I'd recommend PrimoPDF, but that's purely a personal choice).
  2. Open the encrypted PDF file and type in the password.
  3. Invoke the 'Print' option (File->Print) and use the PDF Printer as your choice.
  4. (in case you encounter an error, go to your temp directory (%TEMP%), sort by date-latest and look for a randomly named file with about the same size as your pdf. Rename that extension to .pdf and you're good to go)


Saturday, March 19, 2011

Creating DMZ configurations on Amazon EC2

This post tries to address an approach to replicating corporate-style DMZ configurations using Amazon EC2 components.

Conventional (non-cloud) Network configuration for hosting internet facing applications
Most internet applications are deployed on servers placed in secured demilitarized zones.
A DMZ's main function is to restrict the extent of an attack should systems be compromized.
Typically, there would be a main firewall that allows traffic from the internet only to web servers on a particular port. Subsequent to that there could possibly be firewalls that isolate application servers, database and reporting servers etc.

An example of this configuration is shown below. It consists of a Web DMZ hosting only web servers accessible from the internet via port 80. The application servers are placed after the second firewall and cannot receive traffic from any other source other than the web servers. The traffic is only restricted to port 8009 and only in one direction. The database servers are behind the third firewall and can only receive traffic from the application servers on port 3128.
For monitoring and management, all machines in the network have been allowed access on port 22 from machines internal to the company.

Cloud Network configuration for hosting internet facing applications

The first thing to realize is that a Security Group is quite similiar to a firewall configuration specifying the allowed protocol (tcp/udp), port/port range, traffic direction and source network. The only real difference is that Security Groups currently only support the ALLOW sematics (not the DENY), but this is quite sufficient as we shall see.

Once a Security Group is created, it can be associated to a server instance. In reality, the Security Group/s have to be specified for an instance before it can be instantiated.

They say that a picture is worth a thousand words, but I don't think that includes code.
The following depicts the configuration of Amazon's EC2 Security Groups to replicate the above DMZ configurations.

The simplest approach to achieve this is as follows:
  1. Map each DMZ to a Security Group
  2. Create the Security Groups in EC2 using the ec2-add-group API
  3. Authorize access (port, port-range, direction, source group/CIDR) using the ec2-authorize API
  4. Create instances using these security groups

Example: Web DMZ, App DMZ and DB DMZ

//create groups / zones
ec2-add-group web-dmz -d "Web DMZ"
ec2-add-group app-dmz -d "Application DMZ"
ec2-add-group db-dmz -d "Database DMZ"

//Allow admin access to all the servers
ec2-authorize web-dmz -P tcp -p 22 -s
ec2-authorize app-dmz -P tcp -p 22 -s
ec2-authorize db-dmz -P tcp -p 22 -s

//Allow access to the site from anywhere on the internet
ec2-authorize web-dmz -P tcp -p 80 -s

//Allow access from Web DMZ to Application DMZ on port 8009 only
ec2-authorize app-dmz -o web-dmz -u xxxxxxxxxxxx -P tcp -p 8009

//Allow access from Application DMZ to Database DMZ on port 3128 only
ec2-authorize db-dmz -o app-dmz -u xxxxxxxxxxxx -P tcp -p 3128

//Create instances and assign them to DMZs
ec2-run-instances ami-cef405a7 -z us-east-1d -t t1.micro -g web-dmz
ec2-run-instances ami-cef405a7 -z us-east-1d -t t1.micro -g app-dmz
ec2-run-instances ami-cef405a7 -z us-east-1d -t t1.micro -g db-dmz