Closed rju closed 1 week ago
author nils-christian -- Fri, 15 Aug 2014 14:06:09 +0200
I added a possible solution in a branch with ca20ec477a2006f2d9307ee1622ea18d98d2debc.
The solution allows to configure a limit for the cache:
## The maximal size of the signature cache. This is a weak limit, as the cache can exceed this size ## slightly in practical application. ## Set to 0 for an unbounded cache. kieker.monitoring.adaptiveMonitoring.maxCacheSize=0 # ## The behaviour of the signature cache, if the maximal size is bounded. ## 0: The cache ignores entries once the maximal size is reached. ## 1: The cache removes a (semi)random entry from the cache once the maximal size is exceeded. kieker.monitoring.adaptiveMonitoring.boundedCacheBehaviour=0
The limit is weak, as a stronger limit would require additional synchronization in the map. The cache allows two behaviours, shown in the above listing.
A perfomant and thread-safe LRU cache would require some more work, I guess.
Opinions on this before I merge it back into the master?
author RTSYS Techniker -- Thu, 21 Aug 2014 16:31:14 +0200
As discussed today: Use -1 for unbounded buffer; Add description; Add additional behaviour for complete clean; Sanity checks for values
author nils-christian -- Thu, 21 Aug 2014 17:29:16 +0200
Implemented and merged into the master with 3f5bb352d232e3c489c066a82e645f632164717d.
JIRA Issue: KIEKER-1169 Adaptive monitoring: Signature caches currently unbounded Original Reporter: Andre van Hoorn
As discussed today. One bad scenario would, for example, be an adaptation based on a timestamps or trace IDs.