u/supremeO11

I'm trying to validate whether this is a real problem that other Java developers face, or whether it's just something specific to my setup.

A while ago I was working on a project where I regularly had around 9 spring boot microservices running locally, along with Activemq and elasticsearch.

Quite a few times I'd hit a point where few services (very often Elasticsearch) simply wouldn't start because the machine was running out of memory. My usual soln was to manually lower the -Xmx of some services, restart them, and keep experimenting until everything fit.

It made me wonder:

- How common is this for people working with multiple JVM services locally?

- Do you just accept it and restart services with different heap sizes?

- Do you have fixed -Xmx values checked into your projects?

- Do you use Docker resource limits or just buy more RAM?

- Have you ever had to stop one service just to start another?

I'm also curious about production.

When services begin running into memory pressure:

- How do you usually detect whether it's a genuine memory leak or just increased load?

- How often do you end up changing heap sizes?

- Is this mostly handled by Kubernetes/VPA/manual tuning, or is it still a fairly manual process?

The reason I'm asking is that I've been experimenting with an idea for a tool that continuously watches JVM heap usage, tries to distinguish memory leak from normal load, and could automatically rebalance heap allocations (or restart a JVM with a better heap size when necessary) instead of requiring manual tuning.

I'm not trying to promote anything I'm still in the research stage and genuinely want to know whether I'm solving a real problem or one that only I experienced.

I'd really appreciate hearing how people currently deal with this in both local development and production.

I've been working on an open-source runtime engine for Java, OxyJen, which went from sequential chain to complete Directed Acyclic Graph. Most AI frameworks push you toward hidden execution and agent loops. OxyJen v0.5 goes the other way: workflows are explicit graphs with typed nodes, bounded concurrency, clear failure paths, and deterministic control flow. It is not just an LLM helper anymore.

What v0.5 gives you:

- SchemaNode - structured extraction with schema validation and retry

- LLMNode - direct model-backed steps

- LLMChain - retries, fallback, timeouts, and backoff

- BranchNode - mutually exclusive routing

- RouterNode - multi-path fan-out

- ParallelNode - deterministic pure-Java parallel work

- MergeNode - explicit fan-in

- MapNode - batch workflows over collections

- GatherNode - collection, filtering, and aggregation

- RouteEdge and FailureEdge - explicit router and failure semantics

- connectAnyFailureTo(...) - failure routing, makes recovery, fallback, and error aggregation as part of the graph itself.

The graph DSL lets you build workflows with fluent routing, conditional edges, loops, failure paths, and batch/concurrent flows. Real execution logic lives in code as a graph, not buried inside a sequential chain.

ParallelExecutor runs the DAG with a shared ExecutionRuntime — concurrency, timeouts, and failure behavior controlled centrally.

Small example:

```java

javaGraph graph = GraphBuilder.named("doc-flow")

.addNode("extract", SchemaNode.builder(Document.class)

.model(chain).schema(schema).build())

.addNode("router", RouterNode.<Document>builder()

.route("summary", d -> true, "summaryPrompt")

.route("risk", d -> true, "riskPrompt")

.route("actions", d -> true, "actionsPrompt")

.build("router"))

.addNode("checks", ParallelNode.<Document, String>builder()

.task("amount", d -> hasAmount(d) ? "ok" : "missing")

.task("date", d -> hasDate(d) ? "ok" : "missing")

.build("checks"))

.addNode("merge", new MergeNode.Builder()

.expect("summary", "risk", "actions", "checks")

.build("merge"))

.connect("extract", "router")

.connect("router", "summaryPrompt")

.connect("router", "riskPrompt")

.connect("router", "actionsPrompt")

.connect("checks", "merge")

.connect("summary", "merge")

.connect("risk", "merge")

.connect("actions", "merge")

.build();

```

If you need any of these, OxyJen has it:

- Structured extraction with typed outputs -> SchemaNode

- Fan-out to multiple parallel analyses -> RouterNode

- Deterministic local checks -> ParallelNode

- Explicit fan-in of partial results -> MergeNode

- Batch processing over collections -> MapNode + GatherNode

- Graph-level failure routing -> connectAnyFailureTo(...)

Built for document extraction, support triage, batch enrichment, compliance pipelines, and any complex DAG system where AI components need to stay observable, bounded, and predictable.

This version took around 3 months to build. There's a lot not covered here. I would suggest going through the docs to know what this version and Oxyjen are trying to be.

GitHub: https://github.com/11divyansh/OxyJen

Docs: https://github.com/11divyansh/OxyJen/blob/main/docs/v0.5.md

You can check out the examples to understand how the system works. It's marked with comments to for better understanding.

