Hi Tako,
well its somewhat easy.
First, you need to get an account - funnywise, you usually have one as
you can just login with your amazon.com account. Then you'd register
yourself for the services you want - here: EC2 (aws.amazon.com);
After that youre "in". To get started you need to understand how aws
works. In EC2 you can have "instances" - a dedicated virtual machine
with guaranteed cpu time and ram that is available in 5 flavours (power
+ ram - differs in pricing, going from 0,10 per hour to over a dollar
per hour - pricing is shown on aws).
BTW, regarding the pricing: is right that aws doesnt let you try it for
free, however, my whole testrun did cost under a dollar, namely 0,57
USD. Thats nearly "free" to me.
If a instance is shutdown, you'll loose *all* data in it and its reset
to pre-start (!) state. So even you have space in an instance, the data
there will be lost. To overcome this, you need space that can be mounted
- this is called EBS (Elastic Block Store). You can think of these as a
real hard drive that can be attached to 1 (only 1!) AMI instance.
BTW: all cations like new instance, storage and so on can be easily set
up by using the Amazon Management Cosole (webapp under
console.aws.amazon.com).
So the overview for a JR testrun is:
1 AMI Instance (small) <---connected-----> 1 ECB Volume
AWS offers much more services, but these are *not* necessary now (later
it may be useful to use additonal aws sotrage options for lower price/
sharing between instances/ backup etc...)
So, after you get the first grip, you just need to start an instance at
first. As AMI image I would go with "ami-45997c2c" as this is a public
one that has java and tomcat on it (you also can build your own AMI
local and upload, but for testrun its waste of time, as over 1800
preconfigured AMIs are available in US region and over 200 in EU
region). Also make sure you get a key-pair generated in first time use
and download it - this is needed for SSH root access to it later on.
After your instance is up and running you need to attach space. So you
go to ECB Volumes and add a new one. Make sure you create both (instance
and volume) in same (!) places called "availability zone" in aws (can be
looked up for the instance in case not configured explicitely in the
console by just klicking on the running instance). In case you create
one in zone A and the other in B you can't attach them together.
After ECB is setup and attached, you can access the instance using SSH
and your private key. Then simply create a directory and mount the
volume to it (remember: first time you need to format it). In case your
instance is shut off, or the ECB detached (do unmount first!), your
data will be still existing on your ECB volume and can be attached to
any future instances (for long term however, you should have a look at
aws S3).
So after instance is running and storage mount, you then can config your
repository.xml to use the mount path for file based JCR repo. Then just
deploy your application to the tomcate via SFTP and voila, JCR on AWS
running. If you want to kill the instance, you can do so and then create
a new instance and repeat the app upload and in case storage path is
equal all should be working.
You'll notice that the URL changes all time - to overcome this you'll
need to grab a "aws elastic IP", a fixed IP that can be attached to
instances and wont change as long as you "possess" it (costs money
depending if in use or not - prices can be looked up under aws.amazon.com).
So, that'll should get you up and running. Further AWS and Java
dependend info under:
http://developer.amazonwebservices.com/connect/kbcategory.jspa?categoryID=130
Best,
Korbinian
Tako Schotanus schrieb:
"In an short attemp I tried to get from 0-AWS knowledge to a running JR demo
app"
Hi Korbinian,
would you mind detailing a bit more how and what you did? I don't mean an
exact description but just a rundown of the services you used and such.
Is there a way to try what you did for free? Because I have the feeling from
what I read that you always have to pay with Amazon?
It's one of the reasons I never tried any of the Amazon services and it
might be an advantage that Google has: in lots of places developers make the
tech decisions and if Google allows you to try things out for free you're
more likely to take a look at it.
Cheers,
-Tako
On Mon, Apr 13, 2009 at 11:10, Korbinian Bachl - privat <
korbinian.ba...@whiskyworld.de> wrote:
well, even if one would be able to deploy JR, it would be a real joke, as
googles hard limitations (maybe they soften these later on) would make files
over 1MB each impossible - this and the maximum 10MB response limit kills
nearly all java apps that are somewhat file related... Currently, im really
unsure what market they target with GAE Java as the limitations makes nearly
all java apps that might benefit most of such a cloud infrastructure
impossible, e.g:
Time per request 30 sec
-> and no threads + background = no data crunching...
Files per app 1,000
-> this one looks odd... I nowhere could find what a "file" by their
definition is, but a limit to 1000 real classes sounds a showstopper for
many apps
HTTP response size 10 MB
-> I still don't understand how one then could make backups from one owns
data...
Datastore item size 1 MB
-> that makes either fuzzy workarounds for larger data or it just won't
store anything bigger as 1 MB each
Application code size 150 MB
-> this sounds high enough
In the meantime I think that GAE Java will mostly help AWS or even Azure.
In an short attemp I tried to get from 0-AWS knowledge to a running JR demo
app. It took me less than 30 minutes of reading and 5 minutes of setup till
my first instance was up, had attached storage and a fix IP on it (used some
sun AMI, had all on it for JEE5)...
As google will get similar price range for GAE as AWS is today, I dont see
any use in investing more time on GAE just to avoid some of their
restrictions while there are other solutions on the market already that
nearly have no limits at all. Only hazzle from AWS I found out so far is
the billing + invoices that are not yet compatible with EU (european) fiscal
needs.
Best,
Korbinian
Stefan Guggisberg schrieb:
On Sat, Apr 11, 2009 at 4:36 PM, Torgeir Veimo <torg...@pobox.com> wrote:
has anyone been able to deploy a Jackrabbit repo within google AppEngine
for Java? - if yes, I would be interested in how to overcome the "no
file
messing allowed" limitation.
You'd have to implement a bundle persistence mechanism that works with
JDO
and a JDO filesystem. Not too hard I think. The challenge probably lies
in
implementing an index storage implementation for lucene that works with
JDO.
agreed. i have never used jdo, but i would guess it doesn't support
RandomAccessFile-like
funtionality (which AFAIK is required by lucene).
however, the most 'challenging' restriction of the google appengine
sandbox is the lack of
thread creation support... this makes it virtually impossible to
deploy infrastructure
apps (like e.g. jackrabbit :(
cheers
stefan
--
Torgeir Veimo
torg...@pobox.com
