bkkothari2255 commented on code in PR #86:
URL: 
https://github.com/apache/sling-org-apache-sling-models-impl/pull/86#discussion_r3035941975


##########
src/main/java/org/apache/sling/models/impl/AdapterImplementations.java:
##########
@@ -314,39 +316,71 @@ public Class<?> getModelClassForResource(final Resource 
resource) {
         return getModelClassForResource(resource, 
resourceTypeMappingsForResources);
     }
 
+    @SuppressWarnings("unchecked")
+    private static Map<Map<String, Class<?>>, Map<String, Object>> 
getModelClassCache(final ResourceResolver resolver) {
+        return (Map<Map<String, Class<?>>, Map<String, Object>>)
+                resolver.getPropertyMap().get(CACHE_KEY);
+    }
+
     protected static Class<?> getModelClassForResource(final Resource 
resource, final Map<String, Class<?>> map) {
         if (resource == null) {
             return null;
         }
         ResourceResolver resolver = resource.getResourceResolver();
         final String originalResourceType = resource.getResourceType();
+        if (originalResourceType.isEmpty()) {
+            return null;
+        }
+
+        Map<Map<String, Class<?>>, Map<String, Object>> cache = 
getModelClassCache(resolver);
+
+        if (cache == null) {
+            // Thread-safe Identity map to prevent O(N) deep equality checks 
on the massive map
+            cache = java.util.Collections.synchronizedMap(new 
java.util.IdentityHashMap<>());

Review Comment:
   > A `ResourceResolver` is not thread-safe, so this cache does not need to be 
thread-safe as well.
   
   You are absolutely right! 
   
   in a production environment, the `ResourceResolver` is tied to a single 
request and single thread, so it shouldn't need thread-safety
   
   However, during the maven build, I observed that during the integration 
tests (like AdapterFactoryTest), a single mocked `ResourceResolver` is actually 
shared across multiple threads. This contract violation in the test suite was 
corrupting the standard map buckets and causing the JVM to hang
   
   I added synchronizedMap purely as a workaround to keep the test suite passing
   
   If we prefer to keep the production code "pure" we can remove the 
synchronization and look into fixing the multi-threading in the test class 
instead 
   
   What do you prefer?



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to