@VajramLogic
public static methodName(@BindFrom("dependency_name") DependencyResponse response){
 //
}

should be allowed

vajram build should fail if two resolvers resolve the same input of the same dependency

In *.vajram.yaml developer should be able to mark a dependency as fanoutEnabled: true/false.
This should tell the vajram-codegenerator that AllInputs.java should not dependency response. Instead it should have a ValueOrError - simplifying developer's task of accessing dependency values

This is currently for educational, readability and explicability purposes.
The idea is to design a high level programming language grammar that allows us to express the ideas of vajram/knode in a clear and concise manner.
This concise grammar and code can guide the design of vajrams in java to be as close to the ideal as possible.

At a later time, this programming language grammar can be developed into a full-fledged programming language (either JVM based, or otherwise) allowing us to write native vajrams without annotations and code generation.

Open question: What happens when a subset of requests fail in batch-call to a dependency?

Krystex should be able to inject inputs which have not been provided by client nodes.
This has to be done without adding any external 3rd party dependencies and clients should be able to use their own custom DI frameworks like Guice.

The current implementation is aimed to be generic and should work for IO Vajrams and Nodes as well. But most of the code is gated behind entity.isBlocking() checks. Remove these checks, test that IO Vajrams and Nodes are working, make necessary changes and add test cases for the same

Currently, Inputs is a final class encapsulating a map. This means every time we need to access any single input from the class we need to a ImmutableMap lookup. While an ImmutableMap lookup is O(1) and might be acceptable in common scenarios, this can add up to consume some significant (single digit %) CPU in a framework like Krsytal where we process thousands of requests per second and each request accesses inputs multiple times. While the ImmutableMap lookup might be inevitable in some scenarios, it can be avoided in other scenarios where the call is being made from inside vajram code which is data type and input schema aware, rather than krystex code which is data type and input schema unaware.

To take advantage of this difference, we can do the following:
We make Inputs class an interface and let the vajram-codegen auto-generate an implementation of Inputs. This implemented class will have the ability to access individual inputs without map look-ups if the caller knows the input name at compile time. Even in cases where the inputs are accessed from krystex, we can autogenerate a switch-cased input accessor which could be faster than a hash map lookup (This needs to be verified and quantified. Also, if switching over strings (input names) is slower, we can consider assigning a unique int id to each input, and use that to refer to inputs instead. This will definitely improve performance of random access of inputs from krystex since switching over integers is faster than switching over strings and looking up hashmaps - this improvement needs to be quantified as well.
Refs:
https://stackoverflow.com/questions/27993819/hashmap-vs-switch-statement-performance
https://web.archive.org/web/20180818151450/http://java-performance.info/string-switch-implementation/
https://stackoverflow.com/questions/12020048/how-does-javas-switch-work-under-the-hood
https://www.artima.com/articles/control-flow-in-the-java-virtual-machine
)

The implication of this is that Inputs equality can get affected. Currently two Inputs are equal if they have the same key value pairs. But with auto-generated Inputs implementations, this behaviour might no be possible to achieve. I don't think Krystal relies on this behaviour anywhere, so this change should be fine, but this has to be verified first.

• TypeSafe -
  • Devs should use type safe auto generated models to prime the cache
  • We should not allow wrong data types to be used - shoudl fail at compile time
• StrictPermissions
  • Cache Priming should be disabled by default - means no one should be able to prime Vajram T unless vajram T allows it explicitly

Open question:

• CommonCachePrimer? or Vajram specific cache primer

Currently VajramKryonGraph.validateMandatory is taking ~10% of the CPU of Kryon.executeMainLogicIfPossible. Most of this time is going in Stream processing and iteration.

I idea is to move this validation into auto-generated vajram models code so that we can omit iteration and stream processing. Instead we can custom generate a validation method which access each input explicitly. This way we can avoid Inputs.getInputValue lookup as well.

Simplifying IO Vajrams supporting Input modulation.

• New @demodulation annotation to consume the service client response
• Codegen for service client response failure handling in VajramImpl. This will include completing the futures (successfully or exceptionally)

The javadoc must be read and added to the facet metadata so that it is available as documentation

All data types should match the corresponding definitions in .vajram.yaml files instead of failing at runtime.

Provide a test harness where devs can mock dependency vajrams and write unit test cases

Vajram output type should be defined in the vajram yaml config file. This will eliminate adding vajram response type declaration in the dependency details. Also this can be used in identifying duplicate vajrams during build based on input and output type if required.

Refs:
https://opentelemetry.io/docs/
https://github.com/open-telemetry/opentelemetry-java

This ensures that pure functional programming is achieved

Implement a feature where vajram models are auto-generated whenever user edits and saves a .vajram.yaml file

NodeCommands should be written to the command queue iff the nodeCommand originates from a thread different from the main Thread (Like IO reactor threads). This way, we minimize monitor locking - since command queue is thread safe, and use monitor locking only when needed (when different threads need to access the command queue).

