Uploaded image for project: 'Infinispan'
  1. Infinispan
  2. ISPN-1425

Incorrect settings [timeToLiveSeconds,maxIdleTimeSeconds] when default in REST

    XMLWordPrintable

Details

    • Bug
    • Resolution: Won't Do
    • Major
    • None
    • 5.1.0.ALPHA1
    • Remote Protocols
    • None
    • Hide

      Start a infinispan REST server
      Configure cache with <expiration lifespan="30000" maxIdle="30000" />
      POST a new entry without maxIdleTimeSeconds or timeToLiveSeconds HTTP header
      This new entry will survive all the time.

      Show
      Start a infinispan REST server Configure cache with <expiration lifespan="30000" maxIdle="30000" /> POST a new entry without maxIdleTimeSeconds or timeToLiveSeconds HTTP header This new entry will survive all the time.
    • Workaround Exists
    • Hide

      As indicated in the API documentation, you can get entries to be stored with configured expiration/lifespan settings passing 0 as parameters:
      https://docs.jboss.org/author/display/ISPN/Accessing+data+in+Infinispan+via+RESTful+interface

      Show
      As indicated in the API documentation, you can get entries to be stored with configured expiration/lifespan settings passing 0 as parameters: https://docs.jboss.org/author/display/ISPN/Accessing+data+in+Infinispan+via+RESTful+interface
    • Low

    Description

      If HTTP client didn't use
      timeToLiveSeconds or/and maxIdleTimeSeconds in all PUT/POST header request
      Cache entry will allways use -1 for timeToLiveSeconds and -1 for maxIdleTimeSeconds
      instead of current Cache settings

      Attachments

        1. Server.scala.ISPN-1425.patch
          1 kB
          Greg AUTRIC
        2. Server.scala.ISPN-1425.v2.patch
          1 kB
          Greg AUTRIC

        Issue Links

          is related to

          Enhancement - An enhancement to or refactoring of existing functionality that is not configurable by an end user (typically a change made by an internal team that affects users) ISPN-1307 REST protocol improvements for version 2

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Resolved

          Activity

            People

              rh-ee-galder Galder Zamarreño
              rh-gs-gautric Greg AUTRIC (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Time Tracking

                  Estimated:
                  Original Estimate - 2 hours
                  2h
                  Remaining:
                  Remaining Estimate - 2 hours
                  2h
                  Logged:
                  Time Spent - Not Specified
                  Not Specified