We suffer from the same problem as reported in HHH-2470.
MAT shows a growing heap consumption by the QueryPlanCache and growing number of NativeSQLQueryPlan and SQLCustomQuery. The numbers and heap consumption double when testing twice as long.
We see many duplicate NativeSQLQueryPlan objects on the heap.
HHH-2470 is reported as fixed by properly implementing equals and hashCode in NativeSQLQuerySpecification which is used as key in the cache.
It has NativeSQLQueryScalarReturn and NativeSQLQueryNonScalarReturn as possible members and those equals and hashCode methods are implemented in this fix.
When I look for differences between duplicates on the heap, I see that the key.queryString.hashCode is identical. Yet, the key.hashCode is *not*!
hashCodes are identical for those NativeSQLQueryScalarReturn objects in the queryReturns array which have a standard type like StringType. However, they are *not* identical if they have a CustomType!
NativeSQLQueryScalarReturn.equals calls type.equals and CustomType does not implement equals nor hashCode. So, it returns the identity equals and hashCode inherited from Object and the keys will not be equal (while they should be) and always have a cache miss and creating a new, duplicate, cache entry. It is thrashing the cache.
I don't understand why the keys need to be so complex with aliases and types in it. Doesn't the query string alone already uniquely identify the query plan? It also becomes expensive to check the keys for equality this way. |
|
