I will try to find time to retry with terracotta trunk. But even if the latency is better, the ALL node issue will be a killer for clusters larger than 2 or 3.
Taylor (@terracotta)
Great article – good to see great use cases like this popping up!
Just thought I would note that if the bayeux object is actually declared as a root the null check is not strictly necessary – terracotta will already ignore the assignment. The only reason you would need to do that is if there are side effects of the construction of the object.
It may not be obvious at first, but what happens is that Terracotta checks a root field and if it has already been created in the cluster once, then the root object is faulted in from the server and assigned instead of the newly created object.
Steve
If you hop on irc I can take you through experimenting with dmi that doesn’t apply if the receiver isn’t local. It should be pretty easy. We can even go furthor at some point and make it so that the server doesn’t even send to nodes that don’t locally have the reciever. I like to have these kinds of things felt out a bit in real use cases before we introduce them into the product to avoid becoming a big ball of features :-).
Steve
We haven’t gotten to the on_change callback yet but we did just add the mode where DMI is only sent nodes that the object the dmi is called on is resident in.
Comments
6 responses to “Clustering cometd with Terracotta.”
Good article. Would be interesting to try your stuff off of trunk. We redid dmi and it is a bunch faster.
Steve,
I will try to find time to retry with terracotta trunk. But even if the latency is better, the ALL node issue will be a killer for clusters larger than 2 or 3.
Great article – good to see great use cases like this popping up!
Just thought I would note that if the bayeux object is actually declared as a root the null check is not strictly necessary – terracotta will already ignore the assignment. The only reason you would need to do that is if there are side effects of the construction of the object.
It may not be obvious at first, but what happens is that Terracotta checks a root field and if it has already been created in the cluster once, then the root object is faulted in from the server and assigned instead of the newly created object.
If you hop on irc I can take you through experimenting with dmi that doesn’t apply if the receiver isn’t local. It should be pretty easy. We can even go furthor at some point and make it so that the server doesn’t even send to nodes that don’t locally have the reciever. I like to have these kinds of things felt out a bit in real use cases before we introduce them into the product to avoid becoming a big ball of features :-).
We haven’t gotten to the on_change callback yet but we did just add the mode where DMI is only sent nodes that the object the dmi is called on is resident in.
thank you admin