[Logo] Terracotta Discussion Forums (LEGACY READ-ONLY ARCHIVE)
  [Search] Search   [Recent Topics] Recent Topics   [Members]  Member Listing   [Groups] Back to home page 
[Register] Register / 
[Login] Login 
[Expert]
Messages posted by: abroszni  XML
Profile for abroszni -> Messages posted by abroszni [13]
Author Message
This refers to caching web pages,
In the example, the URL
/admin/SomePage.jsp?id=1234&name=Beagle

will generate a page.
Since the Cache is a <Key, Value> store, the value will be the page, and the key will be the URL

Now think of the case where you use tracking software that will use unique parameters for different visitors of the same page, e.g.

/admin/SomePage.jsp?id=1234&name=Beagle&trackingId=1111
/admin/SomePage.jsp?id=1234&name=Beagle&trackingId=1112
/admin/SomePage.jsp?id=1234&name=Beagle&trackingId=1113

You might not want to cache the same page multiple times so you will have to override the
net.sf.ehcache.constructs.web.filter.SimplePageCachingFilter.calculateKey() method, in order to parse the URL given and generate the same key for those 3 URLs above.

You can look at:
http://ehcache.org/documentation/recipes/pagecaching

for a tutorial
What is your mapping config? read-write cache?
Do not forget that Ehcache can be used as an in-memory cache and as a second level cache for hibernate.
If you plan to do both in your application, I would advise to use two different cache configuration files.
The reason behind that is that even though you could hold all your caches definitions in one file, I would find it easier to separate them, since they will not be used for the same functionalities.
It will also be easier to tune, with ARC (auto resource control) you could have your two different CacheManagers using different portions of the memory.

Look at http://ehcache.org/documentation/configuration/cache-size
section 'Pooled resources'

Code:
 <ehcache xmlns...
         Name="HibernateCaches"
         maxBytesLocalHeap="100M"
         maxBytesLocalOffHeap="10G"
         maxBytesLocalDisk="50G">
 ...
 
 <cache name="Entity1" ... </cache>
 <cache name="Entity2" ... </cache>
 <cache name="Entity3" ... </cache>
 
 </ehcache>
 
 and
 
 <ehcache xmlns...
         Name="InMemoryCaches"
         maxBytesLocalHeap="100M"
         maxBytesLocalOffHeap="10G"
         maxBytesLocalDisk="50G">
 ...
 
 <cache name="Cache1" ... </cache>
 <cache name="Cache2" ... </cache>
 <cache name="Cache3" ... </cache>
 
 </ehcache>
 
 

Or, to answer your original question:

Code:
 ((EhcacheEntityRegion)((SessionFactoryImpl)sessionFactory).getAllSecondLevelCacheRegions()
       .get("com.pany.YourEntity")).getEhcache().getCacheManager()
 


There might be an easier way. that's the first one which come out of my head.
You'll access to the same Caches instances

Try:
Code:
 ((EhcacheEntityRegion)((SessionFactoryImpl)sessionFactory).getAllSecondLevelCacheRegions()
         .get("com.pany.YourEntity")).getEhcache()
 
 and
 
 CacheManager.create(getClass().getResource("your-ehcache-config.xml")).getEhcache("com.pany.YourEntity")
 


You should access the same cache instance.
You should be able to use the same ehcache.xml as the one used by hibernate.

Code:
 CacheManager cacheManager = CacheManager.create(getClass().getResource("your-ehcache-config.xml"));
 
 ....
 
 cacheManager.shutdown();
 
Hi,
just one precision, HashCodeCacheKeyGenerator is part of ehcache-spring-annotation :
http://code.google.com/p/ehcache-spring-annotations/

which is not developed by Terracotta, so if something is happening there, you should contact them.

However I had a look and I am not certain that the HashCodeCacheKeyGenerator is wrong in your case.
If I understand correctly, you are calling your method:
Code:
 public String getValue(final String key, final String type, final Locale locale) 
 

and you indicate that you used the following parameters:

"String 1", type 1
"String 2", type 2
 


There's one parameter missing here, the Locale, and your second parameter is not a String in your description, but I assume you have tried with
"String 1", "type 1", null
"String 2", "type 2", null

When debugging the HashCodeCacheKeyGenerator method, you found that the hashcode of String "String 1" and "String 2" differs by 31, which makes sense. I don't understand your comment here when you say :

we found that hashCode of String 1 differs from HashCode of String 2 by just 31. 31 is the Multiplier which is used for hashCode calculation. So the 2 calls return exactly the same hashCode.
 

Because "String 1" and "String 2" SHOULD return a different hashcode. The hashcode is used to calculate the key of the Element in the cache.
I hope it is clear that when you enter the parameters with "String 1" and "String 2", your method should return two different results, thus caching two different Elements. (Do not forget that Ehcache is a key-value cache, so caching two different objects means having two keys, one per object).

Be also careful that the HashCodeCacheKeyGenerator is a recursive method, and it calculates the key of the Element by recursing through the parameters you give in the method (and other parameters according to the @Property you set.).
Meaning that "String 1" is not the only parameter used to calculate the hash.

The end of the story is, with the information you've described, I can't see why an issue would be in the HashCodeCacheKeyGenerator.

One last comment, when using a HashCodeCacheKeyGenerator, you can expect to have different parameters giving the same hash, thus the same key.
That's the idea behind the hash function, reducing a set of data to a smaller set, thus having multiple data resulting in one same value. A hash is different from a unique identifier.
The chance is slim as it is a long but it exists.
If you want to avoid it, you should not use the HashCodeCacheKeyGenerator.

