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

Gateway: Allow to configure a recovery_after_time and recover_after_nodes #223

Closed
kimchy opened this issue Jun 14, 2010 · 1 comment
Closed

Comments

@kimchy
Copy link
Member

kimchy commented Jun 14, 2010

Currently, when the first master starts up, it will recover the cluster state from the gateway and start to create indices immediately. This means that the first node (first master) will start allocating a lot of shards to itself (since other nodes might take time to join the cluster to share the load).

It would make sense to delay the recovery either by time or by cluster size. For example, to delay the recovery by time set:

gateway:
  recover_after_time: 1m

And to delay recovery after a certain cluster size has been reached:

gateway:
  recover_after_nodes: 5

Note, the two flags can be combined.

@kimchy
Copy link
Member Author

kimchy commented Jun 14, 2010

Gateway: Allow to configure a delay till index creation from gateway will occur, closed by 98df1b3.

ClaudioMFreitas pushed a commit to ClaudioMFreitas/elasticsearch-1 that referenced this issue Nov 12, 2019
Support for Activating License
williamrandolph pushed a commit to williamrandolph/elasticsearch that referenced this issue Jun 4, 2020
Reuse the unpacking/json-ification of complex objects
relates elastic#223

(cherry picked from commit 8d5b0ea94a9dfd0ebf616beb9eb57e33bf69a6bc)
williamrandolph pushed a commit to williamrandolph/elasticsearch that referenced this issue Jun 4, 2020
relates elastic#223

(cherry picked from commit 921c34145e26572352cb1a16c1d307c32a89c9d9)
mindw pushed a commit to mindw/elasticsearch that referenced this issue Sep 5, 2022
1.9 cherry picks 2021 09 02

* MPC-2533: Add polimi sandbox

* MPC-2684: Add ucf sandbox

* Add uc3m-c stack
costin pushed a commit that referenced this issue Dec 6, 2022
Resolves #221

Because ESQL needs to know the context of the current command to correctly parse its structure, command names need to be lexed as individual tokens if they occur in a position where a command name is expected (at the beginning of the query or after a pipe). But if the command name occurs in a different position, it acts as a normal identifier and should be lexed accordingly.

The easiest way to achieve this is to introduce two separate lexer modes. The default mode is used in the command context and the EXPRESSION mode is used when parsing the content of a command (expressions). Another lexer mode in the context of the from command could also be used to address #219.

Unfortunately, lexer modes are only supported if the parser and lexer are split into two separate grammars (not within a combined grammar). I tried to keep the diff caused by this split as minimal as possible but ANTLR does not make this very easy.

Alternatively, one could also allow the command tokens as an alternative for UNQUOTED_IDENTIFIER and then turn it into its string representation in the visitor. This approach is more brittle though as forgetting to add a command as a possible identifier can break existing queries. Additionally, it does not allow alternative lexer modes for commands that accepts arguments other than normal expressions.
costin pushed a commit that referenced this issue Dec 6, 2022
Resolves #219.

Extends the lexer modes introduced in #223 with another mode for commands accepting wildcard identifiers.
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant