Hi guys,
I accidentally deleted the version directory inside of the repository.
Now I am getting sometimes this Exception:
java.lang.NullPointerException
at
org.apache.jackrabbit.core.VersionManagerImpl.getVersionHistory(VersionManagerImpl.java:145)
at org.apache.jackrabbit.core.NodeImpl.getVer
Thomas, you are right. I saw the code, but still I cannot explain why these
57 threads are doing the same thing and been waiting for at least 5 seconds.
Our deployment is a Linux Red Hat Enterprise 2.6.18-194.el5 running in a 4
6-core machines (24 cores) with 34 GB RAM.
Jackrabbit 2.0
any sugge
Thanks for the response.
They are all different thread ids.
What would it be the best way to avoid so many threads getting blocked
there?
On Wed, Oct 6, 2010 at 11:44 PM, Thomas Müller wrote:
> Hi,
>
> > We have more than 50 threads waiting here.
>
> Is it the same thread number for each of the
Hi,
On Thu, Oct 7, 2010 at 3:19 PM, Stefan Hagedorn wrote:
> ...I am pretty new to Jackrabbit and while thinking about how to organize my
> content in the repo, I was
> wondering if the structure/hierarchy of the nodes has an (significant) impact
> on indexing and searching
I don't have de
Hi Luis,
Of course, we may not have the same usage & configuration but on our side, we
have a 40GB repository.
And we upgraded flawlessly from 1.5.6 to 1.6.1 just by changing the jackrabbit
jar.
You might want to try on a staging environment if you have one.
Regards,
Laurent
-Message d'o
Hi,
I am pretty new to Jackrabbit and while thinking about how to organize my
content in the repo, I was wondering if the structure/hierarchy of the nodes
has an (significant) impact on indexing and searching.
I was thinking about organizing my content in files and folders, because I read
so
Hi Jukka,
Of course, I do appreciate the time you put in to help out, and possibly
state the obvious from your perspective. We don't update every component of
our architecture if it is stable. Our repository was fairly stable until
lately. We have a 20GB+ repository so the migration, jumping minor
Hi,
On Thu, Oct 7, 2010 at 1:19 PM, Luis Muniz wrote:
> On Thu, Oct 7, 2010 at 11:47 AM, Jukka Zitting wrote:
>> On Thu, Oct 7, 2010 at 11:44 AM, Luis Muniz wrote:
>> > We are using jackrabbit-1.5.6, should we think about upgrading?
>> Yes.
> Why?
You're one major and two minor releases behind
Hi
On Thu, Oct 7, 2010 at 11:47 AM, Jukka Zitting wrote:
> Hi,
>
> On Thu, Oct 7, 2010 at 11:44 AM, Luis Muniz wrote:
> > We are using jackrabbit-1.5.6, should we think about upgrading?
>
> Yes.
>
> Why?
> BR,
>
> Jukka Zitting
>
Hi,
On Thu, Oct 7, 2010 at 11:44 AM, Luis Muniz wrote:
> We are using jackrabbit-1.5.6, should we think about upgrading?
Yes.
BR,
Jukka Zitting
Hi,
We are trying to figure out a deadlock taht blocks all incoming requests
until we restart the jackrabbit repository.
The repository runs as a standalone server. It is accessed by rmi over http.
This is our rep.properties file (from repository/meta):
#Wed Oct 06 16:10:01 CEST 2010
option.ve
Hi,
On Thu, Oct 7, 2010 at 6:52 AM, Jérôme Verstrynge wrote:
> Is there any method to create a pure in-memory (transient) repository using
> java code only?
That's currently not possible.
BR,
Jukka Zitting
Hi all,
is it possible to create a SQL query to select all locked or not locked
nodes?
I am currently using this query to search for locked nodes:
SELECT * FROM nt:base WHERE jcr:lockOwner IS NOT NULL
And this query to search for not locked nodes:
SELECT * FROM nt:base WHERE jcr
On Wed, Oct 6, 2010 at 10:41 PM, Palmer, Tom wrote:
> I'm having a hard time understanding the utility of defining a property
> as protected. If it's protected then the only way to get a value set is
> to also specify autocreated and a default but that doesn't work for
> setting dynamic values si
14 matches
Mail list logo
