Uploaded image for project: 'Spring Data Redis'
  1. Spring Data Redis
  2. DATAREDIS-748

Spring Data Redis indexes not cleaned up when setting TTLs

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Works as Designed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      When using the Spring-data-redis library to manage repositories, Spring creates new keys and sets under the hood to facilitate various type of key lookups. I noticed that when we set TTLs on the same objects (as opposed to a straight delete), these additional keys (indexes) and set members don't get deleted.
      This has caused us to run out of disk space on the redis server as the associated keys never get removed.

      More details:
      In my setup, lets say I have a PersonRepository storing a Person class. The Person class (hash is "person") has say a bunch of fields, of note - name (identifier), email (indexed) & ttl (default value 0). Now lets say the first time the person object gets saved, the TTL is not set as expected as its 0. A bunch of other objects get created and updated, like person:johnsmith:idx etc.

      Now when I go ahead and update the object by reading it (say using repo.findOne()), updated the ttl value to something and saved - the TTL gets set as expected. At this point, once the key expires, the related indices and key references do not get removed. If instead of updating (the TTL) on the object, we went ahead and straight away deleted, I believe the references get removed.

        Attachments

          Activity

            People

            Assignee:
            mp911de Mark Paluch
            Reporter:
            ideazinfinite Rajesh A
            Last updater:
            Mark Paluch
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: