Vert.x Event Loop

Event Loop is not new and also not specific to Vert.x (used in Node.js).   I will be talking about it, in a top down fashion. 

Vert.x is a library (yes, it's just jar) which allows to develop Reactive applications on JVM.  Reactive system is defined in Reactive Manifesto. Vert.x supports this manifesto, so it enables application written in Vert.x to be - Responsive, Elastic, Resilient and Message driven.

The last point (Message Driven) of reactive manifesto defines the essence of Vert.x - It's event/message driven and non-blocking/asynchronous. This means, different components interact with each other asynchronously by passing messages. 

//Synchronous and blocking API call
Object obj = new MyObject();
obj.fetchDataFromUrl(url);

The traditional application makes blocking API call, so calling thread waits until the response is available. This means until the response is available the thread is sitting ideal and doing nothing. This is not a good thing from a resource utilization point of view. Now, how about making that thread more specialized whose job is only to post request, i.e. it's not going to wait for a response to arrive. The thread will go on doing only one thing till the sky falls. This way the thread will not be sitting ideal (unless there is NO request). Putting it in a more generic term, the thread will be passing on messages or events. 

Event Loop is basically a thread (or a group of threads; Vert.x matches it closest to CPU cores) whose job is to keep passing on messages to their specific handlers. The threads pick the event (from a queue) and then hands over the event to the right handler. Event loop maintains the order (as it picks the events internally from a queue) and it's also synchronous as there is going to be one or limited threads (Note: they themselves are synchronous). Vert.x allows configuring the number of threads (one per core of the CPU). Handlers are always called by the same event loop so there is no need of synchronization.

Event Loops are limited and so special, so blocking them will be disaster. Event loop calls the method asynchronously and in a non-blocking manner. Once the response arrives the same event loop calls the callback. 


References
http://vertx.io/docs/vertx-core/java/#_in_the_beginning_there_was_vert_x
http://www.dre.vanderbilt.edu/~schmidt/PDF/reactor-siemens.pdf
http://vertx-lab.dynamis-technologies.com/
https://github.com/vietj/vertx-materials/blob/master/src/main/asciidoc/Demystifying_the_event_loop.adoc
https://strongloop.com/strongblog/node-js-event-loop/
http://www.enterprise-integration.com/blog/vertx-understanding-core-concepts/

Pushing a new project to Github

This post talks about pushing a new project on Github. Make sure that the project is not created already on the Github.

I have illustrated using a sample application named as websockets.  I have shown created a project with just one file (README.md) and then pushing the project to github. You can run below commands in terminal or gitbash. 

$ mkdir websockets
$ cd websockets

$ echo "# websockets" >> README.md

$ git init

Initialized empty Git repository in /Users/siddheshwar/Documents/gitRepo/websockets/.git/

$ git add README.md

$ git commit -m "first commit"

[master (root-commit) 24fac01] first commit

1 file changed, 1 insertion(+)

create mode 100644 README.md

$ git remote add origin https://github.com/raiskumar/websockets.git

$ git push -u origin master

Username for 'https://github.com': rai.skumar@gmail.com

Password for 'https://rai.skumar@gmail.com@github.com': 

Counting objects: 3, done.

Writing objects: 100% (3/3), 233 bytes | 0 bytes/s, done.

Total 3 (delta 0), reused 0 (delta 0)

To https://github.com/raiskumar/websockets.git

 * [new branch]      master -> master

That's it, you are done !!!

Gradle - Create Java Project Structure

Gradle Init plugin can be used to bootstrap the process of creating a new Java, Groovy or Scala project. This plugin needs to be applied to a project before it can be used. So if we want to create default directory structure of a Java project this plugin can be handy (Especially if you don't have Gradle plugin in your IDE).

$gradle init --type java-library

The init plugin supports multiple types (it's 'java-library' in above command). Below are the command sequence and directory which gets created after successful execution.

$ mkdir hello-gradle
$ cd hello-gradle/
$ gradle init --type java-library
:wrapper
:init

BUILD SUCCESSFUL

Total time: 8.766 secs
$ ls -ltr
total 20
drwxrwxr-x. 3 vagrant vagrant   20 Jul 20 06:00 gradle
-rwxrwxr-x. 1 vagrant vagrant 5080 Jul 20 06:00 gradlew
-rw-rw-r--. 1 vagrant vagrant 2404 Jul 20 06:00 gradlew.bat
-rw-rw-r--. 1 vagrant vagrant  643 Jul 20 06:00 settings.gradle
-rw-rw-r--. 1 vagrant vagrant 1212 Jul 20 06:00 build.gradle
drwxrwxr-x. 4 vagrant vagrant   28 Jul 20 06:00 src
-- 

So above command also installs the other Gradle dependencies to run the build (i.e. gradl, gradlew.bat). If you don't know what the appropriate type for your project, specify any value then it will list valid types.

$ gradle init --type something
Execution failed for task ':init'.
> The requested build setup type 'something' is not supported. Supported types: 'basic', 'groovy-library', 'java-library', 'pom', 'scala-library'.

--

So, if you just type any random text as type; Gradle tells the allowed types.

If you just use $gradle init , then gradle tries (it's best) to automatically detect the type. If it fails to identify the type, then applies basic type. 

Importing Gradle Project to Eclipse

Note that, above command created gradle specific files along with default java directories (like src) but it didn't create eclipse specific files. This means, if you try to import above created project in eclipse it will not work. To achieve that, do below:

1. Add eclipse plugin in gradle build file (i.e. build.gradle).  Put below after java plugin. 

          apply plugin: 'eclipse'

1. Run $gradle eclipse

This basically creates files - .classpath, .project and .settings

Now, you are good to import above project in eclipse.

Alternatively, you can clone from my GitHub repository. 

---

Happy coding !!!

Microservices Explained

I have been reading about microservices for a while (must admit, I delayed it thinking, it's just old wine in new bottle), and the more I dive deeper, the more exciting I find it. I am a big fan of design principle, Single Responsibility Principle (SRP) as it helps in putting boundries on class (and even on methods). SRP helps in making code simpler and cleaner (ofcourse, other design principles are equally important, but my love for SRP is boundless!). And I always used to wonder, why can't we apply SRP at service layer? And finally, Microservices God have heard me!

For a service to be called as micro it should be really small in size and that's going to be possible, if and only if, your service does only one thing(i.e follows SRP). And it should do that one thing really well. This in turn will help to easily implement, change, build, distribute, and deploy the service. This will also help in creating a highly decentralized and scalable systems. I tried looking on web to find definition of miroservices, the one which I found covering all aspects is from Martin Fowler (link).

In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

Let's cover some of the aspects of microservices:

1. Each service (or set of few) should have it's own data store. So having 100's of data store is normal. You can choose between relational, noSQL DB, or even in-memory db depending on your need. If you have 2 DB and dozen of services around it, you are not micro yet.
2. They are organized functionally or around business functions. This helps in keeping boundaries separate and clear.
3. Loosely coupled and highly cohesive (or another way to put, they do one thing really well).
4. They are usually RESTFul (to maintain simplicity). They receive a request, apply logic and produce the response. But they also support other interaction styles as well like RPC, message, event, stream. 
5. They are usually asynchronous and use simple message queues. The real intelligence of the system lies at either end of the queue (i.e. with services).
6. The complete infrastructure of build to production deployment should be automated (i.e. it should have CI/CD).
7. In a microservice world, your single monolithic service could be replaced by 100's of microservices. You should design each microservice keeping in mind worst; design for failure. A service being down in production is a normal thing, your system should be able to handle it gracefully.  
8. Microservices stresses a lot on real-time monitoring matrices like average response time, generate the warning if a service is not responding etc. 
9. In an ideal scenario, the event bus should replace your operational database. Kafka is one of the fast bus and it's fast because it's dumb (i.e. it just delivers events).
10. Microservices make your system/application more distributed which intern adds more complexity. 

Found this video interesting as it talks about challenges in implementing microservices, link.

References

http://martinfowler.com/articles/microservices.html

http://microservices.io/patterns/microservices.html

http://2012.33degree.org/talk/show/67

https://jaxenter.com/cracking-microservices-practices-107924.html