If you want to report a bug you could check that there's a real issue by trying a simple Unit test to assess that using different parameters will not fail.
Code:
  @Test
   public void testHashkeyGenerator() {
     HashCodeCacheKeyGenerator generator = new HashCodeCacheKeyGenerator(true, false);
     Long key1 = generator.generateKey(UseYourServiceClassHere.class, "getValue", String.class, "String 1", "type 1", Locale.getDefault());
     Long key2 = generator.generateKey(UseYourServiceClassHere.class, "getValue", String.class, "String 2", "type 2", Locale.getDefault());
     Assert.assertNotEquals(key1, key2);
   }
 

The first parameter is the name of your class using the annotation, the 2nd param is the name of the method onto which you put the @Cacheable annotation, the 3rd param is the class of the Object your method returns, then the following params are the parameters you pass in your method.

If you manage to make this test fail for a couple of sets of parameters, please give the complete sets of parameters you used, as well with the description of your Service class.
And I would advise to post the info in the ehcache-spring-annotations forum
http://groups.google.com/group/ehcache-spring-annotations

but you can also post here, we're glad to help.
Eventually anyway, if there is a bug in the HashCodeCacheKeyGenerator, this has to be fixed by the ehcache-spring-annotations developers.
2 and 3 are doing the same
1 and 4 are the same (minus the path parameter)
all 4 are doing exactly the same except that 2 and 3 will use the singleton pattern to be sure you instantiate only once the CacheManager, while 1 and 4 will initialize the CacheManager every time.

so best advice is call 2 or 3 like you did.
1 and 4 would be more useful in the case where for some reason you want to handle the singleton by yourself

Glancing at your code, the Spring service looks ok to me except maybe the @Transactional annotation, but it's difficult to say without your Spring config, can you post it?
Thanks for the info, I'm gonna have a look at the logs, meanwhile I filled a Jira: https://jira.terracotta.org/jira/browse/CDV-1598
Those exceptions are not fatal, they are actually a sign that your Active node is requesting your faulty Active node to go to its normal state (Passive).

What puzzles me is that you indicate that you tried to wipe your database before restarting. If you did so, the servers should restart as normal, and be able to connect.

In your tc-config.xml, I see that your server data is in /tmp/FNUI1/ and /tmp/FNUI2/

I'll ask you to go back to the basics,
- stop the L2's,
- stop your webapp/any L1,
- verify that no server is running : ps aux | grep com.tc.server.TCServerMain
- erase those /tmp/FNUI* directories,
- start only your L2's (do not start your webapp/L1's).
bin/start-tc-server.sh -f ..yourpath../tc-config.xml

This should make the 2 servers start as Active/Passive.
If not, once again, send me the server-logs, every one of them.

I'm asking you that again because here in your FNUI1 log, @16:23:01,370, there's the first exception about the communication between the 2 servers, but your FNUI2 log starts @16:23:22,502. I guess FMUI2 had to restart and backed up its log as terracotta-server.log.1, before starting a new one.

Thanks!
Eric, in the logs, for FNUI1, I see
2011-09-12 16:23:38,268 [L2_L2:TCComm Main Selector Thread_R (listen 0:0:0:0:0:0:0:0:9530)] INFO com.tc.net.core.CoreNIOServices - IOException attempting to finish socket connection
java.net.ConnectException: Connection refused

meaning the server on FNUI1 can't connect to the the server on FNUI2

the logs for FNUI2 stops at
2011-09-12 16:23:33,262 [WorkerThread(group_discovery_stage, 0, 0)] INFO com.tc.net.protocol.transport.ClientMessageTransport - ConnectionID(-1.ffffffffffffffffffffffffffffffff):
Attaching new connection: com.tc.net.core.TCConnectionImpl@603544782: connected: true, closed: false local=10.141.174.103:35912 remote=10.141.174.102:9530 connect=[Mon Sep 12 16:23:33 GMT+00:00 2011] idle=2ms [0 read, 0 write]

If you look at the times, FNUI2 seems not to be running at 16:23:38,268, when FNUI1 tries to communicate with it.

I assume therefore that at this point it crashed, can you confirm it? Do you have the Thread dump which got generated from the crash?
I tried your config with several combinations of active/passive servers joining/leaving the cluster and had no problem, but the logs you're getting 'COMMUNICATION ERROR' looks like there's a network problem.

Could you run nping on each of your server?

On your machine : FNUI1 (ip 10.141.174.102)
Code:
sudo nping --tcp -p 9510 --delay 1s -c10000 -H 10.141.174.103 > /var/tmp/FNUI1-nping.log

On your machine : FNUI2 (ip 10.141.174.103)
Code:
sudo nping --tcp -p 9510 --delay 1s -c10000 -H 10.141.174.102 > /var/tmp/FNUI2-nping.log

Then reproduce the error, and attach the complete server.logs + logs of nping, this will help me to reproduce your issue.

Thanks!
Aurelien

enewett wrote:
Using Terracotta 3.4.1 with Ehcache 2.3.2


 


I tried your test and didn't encounter the problem you describe,
Are you using maven or did you include the jars manually?
Could you run the test and include the %(user.home)/terracotta/client-logs/terracotta-client.log and %(user.home)/terracotta/server-logs/terracotta-server.log ?
 
Profile for abroszni -> Messages posted by abroszni [13]
Go to:   
Powered by JForum 2.1.7 © JForum Team