jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tako Schotanus <quinte...@gmail.com>
Subject Re: Jackrabbit & google AppEngine
Date Mon, 13 Apr 2009 13:52:09 GMT
Thanks! That is a lot more detail than I hoped for :)

Seems very interesting, I definitely need to take a look at this.
Just one thing: is it possible to keep these tests around without having to
pay maintenance? Or is it test and trow away?

After reading about the GAE a bit I understand that one of the differences
is that Amazon gives you full flexibility (which is made easier with the
templates) while Google restricts you to their platform. The advantages of
Amazon's flexibility are obvious ofcourse, but it also means that a lot of
the scalability of your app is your responsibility. The advantage of "the
Google Way" seems to be that scalability comes "free" (if you can adjust
your app to the limits imposed by them).

Interesting stuff.

Cheers,
 -Tako

On Mon, Apr 13, 2009 at 12:45, Korbinian Bachl - privat <
korbinian.bachl@whiskyworld.de> wrote:

> 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.bachl@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 <torgeir@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
>>>>> torgeir@pobox.com
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>
>>


-- 

-Tako

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message