Abstract: An approach is provided for sharing valid token(s) across application instances. If refresh token rotation is used, (i) a token request is received which includes a number of tokens required, (ii) access and refresh token pairs are generated and shared so that a total number of the pairs equals the number of tokens, and (iii) the access and refresh token pairs are sent to a client so that in response to token requests, the application instances obtain respective access and refresh token pairs. If refresh token rotation is not used, (iv) a request for a refresh token is received, (v) an existing access token is validated, where the access token is bound to the refresh token, and (vi) if the existing access token is expired, a new access token is generated and sent to the client; otherwise, the existing access token is sent to the client.

Abstract: An approach is provided for sharing valid token(s) across application instances. If refresh token rotation is used, (i) a token request is received which includes a number of tokens required, (ii) access and refresh token pairs are generated and shared so that a total number of the pairs equals the number of tokens, and (iii) the access and refresh token pairs are sent to a client so that in response to token requests, the application instances obtain respective access and refresh token pairs. If refresh token rotation is not used, (iv) a request for a refresh token is received, (v) an existing access token is validated, where the access token is bound to the refresh token, and (vi) if the existing access token is expired, a new access token is generated and sent to the client; otherwise, the existing access token is sent to the client.

Abstract: An approach is provided for sharing valid token(s) across application instances. If refresh token rotation is used, (i) a token request is received which includes a number of tokens required, (ii) access and refresh token pairs are generated and shared so that a total number of the pairs equals the number of tokens, and (iii) the access and refresh token pairs are sent to a client so that in response to token requests, the application instances obtain respective access and refresh token pairs. If refresh token rotation is not used, (iv) a request for a refresh token is received, (v) an existing access token is validated, where the access token is bound to the refresh token, and (vi) if the existing access token is expired, a new access token is generated and sent to the client; otherwise, the existing access token is sent to the client.

Abstract: An approach is provided for sharing valid token(s) across application instances. If refresh token rotation is used, (i) a token request is received which includes a number of tokens required, (ii) access and refresh token pairs are generated and shared so that a total number of the pairs equals the number of tokens, and (iii) the access and refresh token pairs are sent to a client so that in response to token requests, the application instances obtain respective access and refresh token pairs. If refresh token rotation is not used, (iv) a request for a refresh token is received, (v) an existing access token is validated, where the access token is bound to the refresh token, and (vi) if the existing access token is expired, a new access token is generated and sent to the client; otherwise, the existing access token is sent to the client.

Abstract: A first queue stores messages to be consumed. A second queue temporarily stores completely duplicative messages that have message identifiers equal to message identifiers of messages currently being processed s and that have times equal to times of the messages being processed; processing of the completely duplicative messages never occurs. By comparison, a partially duplicative message has its processing delayed until the message of which it is partially duplicative has been finished being processed. A partially duplicative message has a message identifier equal to a message identifier of a message referenced within the non-persistent store and has a time unequal to a time of the message referenced within the non-persistent store is moved from the first to the second queue. A non-persistent store stores references to the messages currently being processed. Once the messages are finished being processed, the references to them are removed from the non-persistent store.

Abstract: A first queue stores messages to be consumed. A second queue temporarily stores completely duplicative messages that have message identifiers equal to message identifiers of messages currently being processed s and that have times equal to times of the messages being processed; processing of the completely duplicative messages never occurs. By comparison, a partially duplicative message has its processing delayed until the message of which it is partially duplicative has been finished being processed. A partially duplicative message has a message identifier equal to a message identifier of a message referenced within the non-persistent store and has a time unequal to a time of the message referenced within the non-persistent store is moved from the first to the second queue. A non-persistent store stores references to the messages currently being processed. Once the messages are finished being processed, the references to them are removed from the non-persistent store.