[JBoss Cache: Core Edition] - Caching JSP output does JBoss cache support this
by hicnar
Hi,
I've skimmed through the JBoss cache users guide looking for any info about the possibility to employ JBoss Cache for caching jsp/servlet responses. There's a very old entry on this forum ( see http://www.jboss.com/index.html?module=bb&op=viewtopic&t=56775 ) suggesting that this was considered once.
A bit more about what caching functionality needed.
We need to cache documents generated by JSPs and servlets, but the content returned to the client may vary depending on the IP address the user connects from. For example it is entirely possible that a url address typed in a browser from the US territory will result in a different response than exactly the same url but requested from the UK. We already have a mechanism for obtaining the territory code based on the IP address as returned by the ServletRequest.getRemoteAddr().
I would imagine the solution in form of an intercepting filter (which all requests to be cached pass through) getting the territory info based on the IP and then preparing the caching key and consulting the cache for potentially ready response.
Is there anything like this already available in the JBoss Cache? Assuming the solution exists, is this solution configurable enough to cater the above described needs?
Will be grateful for any suggestions!
Cheers
Krzysztof
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166267#4166267
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166267
17 years, 9 months
[JBoss Cache: Core Edition] - Re: JBoss Cache performance looks pretty poor :(
by jason.greene＠jboss.com
"phpguy99" wrote :
| I haven't changed my code to spread objects further down the tree.
| BTW, this seems odd or I may have missed something, but shouldn't the cache system do this spreading behind the scene? Depends on the key of the objects to cache, it could be difficult to balance the tree. And to know the "path" before I can do a "get". It's much simpler to do straight "key" lookup. (just my 2cents)
|
Could you tell us about your access patterns? How often do you insert? How many simultaneous writers will you have on the same server/process? A node currently has 4 segments, so it's tuned for allowing 4 simultaneous child node inserts. So, only if you have > 4 concurrent threads (more than 4 cpu cores) all inserting at the same time, that could become a bottleneck.
If this is the case, and you need to spread, you don't really need to do active balancing, just a simple modulus of a spread would work fine. Like
| x = ID % 10000
| fqn = /x/ID
|
We do plan to make this concurrency level configurable in 3.0, so you won't need to spread things out if you don't need to.
anonymous wrote :
| Back to performance and memory.
| It's stable now with 2 nodes. The rate of my insert is increased from 2000/s to 4000/s. This is one at a time and SYNC that is 0.25ms/operation which is very good and multithreaded should increase this by a lot (I hope).
| But the memory consumption is still very high (maybe b/c I put everything right under "root"). 4GB for my 1M objects
|
You are still experiencing JBCACHE-1383. Which causes 16 CHM segments and locks to be created per node. The update reduced it to 4. It is not yet in a release, although you can build the latest 2.2.x branch if you want. The MVCC locking mode in 3.0 completely eliminates the 4 CHM segment and lock overhead, so you might want to give that a try.
anonymous wrote :
| I constantly see:
| 2008-07-23 10:09:47,929 [Incoming,JBossCache-Cluster,10.57.132.54:38174] WARN org.jgroups.protocols.pbcast.NAKACK.handleMessage - 10.57.132.54:38174] discarded message from non-member 10.57.132.53:33187, my view is [10.57.132.54:38174|0] [10.57.132.54:38174]
|
This could indicate you have other traffic on the same multicast address. You might want to make sure the nodes in your cluster are the only ones using that address.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166265#4166265
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166265
17 years, 9 months
[JBoss Cache: Core Edition] - JBC2.1.1.CR2 evenQueue Bug?
by fuzzbient
JBossCache version:2.1.1.CR2 with Hibernate version:3.3.0.CR1
Under heavy load, many of the objects in my application reach the capacity threshold for JBossCache which generates the following warning and locks up the calls to select them.
eviction node event queue size is at 98% threshold value of capacity: 200000 Region: /org/somepath/MyClass/ENTITY You will need to reduce the wakeUpIntervalSeconds parameter.
I already have the wakeUpIntervalSeconds set to the minimum value of 1. I've tried increasing the eventQueueSize attribute to 500000 with the same issue except it takes a bit longer to show up. Here is my EvictionPolicyConfig.
| <attribute name="EvictionPolicyConfig">
| <config>
| <attribute name="wakeUpIntervalSeconds">1</attribute>
| <attribute name="policyClass">org.jboss.cache.eviction.LRUPolicy</attribute>
| <region name="/_default_">
| <attribute name="maxNodes">50000</attribute>
| <attribute name="timeToLiveSeconds">3600</attribute>
| <attribute name="maxAgeSeconds">3600</attribute>
| <attribute name="minTimeToLiveSeconds">120</attribute>
| </region>
| <region name="/TS" policyClass="org.jboss.cache.eviction.NullEvictionPolicy"/>
| </config>
| </attribute>
|
If I roll back to JBossCache 1.4.1.x, the problem goes away. Do you think this would be a problem with JBossCache or is it the integration between Hibernate and JBossCache. It's almost like the eviction thread does not ever run or it blocks and gets hung. Anyone else having this issue or know of a resolution?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166262#4166262
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166262
17 years, 9 months