jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Guggisberg" <stefan.guggisb...@day.com>
Subject Re: Problems with MySqlPersistenceManager: "unable to update item"
Date Wed, 07 May 2008 14:07:27 GMT
On Tue, May 6, 2008 at 4:28 PM, Lorenzo Dini <Lorenzo.Dini@cern.ch> wrote:
> Hi
>
>  I tried the latest version of MySQL (5.0.51) and it works just fine!
>
>  It seems there are problems with MySQL 5.0.27 and jackrabbit-core 1.4.2
> bundle.

i am glad the switch solves your issue but i still would want to know
the reason for
the failure ;)

please let me know if you've got some new insights,

thanks
stean

>
>  Lorenzo
>
>  Lorenzo Dini ha scritto:
>
>
>
> > Hi,
> >
> > thank you for the reply.
> >
> > I attache the full DEBUG logs, from the creation of the node
> 5462ac5e-ff4d-4489-9423-427f1e3d4520 to the exception.
> >
> > if you please can have a look at the entries, I do not see any other
> exception beofore the "unable to update item"...
> >
> > The node is created at line 1 of the log.
> >
> > Then all the items are added and cached.
> >
> > Just before the exception, I see another creation of the same node
> 5462ac5e-ff4d-4489-9423-427f1e3d4520 (line 320).
> >
> > It seems that the node is not found in the DB and it is trying to recreate
> it??
> >
> > Do I have to configure MySQL in a custom way to use the bundles??
> >
> > Lorenzo
> >
> >
> >
> > Stefan Guggisberg ha scritto:
> >
> > > hi lorenzo
> > >
> > > On Tue, Apr 29, 2008 at 6:32 PM, Lorenzo Dini <Lorenzo.Dini@cern.ch>
> wrote:
> > >
> > > > Hi all,
> > > >
> > > >  I get an exception while saving nodes with MySqlPersistenceManager
> that it
> > > > does not happen if I use DerbyPersistenceManager.
> > > >
> > > >  The weird thing is that executing the same code several times under
> the
> > > > same conditions (the code stores a long sequence of nodes), the
> exception
> > > > not always at the same point but happens randomly on different nodes.
> > > >
> > > >  Cannot be the DB connection because the DB is on the same machine.
> > > >
> > > >  This is the stacktrace:
> > > >
> > > >  RepositoryException:
> > > > /etics:volatiles/etics:projects[2]/etics:components[6]: unable to
> update
> > > > item.: a057d13d-c342-4b07-b7d6-ed088b4f6b20
> > > >  org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1258)
> > > >
> > > >
> org.etics.repository.webservice.persistency.SubmissionManager.storeConfigurations(SubmissionManager.java:590)
> > > >
> > > >
> org.etics.repository.webservice.persistency.SubmissionManager.storeComponents(SubmissionManager.java:511)
> > > >
> > > >
> org.etics.repository.webservice.persistency.SubmissionManager.storeProjects(SubmissionManager.java:301)
> > > >
> > > >
> org.etics.repository.webservice.persistency.SubmissionManager.saveArtefactStructure(SubmissionManager.java:160)
> > > >
> > > >
> org.etics.repository.webservice.persistency.SubmissionQueue$SubmissionRun.run(SubmissionQueue.java:189)
> > > >
> > > >
> > > >  Debugging a bit I saw the real exception: NoSuchItemStateException in
> > > > AbstractBundlePersistenceManager.java:559
> > > >
> > > >  553 if (state.isNode()) {
> > > >  554   NodeId nodeId = (NodeId) state.getId();
> > > >  555   NodePropBundle bundle = (NodePropBundle) modified.get(nodeId);
> > > >  556   if (bundle == null) {
> > > >  557     bundle = getBundle(nodeId);
> > > >  558     if (bundle == null) {
> > > >  559       throw new NoSuchItemStateException(nodeId.toString());
> > > >  560     }
> > > >  561     modified.put(nodeId, bundle);
> > > >  562   }
> > > >  563   bundle.update((NodeState) state);
> > > >  564 }
> > > >
> > > >
> > > >  This is my configuration:
> > > >
> > > >  <PersistenceManager
> > > >
> class="org.apache.jackrabbit.core.persistence.bundle.MySqlPersistenceManager">
> > > >        <param name="bundleCacheSize" value="8"/>
> > > >        <param name="consistencyCheck" value="true"/>
> > > >        <param name="minBlobSize" value="16384"/>
> > > >        <param name="driver" value="com.mysql.jdbc.Driver"/>
> > > >        <param name="url" value="jdbc:mysql://localhost:3306/bundle"/>
> > > >        <param name="user" value="***"/>
> > > >        <param name="password" value="***"/>
> > > >        <param name="schema" value="mysql"/>
> > > >        <param name="errorHandling" value=""/>
> > > >        <param name="schemaObjectPrefix" value="${wsp.name}_"/>
> > > >  </PersistenceManager>
> > > >
> > > >  libraries:
> > > >        jackrabbit-api-1.4.jar
> > > >        jackrabbit-core-1.4.2.jar
> > > >        jackrabbit-jcr-commons-1.4.2.jar
> > > >        jackrabbit-spi-1.4.jar
> > > >        jackrabbit-spi-commons-1.4.jar
> > > >        jackrabbit-text-extractors-1.4.jar
> > > >        lucene-core-2.2.0.jar
> > > >
> > > >  MySQL Server Version: 4.1.20
> > > >
> > > >  I tried with both:
> > > >        mysql-connector-java-5.1.6-bin.jar
> > > >  and
> > > >        mysql-connector-java-3.1.10-bin.jar.
> > > >
> > > >
> > > >  Without changing anything, but using Derby, it works:
> > > >
> > > >  <PersistenceManager
> > > >
> class="org.apache.jackrabbit.core.persistence.bundle.DerbyPersistenceManager">
> > > >        <param name="url"
> value="jdbc:derby:{wsp.name}/db;create=true"/>
> > > >        <param name="schemaObjectPrefix" value="${wsp.name}"/>
> > > >  </PersistenceManager>
> > > >
> > > >
> > > >  I have been using the same code with Jackrabbit 1.3 for more than one
> year
> > > > now without problems (SimpleDBPersistanceManager on top of the same
> MySQL).
> > > >
> > > >  What can it be??
> > > >
> > >
> > > that's hard to tell without getting some more information. all i can
> > > say is that reading
> > > an existing  bundle from the db fails for some reason.
> > >
> > > if you haven't done so already please increase the logging level. you
> should
> > > find more detailed information regarding the issue causing the failure
> > > in the log.
> > >
> > > could you please provide all relevant log entries?
> > >
> > > does the failure occur after a certain period of time? if yes it could
> > > be related
> > > to the auto-reconnect logic. is the db completely left alone or is it
> backed up/
> > > restarted periodically?
> > >
> > > last but not least:
> > > i know it's difficult but is there a chance that you could put
> > > together a simple
> > > test case for reproducing the issue?
> > >
> > > cheers
> > > stefan
> > >
> > >
> > > >  Thank you for your help.
> > > >
> > > >  Lorenzo
> > > >
> > > >
> > > >
> > > >  --
> > > >  *Lorenzo Dini*
> > > >
> > > >  CERN - European Organization for Nuclear Research
> > > >  Information Technology Department
> > > >  CH-1211 Geneva 23
> > > >
> > > >  Building 28 - Office 1-007
> > > >  Phone: +41 (0) 22 7674384
> > > >  Fax: +41 (0) 22 7668847
> > > >  E-mail: Lorenzo.Dini@cern.ch
> > > >
> > > >
> > >
> >
> >
>
>  --
>  *Lorenzo Dini*
>
>  CERN - European Organization for Nuclear Research
>  Information Technology Department
>  CH-1211 Geneva 23
>
>  Building 28 - Office 1-007
>  Phone: +41 (0) 22 7674384
>  Fax: +41 (0) 22 7668847
>  E-mail: Lorenzo.Dini@cern.ch
>

Mime
View raw message