jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Frédéric Esnault <f...@legisway.com>
Subject RE: atomic vs group node creation/storage
Date Thu, 21 Jun 2007 13:56:59 GMT
Hi Stefan,

First thanks for your answer. In fact I just found in a mailing list a message from you about
this, explaining this blob size limit problem. And your answer here answers my other question
: why is my webapp didn't have this problem when creating a node with 12 000 child nodes,
and why this external tool does only creating 2 500 child nodes.

In fact my webapp is configured in maven, with jackrabbit 1.3 as a dependency. For this tool,
I quickly copied jars of Jackrabbit 1.2.3. Shame on me ;-)

Frédéric Esnault

-----Message d'origine-----
De : Stefan Guggisberg [mailto:stefan.guggisberg@gmail.com] 
Envoyé : jeudi 21 juin 2007 15:54
À : dev@jackrabbit.apache.org
Objet : Re: atomic vs group node creation/storage

On 6/21/07, Frédéric Esnault <fesn@legisway.com> wrote:
> Now I have a strange problem with the test tool. I tried to launch creation on 2500 nodes,
and got this :
> Exception in thread "main" javax.jcr.RepositoryException: /: unable to update it
> em.: failed to write node state: 409d58ab-bd92-410c-8096-1fca52b8ef63: failed to
>  write node state: 409d58ab-bd92-410c-8096-1fca52b8ef63
>         at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1212)
>         at org.apache.jackrabbit.core.SessionImpl.save(SessionImpl.java:823)
>         at TestSingleGroup.testOneByOne(TestSingleGroup.java:109)
> Caused by: com.mysql.jdbc.MysqlDataTruncation: Data truncation: Data too long fo
> r column 'NODE_DATA' at row 1

seems like you hit the size limit of the 'blob' data type. for more information
see https://issues.apache.org/jira/browse/JCR-760. please note that this
issue should have been fixed in the 1.3 release. what version are you using?


> Frédéric Esnault
> -----Message d'origine-----
> De: Thomas Mueller [mailto:thomas.tom.mueller@gmail.com]
> Envoyé: jeudi 21 juin 2007 11:25
> À: dev@jackrabbit.apache.org
> Objet: Re: atomic vs group node creation/storage
> Hi,
> > The number of rows was increasing also very fast.
> > When my default_node table reached 22 GB, it was holding 35 million rows.
> Is the problem now, that it is reproducible on your machine, but not
> on my machine? Could you run my test case on your machine? It is
> simpler and doesn't use node types. If you can't reproduce the problem
> with my test on your machine, but can reproduce it with your test
> case, could you send your complete test code (there are still some
> pieces missing, for example initializeContractor)?
> > The problem here is that if you use predicate on the node with plenty of instances
(say a contract), the search works fine,
> OK
> > the problem is if the search has to look at all the instances of this type of node.
> I'm not sure if I understand the problem... You would search all nodes
> of the same type without any condition ("SELECT * FROM x:y")? Why
> would you do a search like this, and how would using same name
> siblings solve the problem?
> > We actually plan a 100K nodes repository, with an extreme limit to 250K,
> > which could possibly mean something like a maximum of 25K to 30K child nodes,
> Somebody else already said, many child nodes is only a problem for
> writing. And for manually browsing the repository, if you want to do
> that.
> Thomas
> Attachment: testSingleGroup.zip (I hope this works)

View raw message