Great news. We're currently just using local file systems in production.
So how big a deal would it be for us to write a custom Syndicator ?
I guess getting new slave instances to register would just be a
question of adding a URL to the author that the slave invokes with the
slave's IP & path to magnolia and the shared secret to ensure the
slave is one we own.
How sensitive is the publishing process if a registered node is not
reachable ? Will the other nodes be updated (assuming we're not using
the transactional publishing facility) ?
Regards,
Jon.
On 30 Mar 2009, at 13:05, Grégory Joseph wrote:
Hi Jon,
#4 is the easiest to start with (are you currently using derby in
production??), although I'm unsure how Jackrabbit will behave in
such a context, and your db might
#2/#3 sound interesting, where #3 seems reasonably simple to
implement, with a combination of a custom Syndicator on the author
instance, and a setup task on the public instances.
You might also want considering clustering at repository level;
jackrabbit 1.5
Eager to read other's feedback on this scenario !
Cheers,
-g
On Mar 30, 2009, at 11:36 AM, Jon Barber wrote:
I really like Magnolia - we've used it successfully for sites we've
done and integrated it successfully with Spring. The company I work
for is a digital agency, which means that we do a lot of marketing
driven web sites, which by their nature have very spiky traffic
profiles. To cope with this we're looking to host future sites on
cloud infrastructures such as Amazon EC2. The idea is that we can
auto scale by bringing up new server instances when we hit certain
thresholds, e.g. connections per sec per server, cpu usage etc.
So now I'm trying to work out how we can use Magnolia in this
setup. The problem I have at the moment is that Magnolia has a push
model for distribution, which would be problematic for this setup.
Take the scenario where a new slave instance is started - how do we
get the latest content onto this instance without human
intervention ?
As I see it we have the following options :
1. Add a facility so that new slaves can auto register with the
author instance and trigger a content refresh. We would have to add
some password / key mechanism so that only slaves we own can
register with the author. Also, a content refresh would involve all
slaves being updated - less than ideal.
2. Create an alternative pull model, such that slaves can start
from fresh and pull down a snapshot of the content. Combine this
with 1 so that slaves are auto registered for later refreshes using
the standard Magnolia model. We would also have to add an option
for when slaves shut down to de-register.
3. Use some mechanism so that the author instance provides an
export to S3 of the content and the slaves import this at startup -
variant of option 2.
4. Use MySQL or similar as the JCR storage medium. Slaves get a
read only connection to this database.
What is the lists thoughts on this ? Which of the options above
seem like a good choice / most realistic ?
Thanks,
Jon.
----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <[email protected]>
----------------------------------------------------------------
----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <[email protected]>
----------------------------------------------------------------
----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <[email protected]>
----------------------------------------------------------------
