session replication must be revived

[William Burke]

Quarkus  LC4J apps are stateful.  Since chats (human and agent to agent) require conversational state( chat memory and session state).  While using Q-LC4J with websockets gives you session capabilities, those session capabilities can't survive a restart.

We haven't dealt with session persistence and replication in many many years and I was involved a bit in the 2000s around EJB stateful bean replication.  We need a solution though, otherwise users are going to be managing stateful sessions themselves.

Who remembers the pitfalls of implementing statefull session persistence and replication?  Is an automatic solution viable?  I remember straight serialization being a shitshow at first because it saturated networks.  I know we implemented something in Infinispan and AOP that intercepted field writes and would do fine-grain replication.  Are those automatic solutions viable?

What about a manual HttpSession like API (get/set of a map).

What solutions can/should we offer?  I can certainly come up with one based on prior experiences, but I'd really like some input.

[1] https://github.com/quarkiverse/quarkus-langchain4j/pull/2452

[2] https://github.com/quarkiverse/quarkus-langchain4j/issues/1761

--

Bill Burke

IBM

[Eric Deandrea]

Doesn’t the micro services manual say that things should be stateless? 🙂

All kidding aside, wouldn’t a solution be to use some kind of backing store (Infinispan/redis/etc) to store conversations? Or thinking about something like a chat memory service, where the chat history was also offloaded to some other place, wouldn’t that solve the problem?

I’m not saying that some way to persist conversations isn’t needed, just trying to look at it from a different angle.

Eric Deandrea

Java Champion

Senior Principal Software Engineer

Quarkus | LangChain4j | Docling-Java

Red Hat

edea...@redhat.com    M: 603.453.5840

--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/CAL%3DE%3DjSfQ4zbK%2Bh3pXm5rL2H36fK8EvydRHoFYtU9A7bV8OxCA%40mail.gmail.com.

[William Burke]

On Tue, May 26, 2026 at 8:37 AM 'Eric Deandrea' via Quarkus Development mailing list <quark...@googlegroups.com> wrote:

Doesn’t the micro services manual say that things should be stateless? 🙂

Yeah, and modern web apps store state in the client.  Chat scopes for instance, originally had an HTTP only interface and had an SPI to store application state and a "client-side" chat memory store.  It required a programmatic API though to store session state.  I ditched it because Web Sockets supported sessions.

 

All kidding aside, wouldn’t a solution be to use some kind of backing store (Infinispan/redis/etc) to store conversations? Or thinking about something like a chat memory service, where the chat history was also offloaded to some other place, wouldn’t that solve the problem?

You're just repeating the question  I'm asking :)  what would the solution be?  There is already a plethora of chat stores for LC4J. but application state needs to be incorporated, which is why I'm asking this question.  I want something that has a nice integrated clean experience.  I don't want users to have to:

* managed @MemoryIds themselves

* Managed conversation boundaries themselves

* manage conversation state themselves

I alreayd created an API and programming model for this, I just don't have session recovery facilities.