Terracotta Discussion Forums (LEGACY READ-ONLY ARCHIVE)

Hi,

Actually we're simplifying everything for the TIM world and created a Terracotta Toolkit for people that want direct access to those data structures. You should indeed not be able to use tim-concurrent-collections with the latest Terracotta release, that's intended. All those classes have been moved into the terracotta-toolkit. They might have changed packaged though in our effort to clean everything up and aggregate many isolated TIMs. Once you compile against the toolkit, you should be fine.

It goes even further, we developed a complete TCK to validate that the toolkit API is tested against a stable spec. According to a clear versioning scheme we will now never be able to make backwards incompatible changes within minor version released.

Hope this helps,

Geert

Thanks for reporting this, it's indeed an oversight and will be fixed in a future version. For the time being, you can work around it by handling the CacheExceptions yourself in your CacheWriter implementation.

I've created a Jira to track this issue:
https://jira.terracotta.org/jira/browse/EHC-750

Best regards,

Geert

You might want to enable Ehcache's Terracotta feature and use bulk load, this has been specifically optimized for storing large amounts of data in big chunks:
http://ehcache.org/documentation/bulk_loading.html

Do you have a log file of the other client?

I still need to look at the exceptions in the client log.

However, the Terracotta server doesn't immediately consider a client dead when can't be reached anymore. You might want to try to experiment with the heathchecker parameters to lower the timeout and get this to happen quickly. More info here:
http://www.terracotta.org/documentation/ga/product-documentation-16.html#50421767_85916

I looked more at the init stuff and it seems you've uncovered a bug, thanks! :-)

I've created a Jira for it here:
https://jira.terracotta.org/jira/browse/EHC-742

Yes, you need to activate the cache writer for that cache with the cacheWriter cache. You can optionally not specify a factory and manually register the cache writer as you do in your code.

http://ehcache.org/documentation/write_through_caching.html

HTH,

Geert

Hi,

Thanks for identifying this omission, we obviously regrettably simple forgot to add this when creating the cluster API for ehcache. We've created a Jira issue to track this and will soon solve it:
https://jira.terracotta.org/jira/browse/EHC-733

Sorry for the inconvenience,

Geert

Hi,

The express toolkit has a lock API that allows you to make TC clustered locking calls and that basically create a transaction in the DSO sense. This is available through the getReadWriteLock(name) method on the clustering provider.

With the express API you have two options for clustering your own classes:

1. write the required code in the advanced 'behind the scenes' toolkit API to support these types and have them instrumented in the express classloader's context, this is still a bit hokey and we're working out how to improve the experience with this at the moment

2. serialize your types and store byte arrays if identity or fine-grained changes aren't important

Hope this helps,

Geert

We don't support sharing state between different web applications on the same JVM. We're creating a series of classloader contexts that are our own, moving your jar to the common Tomcat lib dir doesn't change that.

Please follow the instructions in the documentation about how to do a custom Terracotta installation:
http://terracotta.org/documentation/ga/product-documentation

Hi,

Yes, write behind guarantees that what will be on the queue will be a copy of the element at the state it was when the putWithWriter and removeWithWriter calls were executed. This is very important since otherwise you risk having the element change underneath you in the meantime. It's part of the design. You're always able to access the current element version from the cache itself if needed, but if the snapshot in time isn't tied to the write behind operation, that information is lost forever. A nice boon is indeed that concurrency is made a lot easier on a per element level.

The difference between serialized and identity mode (in case you're running a clustered Terracotta cache), is that the value of the element that is queue is either a copy or not. This is configured at cache-level and only when custom mode clustered is used.

Glad you're liking our CacheWriter and write behind architecture :-)

Take care,

Geert

Which version of ehcache?

Can you please provide the versions of all the components you're using?
Can you also provide more detailed strack traces when you see the exceptions happen, that gives us more context.

Thanks,

Geert

Glad you have it running :-)