what is zookeeper,role of zookeeper.

There are many confusion about zookeeper,what zookeeper is ?.

What is the role of zookeeper .What zookeeper does.

In Simple term,Zookeeper ensure people or node which are agreed to work together ,should work together.

Scaling the Read Query Load On MongoDB server

Requirement Overview:We are capturing all activity on Jobs In mongoDB like view ,apply,view source,apply source etc.There is lots of read query fired on real times to get stats about jobs.

We need to scale our read load so that we can serve all read request without any delay.

Approach :There are 2 ways of reducing read load on Primary MongoDB server.

       

1. Distributing the Data on Multiple Node (Sharding).

            

     2.  Use secondary mongodb node for read query.

By default, an application directs its read operations to the primary member in a replica set.        

Since Our data size is not large ,we have not implemented sharding .But read operation are very high on the same data Set.

Code Snippet:

var collection =dataLoggerDB.collection(currentCollection,{readPreference:'secondaryPreferred'});

Read Preference Options:

Read Preference Mode	Description
primary	Default mode. All operations read from the current replica set primary.
primaryPreferred	In most situations, operations read from the primary but if it is unavailable, operations read from secondary members.
secondary	All operations read from the secondary members of the replica set.
secondaryPreferred	In most situations, operations read from secondary members but if no secondary members are available, operations read from the primary.
nearest	Operations read from member of the replica set with the least network latency, irrespective of the member’s type.

basic difference between column oriented DB vs Row Oriented DB

basic difference between column oriented DB vs Row Oriented DB :

 1.Scan Less data as compare to row base data base while doing aggregation etc.
 2.Better compress for column data.

Promises in AngularJS, Explained as a Cartoon

One morning, a father says to his son: "Go and get the weather forecast, son!"

Every Sunday morning, a father asks his son to go and find out the weather forecast for the afternoon, by using his super-strong telescope to look across the horizon from the tallest hill by their house. The son promises his dad he will go and get the weather forecast. He creates a promise with his dad at the door when he leaves.

At that point, the dad decides if the weather tomorrow is good, he'll prepare a fishing trip for tomorrow. If it's bad he won't. Also, if the son is unable to get a forecast, he'll stay in as well.

After 30mins or so, the son comes back. Different things happen from week-to-week:

Outcome A) Weather forecast retrieved! Sunshine :-)

The son succeeded in retrieving the weather forecast, clear skies and sunshine! The promise was fulfilled (the son kept his promise) and the dad decided to pack up for the fishing trip for Sunday.

Outcome B) Weather forecast retrieved! Cloudy and rain :-(

The son succeeded in retrieving the weather forecast, but it looked like cloudy and rain. The promise was fulfilled but dad decided to stay in because of the bad weather.

Outcome C) Couldn't get the weather forecast :-/

The son failed to retrieve the forecast, there was a problem; it was way too foggy to see what weather was coming over the hills. The promise the son made when he left was broken - the promise was rejected! The dad decided to stay in, it wasn't worth the risk.

---

How does this look in code?

The dad is controlling the logic in this situation, and he's dealing with the Son as if he's a service.

We've already stated the logic, the father asks the son to get the weather forecast, and as the son can't tell him immediately, and the father has other things to do while he waits, the son makes a promise he shall return with the weather. When the dad has the forecast, he'll either pack up the boat, or stay inside. The important thing to note here, is the son's trip up the hill shouldn't 'block' the dad from doing anything, so this is why the situation is perfect for the creation of a promise, which can be resolved (fulfilled or rejected) later on.

Using Angular's then() function we can specify what the Dad needs to do in the event of each outcome. The then() function accepts 2 functions as parameters: a function to be executed when the promise is fulfilled, and a function to be executed when the promise is rejected.

Controller: FatherCtrl

The father is controlling the situation here:

        // function somewhere in father-controller.js
        var makePromiseWithSon = function() {
            // This service's function returns a promise, but we'll deal with that shortly
            SonService.getWeather()
                // then() called when son gets back
                .then(function(data) {
                    // promise fulfilled
                    if (data.forecast==='good') {
                        prepareFishingTrip();
                    } else {
                        prepareSundayRoastDinner();
                    }
                }, function(error) {
                    // promise rejected, could log the error with: console.log('error', error);
                    prepareSundayRoastDinner();
                });
        };
    

Service: SonService

The Son is being used as a service, he climbs the hill and tried to see the weather. We'll suppose when the son is looking through his telescope and looking for the approaching weather, it's analogous to using a weather API, in the sense that it's an asynchronous operation, he may get a variable answer, and there may be a problem (say, a 500 response, foggy skies).

The response from the 'Fishing Weather API' will be returned with the promise, if it was fulfilled. It will be in the format: { "forecast": "good" }

    app.factory('SonService', function ($http, $q) {
        return {
            getWeather: function() {
                // the $http API is based on the deferred/promise APIs exposed by the $q service
                // so it returns a promise for us by default
                return $http.get('http://fishing-weather-api.com/sunday/afternoon')
                    .then(function(response) {
                        if (typeof response.data === 'object') {
                            return response.data;
                        } else {
                            // invalid response
                            return $q.reject(response.data);
                        }

                    }, function(response) {
                        // something went wrong
                        return $q.reject(response.data);
                    });
            }
        };
    });
    

---

Summary

This analogy demonstrates the asynchronous nature of the request the dad makes to his son, for the weather forecast. The dad doesn't want to wait at the door in anticipation when the son leaves, because he has other stuff to do. Instead, he makes a promise at the door, and decides what will happen in either of the 3 scenarios (good weather/bad weather/no forecast). The son immediately gives a promise to his dad when he leaves, and will resolve or reject it on his return.

The son is dealing with an asynchronous service (searching the sky with his telescope/using a weather API) to get data, but all of this is correctly abstracted away from his old man, who doesn't really understand technology!

source

http://andyshora.com/promises-angularjs-explained-as-cartoon.html

Method injection with Spring

Spring core comes out-of-the-box with two scopes: singletons and prototypes. Singletons implement the Singleton pattern, meaning there’s only a single instance at runtime (in a JVM). Spring instantiate them during context creation, caches them in the context, and serves them from the cache when needed (or something like that). Prototypes are instantiated each time you access the context to get the bean.

Problems arise when you need to inject a prototype-scoped bean in a singleton-scoped bean. Since singletons are created (and then injected) during context creation: it’s the only time the Spring context is accessed and thus prototype-scoped beans are injected only once, thus defeating their purpose.

In order to inejct prototypes into singletons, and side-by-syde with setter and constructor injection, Spring proposes another way for injection, called method injection. It works in the following way: since singletons are instantiated at context creation, it changes the way prototype-scoped are handled, from injection to created by an abstract method. The following snippet show the unsuccessful way to achieve injection:

public class Singleton {

    private Prototype prototype;

    public Singleton(Prototype prototype) {
        this.prototype = prototype;
    }

    public void doSomething() {
        prototype.foo();
    }

    public void doSomethingElse() {
        prototype.bar();
    }
}

The next snippet displays the correct code:

public abstract class Singleton {

    protected abstract Prototype createPrototype();

    public void doSomething() {
        createPrototype().foo();
    }

    public void doSomethingElse() {
        createPrototype().bar();
    }
}

As you noticed, code doesn’t specify the createPrototype() implementation. This responsibility is delegated to Spring, hence the following needed configuration:

<bean id="prototype" class="ch.frankel.blog.Prototype" scope="prototype" />
<bean id="singleton" class="sample.MySingleton">
 <lookup-method name="createPrototype" bean="prototype" />
</bean>

Note that an alternative to method injection would be to explicitly access the Spring context to get the bean yourself. It’s a bad thing to do since it completely defeats the whole Inversion of Control pattern, but it works (and is essentially the only option when a nasty bug happens on the server - see below).

However, using method injection has several main limitations:

• Spring achieves this black magic by changing bytecode. Thus, you'll need to have the CGLIB libraryon the classpath.
• The feature is only available by XML configuration, no annotations (see this JIRAfor more information)
• Finally, some application servers have bugs related to CGLIB (such as this one)

tomcat 7 difference nio (non blocking I/O) vs bio (blocking I/O)

Tomcat has a couple of connectors to choose from. I’ll leave aside the APR connector, and focus on the BIO and NIO.

The BIO connector (blocking I/O) is blocking – it uses a thread pool where each thread receives a request, handles it, responds, and is returned to the pool. During blocking operations (e.g. reading from database or calling an external API) the thread is blocked.

The NIO connector (non-blocking I/O) is a bit more complicated. It uses the java NIO library and multiplexes between requests. It has two thread pools – one holds the the poller threads, which handle all incoming requests and push these requests to be handled by worker threads, held in another pool. Both pool sizes are configurable.

