You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@openjpa.apache.org by Oliver Krohne <ma...@oliverkrohne.de> on 2010/05/17 11:20:48 UTC
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
Re: configure RemoteCommitProvider for Amazon EC2
Posted by okrohne <ok...@yahoo.de>.
Hi Donald,
I need to use the in a distributed multi jvm but of course with eviction.
That is why wonder if the ehcache replikation itself can do the job.
OpenJpa Cache will be configured as "sjvm" and ehcache will be configured
to replicate "removes, updates as synchronized ".
So if a e.g. "remove" on the DataCache is synchronized propagated by ehcache
via jgroups
to all other nodes, we should have the same behavior as using
TCPRemoteCommitProvider.
Oliver
--
View this message in context: http://openjpa.208410.n2.nabble.com/configure-RemoteCommitProvider-for-Amazon-EC2-tp5064783p5087435.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: configure RemoteCommitProvider for Amazon EC2
Posted by Donald Woods <dw...@apache.org>.
On 5/18/10 1:57 AM, okrohne wrote:
>
> Hi Donald,
>
> unfortunatly SQS would not allow to have a transactional cache as there is
> a possible delay of 20sec until a message can be fetched and it is designed
> that only one instance consumes the message.
>
> ehcache: Wouldn't the ehcache-jgroups replication
> (http://ehcache.org/documentation/distributed_caching_with_jgroups.html )
> do the job as it would propagate put,update,delete to all members.
> I assume one need only to configure the cache for svjm and let
> ehcache+jgroup do the eviction.
> There is already a ehache-openjpa plugin
> (http://ehcache.org/documentation/openjpa_provider.html)
> What do you think?
Looking at the latest 0.2.0 plugin, it seems to only support the
Data/Query cache interface and not the RemoteCommitProvider interface.
It includes a noop RCP to use when openjpa.DataCacheManager is set to
ehcache.
So, are you trying to use a distributed/multi-jvm Data Cache [1] or just
remote event notifications [2] w/o caching? If #1, you can use the
existing ehcache-openjpa plugin, but #2 will require a new EhcacheRCP to
be created....
[1]
http://openjpa.apache.org/builds/2.0.0/apache-openjpa-2.0.0/docs/manual/manual.html#ref_guide_cache
[2]
http://openjpa.apache.org/builds/2.0.0/apache-openjpa-2.0.0/docs/manual/manual.html#ref_guide_event
-Donald
>
> Thanks,
> Oliver
Re: configure RemoteCommitProvider for Amazon EC2
Posted by okrohne <ok...@yahoo.de>.
Hi Donald,
unfortunatly SQS would not allow to have a transactional cache as there is
a possible delay of 20sec until a message can be fetched and it is designed
that only one instance consumes the message.
ehcache: Wouldn't the ehcache-jgroups replication
(http://ehcache.org/documentation/distributed_caching_with_jgroups.html )
do the job as it would propagate put,update,delete to all members.
I assume one need only to configure the cache for svjm and let
ehcache+jgroup do the eviction.
There is already a ehache-openjpa plugin
(http://ehcache.org/documentation/openjpa_provider.html)
What do you think?
Thanks,
Oliver
--
View this message in context: http://openjpa.208410.n2.nabble.com/configure-RemoteCommitProvider-for-Amazon-EC2-tp5064783p5068597.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: configure RemoteCommitProvider for Amazon EC2
Posted by Donald Woods <dw...@apache.org>.
On 5/17/10 5:20 AM, Oliver Krohne wrote:
> 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.
What about the Amazon Simple Queue Service (SQS)?
>
> 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?).
I've only used ActiveMQ as a JMS provider in Apache Geronimo, but it
does have robust discovery and fail-over mechanisms.
http://activemq.apache.org/configuring-version-5-transports.html
http://activemq.apache.org/networks-of-brokers.html
http://activemq.apache.org/failover-transport-reference.html
>
> 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?
To use ehcache, you'd need to create a EhcaheRemoteCommitProvider that
can instantiate a CacheManager and Cache based on a XML configuration
file. I've opened OPENJPA-1669 and started looking at creating one for
trunk :-)
-Donald
>
>
> Thanks,
> Oliver
RE: configure RemoteCommitProvider for Amazon EC2
Posted by C N Davies <cn...@cndavies.com>.
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:mail@oliverkrohne.de]
Sent: Monday, 17 May 2010 7:21 PM
To: users@openjpa.apache.org
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=