Skip to content

IGNITE-28920 Reduce MarshallableMessage scope: GridCacheEntryInfo uses marshal hooks only to rebase expireTime - #13447

Open
Vladsz83 wants to merge 18 commits into
apache:masterfrom
Vladsz83:IGNITE-28920-Reduce-MarshallableMessage-scope-GridCacheEntryInfo-uses-marshal-hooks-only-to-rebase-expireTime
Open

IGNITE-28920 Reduce MarshallableMessage scope: GridCacheEntryInfo uses marshal hooks only to rebase expireTime#13447
Vladsz83 wants to merge 18 commits into
apache:masterfrom
Vladsz83:IGNITE-28920-Reduce-MarshallableMessage-scope-GridCacheEntryInfo-uses-marshal-hooks-only-to-rebase-expireTime

Conversation

@Vladsz83

@Vladsz83 Vladsz83 commented Aug 7, 2026

Copy link
Copy Markdown
Contributor

Thank you for submitting the pull request to the Apache Ignite.

In order to streamline the review of the contribution
we ask you to ensure the following steps have been taken:

The Contribution Checklist

  • There is a single JIRA ticket related to the pull request.
  • The web-link to the pull request is attached to the JIRA ticket.
  • The JIRA ticket has the Patch Available state.
  • The pull request body describes changes that have been made.
    The description explains WHAT and WHY was made instead of HOW.
  • The pull request title is treated as the final commit message.
    The following pattern must be used: IGNITE-XXXX Change summary where XXXX - number of JIRA issue.
  • A reviewer has been mentioned through the JIRA comments
    (see the Maintainers list)
  • The pull request has been checked by the Teamcity Bot and
    the green visa attached to the JIRA ticket (see tab PR Check at TC.Bot - Instance 1 or TC.Bot - Instance 2)

Notes

If you need any help, please email dev@ignite.apache.org or ask anу advice on http://asf.slack.com #ignite channel.

…age-scope-GridCacheEntryInfo-uses-marshal-hooks-only-to-rebase-expireTime' into IGNITE-28920-Reduce-MarshallableMessage-scope-GridCacheEntryInfo-uses-marshal-hooks-only-to-rebase-expireTime

# Conflicts:
#	modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCacheEntryInfo.java
#	modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/GridDhtGetFuture.java
…ope-GridCacheEntryInfo-uses-marshal-hooks-only-to-rebase-expireTime
…age-scope-GridCacheEntryInfo-uses-marshal-hooks-only-to-rebase-expireTime' into IGNITE-28920-Reduce-MarshallableMessage-scope-GridCacheEntryInfo-uses-marshal-hooks-only-to-rebase-expireTime

# Conflicts:
#	modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCacheEntryInfo.java
@anton-vinogradov

Copy link
Copy Markdown
Contributor

An entry from a cache without an expiry policy now arrives already expired.

initTime == 0 is the "no expiration" mark, but initTime has no @Order, so it does not go on the wire, and the empty constructor the message factory uses always sets it:

public GridCacheEntryInfo() {
    initTime = System.currentTimeMillis();
}

So on the receiver initTime is never zero and expireTime() returns initTime + expireTimeDelta, the moment the message object was created. Every expiration check in the code reads that as expired, expireTime > 0 && expireTime <= U.currentTimeMillis().

  • sender, no expiry policy: initTime = 0, expireTimeDelta = 0, and only the delta is transferred
  • receiver: initTime = <read time>, expireTimeDelta = 0, expireTime() = <read time>

That is every entry of every cache that has no expiry policy, on rebalance and on every get response. On rebalance IgniteCacheOffheapManagerImpl.storeEntries puts the value into the data row, so the entries land with a pending expiration and the TTL thread removes them.

GridCacheRebalancingSyncCheckDataTest catches it. Green on master, red on bc38d2b:

[ERROR] Tests run: 1, Failures: 1 -- GridCacheRebalancingSyncCheckDataTest
GridCacheRebalancingSyncCheckDataTest.access$100:37->JUnitAssertAware.assertNotNull:180

Same thing at the unit level:

assertEquals(0, writeAndReadBack(entryInfo(0)).expireTime());

java.lang.AssertionError: expected:<0> but was:<1786287823668>

The mark has to live in a transferred field. -1 in the delta itself does that, and in the varint wire format it costs the same single byte as 0, so it is free. That, together with the clamp that keeps the negative range unambiguous, is what Vladsz83#1 does.

@github-actions

github-actions Bot commented Aug 9, 2026

Copy link
Copy Markdown

Possible compatibility issues. Please, check rolling upgrade cases

This PR modifies protected classes (with Order annotation).
Changes to these classes can break rolling upgrade compatibility.

Affected files:

  • modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCacheEntryInfo.java

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants