In the previous post we saw, how to list all the Calendar's. In this post we shall build upon the code to list all the calendar's for a given user account, and update the MS Project tasks to the selected calendar.

We shall need to following three steps:

• List Calendars and select one
• Parse MS Project tasks and convert them to Calendar events
• Update Google Calendar with Events

Step 1: List All calendar's

We have already seen the code for this in previous post

Step 2: Parse MS Project task and convert to Calendar Event

Lets look at the code for the conversion

protected CalendarEventEntry convertTaskToCalenderEntry(Task task) {
    System.out.println("Task "+task);
    CalendarEventEntry eventEntry = new CalendarEventEntry();
    eventEntry.setTitle(new PlainTextConstruct(task.getName()));

    When date = new When();
    date.setStartTime(new DateTime(task.getStart()));
    eventEntry.addTime(date);
    return eventEntry;
}

The code takes Start and End date of task, as well as title, and creates an CalendarEventEntry for the same. There can be additional logic built into this, like filtering events based on some rules etc.

Step 3: Updating entries into Google Calendar

public void updateCalenderWithEntry(List<Task> tasks, CalendarService calendarService, URL url) {
    for (Task task : tasks) {
        CalendarEventEntry entry = convertTaskToCalenderEntry(task);
        try {
            calendarService.insert(url, entry);
        } catch (IOException e) {
            e.printStackTrace();
        } catch (ServiceException e) {
            e.printStackTrace();
        }
    }
}

Here we just iterate through the tasks and update the events using CalendarService. The Calendar URL can be retrieved from the CalendarEntry class.

A complete working example is part of com.ashishpaliwal.mpputils.examples.MppToGoogleCalendar

Using the sample program

>com.ashishpaliwal.mpputils.examples.MppToGoogleCalendar [MPP File] [Google User Name] [password]

What's Next?

Eager to hear from user, what they would like to see. Adding a UI and out-of-box working package is something that would be good. However, please do try using this and I shall try my best to improve this.

Lets explore how to find this.

• Find the pid of the application, using top or jps command
• Once you get the pid, run following command
  $ ps -L pid

We get an output as shown in the figure




ps output

The output displays all the Threads in the application along with the time spent. Find the Thread that has spent highest time in execution (Entry circled on right). Once we identify this, get the LWP ID of the Thread (Entry circled on left).

• Using jstack or visualvm, take a Thread dump.
• Convert LWP ID to Hex and search for the ID in Thread dump.

Then you can narrow down the thread which is consuming max CPU and investigate further.

To begin, you can get the code form github at following location

https://github.com/paliwalashish/mpputils

Building the code

To build the code and download the dependencies, please refer to the wiki page https://github.com/paliwalashish/mpputils/wiki/Build

Retrieving Calendar's

Now lets move to retrieving the list of all the Calendar's for a user
The code is simple enough, here is the function which does the

public static List<CalendarEntry> getAllCalendars(String userName, String password) throws Exception {
        CalendarService myService = new CalendarService("CalendarService-"+userName);
        myService.setUserCredentials(userName, password);

        // Send the request and print the response
        URL feedUrl = new URL("https://www.google.com/calendar/feeds/default/allcalendars/full");
        CalendarFeed resultFeed = myService.getFeed(feedUrl, CalendarFeed.class);

        return resultFeed.getEntries();
    }

This snippet shall return all the Calendar's for the specified user account.

The code has an example of using the same. Please refer to com.ashishpaliwal.mpputils.examples.ListAllCalendars class on the usage.

In the next part we shall see the code for updating of Google Calendar with MS Project task.

Here is the snippet. Removed all additional validation and other stuff for simplicity.

public class LruCache {
    // cache data holder
    Map<Object, Object> cache;

    // Max size
    private int maxCacheSize;

    public LruCache(int maxSize) {
        this.maxCacheSize = maxSize;
        cache = new LinkedHashMap(maxSize, 0.75f, true) {
            @Override
            protected boolean removeEldestEntry(Map.Entry eldest) {
                return size() > maxCacheSize;
            }
        };
    }

    public void put(Object key, Object value) {
        cache.put(key, value);
    }

    public Object get(Object key) {
        return cache.get(key);
    }
}

The implementation is fairly simple. The third parameter while initialization of LinkedHashMap is the key. a value of "true" means the implementation should use access-order while evicting the entry.

In this small post we shall explore Terracotta, a leading pure Java Scalability platform. The discussion is based on the AtomicInteger example from Terracotta site, which shows how to implement a Cluster wide id generator (Actually it’s the Sequencer example, but to keep my steps simple had used AtomicInteger). The reason why I choose this example was coz of a very similar requirement that I had to implement in Clustered J2EE application.
Terracotta is well known and needs no introduction

About problem Statement

Well, I needed a simple solution to have
• Cluster wide unique id’s
• Less frequent access to these id’s
• Optional Persistence

NOTE: Please note that the current example is slightly modified version of example from terracotta.org.

Pre-requisite

To run this example, you need to have following installed
• Terracotta
• And JDK offcourse
Let’s take a look at the sample code first

import java.util.concurrent.atomic.*;

public class IdGenerator
{

private AtomicInteger masterCounter = new AtomicInteger(0);

private AtomicInteger slaveCounter = new AtomicInteger(1024);

public int getNewMasterId()
{
int newId = masterCounter.getAndIncrement();
System.out.println("Master Id is: " + newId);
return newId;
}

public int getNewSlaveId()
{
int slaveId = slaveCounter.getAndIncrement();
System.out.println("Slave Id is: " + slaveId);
return slaveId;
}

public static void main(String[] args)
{
new IdGenerator().getNewMasterId();
}
}

The code has two fields ids master and slave, of which master id need to be unique cluster wide. The code is pretty straight forward, and there is nothing to explain. The id’s are generated by simple getAndIncrement() API.

Lets see the tc-config.xml

<tc:tc-config xmlns:tc="http://www.terracotta.org/config"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.terracotta.org/schema/terracotta-4.xsd">

<application>
<dso>
<roots>
<root>
<field-name>IdGenerator.masterCounter</field-name>
</root>
</roots>
</dso>
</application>
</tc:tc-config>

Since only master Id needed to be unique in this case, hence the configuration

Let’s look at the deployment architecture

Deployment Architecture

The application was to run on 3 nodes (3 JVM’s on same machine) and one Terracotta server running.
Before we get into running this application, lets take a look at some useful scripts provided by Terracotta
• dso-java (bat|sh) – startup script that bootstraps Terracotta libraries to your application
• start-tc-server (bat|sh) – Script to start Terracotta Server. It is mandatory to start Terracotta Server before running Clients

Let’s run the application
1. Compile the application. There is no dependency on TC libraries.
2. First Start the terracotta Server using script start-tc-server
3. Run 3 separate JVM with command “dso-java IdGenerator”
That’s it. Our first application is running. If we observe the console output, you can see that we have unique id’s for each invocation.

References:

Source code for Terracotta examples - http://svn.terracotta.org/svn/forge/cookbook

… interface provides a way of decoupling task submission from the mechanics of how each task will be run, including details of thread use, scheduling, etc. An Executor is normally used instead of explicitly creating threads.

Indeed, Executors provide a more robust and easy mechanism for decoupling of submitting a task, from its execution.

In this series, we shall explore this concurrency construct in detail.

NOTE: Have tried to avoid explaining what is already available in javadoc.

Let’s first see the lifecycle of an Executor

ExecutorService extends the Executor interface, adding a bunch of life cycle methods.

Executor Life Cycle

public static void main(String[] args) {
// Executor doesn't exist before this step
// Executor created and moved to running state
ExecutorService executor = Executors.newSingleThreadExecutor();

// Executor into running state
executor.execute(new Runnable() {
public void run() {
System.out.println("Running...");
}
});

// Lets shutdown
executor.shutdown();

System.out.println(" isShutdown = "+executor.isShutdown());
System.out.println(" isTermianted = "+executor.isTerminated());
}

The program depicts the complete lifecycle. Please see the comments inline in the code

Initially the Executor doesn’t exist. When we create an Executor, using Executor’s we have it in Ready state (ready to accept tasks for execution).
Once we submit a task for execution, the Executor moves to running state. Once it completes the task, it moves back to ready state.

Once we call shutdown() on Executor, it begins its shutdown cycle. Once it is completed it moves to Terminated state.

There are couple of things that need to be noted after shutdown is initiated. An Executor can be executing or may have couple of tasks pending to be executed.

Calling shutdown() initiates an orderly shutdown, means all the pending tasks shall be completed, but new tasks won’t be accepted

Calling shutdownNow() initiates a shutdown, by trying to halt the processing the tasks by interrupting the threads. The method returns a list of Runnable’s which were not executed. Programs can use them to reschedule them later or discard them.

What will happen, if we submit a task once shutdown has been initiated?
This situation can be handled by using RejectExecutionHandler. The default implementation simply discards the tasks. We can have the custom logic to handle the tasks that couldn’t be executed.

Upcoming topic – Exploring a little on ScheduledExecutorService

To begin with decided to run some samples on switch and if-else constructs and analyze further.

Wrote three function
1. For if-else - a if-else ladder based on int comparisons
2. For Switch - switch with 21 cases, from 1 to 20
3. For Switch - switch with sparse random values

The reason for choosing two functions for switch was this statement from VM spec "Compilation of switch statements uses the tableswitch and lookupswitch instructions"

Lets see the function codes

if-else

public static void testIfElse(int jumpLabel) {
if(1 == jumpLabel) {
    System.out.println("1");
} else if(2 == jumpLabel) {
    System.out.println("2");
} else if(3 == jumpLabel) {
    System.out.println("3");
} else if(4 == jumpLabel) {
    System.out.println("4");
}
// Removed for simplicity
else {
    System.out.println("default");
}
}

Lets see the switch functions

Finite switch version

public static void testSwitchFinite(int jumpLable) {

switch (jumpLable) {
case 1:
    System.out.println("1");
    break;

case 2:
    System.out.println("2");
    break;

case 3:
    System.out.println("3");
    break;

case 4:
    System.out.println("4");
    break;

case 5:
    System.out.println("5");
    break;

// Removed other cases for simplicity

default:
    System.out.println("default");
    break;
}
}

Sparse switch version

public static void testSwitchSparse(int jumpLable) {

switch (jumpLable) {
case 100:
    System.out.println("1");
    break;

case -1:
    System.out.println("2");
    break;

case 5000:
    System.out.println("3");
    break;

case -8:
    System.out.println("4");
    break;

case 1600:
    System.out.println("5");
    break;

case 250:
    System.out.println("250");
    break;

// Removed other cases for simplicity

default:
    System.out.println("default");
    break;
}
}

With the groundwork done, its the benchmarking time. The benchmarking strategy was simple. Run these functions in loop and see the result, with iteration ranging from 100 to 1000.

Lets look at one of the functions

public static void testSwitchPerf(int iteration) {
    long t1 = System.nanoTime();
    for (int i = 0; i < iteration; i++) {
        testSwitchFinite(i);
    }
    long t2 = System.nanoTime();
    System.out.println("Time Taken (switch) = "+(t2 - t1)/1000000);
}

Well this was the ground work, after executing the conditions, here is the data

NOTE: There is some difference due to the way data is provided and the sample space doesn't provide precise results. However, since the sample space is same for both, it would serve its purpose

Conclusion

1. There is no significant execution difference between if-else and switch. The difference observed is due to the sample space choosen.
2. If using if-else, its always recommended to put frequently used if condition at the top of if-else ladder
3. The finite switch statement was converted to tableswitch and sparse switch was converted to lookupswitch

would be interested to hear from folks about their experience in relation to this. I would say, i still prefer switch for readability. Henceforth, my review comment shall be modified as "Use switch instead of if-else, its more readable and has better performance"

Share your thoughts

I would be very keen to hear from you all, about your opinions and experience about the topic