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, 30 Apr 2008 12:24:28 GMT
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
>

Mime
View raw message