Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GEODE-8856: Persist gateway-sender startup-action #7859

Open
wants to merge 2 commits into
base: develop
Choose a base branch
from

Conversation

jvarenina
Copy link
Contributor

New startup-action parameter with values "stop", "pause" and "start" is now persisted
during the runtime when following commands are issued:

  • pause gateway-sender --> startup-action="pause"
  • stop gateway-sender --> startup-action="stop"
  • start gateway-sender --> startup-action="start"
  • resume gateway-sender --> startup-action="start"

The startup-action parameter is persisted within cluster configuration when above gfsh
commands are executed successfully on at least one of the servers. Parameter is
not updated and persisted when commands are executed per member as
cluster configuration is not persisted in that case.

New startup-action parameter will now inter-work with manual-start in a following way:

  • If manual-start="true" and startup-action parameter is missing, then gateway sender
    will require manual start (same as before).
  • If manual-start is not set (or "false") and startup-action parameter is missing, then
    gateway sender will be started automatically (same as before).
  • If parameter startup-action is available in cluster configuration at startup,
    then gateway-sender will try to reach that state regardless of manual-start
    parameter value.

The manual-start is also improved in order to fully comply to above requirement to
start gateway sender in stopped state.

Current problem with manual-start parameter:

Currently, when manual-start is configured to be "true", then colocated persistent
parallel gateway sender queue region and buckets are not recovered after server
is restarted. Because of that the main persistent region that is colocated with
gateway sender queue region cannot reach online status.

Solution to manual-start problem implemented in this commit:

When manual-start parameter is "true" or gateway sender startup-action is "stop", then
persistent parallel gateway-sender queues will now be recovered (if needed) from
persistent storage during startup of the server. Queues will be recovered by using the
existing mechanism that is used when gateway sender is automatically recovered
(manual-start==false) after server is restarted. In this case parallel gateway sender
queue persistent region and buckets are recovered (if needed) right after the main
persistent region and buckets are recovered.

Additionally in above case, parallel gateway sender will now reach the same state
that it has when first started and then stopped by using gfsh command. In that state
parallel gateway sender queue buckets remain on the servers, but dispatcher threads are
stopped and non of the events are stored in queues.

For all changes:

  • Is there a JIRA ticket associated with this PR? Is it referenced in the commit message?

  • Has your PR been rebased against the latest commit within the target branch (typically develop)?

  • Is your initial contribution a single, squashed commit?

  • Does gradlew build run cleanly?

  • Have you written or updated unit tests to verify your changes?

  • If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?

New startup-action parameter with values "stop", "pause" and "start" is now persisted
during the runtime when following commands are issued:

    pause gateway-sender  --> startup-action="pause"
    stop gateway-sender   --> startup-action="stop"
    start gateway-sender  --> startup-action="start"
    resume gateway-sender --> startup-action="start"

Parameter is not updated and persisted when commands are executed per member as
cluster configuration is not updated in that case.

New startup-action parameter will now inter-work with manual-start in a following way:

  - If manual-start="true" and startup-action parameter is missing, then gateway sender
    will require manual start (same as before).
  - If manual-start is not set (or "false") and startup-action parameter is missing, then
    gateway sender will be started automatically (same as before).
  - If parameter startup-action is available in cluster configuration at startup,
    then gateway-sender will try to reach that state regardless of manual-start
    parameter value.
@jvarenina jvarenina marked this pull request as ready for review September 19, 2022 14:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
1 participant