How to exchange data between servlets in different nodes in same cluster

Hello JavaRanch!

I'm looking for advice here.
What is better and easier approach for exchanging data (in my case list of objects) between servlets in different nodes in same cluster?

I thought about RMI or just direct url servlet call. But it seems that I'm missing something here.

My problem is the following:
I have to create some kind of diagnostic storage for each cluster member. It will collect all information and errors during application work.
And If I need to check application status I do web request and it will show me that these servers (cluster members) are okey and that node has an issue.

I'm using spring and tomcat

Any thoughts and ideas are welcome!

Thanks in advance.

/Andy

How about writing the pertinent information to a DB? That way it's always available, to whoever needs to get at it, even if the JVM has been shut down or restarted.

May be storing objects in common JNDI structure can be of help
other option is DB (which is already mentioned).
normally , paid or commercial application servers do provide this information out of box

I second Ulf's recommendation.

I'll 3rd it!

Storing the information in the DB not only makes it persistent and readily available, that ready availability extends to things outside of the Java or cluster environment. Even if you don't need that now, that kind of availability frequently comes in handy down the road when there are new requirements that need it.

This has saved me lots and lots of time in many projects when at the last minute someone says: "Oh by the way, I forgot to mention that such-and-such a process also needs this information?"

That and the fact that replicating data across multiple, physically separated, nodes in a non-trivial / extremely hard problem. This is why projects like Hadoop exist and are so popular.

Thanks to all who responded!

Yeap, I thought about writing it to db, actually I will do it , but writing to database adds penalty to performance. So I wanted to collect data in real time and write it to database after an hour by chunks.
But it seems that I have to change my approach and add some kind of backend asynchronous writer.

Thank you.
/Andy

Andy Storm wrote:but writing to database adds penalty to performance

Until you know you have a performance problem and can prove that the bottleneck is in writing to your DB then I would not worry about it. Implement the simplest thing that solves your problem. Then if, and only if, you have observed substandard performance through thorough testing and measurement, should you look to implement any optimisations.

Otherwise you may spend a lot of time, and potentially money, fixing an issue that just doesn't exist.

Tim,
I'm 100% agree with your note here.
But I have a goal to make performance as fast as possible, that's why I'm thinking in this way.

Anyway I already started to implement solution which we discussed

Thanks a lot!

/Andy

I don't want to belabour the point too much but "as fast as possible" is not a realistic requirement. This is the response you'll get from any customer when you ask them "How fast to you need it?". You need to clarify what this means and be able to define how fast is fast enough. Any faster than that is a waste.

If you really do need performance to be "as fast as possible" then you'd better dust off that credit card because you're going to need it to buy that 10 acre data center filled with top of the range over-clocked super computer farm. Oh, and brace yourself for the monthly energy bill.

Hehe, well you are right, again

But I have some kind of technical requirement, It's okey.
I just meant that one more extra db request can be redundant.

Thank you
/Andy