Terracotta Discussion Forums (LEGACY READ-ONLY ARCHIVE)

Yep, it's perfectly ok. We've tested with up to 4 passives I believe but even that is not a hard limit.

Thanks for posting. Did any errors occur on the client first? I.e. an oome?
We are digging around to see if we can track this down.

Still having problems posting? Seems this forum software has issues with certain chars. In the short run might be easier to sign up for the tc-users email list. Or you can e-mail me steve at terracottatech dot com

Definitely upgrade to 2.2.1 stable. In the mean time I'm going to do some experimenting. I suspect this is about the combination of large ArrayLists and what we call literals (especially large onces. We deal with strings as literals).

We also have some optimizations for large strings that we aren't currently doing that we should be. I'll get someone to post back with more details. If you get time. Might be interesting to replace the ArrayList with a HashMap and see if the issue goes away. Then, instead of directly referencing large Strings from the array/map reference an object which references the String. This is just temporary while we put in the fix but it would help prove out that the problem is what I think it is.

If you can't get to the above, don't worry about it. We will.

can you try it with 2.2.1 and see if the problem goes away. It has some memory tuning and performance improvements.

Which version of the software are you experimenting with?

The following turns on persistence (see the reference config dso/config-sample/tc-config-reference.xml for details on all the options).

<persistence>
<mode>permanent-store</mode>
</persistence>

I'm currious to know what you are doing because even in temporary swap mode the server shouldn't OOME except for under some pretty extreme conditions like sending all the 500 meg of data down in one transaction (sync block). Could you share a bit more about your app?

Nope, these are good ideas. Historically we have tried to do things that maintain backward compatibility to the 1.4 jvm but moving forward that is becoming less and less important. It is also possible for us to have multiple bootstrapping mechanisms. The native one is a little less desireable than your other suggestion just because it isn't java etc but neither is bad. Of course either will be tricky so I recommend asking lots of questions early and often.

If this is something you want to take a look at I recommend creating it in JIRA for tracking. Also, this kind of thing should be discussed on tc-dev :-)

Any thought to adapting the tool to create an ssh tunnel to the box with the l2?

It is just sleepycat under there.

http://www.oracle.com/database/berkeley-db.html

It will be compressing and garbage collecting those files over time. They don't tend to get particularly out of control in our experience.

These are good points. We have an open bug already talking about some potential log file improvements:

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

Can you add your thoughts to that. We're going to be addressing this soon.

This may not be a great answer but I have used a few strategies around this in the past.

I've used a Cyclic barrier to make sure no one continues until N nodes have reached the barrier

I've used a collection that nodes add themselves to on startup so that I can see if other nodes are around.

Those of course were just hacks. In moraga we are putting in eventing on node join and leave so you will be able to see explicitly from your own code when you join or leave a cluster and when anyone else joins or leaves the cluster.

Also, you can use the admin console ( or jmx in general) to see what nodes are connected to the L2.

Hope this helps

I need a little more detail on what your asking? Right now they are saved to sleepycat which is a storage manager. Our internals are pretty generic and we will likely experiment with stuffing the objects in other db's as well over the coming year. It is actually pretty easy to do because all of our data is just objectID blob pairs. Pretty easy to map into tables.

Hope this helps,
Cheers,
Steve

Not exactly. It's a combination of LFU and LRU in both the server cache and the client cache. Probably the best place to get a detailed description would be the tc-dev mailing list.

Cheers,
Steve

Not sure if this answers your question but our server is just Java. While we don't support it this way right now you can kick it off from the main method anyway you want. If you look at our tests we often run the server in process with the L1's just for simplicity.

Cheers,
Steve

You've read our collective minds. For our next release we are planning on adding a few cool features around this.

1) You will be able to mark a map as your node map and it will always be up to date with the current list of nodes. You'll be able to use this to a) keep track of what nodes are currently connected and b) store values by node as an indirect form of communication between nodes.

2) Eventing. You'll be able to specify that you want methods that you choose to be called on node join, node leave connect and disconnet.