Thursday, October 22, 2015

Hystrix demistified

Hystrix is simple in itself and very easy to understand, still some get confused about how it works.
So let me give a simple example of how it works.
I have taken below example from : Hystrix site Getting-Started
public class CommandHelloWorld extends HystrixCommand<String> {

    private final String name;

    public CommandHelloWorld(String name) {
        super(HystrixCommandGroupKey.Factory.asKey("ExampleGroup"));
        this.name = name;
    }

    @Override
    protected String run() {
        // a real example would do work like a network call here
        return "Hello " + name + "!";
    }
}

String s = new CommandHelloWorld("Bob").execute();
Let us demystify this code:

First:

You need to extend the HystrixCommand to use Hystrix circuit breaker.
HystrixCommand<String>  // This statement tells what your Hystrix command is going to return when your execute it. (Return value of run() method)

HystrixCommand<AnyObject>

HystrixCommand<Anything> 

Second:

Constructor behave as the entry point of your Hystrix Command. You should define it in such a way that values passed can be used to:
1) defining Hystrix Command name, group name , Cache key etc.
2)  help execute the run() method to do the actual task by providing needed element.
    public CommandHelloWorld(String name) {
        }

Example 1:

In above example this parameter is used in run method.
    public CommandHelloWorld(String name) {
    super(HystrixCommandGroupKey.Factory.asKey("ExampleGroup"));
    }

Example 2:

The parameter here are used to define Hystrix Command and are used in run method to make a http call.
   public CommandHelloWorld(String groupKeyName,String commandName, HttpClient httpClient, HttpContext httpContext, HttpRequestBase httpRequest) {
        super(Setter.withGroupKey(HystrixCommandGroupKey.Factory.asKey(groupKeyName)).andCommandKey(HystrixCommandKey.Factory.asKey(commandName)));
    }
    

Example 3:

The parameter here are used to define Hystrix Command and are used in run jdbc call.
public CommandHelloWorld(String groupKeyName,String commandName, JDBCTemplate jdbcTemplate) {
        super(Setter.withGroupKey(HystrixCommandGroupKey.Factory.asKey(groupKeyName)).andCommandKey(HystrixCommandKey.Factory.asKey(commandName)));
    }

Third:

This call is to configure the HystrixCommand.
super(HystrixCommandGroupKey.Factory.asKey("ExampleGroup"));  // this define the group name of your Hystrix command.

Hystrix define two constructror for configuration:

protected HystrixCommand(HystrixCommandGroupKey group) { // Example 1 
        this(new HystrixCommand.Setter(group, null));
    }

protected HystrixCommand(HystrixCommand.Setter setter) { // Example 2 or 3
        this(setter.groupKey, setter.commandKey, setter.threadPoolKey, (HystrixCircuitBreaker)null, (HystrixThreadPool)null, setter.commandPropertiesDefaults, setter.threadPoolPropertiesDefaults, (HystrixCommandMetrics)null, (HystrixCommand.TryableSemaphore)null, (HystrixCommand.TryableSemaphore)null, (HystrixPropertiesStrategy)null, (HystrixCommandExecutionHook)null);
    }

Fourth:

To implement the HystrixComman override the run() method. This is where you will do all the task as per your requirement.
@Override
    protected String run() {
        // a real example would do work like a network call here
        return "Hello " + name + "!";
    }

Fifth:

The above created command be used like this :String s = new CommandHelloWorld("Bob").execute(); // this will internally call the run() method

Monday, October 5, 2015

Spring Core -- Interesting Observations



  1. Spring Framework -> It's programing model. 
  2. When doing Unit Test of Spring Application Try not to use Spring. Dependencies can easily be stubbed out for unit Testing.
  3. Used Java based configuration  as its more intuitive and easy to comprehend by Java programmer.
  4. If a Class want to have Fields which are mandatory for its creation/working make sure your use constructor for it. Try not to Auto-wire the private fields, It will be hard to test it.
  5. It is good practice to have a Integration Test for configuration to validate that your Spring Context only has bean which you intend to have.
  6. Try not to have schema version number in name space of your xml files, as correct version is automatically picked by Spring. Also it made easy for upgrade .  But if you add it  it does not add any value, but make your code hard to  upgrade.
  7. Try to have multiple configuration files one for each different aspect of your application.
  8. e.g application bean configuration. infrastructure configuration, rest configuration, soap configuration etc.
  9. User Spring Profile for managing your application based on different env.   Component which does not have any Profile annotation on it is always available along with the currently active profile components.
  10. Never rely on the Spring generated Names when using @Component can lead to run time issues.
  11. Java Configuration is arguably better than using @Component.


Transaction

Transaction will not work if you break the thread boundary. Transaction is Spring are stored in thread-local which are not  passed between threads.

So if a thread begins a transaction and in between your code you create a new thread then most probably your transaction wont work. as the newly created thread wont have the transaction element.


Constructor vs Setter Dependency when to use which?

Constructor :

  1. Mandatory fields
  2. Immutable dependencies
  3. Concise (pass several parameter at once).


Setter Dependency :

  1. Option /Changeable dependency
  2. Circular dependency
  3. Inherited automatically.