-
Notifications
You must be signed in to change notification settings - Fork 0
FAQ
Common questions about using and operating Vyra.
vyra-core is intentionally designed with zero third-party dependencies. It bundles neither Jackson nor Gson, so you don't inherit library version conflicts in your project. Choosing your serializer explicitly makes the wire format a deliberate architectural decision. See Serialization.
Yes. The vyra-inmemory module provides an in-memory transport that runs completely inside the JVM without Docker or network dependencies. It works well for unit tests, mocking, and local development. See Transports.
Yes. Because Vyra relies on plain Java records and standard CompletionStage APIs with zero DI or bytecode reflection, you can declare Vyra as a Spring @Bean or inject it into your service classes.
Launch multiple instances of your service that register a handler for the same target (e.g. vyra.handle("billing", ...)). The transport distributes incoming requests across all available workers in a round-robin worker queue.
The pending request is removed from memory, and the caller's CompletionStage immediately completes exceptionally with a VyraTimeoutException. If the remote worker finishes later and replies, Vyra safely discards the late response without leaking memory. See Timeouts & errors.
No. Events are delivered at-most-once: if a subscriber is offline when an event is published, the event will not be delivered when it restarts. For guaranteed delivery or work processing, use Request / response.
Use vyra.broadcastRequest("target", req, Response.class, timeout). It broadcasts the request to all nodes handling the target (bcast:<target>). Handlers that cannot answer or do not own the entity return null (or complete with null) and stay silent. The first node that returns a non-null response completes the request stage directly to the caller (res:<clientNodeId>), while subsequent responses are safely discarded. See Request / response.
Not directly, because Java erases generic type parameters at runtime (List<Player>.class is not valid Java syntax). Instead, wrap the list inside a concrete record:
public record PlayerListResponse(List<Player> players) {}See Best practices.
No. All nodes sharing the same transport must adhere to the uniform network constraint and use the same serializer. Mixing formats (e.g. Smile and JSON) will cause envelopes to be dropped with a warning. See Serialization.
Google Gson treats untyped JSON numbers as Double by default, which loses precision for 64-bit integers exceeding String or BigDecimal, or use JacksonSerializer instead.
No. Vyra isolates network I/O threads (async event loops and dedicated blocking worker-queue threads) from user logic. User handlers and deserialization are immediately submitted to a separate handler executor. Even if a handler blocks on a slow SQL query, the network loops remain fully responsive. See Concurrency.
You are. Following the lifecycle rule (supplied = yours, created = ours), calling vyra.close() closes only the connections opened by that specific Vyra instance. It never shuts down the underlying RedisClient, allowing you to share the client safely across multiple services or DAOs. See Configuration.
Vyra will attempt to deserialize the envelope. If it fails, Vyra logs a warning describing the unparseable message and safely drops it. The node will never crash.
- Read the beginner's tutorial in Getting started.
- Explore production design patterns in Best practices.
Vyra documentation