In past local NFRs it was found that Krystex throughput and latency saw significant improvement when the commandQueue usage was optimized by replacing ThreadPoolExecutor (which uses ArrayBLockingQueue internally) With ForkJoinPool (which has a more sharderd queue model to maximize concurrency) (See #83). This seems to be because of contention in the command queue.

With more and more compute nodes being added (We expect the number of compute nodes in the call graph to be at least an order of mangnitude more than io nodes), avoiding command queue usage when the node command originates from the main thread can give us close to java method call performance or in the same ballpark

When creating a dependent chain via fromTriggerOrder method, traverse the call graph and infer the node id.
In DependentChain class, change Optional<NodeId> to NodeId
Remove custom equals and hashcode

Instead, record it as an annotation on the request class so that annotation processor has access to it.

Currently Kryon.getSortedDecorators is taking up ~7.5% of the CPU of Kryon.executeMainLogicIfPossible.
Out of this 50% is being taken up by

logicExecutionContext ->
                vajram.getInputDefinitions().stream()
                    .filter(inputDefinition -> inputDefinition instanceof Input<?>)
                    .map(inputDefinition -> ((Input<?>) inputDefinition))
                    .anyMatch(
                        input ->
                            input.sources() != null
                                && input.sources().contains(InputSource.

which is inside VajramKryonGraph.registerInputInjector.
Computing this every time is not needed as this is static and does not change during the runtime of the application. We can cache this inside VajramDefinition and reuse it.

Problem:
Currently the ResolverCommand.Skip feature and the FlushCommand feature do not interoperate well.
When a node is skipped, it immediately returns, and does not interact with its dependencies.
But the Flush functionality of Krystex only works if every dependantChain reliably flushes all its dependencies.

Requirement:
When a node receives a SkipCommand, force flush all its dependencies.

Testing:
Add test case to cover this case :
A depends on B and B depends on C.
A skips B
A flushes B
B should Flush C

Added a "disabled" test case:
KrystexVajramExecutorTest#flush_skippingADependency_flushesCompleteCallGraph

Fix this bug and enable this test case.

Provide a way to define inputs, dependencies and output type of a vajram in annotations.
Implement an annotation processor which parses these annotation and auto-generated vajram models.
In effect, deprecate the *.vajram.yaml files

Users of Krystex should be able to

• Dump the complete call graph with inputs, outputs, exceptions and timestamps/latencies of each Kryon.
• The dump can be a json or it can be in a format which can be loaded in a browser where the complete call graph and the facet values can be viewed as an interactable Graph. The user should be able to filter node in the graph based on tags (IO, compute, service)

Resolvers and VajramLogic should be able to accept
Optional<T> for and only for optional inputs and optional dependencies with no fanout
ValueOrError<T> for and only for optional dependencies with no fanout

Change
@Resolve(value="dep_name", inputs = {"i1","i2"} ) to
@To(dep="dep_name", depInputs = {"i1","i2"} )
OR
@ResolveInputsOf(dep="dep_name", depInputs = {"i1","i2"} )

Change
@BindFrom to @From

Implement Caching decorator and remove the caching logic from Kryons so that we can pick and choose when to use caching and when not.

Rename Inputs class to Facets
Rename @VajramLogic to @Output

In cases where the VajramLogic cannot be called due to reasons like circuitBreaker being open or semaphore exhaustion, a simple function in the vajram with an annotation like @DefaultValue should be called to compute and return the default value of the vajram.

• The default value function's code cannot exit the JVM's boundaries (e.g no IO calls).
• The default value function should have access to the input values of the vajram (not the dependency values)

Open questions:

• Should the default value function have access to the exception thrown? (Need to collect use cases for this) (ref)
• If the above is true, should we allow multiple default value methods with different exception signatures? (ref)
• Should the default value be used only as a fallback in case of circuit open and bulkhead full? Or should clients have access to the default value for other scenarios like Timeouts, and other generic exceptions? (Need to collect use cases for this)

Plugin should be able to

• Show data type errors
• Show error for missing resolvers for dependency inputs
• Show cyclic dependency errors
• Show sub-optimal resolution errors
• Show error for duplicate resolvers
• Auto-generate resolver code
• Auto-generate vajram file skeleton via Create New (⌘N) action, and via quick actions on errors.

Separate Request and Session scoped injection into separate decorators and apply this where ever needed.

Change DependencyCommand hierarchy to remove SkipCommand interface, and introduce skipExecute() and skipMultuExecute().
Add validation such that a resolvers CANNOT return DependencyCommand - they can either return SingleExecute or MultiExecute

This will allow code generate to infer which dependencies have fanout enabled

Today, to create a shared Input modulator, the only way is to list the complete dependent chains which have to share the input modulator.

Provide a way to more easily configure shared modulators

The existing implementation of Krystal Executor is based on a single-threaded, event-loop based model. Implement an executor based on java virtual threads of JDK 20.

The idea is that such an executor will have simpler call stacks potentially making understanding error logs and debugging easier.

Provide a way to define a vajram in a single method(instead of the current construct of one class per vajram) to reduce boilerplate and ceremony. (For example: Producers Framework)

Try to make compiler check that dependency vajram and input being resolvred are same.

Rough analysis of CPU flame charts show significant usage of CPU by Stream pipelines
For example, in one instance, filtering a list by applying a condition and finding the first match is taking 5x more CPU than the condition itself.
This means out of all the streams being used in Krystal, upto 4x CPU is being wasted by Streams.
If this can be reclaimed by replacing streams with for loops over iterators, we should do that.

Code which makes IO calls which return CompletableFutures are called BlockingVajram and BlockingNode today. This is confusing. The code which is making IO calls don't actually block since they are using the non-blocking network call paradigm. These names need to be changed.

Suggestion:
Change Blocking to IO and NonBlocking to Compute (IOVajram, ComputeVajram, IONode, ComputeNode etc..)

The current implementation only supports vajrams where all of its dependencies are independent of each other and not wired to each other.

Even if we allow multiple decorators for the same type, at runtime for a given execution, only one should be used - we should not allow multiple decorators of same type to be applicable to the same node for the same execution instance.

Extends #110

#111 Added support for generative Vajram models on file save.
Enhance this implementation to support VajramaImpl as well.