BridgeRequestScopeCacheImpl does not respect javax.portlet.faces.MAX_MANAGED_REQUEST_SCOPES

• Type: Bug
• Status: Closed
• Priority: Minor
• Resolution: Fixed
• Affects Version/s: 2.1.1-ga2, 3.0.1-legacy-ga2, 3.0.1-ga2, 3.1.1-ga2
• Fix Version/s: 2.1.2-ga3, 3.0.2-legacy-ga3, 3.0.2-ga3, 3.1.2-ga3, 3.2.x, 4.1.x
• Component/s: liferay-faces-bridge
• Labels: None
• Similar Issues: Show 5 results ; ;

  FACES-297	#{liferay.themeImagesURL} does not respect CDN
  FACES-233	Handle case of Chrome not respecting HttpServletResponse.SC_NOT_MODIFIED after redirect
  FACES-219	Optimization - assume that developers don't want the BridgeRequestScope preserved at the end of the RenderRequest
  FACES-210	PortletContainerFactoryImpl not respecting request attribute optimization
  FACES-1274	HttpServletRequestAdapter does not implement the PortletRequest interface

This issue was first mentioned in the following forum post:
http://www.liferay.com/community/forums/-/message_boards/view_message/18723724

In order to conserve memory, developers need to have more flexibility and control of the cache size.

[Neil Griffin]

Hi Jens,

I have been reading the JavaDoc specs for ConcurrentHashMap and also a blog titled ConcurrentHashMap Revealed in order to gain a better understanding of the problem.

Since the default value of "com.liferay.faces.bridge.bridgeRequestScopePreserved" is false, and now that the FACES-1445 and FACES-1463 memory leaks are fixed, the BridgeRequestScopeCache should not be causing java.lang.OutOfMemoryError anymore.

For example, consider the typical use-case of 10,000 users concurrently visiting a Liferay Portal page with a JSF portlet. That will cause 10,000 instances of BridgeRequestScopeImpl to be stored in the BridgeRequestScopeCache, but these instances will be removed at the end of the RENDER_PHASE of the portlet lifecycle.

In the forum post, you wrote:

The cache implementation extends the ConcurrentHashMap with the intention to limit the capacity [...] The setting MAX_MANAGED_REQUEST_SCOPES has no effect, because you can only set the initial and not the maximal capacity of a ConcurrentHashMap.

You are correct here – javax.portlet.faces.MAX_MANAGED_REQUEST_SCOPES doesn't work, because the ConcurrentHashMap doesn't have the ability to limit the number of map entries. Instead, it specifies the initial capacity of the ConcurrentHashMap.

You also wrote:

the size of a ConcurrentHashMap is fixed to 2^30.

But I am not sure that this is correct. According to the blog, as segments grow, they reach an ultimate capacity of 2^30.

Because of the performance benefits of ConcurrentHashMap in a multithreaded environment, we would like to keep ConcurrentHashMap as the base class. However, in order to implement the standard javax.portlet.faces.MAX_MANAGED_REQUEST_SCOPES feature, we could override the ConcurrentHashMap#put(key, value) method in order to achieve an LRU type of mechanism. But we think that the default value should be -1 or something like that, so that there is no-limit (unlimited) by default.

What do you think?

Thanks,

Neil

[Jens Meinecke]

I agree with you except one point: the limit of the map. I think it should be limited because of the robustness. What is the reason for an unlimited cache in your opinion?

Limitation of the cache means that elements will be overwritten every time in the worst case. So effectivly you feel like having no cache but your portal will run.

No limitation of the cache can end in another memory leak and your portal will crash in the worst case. Perhaps there is no other leak but you do not have control what the customers do in their portals. That is why I would prefer this way.

[Neil Griffin]

Hi Jens,

Thanks for getting back to us. We will override ConcurrentHashMap#put(key, value) and provide a way for you to set the max in your environment with javax.portlet.faces.MAX_MANAGED_REQUEST_SCOPES. That will also satisfy the JSR 329 spec requirement. We'll try and do it this week.

Best Regards,

Neil

[Neil Griffin]

The reason for the unlimited cache:

When "com.liferay.faces.bridge.bridgeRequestScopePreserved" is false, BridgeRequestScope is basically the same as RequestScope. So if 10,000 simultaneous requests come in, and the app server is able to handle it, then the BridgeRequestScopeCache should be able to handle it as well. Setting a default maximum would effectively limit the number of simultaneous requests.

[Jens Meinecke]

Ok, limiting the maximum of simultaneous requests is not an option. I thought if you limit a cache, you limit the number of elements can be accessed very fast (or stored), but not the maximum of elements can be processed through a cache.

I am not very familiar with the details of the JSF specification. So it is up to you now. I am sure you will make the right decision.

[Neil Griffin]

Thanks Jens, this issue is fixed now.