[GitHub] marcaurele opened a new pull request #2913: Deactivate ehcache

[GitBox <gi...@apache.org>]

marcaurele opened a new pull request #2913: Deactivate ehcache
URL: https://github.com/apache/cloudstack/pull/2913
 
 
   ## Description
   
   This PR is for deactivating Ehcache in CloudStack since it is not usable. The first commit remove the default RMI cache peering configured for multicast which most of the time cannot work. It also requires to have an interface up which is not always the case while developing offline.
   The second commits remove the configuration to activate caching on some DAOs.
   
   ### Problems
   The code in CS does not seem to fit any caching mechanism especially due to the homemade DAO code. The main 3 flaws are the following:
   
   #### Entities are not expected to be shared
   There is quite a lot of code with method calls passing entity IDs value as `long`, which does some object fetching. Without caching, this behavior will create distinct objects each time an entity with the same ID is fetched. With the cache enabled, the same object will be shared among those methods. It has been seen that it does generate some side effects where code still expected unchanged entity attributes after calling different methods thus generating exception/bugs.
   
   #### DAO update operations are using search queries
   Some part of the code are updating entities based on a search query, therefore the whole cache must be invalidated (see GenericDaoBase: `public int update(UpdateBuilder ub, final SearchCriteria<?> sc, Integer rows);`).
   
   #### Entities based on views joining multiple tables
   There are quite a lot of entities based on SQL views joining multiple entities in a same object. Enabling caching on those would require a mechanism to link and cross-remove related objects whenever one of the sub-entity is changed.
   
   ### Final word
   Based on the previously discussed points, the best approach IMHO would be to move out of the custom DAO framework in CS and use a well known one (out of scope of this change of course). It will handle caching well and the joins made by the views in the code. It's not an easy change, but it will fix along a lot of issues and add a proven / robust framework to an important part of the code.
   
   
   ## Types of changes
   <!--- What types of changes does your code introduce? Put an `x` in all the boxes that apply: -->
   - [ ] Breaking change (fix or feature that would cause existing functionality to change)
   - [ ] New feature (non-breaking change which adds functionality)
   - [ ] Bug fix (non-breaking change which fixes an issue)
   - [ ] Enhancement (improves an existing feature and functionality)
   - [x] Cleanup (Code refactoring and cleanup, that may add test cases)
   
   ## How Has This Been Tested?
   A cluster of management servers with a manual ehcache RMI configuration has been setup to test different changes in the caching. The RMI cache setup has been verified though cache invalidation being propagated to the other server. A series of integration tests have been run, while figuring out the reason for (random) errors.
   

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services