Terracotta Discussion Forums (LEGACY READ-ONLY ARCHIVE)

For those who want to build 3.2.2 from source, this blog post explains the details:

http://gabenell.blogspot.com/2010/09/how-to-build-terracotta-from-source.html

Thanks for the pointer; as I am using the express config it looks like CDV-1444 is the issue. Glad to see it's tracked.

I am trying to inspect the second level cache by calling

Code:

session.getSessionFactory().getStatistics().getSecondLevelCacheStatistics("regionName").getEntries()

and I get

Code:

java.lang.ClassCastException: java.lang.String cannot be cast to org.hibernate.cache.CacheKey
 	at org.hibernate.stat.SecondLevelCacheStatistics.getEntries(SecondLevelCacheStatistics.java:74)

I don't get this if I do not specify <terracotta clustered="true"/> in ehcache.xml for this region. It looks like the key is some kind of terracotta specific value and not the CacheKey object hibernate expects.

Edit: I am using ehcache-core 1.7.2 and ehcache-terracotta 1.8.0

I encountered the same issue.

It seems that the TC Dev console actually tries to connect to the servers based on the host names listed in the remote tc-config.xml. So a config using internal IP/DNS addresses could not be connected to from outside. And on EC2 the public DNS is not bound to the local interface. You CAN connect from an EC2 instance to it's public address, though this will route the packets outside the local network, then back in, which might be feasible just for testing but certainly not for production.

One possibility would be for the TC dev console to rely on the TC server to tunnel data to/from other servers or aggregate it somehow.

Another would be to fire up the dev console on the EC2 instance with X forwarding set up. I did this but for some reason the console was extremely laggy (order of 30+ seconds), far more than the network lag or even other apps running over X. Also the dev console was pretty responsive before I connected, it only became lagged after connecting. So I think there is some kind of problem with the dev console in that environment, not sure exactly why.

I ran into a similar issue regarding sticking hibernate objects into terracotta. I would get a org.hibernate.LazyInitializationException when doing this.

The interesting thing is that I don't experience this problem if I set my class-expression to "*..*"

Is that because with this configuration, terracotta is instrumenting even the runtime-generated hibernate proxy objects?

Assuming I'm right,

1) is it still a bad idea to try to stick (lazy) hibernate objects into TC?
2) if it isn't a bad idea, is there a better class-expression to use to capture hibernate proxies rather than wildcarding the whole universe?

Thanks