Terracotta Discussion Forums (LEGACY READ-ONLY ARCHIVE)

You are correct. The extended functionality of allowing multiple threads to read at the same time only works in multiple JVM's. Within a single jvm the locks work as normal synchronized blocks. I'll point this out to the docks guys.

Cheers,
Steve

I confirmed that Roots work with the latest version of jetty so your problem was likely the one referenced above.

If you have any furthor problems please post and I'll walk you through what I did.

Cheers,
Steve

The last version of jetty I tried it with was version 4.2 and in there we were able to create roots but sessions wasn't integrated. Sometimes we need to do some work with containers because of fancy classloader stuff they do.

I'll try to get someone here to give it a whirl. This might be something you already tried but you won't see a root until your code uses it. Thought I would mention that incase you started up and didn't run through the code path.

Cheers,
Steve

What version of jetty are you using? Clustering roots in jetty may just work though we haven't tried the latest version (the shared queue sample in our kit clusters roots in an older version of jetty). Clustering session requires some integration. One of the jetty leads said they were going to do it recently. I would post your request to the jetty mailing list just to let them know you are interested. Might bump the priority.

Cheers,
Steve

I know people here have done something like this. One of them will get back to you asap but they said they were able to get really great performance.

Cheers,
Steve

Thanks for the heads up! I will pass it along. We have a tool that redirects those links to the proper places on the website. It probably hasn't been updated for the coming release. Generally speaking you can file bugs at jira.terracotta.org but this is fine too.

Cheers,
Steve

While we currently have some tuning knobs for deciding how much is kept in a given jvm we don't give a specific way to drop an object. It's something we have discussed and if someone has a real usecase for it we can certainly work with that person and come up with a good solution.

Cheers,
Steve

The open source version which is currently functionally the same as the enterprise version has no limitations on connections or server uptime. The only restriction is that if you redistribute it you have to do a form of GUI attribution.

Cheers,
Steve

We hope you will keep checking in with us because we are aggressively expanding our platform support with every release that goes by.

Cheers,
Steve

JRocket is not currently a supported JVM. We support the Sun JDK 1.4.2 and 1.5.x. We also have beta support for Sun jdk 1.6. Ibm JDK looks promising for early summer but I'm not sure when Jrocket will bubble up to the top.

Cheers,
Steve

any chance you could e-mail me the code steve at terracotta tech dot com or hop on irc and I can work through it with you. Should make it go quicker.

Cheers,
Steve

Hi,

Are the methods you are using to access the ArrayList syncrhonized on a shared object? Auto-locking tells the code that anywhere one is synchronized on a SharedObject (object reachable from a root) they use a distributed lock. If your code is synchronized on a non-shared object or not synchronized at all you get the error below. You can also use Named Locks to paint a method that has no synchronization as a locked method as well.

Hope this helps,
Cheers,
Steve

Yep, we support Spring 2.0.

http://www.terracotta.org/confluence/display/docs22/Platform+Support+TC-Spring

Cheers,
Steve

As of 2.2.1 we don't support nested "Concurrent" (which means pretty much unlocked) locks.

All other kinds of locks can be nested. Generally speaking Concurrent locks are pretty risky. It's like programming a multi threaded app without synchronizing. Sometimes it is ok but in general it should be used with caution. Can you give a bit more detail about where you are using them? We might be able to suggest an alternate technique.

Cheers,
Steve

The permanent store data files are the same ones for either swap or perm store.

As far as performance believe it or not under most usecases they are now (as of 2.2.1) pretty much the same. While disk can add a little latency on an individual operation the total throughput is unaffected accept in certain very specific cases.

We do have certain classes that need to be tuned in the server for persistent mode when they get large (Set and List are ones that come to my mind).

Hope that helps...