Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@jackrabbit.apache.org
Received-SPF: pass (nike.apache.org: domain of janne.jalkanen@ecyrd.com
 designates 193.64.5.122 as permitted sender)
Message-Id: <9FC27910-F178-45FF-8DBB-911CD419B3BC@ecyrd.com>
From: Janne Jalkanen <janne.jalkanen@ecyrd.com>
To: users@jackrabbit.apache.org
In-Reply-To: <25452050.post@talk.nabble.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Subject: Re: Node capacity
Date: Tue, 15 Sep 2009 16:10:04 +0300
References: <25439191.post@talk.nabble.com>
 <c3ac3bad0909150100w4a6308bdwaddd12871f250a9e@mail.gmail.com>
 <25452050.post@talk.nabble.com>


My understanding is that you can't back up the version storage this  
way.  Or you can, but you can't import it trivially back.

See http://www.nabble.com/question-about-exporting-and-importing-via-JCR-api-td18765103.html

/Janne

On 15 Sep 2009, at 14:08, freak182 wrote:

>
> Hello,
>
> Thanks for the answer.
> My other concern is, does exportDocumentView or exportSystemView can  
> be
> regarded as one option of backing up the nodes?
>
> Thanks a lot.
> Cheers.
>
>
> Alexander Klimetschek wrote:
>>
>> On Mon, Sep 14, 2009 at 18:39, freak182 <eman.nollase@gmail.com>  
>> wrote:
>>> First I want to clarify on few things: in one repository can have  
>>> 1 or
>>> more
>>> workspace, right? and in workspace can have 1 or more nodes, right?
>>
>> Right.
>>
>>> My question is:
>>> 1. is there a limit capacity in workspace? in MB or GB?
>>> 2. is there a limit capacity in node? in MB or GB?
>>
>> Not sure if you mean a quota or a (scaling) limit. Jackrabbit does  
>> not
>> support a quota mechanism (ie. maximum amount of data per user and/or
>> workspace).
>>
>> How much data you can put into the repository depends on the
>> persistence configuration and the hardware. The best performance can
>> be achieved with bundle database persistence managers and a file
>> datastore. The latter will allow for a very scalable handling of  
>> large
>> binary properties. Note that large properties should be binaries...
>> (very) long string properties can slow down access to that node.
>>
>> Regarding number of nodes it is recommended to distribute the load
>> across the tree and to not have many direct children below a node -
>> the rough limit until it still scales well is around 10k nodes.
>>
>>> 3. if I can set the limit, will jackrabbit will auto-create nodes to
>>> store
>>> new files/documents?
>>
>> As said above, you cannot set a limit (quota). But even if there was
>> such a feature - why should setting a limit lead to auto-creation of
>> nodes? I think it should rather throw an exception on write if the
>> quota is exceeded.
>>
>>> 4. if im running out of space in drive c: where my original  
>>> repository
>>> and i
>>> want to use drive d:  or other harddisk to be the storage, how  
>>> easy it to
>>> tell jackrabbit to store/read from that hard disk or drive?
>>
>> Again, depends on the persistence configuration. If you use a
>> database, the mechanisms provided by the db for that case can be used
>> (obviously). Otherwise, incl. the file datastore, Jackrabbit does not
>> have a mechanism for automatic handling of a full disk. Your
>> application will get an (Repository?) exception when trying to write
>> to the repository if the disk is full.
>>
>> Regards,
>> Alex
>>
>> -- 
>> Alexander Klimetschek
>> alexander.klimetschek@day.com
>>
>>
>
> -- 
> View this message in context: http://www.nabble.com/Node-capacity-tp25439191p25452050.html
> Sent from the Jackrabbit - Users mailing list archive at Nabble.com.