You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Tobias Bocanegra (JIRA)" <ji...@apache.org> on 2006/11/03 10:30:16 UTC
[jira] Created: (JCR-617) CachingHieraarchyManager may serve moved
items
CachingHieraarchyManager may serve moved items
----------------------------------------------
Key: JCR-617
URL: http://issues.apache.org/jira/browse/JCR-617
Project: Jackrabbit
Issue Type: Bug
Affects Versions: 1.1
Reporter: Tobias Bocanegra
Assigned To: Tobias Bocanegra
Fix For: 1.2
There is a problem with weak referenced item states and event notification in the
LocalItemStateManager.
consider the following:
- Session A traverses some nodes and fills-up the cache of the ChachingHierarchyManager
- This also fills the weak-ref cache in Session A LocalItemStateManager.
- Session B does some operations
- At some point, GC decides to remove the weakly refferenced ItemStates in Session As
LocalItemStateManager
- Session B moves a node and saves the changes.
- The SharedItemStateManager notifies all listeners that a node was modified
- The LocalItemStateManager of Session A receives the event, but does not bubble it,
because it does not have the item anymore in its cache
- The CachingHierarchyManager of Session A never receives the modification event and still
servers the items at the old location.
Solution A:
reconnect missing states in the LocalItemStateManager when an event is received. this has
the drawback that a lot of state would be generated that are not needed.
Solution B:
add a new event 'nodeModified' that is only sent by the LocalItemStateManager if a
'stateModified' was received for which it does not have the item aymore. this has the
drawback that alot more events are generated.
Will implement solution B
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (JCR-617) CachingHieraarchyManager may serve moved
items
Posted by "Tobias Bocanegra (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-617?page=all ]
Tobias Bocanegra closed JCR-617.
--------------------------------
Resolution: Fixed
Committed revision 470745.
> CachingHieraarchyManager may serve moved items
> ----------------------------------------------
>
> Key: JCR-617
> URL: http://issues.apache.org/jira/browse/JCR-617
> Project: Jackrabbit
> Issue Type: Bug
> Affects Versions: 1.1
> Reporter: Tobias Bocanegra
> Assigned To: Tobias Bocanegra
> Fix For: 1.2
>
>
> There is a problem with weak referenced item states and event notification in the
> LocalItemStateManager.
> consider the following:
> - Session A traverses some nodes and fills-up the cache of the ChachingHierarchyManager
> - This also fills the weak-ref cache in Session A LocalItemStateManager.
> - Session B does some operations
> - At some point, GC decides to remove the weakly refferenced ItemStates in Session As
> LocalItemStateManager
> - Session B moves a node and saves the changes.
> - The SharedItemStateManager notifies all listeners that a node was modified
> - The LocalItemStateManager of Session A receives the event, but does not bubble it,
> because it does not have the item anymore in its cache
> - The CachingHierarchyManager of Session A never receives the modification event and still
> servers the items at the old location.
> Solution A:
> reconnect missing states in the LocalItemStateManager when an event is received. this has
> the drawback that a lot of state would be generated that are not needed.
> Solution B:
> add a new event 'nodeModified' that is only sent by the LocalItemStateManager if a
> 'stateModified' was received for which it does not have the item aymore. this has the
> drawback that alot more events are generated.
> Will implement solution B
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (JCR-617) CachingHieraarchyManager may serve moved
items
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-617?page=all ]
Jukka Zitting reopened JCR-617:
-------------------------------
> CachingHieraarchyManager may serve moved items
> ----------------------------------------------
>
> Key: JCR-617
> URL: http://issues.apache.org/jira/browse/JCR-617
> Project: Jackrabbit
> Issue Type: Bug
> Affects Versions: 1.1, 1.1.1
> Reporter: Tobias Bocanegra
> Assigned To: Tobias Bocanegra
> Fix For: 1.2
>
>
> There is a problem with weak referenced item states and event notification in the
> LocalItemStateManager.
> consider the following:
> - Session A traverses some nodes and fills-up the cache of the ChachingHierarchyManager
> - This also fills the weak-ref cache in Session A LocalItemStateManager.
> - Session B does some operations
> - At some point, GC decides to remove the weakly refferenced ItemStates in Session As
> LocalItemStateManager
> - Session B moves a node and saves the changes.
> - The SharedItemStateManager notifies all listeners that a node was modified
> - The LocalItemStateManager of Session A receives the event, but does not bubble it,
> because it does not have the item anymore in its cache
> - The CachingHierarchyManager of Session A never receives the modification event and still
> servers the items at the old location.
> Solution A:
> reconnect missing states in the LocalItemStateManager when an event is received. this has
> the drawback that a lot of state would be generated that are not needed.
> Solution B:
> add a new event 'nodeModified' that is only sent by the LocalItemStateManager if a
> 'stateModified' was received for which it does not have the item aymore. this has the
> drawback that alot more events are generated.
> Will implement solution B
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (JCR-617) CachingHieraarchyManager may serve moved
items
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-617?page=all ]
Jukka Zitting resolved JCR-617.
-------------------------------
Resolution: Fixed
> CachingHieraarchyManager may serve moved items
> ----------------------------------------------
>
> Key: JCR-617
> URL: http://issues.apache.org/jira/browse/JCR-617
> Project: Jackrabbit
> Issue Type: Bug
> Affects Versions: 1.1, 1.1.1
> Reporter: Tobias Bocanegra
> Assigned To: Tobias Bocanegra
> Fix For: 1.2
>
>
> There is a problem with weak referenced item states and event notification in the
> LocalItemStateManager.
> consider the following:
> - Session A traverses some nodes and fills-up the cache of the ChachingHierarchyManager
> - This also fills the weak-ref cache in Session A LocalItemStateManager.
> - Session B does some operations
> - At some point, GC decides to remove the weakly refferenced ItemStates in Session As
> LocalItemStateManager
> - Session B moves a node and saves the changes.
> - The SharedItemStateManager notifies all listeners that a node was modified
> - The LocalItemStateManager of Session A receives the event, but does not bubble it,
> because it does not have the item anymore in its cache
> - The CachingHierarchyManager of Session A never receives the modification event and still
> servers the items at the old location.
> Solution A:
> reconnect missing states in the LocalItemStateManager when an event is received. this has
> the drawback that a lot of state would be generated that are not needed.
> Solution B:
> add a new event 'nodeModified' that is only sent by the LocalItemStateManager if a
> 'stateModified' was received for which it does not have the item aymore. this has the
> drawback that alot more events are generated.
> Will implement solution B
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (JCR-617) CachingHieraarchyManager may serve moved
items
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-617?page=all ]
Jukka Zitting updated JCR-617:
------------------------------
Affects Version/s: 1.1.1
> CachingHieraarchyManager may serve moved items
> ----------------------------------------------
>
> Key: JCR-617
> URL: http://issues.apache.org/jira/browse/JCR-617
> Project: Jackrabbit
> Issue Type: Bug
> Affects Versions: 1.1, 1.1.1
> Reporter: Tobias Bocanegra
> Assigned To: Tobias Bocanegra
> Fix For: 1.2
>
>
> There is a problem with weak referenced item states and event notification in the
> LocalItemStateManager.
> consider the following:
> - Session A traverses some nodes and fills-up the cache of the ChachingHierarchyManager
> - This also fills the weak-ref cache in Session A LocalItemStateManager.
> - Session B does some operations
> - At some point, GC decides to remove the weakly refferenced ItemStates in Session As
> LocalItemStateManager
> - Session B moves a node and saves the changes.
> - The SharedItemStateManager notifies all listeners that a node was modified
> - The LocalItemStateManager of Session A receives the event, but does not bubble it,
> because it does not have the item anymore in its cache
> - The CachingHierarchyManager of Session A never receives the modification event and still
> servers the items at the old location.
> Solution A:
> reconnect missing states in the LocalItemStateManager when an event is received. this has
> the drawback that a lot of state would be generated that are not needed.
> Solution B:
> add a new event 'nodeModified' that is only sent by the LocalItemStateManager if a
> 'stateModified' was received for which it does not have the item aymore. this has the
> drawback that alot more events are generated.
> Will implement solution B
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira