Recently I waste some time fighting with Terracotta server and 'd like to share my thoughts about it.
First of all nobody solved the issue of clustering database connection and any other network connections either. But to my understanding this is quite important and plausible. This is the only issue that does not allow clustering to come truth.
Now let's get back to Terracotta. The task was to cluster pretty big application tidily integrated with Spring 2.5 (most of database, web-services, executors functionality were written using Spring's WS and JDBC calls). Application runs asynchronous tasks with Quartz. And to sum it up it looks more or less good from software design point of view.
The initial idea was to provide server side failover and thus:
1) Somehow share asynchronous tasks and guarantee re-execution is case of one server fail.
2) Share managed beans exposed outside and their states
3) Since server has complicated business logic that requires some synchronization provide distributed locks (ideally they need to be moved on the database level indeed)
Terracotta is really great product to get deal with. I got excited and confused at the same time because:
1) Terracotta provides integration with Quartz and allows sharing tasks with re-execution, BUT noone tested it with Quarts+Spring (as you probably know Spring gives some good wrappers for Quartz to simplify and unify the code). Thus after wasting 3-4 hours I had to use pure Quartz without Spring.
2) Shared locks as any other shared (distributed) objects works perfect and out of the box, BUT as soon as I start distributing more or less complicated data with some inheritance and fields like Loggers in parent classes I found myself in troubles. I faced the fact that Terracotta cannot exclude field from the distribution if it is declared in parent class (superclass). I had pretty much Spring stuff and I was not able to change the code and had to find out a lot of workarounds for this.
3) Spring. Yep. Wasted days to understand that it's just impossible to distribute most of the beans (especially those ones that had some JDBC stuff injected). All database connections need to be established when you need them. The same should be done in asynch. tasks.
To sum up this post:
1) Terracotta works fine but be ready to refactor your code and keep in mind all "product features" :)
2) Forget about database stuff injection into distributed beans or asynchronous tasks.
3) Be ready to feel "magic inside and consequences outside". Terracotta is a "black box" with some magic.
First of all nobody solved the issue of clustering database connection and any other network connections either. But to my understanding this is quite important and plausible. This is the only issue that does not allow clustering to come truth.
Now let's get back to Terracotta. The task was to cluster pretty big application tidily integrated with Spring 2.5 (most of database, web-services, executors functionality were written using Spring's WS and JDBC calls). Application runs asynchronous tasks with Quartz. And to sum it up it looks more or less good from software design point of view.
The initial idea was to provide server side failover and thus:
1) Somehow share asynchronous tasks and guarantee re-execution is case of one server fail.
2) Share managed beans exposed outside and their states
3) Since server has complicated business logic that requires some synchronization provide distributed locks (ideally they need to be moved on the database level indeed)
Terracotta is really great product to get deal with. I got excited and confused at the same time because:
1) Terracotta provides integration with Quartz and allows sharing tasks with re-execution, BUT noone tested it with Quarts+Spring (as you probably know Spring gives some good wrappers for Quartz to simplify and unify the code). Thus after wasting 3-4 hours I had to use pure Quartz without Spring.
2) Shared locks as any other shared (distributed) objects works perfect and out of the box, BUT as soon as I start distributing more or less complicated data with some inheritance and fields like Loggers in parent classes I found myself in troubles. I faced the fact that Terracotta cannot exclude field from the distribution if it is declared in parent class (superclass). I had pretty much Spring stuff and I was not able to change the code and had to find out a lot of workarounds for this.
3) Spring. Yep. Wasted days to understand that it's just impossible to distribute most of the beans (especially those ones that had some JDBC stuff injected). All database connections need to be established when you need them. The same should be done in asynch. tasks.
To sum up this post:
1) Terracotta works fine but be ready to refactor your code and keep in mind all "product features" :)
2) Forget about database stuff injection into distributed beans or asynchronous tasks.
3) Be ready to feel "magic inside and consequences outside". Terracotta is a "black box" with some magic.
3 comments:
Dennis,
Thanks for the comments. Any bugs you found, features you'd like to add, or general comments would be welcomed by the team.
We have forums support at http://forums.terracotta.org and JIRA at http://jira.terracottta.org
Terracotta does have support for snipping object trees using transient. Did you research the transient keyword?
Sometimes Spring integration can be more difficult - I agree - as it has it's own way of doing things that doesn't generally get in the way, but can sometimes be problematic.
One way to help that along is to post some forum messages on the Spring forums. Even though we have a partnership with them, it always help to see community interest. The more the Spring guys see Spring + Terracotta the more they will want to make sure the two work together flawlessly.
Thanks for your insights!
Btw, it should be noted that Terracotta does not try to distribute JDBC connections - only application state.
It's basically impossible to "cluster" machine specific resources such as TCP connections, disk, and so on at the Java layer only.
I agree mostly w/ Taylor. Just to be clear, it is not impossible to migrate TCP stack but requires a new TCP driver, a customization to the underlying OS, and in some cases a change to the switch.
Whole companies have been created just to create migratable TCP stacks. They have all been acquired. But they tried, nonetheless.
I would call it a _very hard_ problem.
Post a Comment