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.
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 <[EMAIL PROTECTED]>
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: [EMAIL PROTECTED]
--
*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: [EMAIL PROTECTED]