Not quite answering your question but my issue was similar with proprietary OMS. Our DB is pretty large but not in clustered environment, bad design decision made many years ago. So our DB will "go away" and "come back" several times every day without warning, effectively leaving our application without a DB for short periods. We do have other DBs that can support the application but without a cluster our application really needs to reconnect to a new DB when its current DB disappears. I implemented jgroups because it means I can add new nodes on failure of one node, the new node will connect to the new DB and the abandoned node can use an RPC connection to the new node to tell it to take over.
It's rough as guts but it's surprisingly reliable. Chris PS no comments on the design, I inherited it I didn't design it, I just got it to 96% uptime with no budget and late nights. -----Original Message----- From: Oliver Krohne [mailto:[email protected]] Sent: Monday, 17 May 2010 7:21 PM To: [email protected] Subject: configure RemoteCommitProvider for Amazon EC2 Hi, we are going to deploy our app to Amazon EC2. One issue is that the ip-adresses of an ec instance can change and new ec instances can be started which makes the RemoteCommitProvider using TCP unuseable as all TCP adresses where messages are sent to must be configured at the point the instance is starting. New instances can't be added without reconfiguring the running ec instances. Using JMS as transport would work but i don't want a another machine running and hence a new point of failure. But I would be thankful for any experience using JMS (openjms or activemq?). So am thinking of using jgroups were new instances can join a channel, but I did not found someone who has implemented it, maybe in this mailinglist? The other solution would be using ehcache with jgroups replication and just replicate "removes and updates". Does anyone have experience with this setup? Thanks, Oliver=
