You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "julien revel (JIRA)" <ji...@apache.org> on 2011/03/13 00:24:59 UTC
[jira] Created: (JCR-2913) Shared nodes disappear suddenly -
Database corruption : Cannot delete nodes anymore : Error is Node with id
'X" does not have shared parent with id: 'Y'
Shared nodes disappear suddenly - Database corruption : Cannot delete nodes anymore : Error is Node with id 'X" does not have shared parent with id: 'Y'
--------------------------------------------------------------------------------------------------------------------------------------------------------
Key: JCR-2913
URL: https://issues.apache.org/jira/browse/JCR-2913
Project: Jackrabbit Content Repository
Issue Type: Bug
Reporter: julien revel
Priority: Critical
This problem occurs on a following configuration
- JCR 2.3 Snapshot
- Tomcat 6
- Postgresql 9.0
Jackrabbit is embedded within a Spring application, that communicates with clients in AMF format (Flex client)
The symptom is that some shared Nodes have disappeared from the repository, without having deleted by our application (and we checked a lot already).
Then, repository seems to be corrupted, because it becomes impossible to delete any ancestor node of those having disappear.
The error is not reproducible, it may happen at any time, it is random.
Sometimes, with a fresh base, after creating some nodes, sometimes it happens after a while, when playing with the application.
It never happened on Jetty/Derby development server, but always happened on servers with Postgres, even with a single user.
I guess it is not a bug in JCR, but that we provoked the problem in some way. Maybe by multi-threading ?
However, for each remote call that send data to write, we create a new JCRSession, then save it multiple times, then close it.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (JCR-2913) Shared nodes disappear suddenly -
Database corruption : Cannot delete nodes anymore : Node with id 'X" does
not have shared parent with id: 'Y'
Posted by "julien revel (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
julien revel updated JCR-2913:
------------------------------
Summary: Shared nodes disappear suddenly - Database corruption : Cannot delete nodes anymore : Node with id 'X" does not have shared parent with id: 'Y' (was: Shared nodes disappear suddenly - Database corruption : Cannot delete nodes anymore : Error is Node with id 'X" does not have shared parent with id: 'Y')
> Shared nodes disappear suddenly - Database corruption : Cannot delete nodes anymore : Node with id 'X" does not have shared parent with id: 'Y'
> -----------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JCR-2913
> URL: https://issues.apache.org/jira/browse/JCR-2913
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Reporter: julien revel
> Priority: Critical
>
> This problem occurs on a following configuration
> - JCR 2.3 Snapshot
> - Tomcat 6
> - Postgresql 9.0
> Jackrabbit is embedded within a Spring application, that communicates with clients in AMF format (Flex client)
> The symptom is that some shared Nodes have disappeared from the repository, without having deleted by our application (and we checked a lot already).
> Then, repository seems to be corrupted, because it becomes impossible to delete any ancestor node of those having disappear.
> The error is not reproducible, it may happen at any time, it is random.
> Sometimes, with a fresh base, after creating some nodes, sometimes it happens after a while, when playing with the application.
> It never happened on Jetty/Derby development server, but always happened on servers with Postgres, even with a single user.
> I guess it is not a bug in JCR, but that we provoked the problem in some way. Maybe by multi-threading ?
> However, for each remote call that send data to write, we create a new JCRSession, then save it multiple times, then close it.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira