readytalk / cultivar Goto Github PK

Creating a service provider requires that a ZK client has already been started and thus throws an exception while the injector is being constructed. In the absence of this it will figure it out later on a retry, but there needs to be a way to effectively delay the ServiceProvider startup.

The project should be upgraded to gradle 2.0. This requires support from the released version of IntelliJ13 and updating the internal CI infrastructure (if necessary) to support the changes.

As a a server, I would like the ability to swap out the backend behind discovery to use system properties, so that rapid prototyping is easier and can be done without ZooKeeper running.

There are several features in Guice 4.0 which would fill use cases that we have strong use cases for in cultivar (e.g., OptionalBinder), Guice 4.0 will also support for Java 8, which Cultivar cannot support until that upgrade happens.

Criteria for upgrade:

• Guice 4.0 released.
• Internal projects moved to Guice 4.0.

As a deployment engineer, I would like the ability to tell a Cultivar-enabled service to unregister itself in a consistent way–preferably through ZK–without fully shutting down the system, so that I can do "grey shutdowns" where systems are not available for discovery, but are available for testing.

Once Cultivar goes public (Issue #24) there should be a concerted effort to find the parts of the interface that are stable and have been for at least a few months and mark these as non-beta as we move to non-SNAPSHOT releases.

Presently in readytalk.org for reasons relating to conversations that no longer apply. Move to readytalk.com.

As a Software Engineer in Test I would like the ability to override NodeContainer objects using System properties so that I can more easily override values in test environments.

At the moment the tests are all written in Java with JUnit. Scalatest has some nice features in this regard that cultivar can use and also there are some things (ConditionalWait, for example) that are painful to use for testing in a scala context that could be wrapped.

When a web server has both the shutdown hook and the web listener enabled it can cause a harmless but annoying error on shutdown.

Ideally:

• Both utilities should swallow or log at a lower level if the agent is already shutdown or was never started.
• Both utilities should awaitTerminated if something else is in the process of shutting down cultivar.

When starting up a new service following the directions in the getting started guide if one doesn't add any additional modules the service will crash when the CultivarStartStopManager is instantiated because there are no services for the ServiceManager to consume.

Proposed solution: No-op, bound-by-default service.

We should allow for multiple namespaces so that different components can look in common locations for configuration.

This is made slightly challenging because the CuratorFramework does not allow for namespaces to be declared before the client is started, which runs into trouble with how Cultivar wants to define everything up front. A decorator or some equivalent strategy can be used to circumvent this problem.

As a developer I would like the ability to map all string key:value pairs off of a particular node, so that I can easily inject all of the configuration variables for a system in one place.

As an engineer, I would like the ability to create() discovery objects using TypeLiterals, so that I can more easily create objects such as ServiceDiscovery<Map<String, String>>.

(While this specific example isn't a fantastic practice, it comes up often enough–and legitimately enough–to warrant some assistance. Depends on Issue #40).

Create a convenience registration for discovery purposes (using thisInstance), so that it is easier to have services adapt to a common registration and update pattern.

A follow-on to Issue #33.

The DistributedBarrier code and the Lock code uses a different pattern from the other components since it encourages the user to inject a factory rather than building the Distributed(Double)Barrier/DistributedLock object ahead of time. This should be brought into the same basic pattern as other components.

As a web application, I would like cultivar to easily support having a shutdown listener that terminates cultivar, so that I can unregister from cultivar at the right time.

Provide mocks for the Curator and Cultivar objects to allow for easy testing without actually spinning up a Zookeeper instance. This is a requested feature from the SETs.

CURATOR-169 causes the constructor for the NodeCache to block which slows down testing and initial service instantiation. While fixing CURATOR-169 will help fix this matter, abstracting any requirement for service start is not a bad thing for mocking objects down the road.

At the moment Cultivar is compiled and tested mostly with Java 6. We'd like to at some point in the future upgrade it to Java 7.

The current system will give an unhelpful error if the manager starts up that the manager is in state FAILED. Better logging is required around this.

As a developer, I would like to be able to use custom-built providers to allow for more advanced customization and injection of curator objects.

Presently the builders use their own providers and binding. The ability to add customized providers using a documented set of bindings would be of tremendous benefit. This would make cultivar more flexible and allow for more advanced use cases.

Essentially, in the current implementation, the code for building the components responsible for lifecycle management are joined to the components for building the object themselves. These could be cleanly split to allow you to set up the the lifecycle management aspects using the built-in providers or using your own.

The MetricsModule is registering the MetricsTracerDriver against TracerDriver, but not annotated with Curator. This needs to be corrected in order for the MetricsTracerDriver to be used.

As an implementing project I would like AbstractZookeeperClusterTest to accept parameterization, so that I can account for tests that take longer to spin up or tear down.

As a server, I would like a way to read a value from ZK that can be updated until I read it, but then will not change for the life of the program, so that I can store all of my config in ZK even if it gets updated for another process as part of a deploy.

The NodeContainer object keeps up-to-date with what is in ZK, but it also provides some useful utilities for interpreting values in a consistent fashion. It would be nice if this could be "locked" so that the first value it reads from ZK is the value it sticks with indefinitely (basically just reading the value rather than necessarily using a PathCache).

There should be an easy way to register a health check that checks for the successful registration of the service with ZK.

As a deployment engineer, I would like to see the number of services of a particular type that have populated the discovery cache, so that I can quickly diagnose problems and gain confidence in the discovery system.

See issue https://www.jfrog.com/jira/browse/GAP-153

Will need to re-upgrade to 2.0 once 2.2.4 is released.

Periodically (< 1 in 10) the test DistributedDoubleBarrierIntegTest#enter_BlocksUntilAllEnteredBlocksUntilAllLeft_AtLeast100Millis has failed with the log message "Thread finished without leaving" in what appears to be a spurious result. This requires some investigation to see why it might be failing here and improve logging around results.

Failure message:

java.lang.AssertionError: Thread finished without leaving.
    at org.junit.Assert.fail(Assert.java:93)
    at org.junit.Assert.assertTrue(Assert.java:43)
    at org.junit.Assert.assertFalse(Assert.java:68)
    at com.readytalk.cultivar.barriers.DistributedDoubleBarrierIntegTest.enter_BlocksUntilAllEnteredBlocksUntilAllLeft_AtLeast100Millis(DistributedDoubleBarrierIntegTest.java:161)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
    at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
    at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
    at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
    at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
    at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
    at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:46)
    at org.junit.internal.runners.statements.FailOnTimeout$StatementThread.run(FailOnTimeout.java:62)

Currently there's documentation in the README, but there should be more and more in-depth documentation in the wiki and/or GH pages.

Now that we are seeing a slightly broader adoption for cultivar internally, we should have a deeper conversation around what it would take to release a stable version for external consumption and open up the project.

As an engineer, I would like the metrics components split into a separate plugin so that I can can more easily work against a specific version of the metrics libraries or roll my own without bringing in the dropwizard dependencies.

Currently due to an issue with mockito-all we are using JUnit 4.10. Since JUnit 4.12 is in-progress it would be good to use see if we can get around using mockito-all and if the problems still persist in this case. Should upgrade to the newest version of Mockito at the same time.

Presently the system requires that you configure via ZK, which is great for retrofitting running systems but not necessarily great for testing scenarios (where not everything is a real instance) or for rapid prototyping (where the finalized discovery patterns are not in place). It would be useful to have tools in place to better facilitate this testing in containment.

As an application that depends on discovery, I would like applications to unregister even when shut down in an ungraceful way, so that I have faster feedback on failures.

Currently we depend on applications to unregister themselves. This is a perfectly acceptable pattern overall–applications know when they are about to shut down and can time it more effectively–but cultivar should provide tools to allow for a last-ditch effort.

Solution should:

• Be optional.
• Allow for a timeout on unregister, similar to Guava's getExitingExecutorService.
• Log and swallow any exceptions, rethrowing interrupted exceptions.

As an engineer developing with Cultivar, I would like there to be simple container objects for common discovery payloads so that I can quickly standardize common patterns.