Terracotta Discussion Forums (LEGACY READ-ONLY ARCHIVE)

Re: Converting JMS to Java
Posted: Aug 11, 2005 11:59 AM in response to: wpoitras Reply

Hi. This is an excellent question that goes to the heart of DSO's value proposition. We are working on putting together a guide such as you describe.

The short answer is that the best practice is highly dependent on the use case. In some cases, we see that JMS is simply used as a transport for maintaining a distributed cache; DSO is a natural drop-in fit there. If you have more of a pub-sub use case, DSO can still help, though you may need to write some simple code in the app layer to express the delivery semantics you describe.

We're also investigating hybrid solutions in which we would optionally and transparently back a DSO cache with JMS. This would give you the best of both worlds: a simplified programming model with JMS' qualities of service.

We'd be very interested in talking with you more to understand better how Terracotta might be able to address your specific needs.

Cheers,
-p

---
Patrick Calahan
Product Manager
Terracotta, Inc.

Converting JMS to Java
Posted: Aug 10, 2005 1:23 PM Reply

At first glance DSO looks like a wonderful way to replace existing distributed/clustering based technologies with simpler Java. One area that is most relevant to me is JMS. It would be good to have a best practices guide for converting/adapting various APIs and technologies like JMS.

It appears that creating an application like it wasn't a distributed application but then configuring DSO to make it one is the way to approach application development.

So, using commonly available Java libraries how would you replace features in JMS such as (or would you just use JMS):
- persistant destinations
- time to live on messages
- message durability, especially for topics (so that a message isn't removed until all registered listeners have received the message.

OK, let me provide a little more info. We get data files delivered in XML-format, which we parse and store in a data and index store. To be honest, not exactly jdbm but bdb-je which is already known to Terracotta actually (though we use a more recent version). Now bdb-je doesn't offer replication yet, so I guess there lies an opportunity for Terracotta.
Besides that ... for another project we are using Lucene, which is also quite interesting to work with in a distributed setup. It's even further away from JDBC, simply using a bunch of plain files, which for replication requires taking snapshots and re-creating searchers etc. We have a solution for that, but it would be nice to make it simpler and/or more robust.

Hi. I'm not sure I follow. Where would you like to plug in a jdbm-like-store?

Cheers,
-p

_________________
Patrick Calahan
Director, Product Management
Terracotta, Inc.

Currently we are using a very high performance object store, a bit like jdbm.
Would it be possible to use such a store instead of an SQL-based database?
I think that would be desirable from the performance perspective.

Hello. I'll do my best to answer each of your questions

0) Since HA-JDBC is just a JDBC driver, we believe it should work fine. We are still spinning up our own certification tests for this.

DSO, on the other hand, does have a few known issues with Hibernate and Spring - we're in the process of ironing them out now. As you suggest, it's a matter of making sure that the various bytecode instrumentors play well together.

1) It does mesh with our understanding - this is something we are actively exploring. As mentioned above, though, we still have a little bit of work left before we can get there.

2) This is not possible today, but we are working to get there.

3) Right, point taken. It's a bit more challenging for us because we have to be able to instrument any class, not necessarily just those in your application. We are looking to see if we can come up with a solution using 1.5's hotswappable classes.

4) Much of what you see in there are essentially hand-tuned optimizations for some commonly-used classes. And again, we're looking to see if we can hotswap some of the things in there to be more lightweight.

Hope that helps, let me know if you have any other questions.

---
Patrick Calahan
Product Manager
Terracotta, Inc.

Hi there,

My app uses Spring+Hibernate for lifecycle, persistence, etc. I have a few uninformed questions in regards to how TVS/DSO/HA-JDBC would fit into such an environment:

0) Are DSO and HA-JDBC known to play well with Hibernate and/or Spring? If so, is any particular combination of version(s) better? (Note that Hibernate already does its own bytecode instrumentation by default)

1) DSO seems like it would take the place of Hibernate's "second-level cache" without needing to implement their cache API; does this mesh with your understanding?

2) Can I spin up a TVS server as a Spring bean as part of my server's startup process, or does it have to be the main thread?

3) Is it possible to use DSO without changing my JVM's bootclasspath? For example, I'd prefer the TVS environment to apply only to a single web-app. Note that Hibernate doesn't need to modify the bootclasspath to use bytecode instrumentation.

4) It's a little worrying to see java., javax., sun. etc. classes in dso-boot.jar. Is there a lighter-weight way to do it?

Thanks!

-0xe1a

Re: TVS scalability and other related questions
Posted: Aug 19, 2005 4:03 PM in response to: tng713 Reply

Hi. We do have several customers who are preparing to go into production with very large sites. The load generated by TVS tends not to relate directly with the total TPS, but rather with the number of transactions that involve updates to the data set.

We do everything possible to minimize IO traffic: no unecessary cache updates, and no unnecessary message contents. We have yet to see any case where TVS has become a bottleneck in any of these systems - invariably, any blocking they are doing is on their databases, disks, or app servers.

As far as documents go, you can start with the links on our public site

http://www.terracottatech.com/product/dso.html

You can also check out our new blog. I just posted a new article today that describes some of the advantages of Terracotta DSO.

http://blog.terracottatech.com

I'd love to chat with you more about how Terracotta could help improve the scalability of your system - please feel free to drop me a line at <pcal at terracottatech.com>

---
Patrick Calahan
Product Manager
Terracotta, Inc.

TVS scalability and other related questions
Posted: Aug 18, 2005 4:47 PM Reply

I have a few questions in related to the TVS solution. They are as follows

1. Do you have any large customers deploying the TVS solution in production yet? If you do, what is the TPS (Request per second) per server instance or traffic load?

2. Do you have any documents on the clustering techniques used by the TVS (horizontal scaling etc..)?

Thanks
T.N.

Hi, Tom.

No, we do not provide any load-balancing features in Terracotta products. However our products have no problem helping you to replicate session amongst your hosts when using a front-end load-balancer, be it hardware or software based.

Thanks for writing.

_________________
Bill Chever
Product Support Manager
Terracotta, Inc.

I'm wondering what Terracotta can mean for me regarding load balancing.

I understand that Terracotta Sessions is (roughly) functionally equivalent to e.g. Tomcat session replication. So what if I have to balance incoming web requests over the available cluster members? Does Terracotta provide a load balancing solution as well?

Thanks,
Tom

Interesting product.

Our deployments support Weblogic and Tomcat but also WebSphere, JBoss, JOnAS, Sun and Trifork.

Any information on when these will be supported? Could be very useful to us.

_________________
David Q