Hystrix without Archaius

[daijithegeek]

Hi,

I tried to implement a custom HystrixPropertiesStrategy, based on our company configuration mechanism. I was wondering if it is possible to get rid of the Archaius dependency as I really do not want to use it.

Indeed, any HystrixCommandProperties implementation need to call the super() constructor which enables Archaius class access.

Another option is to implement an configuration datasource for Archaius based on our configuration mechanism. I'm not a big fan of it for different reasons. The main one is the fact that I am currently developing a library, and archaius comes with guava and commons-everything dependencies. Therefore I will force library client to get those dependencies, adding many potential conflict on their side.

Am I missing something important there ? Is there a better way?

Thank you!
David

[benjchristensen]

Implementing HystrixPropertiesStrategy is the correct approach and I agree with your reasons. I was able to keep metrics publishing (Servo/Yammer) completely out by defaulting to doing nothing but the systems needs properties so I had to choose a default implementation that it ships with and Archaius is it.

It appears I messed up in the implementation of HystrixCommandProperties and accidentally am directly using HystrixPropertiesChainedArchaiusProperty. At some point I leaked that into it and it needs to be abstracted away behind a HystrixPropertiesChainedProperty interface.

If that gets fixed then you should be able to implement the plugin and exclude Archaius from the dependencies. Would that solve your need?

Do you have time to try doing this refactoring and submit a pull request to fix this (as I'm busy with several other priorities right now)? If so I'll review (and make tweaks if necessary) and accept the change and release a new version for you.

[daijithegeek]

I think it will solve the need.

I'm also short in time, but I will try to spend some time on the issue during the next days. Thank you for the proposal anyway!

[benjchristensen]

@daijithegeek Did anything further come out of this?

[daijithegeek]

Still interested, but did not manage to spend some time on it. Moreover I'm not involved on the project using Hystrix any more. I won't be able to work on it during working hours :/

[MaJunFeng]

hi
Also,I want to implement a custom HystrixPropertiesStrategy, based on our company configuration mechanism. I don't want to use Archaius, and am upset that the method "getProperty" of HystrixCommandProperties contains HystrixPropertiesChainedArchaiusProperty directly. the method "getProperty" is in the constructor of HystrixPropertiesStrategy, and it's modifier is private,which means I can't overide this method with extending HystrixCommandProperties.

why not let the method "getProperty" be private, and move it behind a HystrixPropertiesChainedProperty interface,such as in the HystrixPropertiesCommandDefault. Then we can overide getProperty and get rid of Archaius.

Is there a graceful way to get what I wanted?

Thank you!

[benjchristensen]

Sorry, I don't fully understand. What getProperty method are you referring to?

You can override any of the properties like this:

package hystrix;

import com.netflix.hystrix.HystrixCommandKey;
import com.netflix.hystrix.HystrixCommandProperties;
import com.netflix.hystrix.HystrixCommandProperties.Setter;
import com.netflix.hystrix.strategy.properties.HystrixPropertiesStrategy;
import com.netflix.hystrix.strategy.properties.HystrixProperty;

public class HystrixPropertiesPlugin extends HystrixPropertiesStrategy {

    @Override
    public HystrixCommandProperties getCommandProperties(HystrixCommandKey commandKey, Setter builder) {
        return new MyCommandProperties(commandKey, builder);
    }

    public static class MyCommandProperties extends HystrixCommandProperties {

        protected MyCommandProperties(HystrixCommandKey key, com.netflix.hystrix.HystrixCommandProperties.Setter builder) {
            super(key, builder);
        }

        @Override
        public HystrixProperty<Integer> executionIsolationSemaphoreMaxConcurrentRequests() {
            // done using Factory
            return HystrixProperty.Factory.asProperty(123456);
        }

        // ... etc ...

        @Override
        public HystrixProperty<Boolean> circuitBreakerForceClosed() {
            // or by implementing directly
            return new HystrixProperty<Boolean>() {

                @Override
                public Boolean get() {
                    return false;
                }

            };
        }

    }

}

If the above does not work for you and you'd like to propose changes that will make things easier to use, while retaining backwards compatibility, I'm open to reviewing your proposal and considering it for merging into the project.

[MaJunFeng]

I understand your way.Indeed, it works by Overriding executionIsolationSemaphoreMaxConcurrentRequests method in HystrixCommandProperties,but there are two problems in this way:
1.I have to invoke super(key, builder) int the constructor of MyCommandProperties ,which will eventually invoke getProperty method in HystrixCommandProperties,like this:

 private static HystrixProperty getProperty(String propertyPrefix, HystrixCommandKey key, String instanceProperty, Boolean builderOverrideValue, Boolean defaultValue) {
        return asProperty(new HystrixPropertiesChainedArchaiusProperty.BooleanProperty(
                new HystrixPropertiesChainedArchaiusProperty.DynamicBooleanProperty(propertyPrefix + ".command." + key.name() + "." + instanceProperty, builderOverrideValue),
                new HystrixPropertiesChainedArchaiusProperty.DynamicBooleanProperty(propertyPrefix + ".command.default." + instanceProperty, defaultValue)));
    }

and the getProperty method contains HystrixPropertiesChainedArchaiusProperty etc. which is not what I want.
In a word,it's inevitable that facing HystrixPropertiesChainedArchaiusProperty etc. which involves Archaius.
2.When Overriding executionIsolationSemaphoreMaxConcurrentRequests method in HystrixCommandProperties,I can't use the default value,such as default_metricsRollingStatisticalWindow any more,because all of the modifier of default value in HystrixCommandProperties is private.

My suggestion is like this:
let the modifier of getProperty method in HystrixCommandProperties be abstract,and move the original getProperty method body into HystrixPropertiesCommandDefault.Then we can implement getProperty method by wrap HystrixProperty in MyCommandProperties base on our company configuration mechanism,and does not involve Archaius,and can also use the default value in HystrixCommandProperties.

Do my words convey my meaning to you?

Thank you!

[benjchristensen]

it's inevitable that facing HystrixPropertiesChainedArchaiusProperty etc. which involves Archaius.

Yes you're correct. It is the default system for properties. You can however ignore it and it won't affect you if you override everything.

What problem is it causing for you, other than the jar existing in your application? If you ignore Archaius (don't configure it with any sources) all it does is serve the defaults.

I can't use the default value

The point of defining a plugin is to define your own values and override the default implementation.

However, if you want access to the defaults, you could delegate to the super methods if your configuration source doesn't have the value. Or, use Archaius. You can hook Archaius into your configuration system so your system acts as the datasource for Archaius. It is fully expected that most places will have existing configuration systems which is why Archaius is a pluggable solution. It is used in Hystrix because of the API that allows chaining, polling, dynamic updates, etc. Your company wouldn't need to concern itself with Archaius, it would just be a ConfigurationSource that allows Hystrix to get access to the properties from your configuration system.

The Archaius documentation has some docs for creating your own ConfigurationSource: https://github.com/Netflix/archaius/wiki/Features#a-polling-framework-for-dynamic-configuration-sources

My suggestion is like this ...

As I stated earlier, feel free to provide a pull request proposing the changes, as long as they are backwards compatible. If you don't want to attempt that, this will have to sit for a while as I don't have the time to pursue it right now.

I'm fine with the desire to eliminate Archaius completely and open to non-breaking changes that improve the ability to define a plugin (this is why I use abstract classes rather than interfaces, so changes can be made). In retrospect I probably should have kept Archaius out of hystrix-core the same as I did with the metrics publishers, but I didn't as I felt Archaius was configurable enough. However, since this is not a big enough reason to do breaking changes and bump the major version from 1.x -> 2.x, all changes will need to be backwards compatible and Archaius will have to continue to exist as the default.

Hope this direction helps.

[MaJunFeng]

Ok, i understand it.
I will implement an configuration datasource for Archaius based on our configuration mechanism.
Thank you very much!

[benjchristensen]

I tried pulling Archaius out and it became a mess. I don't think I can do it without breaking changes which means I can't do it in the 1.x series and I have no intention of a 2.x version right now. Thus we need to live with Archaius as a required dependency and I'm closing out this issue.

[agentgt]

I would not have a problem with the Archaius dependency if Archaius itself did not depend on so many things that have static initialization (most notably SLF4J and commons-logging).

There really needs to be a boot strap configuration library that does not depend on a logger or various other infrastructure as you get a nice chicken and egg problem of who does the initial configuration. For example you cannot configure your logging infrastructure with Archaius because it will already have instantiated logging. While you can possibly just live with the fact that your logging infrastructure will have to reinitialize this has historically been problematic with libraries such as logback (in fact there was no way to control the initialization of logback till I filed a bug).

One of the ways to mitigate dispatching to an implementation with out relying on system properties or environment variables is to use the JDK Service Loader (which is what I did for logback). Consequently depending on what jars are in the classpath the right plugins would then be loaded automatically.

TLDR ... depending on libraries that have any sort of dependency of static initialization is hard to remove and makes it difficult for those who care about initialization (usually logging is the primary issue).

[mattrjacobs]

@agentgt I agree 100%. I'll be working on this soon

[agentgt]

For future folks that land here see #970 and #252