Examples with full logs: https://github.com/11divyansh/OxyJen/tree/main/src/main/java/examples

It's still very early stage any feedback/suggestions on the API or design is appreciated. Contributions are welcomed.

I've been working on an open-source runtime engine for Java, OxyJen, which went from sequential chain to complete Directed Acyclic Graph. Most AI frameworks push you toward hidden execution and agent loops. OxyJen v0.5 goes the other way: workflows are explicit graphs with typed nodes, bounded concurrency, clear failure paths, and deterministic control flow. It is not just an LLM helper anymore.

What v0.5 gives you:

- SchemaNode - structured extraction with schema validation and retry

- LLMNode - direct model-backed steps

- LLMChain - retries, fallback, timeouts, and backoff

- BranchNode - mutually exclusive routing

- RouterNode - multi-path fan-out

- ParallelNode - deterministic pure-Java parallel work

- MergeNode - explicit fan-in

- MapNode - batch workflows over collections

- GatherNode - collection, filtering, and aggregation

- RouteEdge and FailureEdge - explicit router and failure semantics

- connectAnyFailureTo(...) - failure routing, makes recovery, fallback, and error aggregation as part of the graph itself.

The graph DSL lets you build workflows with fluent routing, conditional edges, loops, failure paths, and batch/concurrent flows. Real execution logic lives in code as a graph, not buried inside a sequential chain.

ParallelExecutor runs the DAG with a shared ExecutionRuntime where concurrency, timeouts, and failure behavior controlled centrally.

Small example:

```java

javaGraph graph = GraphBuilder.named("doc-flow")

.addNode("extract", SchemaNode.builder(Document.class)

.model(chain).schema(schema).build())

.addNode("router", RouterNode.<Document>builder()

.route("summary", d -> true, "summaryPrompt")

.route("risk", d -> true, "riskPrompt")

.route("actions", d -> true, "actionsPrompt")

.build("router"))

.addNode("checks", ParallelNode.<Document, String>builder()

.task("amount", d -> hasAmount(d) ? "ok" : "missing")

.task("date", d -> hasDate(d) ? "ok" : "missing")

.build("checks"))

.addNode("merge", new MergeNode.Builder()

.expect("summary", "risk", "actions", "checks")

.build("merge"))

.connect("extract", "router")

.connect("router", "summaryPrompt")

.connect("router", "riskPrompt")

.connect("router", "actionsPrompt")

.connect("checks", "merge")

.connect("summary", "merge")

.connect("risk", "merge")

.connect("actions", "merge")

.build();

```

If you need any of these, OxyJen has it:

- Structured extraction with typed outputs -> SchemaNode

- Fan-out to multiple parallel analyses -> RouterNode

- Deterministic local checks -> ParallelNode

- Explicit fan-in of partial results -> MergeNode

- Batch processing over collections -> MapNode + GatherNode

- Graph-level failure routing -> connectAnyFailureTo(...)

Built for document extraction, support triage, batch enrichment, compliance pipelines, and any complex DAG system where AI components need to stay observable, bounded, and predictable.

This version took around 3 months to build. There's a lot not covered here. I would suggest going through the docs to know what this version and Oxyjen are trying to be.

GitHub: https://github.com/11divyansh/OxyJen

Docs: https://github.com/11divyansh/OxyJen/blob/main/docs/v0.5.md

You can check out the examples to understand how the system works. It's marked with comments for better understanding.

Examples with full logs: https://github.com/11divyansh/OxyJen/tree/main/src/main/java/examples

It's still very early stage any feedback/suggestions on the API or design is appreciated.

Hi everyone,

If you're looking to upskill, build something meaningful for your portfolio, or get involved in a growing open-source project, I've got something interesting.

I'm currently building **Oxyjen** - an open-source Java-based graph orchestration framework (think DAG execution + Al workflows). The goal is to make it easy to define and run complex pipelines with clean abstractions.

We're now moving into **v0.5** , where a lot of core architecture is being shaped:

- execution runtime

- parallel + fault-tolerant nodes

- graph DSL improvements

Since this is an active development phase, **documentation is still catching up**, and that's actually where contributors can have a big impact.

Teck stack: Java (Core), Concurrency, Graph/DAG Processing, System design, LLM pipelines

###What you can work on:

- improving / writing docs (high priority)

- small features & utilities

- testing and examples

- understanding and refining the DSL

###Why contribute?

- real system design exposure (not just CRUD)

- visible impact on architecture decisions

- great addition to your portfolio

- recognition for contributions

If you're interested in contributing or just exploring:

https://github.com/11divyansh/OxyJen

I'll add good first issues for the beginners soon.

Even if you're a beginner, feel free to jump in, ask questions, or pick up small issues.

Let's build something solid