Skip to content

Conversation

@DaveCTurner
Copy link
Contributor

It's unclear whether the age mentioned here is the age of the lock, or
just of the detailed state of the lock. This commit clarifies the
message.

It's unclear whether the age mentioned here is the age of the lock, or
just of the detailed state of the lock. This commit clarifies the
message.
@DaveCTurner DaveCTurner requested a review from ywangd September 5, 2025 07:36
@DaveCTurner DaveCTurner added >enhancement :Distributed Indexing/Store Issues around managing unopened Lucene indices. If it touches Store.java, this is a likely label. v9.2.0 labels Sep 5, 2025
@elasticsearchmachine elasticsearchmachine added the Team:Distributed Indexing Meta label for Distributed Indexing team label Sep 5, 2025
@elasticsearchmachine
Copy link
Collaborator

Pinging @elastic/es-distributed-indexing (Team:Distributed Indexing)

@elasticsearchmachine
Copy link
Collaborator

Hi @DaveCTurner, I've created a changelog YAML for you.

Copy link
Member

@ywangd ywangd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

"obtaining shard lock for [%s] timed out after [%dms], lock already held for [%s] with age [%dms]",
"""
obtaining shard lock for [%s] timed out after [%dms]; \
this shard lock is still held by a different instance of the shard and has been in state [%s] for [%s/%dms]""",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

different instance

I think this should be true. Just want to explicitly confirm it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In practice yes. If it were the same instance of the shard, it wouldn't be trying to acquire a fresh shard lock.

Technically it might not be an IndexShard instance that holds this lock, it could also be one of the processes that deletes unused shard data, but we don't see that happen here and IMO the phrase instance of the shard is sufficiently loosely defined to include those processes too.

@DaveCTurner DaveCTurner added the auto-merge-without-approval Automatically merge pull request when CI checks pass (NB doesn't wait for reviews!) label Sep 5, 2025
@elasticsearchmachine elasticsearchmachine merged commit 3ab03b7 into elastic:main Sep 5, 2025
33 checks passed
@DaveCTurner DaveCTurner deleted the 2025/09/05/obtaining-shard-lock-message branch September 5, 2025 08:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

auto-merge-without-approval Automatically merge pull request when CI checks pass (NB doesn't wait for reviews!) :Distributed Indexing/Store Issues around managing unopened Lucene indices. If it touches Store.java, this is a likely label. >enhancement Team:Distributed Indexing Meta label for Distributed Indexing team v9.2.0

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants