io.atomix.copycat.client.session.ClientSequencer Maven / Gradle / Ivy
/*
* Copyright 2016 the original author or authors.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License
*/
package io.atomix.copycat.client.session;
import io.atomix.copycat.protocol.OperationResponse;
import io.atomix.copycat.protocol.PublishRequest;
import java.util.ArrayDeque;
import java.util.HashMap;
import java.util.Map;
import java.util.Queue;
/**
* Client response sequencer.
*
* The way operations are applied to replicated state machines, allows responses to be handled in a consistent
* manner. Command responses will always have an {@code eventIndex} less than the response {@code index}. This is
* because commands always occur before the events they trigger, and because events are always associated
* with a command index and never a query index, the previous {@code eventIndex} for a command response will always be less
* than the response {@code index}.
*
* Alternatively, the previous {@code eventIndex} for a query response may be less than or equal to the response
* {@code index}. However, in contrast to commands, queries always occur after prior events. This means
* for a given index, the precedence is command -> event -> query.
*
* Since operations for an index will always occur in a consistent order, sequencing operations is a trivial task.
* When a response is received, once the response is placed in sequential order, pending events up to the response's
* {@code eventIndex} may be completed. Because command responses will never have an {@code eventIndex} equal to their
* own response {@code index}, events will always stop prior to the command. But query responses may have an
* {@code eventIndex} equal to their own response {@code index}, and in that case the event will be completed prior
* to the completion of the query response.
*
* Events can also be received later than sequenced operations. When an event is received, it's first placed in
* sequential order as is the case with operation responses. Once placed in sequential order, if no requests are
* outstanding, the event is immediately completed. This ensures that events that are published during a period
* of inactivity in the session can still be completed upon reception since the event is guaranteed not to have
* occurred concurrently with any other operation. If requests for the session are outstanding, the event is placed
* in a queue and the algorithm for checking sequenced responses is run again.
*
* @author © 2015 - 2025 Weber Informatics LLC | Privacy Policy