2da77552ce8f2622bbb8cb5bb834aec6a47eb773 8749 |
|
16-Apr-2013 |
JnRouvignac |
(Matthew Swift reviewed) Code cleanup.
OperationWrapper.java:
Generecized the type of the wrapped operation.
Added protected method getOperation() that returns the wrapped operation.
AddOperationWrapper.java, BindOperationWrapper.java, CompareOperationWrapper.java, DeleteOperationWrapper.java, ModifyDNOperationWrapper.java, ModifyOperationWrapper.java, SearchOperationWrapper.java:
Added the generic type to the superclass OperationWrapper.
Got rid of specific instance members to old the operation with the correct type and called getOperation() instead. |
6a08e847c0bf292ea98401ad230d5db48b0b0a26 6754 |
|
25-Feb-2011 |
ludo |
Fix for OPENDJ-55: Failing modify operations causing memory leak.
The memory leak is happening when PreOperation plugins are aborting an update (like UniqueAttributePlugin).
Several issues with the whole plugin manager, preOperation and postOperation plugins.
1/ The postOperation method of a plugin was always called even when the PreOp was skipped. This is due to an error in the ModifyOperationWrapper equals method (A.equals(A) was always false). As a result, the concurrentHashMap of skipped plugins was never cleaned and leaked memory big time.
2/ The postOperation method for most of the registered plugin would not check if the operation was successful or not before processing. This could possibly create issues with Access Controls, Groups or Subentries.
3/ The UniqueAttributePlugin would not clean the concurrentHashMap of attribute values being checked for uniqueness, on errors. On success, it's done in the PostOperation method. On errors, the PostOperation method is not called, so the PreOp needs to cleans it before returning. For this we're now keeping a list of values added to the ConcurrrentHashMap, and remove them before returning an error. |