When to prefer NIO vs BIO depends on the use case. If you mostly have regular request-response usage, then it doesn’t matter, and even BIO might be a better choice (as seen in my previous benchmarks). If you have long-living connections, then NIO is the better choice, because it can server more concurrent users without the need to dedicate a blocked thread to each. The poller threads handle the sending of data back to the client, while the worker threads handle new requests. In other words, neither poller, nor worker threads are blocked and reserved by a single user.

With the introduction of async processing servlet it became easier to have the latter scenario from the previous paragraph. And maybe that was one of the reasons to switch the default connector from BIO to NIO in Tomcat 8. It’s an important thing to have in mind, especially because they didn’t exactly change the “default value”.

The default value is always “HTTP/1.1″, but in Tomcat 7 that “uses an auto-switching mechanism to select either a blocking Java based connector or an APR/native based connector”, while in Tomcat 8 “uses an auto-switching mechanism to select either a non blocking Java NIO based connector or an APR/native based connector”. And to make things even harder, they introduced a NIO2 connector. And to be honest, I don’t know which one of the two NIO connectors is used by default.

So even if you are experienced with tomcat configuration, have in mind this change of defaults. (And generally I’d recommend reading the documentation for all the properties and play with them on your servers)

for more detail check http://techblog.bozho.net/tomcats-default-connectors/

Difference between a Spring singleton and a Java singeleton (design pattern)

Singleton beans in Spring and classes based on Singleton design pattern are quite different.
The Java singleton is scoped by the Java class loader, the Spring singleton is scoped by the container context.
Which basically means that, in Java, you can be sure a singleton is a truly a singleton only within the context of the class loader which loaded it. Other class loaders should be capable of creating another instance of it (provided the class loaders are not in the same class loader hierarchy), despite of all your efforts in code to try to prevent it. In Spring, if you could load your singleton class in two different contexts and then again we can break the singleton concept. So, in summary, Java considers something a singleton if it cannot create more than one instance of that class within a given class loader, whereas Spring would consider something a singleton if it cannot create more than one instance of a class within a given container/context.
Here is some example:
spring-config.xml

 <?xml version="1.0" encoding="UTF-8"?>  
 <beans xmlns="http://www.springframework.org/schema/beans"  
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  
     xmlns:context="http://www.springframework.org/schema/context"  
     xsi:schemaLocation="http://www.springframework.org/schema/beans   
       http://www.springframework.org/schema/beans/spring-beans-3.2.xsd  
       http://www.springframework.org/schema/context   
       http://www.springframework.org/schema/context/spring-context-3.2.xsd">  
   <bean id="a" class="com.pkg.Singleton" scope="singleton" />    
 </beans>  

Bean Singleton

 public class Singleton{  
   private String text;  
   public String getText() {  
     return text;  
   }  
   public void setText(String text) {  
     this.text = text;  
   }  
 }  

Test 

 public class Test {  
   public static void main(String[] args) {  
     ApplicationContext ctx = new ClassPathXmlApplicationContext("spring-config.xml");  
     Singleton a1 = ctx.getBean("a", Singleton.class);  
     a1.setText("text A1");  
     Singleton a2 = ctx.getBean("a", Singleton.class);  
     a2.setText("text A2");  
     System.out.println("a1: " + a1.getText());  
     System.out.println("a2: " + a2.getText());  
   }  
 }  

Output: 

 a1: text A2  
 a2: text A2  

And now let's create another one ApplicationContext: 

 public class Test {  
   public static void main(String[] args) {  
     ApplicationContext ctx = new ClassPathXmlApplicationContext("spring-config.xml");  
     ApplicationContext ctx2 = new ClassPathXmlApplicationContext("spring-config.xml");  
     Singleton a1 = ctx.getBean("a", Singleton.class);  
     a1.setText("text A1");  
     Singleton  a2 = ctx2.getBean("a", Singleton.class);  
     a2.setText("text A2");  
     System.out.println("a1: " + a1.getText());  
     System.out.println("a2: " + a2.getText());  
     // both ctx and ctx2 have same classloaders  
     System.out.println("context1 classloader: " + ctx.getClassLoader());  
     System.out.println("context2 classloader: " + ctx2.getClassLoader());  
   }  
 }  

Output: 

 a1: text A1  
 a2: text A2  
 context1 classloader: sun.misc.Launcher$AppClassLoader@5284e9  
 context2 classloader: sun.misc.Launcher$AppClassLoader@5284e9