Terracotta Discussion Forums (LEGACY READ-ONLY ARCHIVE)

Yeah, I had added it in the wrong place, doh! Sorry about that

Funny, I ran into this two days ago. It's a bug:

http://jira.terracotta.org/jira/browse/CDV-243

The best answer I can give you right now is to look at how we do our tests. anything in com.tctest. uses our framework. Unfortunately it's a bit complicated but we use that framework to run multiple clients and a server either in or out of process.

Moving forward we have been working closely with the maven2 folks and we would like to add a command like mvn tc:run. If that's something your interested in we can definitely work with you to make it happen.

That is theorically possible but not done yet. While the sub-objects of the collection are partially loaded the collection itself is not with the exception of HashMap and Hashtable.

I peaked at jofti a year or so ago and it looked promising. Based on it's claim that it can sit on top of a hashmap I'm guessing that it will just work but I'll give it a try and get back to the list.

We have some stuff we whipped up a while ago that isn't really used anywhere/fully baked that does that stuff. Take a look at the ManagerUtil class methods deepCopy, optimisticBegin optimisticCommit

and the test CloneTestApp

Cheers,
Steve

Good questions.

Generally speaking, the most optimized, for both large size and general speed, collection is currently the HashMap so I would go with that. I would use read locks for read access and write locks for write access. Of course over time this will change and other collections will catch up but as of this date, That is the best.

Cheers,
Steve

The answer is yes and no.

Yes, from at least from a server perspecitve some collections are more optimized than others on various vectors with HashMap and Hashtable probably seeing the most attention. Those two collections have both better memory tuning and faster persistence on the server than others. It is pretty much just a tuning and time spent issue and as demand for more highly optimized other collections comes in we'll tune those furthor as well. So in that regard, yes, some collections are more tuned than others.

No, dynamic resizing isn't a problem for us because we treat or collections logically. We don't notice internal collection operations like that. Like you pointed it, it would perform poorly.

Hope this helps,
Cheers,
Steve

This is a bit tricky. Since java dynamically loads it's classes the question is at what point does a root definition become invalid? One could even be dynamically generating the class with the root. The way I currently deal with this kind of thing is to turn on debugging and if the root isn't getting created I go back and validate my config.

That said, we might be able to have some sort of validator that searches the classpath for all roots and gives a warning if no variable matches the root spec. While not perfect because of dynamically generated stuff I think it would be helpful 99 percent of the time.

I added a feature request to Jira for this:

http://jira.terracotta.org/jira/browse/CDV-237

I think a test version of a config bundle for ehcache is in trunk if you want to grab a nightly.

Cheers,
Steve

Hello,

If you synchronize on a shared object and call wait in one jvm and notify in another things will just work.

You just have to make sure the methods containing that stuff are autolocked in the config.

Cheers,
Steve

We may have to do a little magic to get the spring product to work in Jetty.

We don't technically have support for jetty yet. We'll try to take a look at it early next week.

Cheers,
Steve

Yep, got the source. We have someone looking into it. We think you might have exposed a bug so we are converting to a test case and tracking down the issue. More to come.

Cheers,
Steve

Doesn't sound like that should deadlock. Can you post the thread dump or e-mail it to me (steve at this domain).

Did you take a thread dump of the deadlock? We do upgrade from read to write locks and of course this can lead to dead locks depending on the code that is written. If one has multiple threads with read locks trying to upgrade to write locks they can get stuck.

Thread A
Got read lock
trying to get write lock but can't because Thread B has a read lock

Thread B
got read lock
trying to get write lock but can't because Thread A has a read lock.