[JBoss JIRA] Created: (JBCACHE-710) CacheLoader passivation/activation produces recursive exception when loader.remove fails
9:20 p.m.
CacheLoader passivation/activation produces recursive exception when loader.remove fails
----------------------------------------------------------------------------------------
Key: JBCACHE-710
URL: http://jira.jboss.com/jira/browse/JBCACHE-710
Project: JBoss Cache
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Cache loaders
Affects Versions: 1.4.0
Reporter: Ben Wang
Assigned To: Manik Surtani
Priority: Critical
Fix For: 2.0.0
I have encountered this problem during ejb3 sfsb port of JBC1.4. This is what happened:
In ActivationInterceptor.java, we have:
if (n != null && !n.containsKey(TreeCache.UNINITIALIZED)) {
if (n.hasChildren()) {
if (allInitialized(n)) {
log.debug("children all initialized");
remove(fqn);
}
} else if (loaderNoChildren(fqn)) {
log.debug("no children " + n);
remove(fqn);
}
}
}
}
return retval;
}
private void remove(Fqn fqn) throws Exception {
loader.remove(fqn);
cache.notifyNodeActivate(fqn, false);
if (cache.getUseInterceptorMbeans()&& statsEnabled)
m_activations++;
}
problem arises when loader.remove(fqn) fails (can be a file lock there, e.g.), then if I
have a Cache listener to receive nodeActivate event, and in there, I will have to retrieve
the node value, e.g.,
cache.get(fqn, key)
to process some logic, then get(fqn, key) will come back to ActivationInterceptor and
attempt another .remove() and therefore the recursion.
A proposed fix is we should throw exception when removing the node fails in CacheLoader (I
am using FileCacheLoader), e.g., DataNotRemovedException. That way, ActivationInterceptor
can catch it here and skip event notification (since it won't be valid anyway).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:46 a.m.
New subject: [JBoss JIRA] Commented: (JBCACHE-710) CacheLoader passivation/activation produces recursive exception when loader.remove fails
[ http://jira.jboss.com/jira/browse/JBCACHE-710?page=comments#action_12345784 ]
Manik Surtani commented on JBCACHE-710:
---------------------------------------
Have you got a Unit Test for this?
Also, did this fail with 1.4.0.SP1, and do we need the fix for 1.4.0.SP2, particularly if
it affects SFSB passivation and would be needed for AS 4.0.x?
CacheLoader passivation/activation produces recursive exception when
loader.remove fails
----------------------------------------------------------------------------------------
Key: JBCACHE-710
URL: http://jira.jboss.com/jira/browse/JBCACHE-710
Project: JBoss Cache
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Cache loaders
Affects Versions: 1.4.0
Reporter: Ben Wang
Assigned To: Manik Surtani
Priority: Critical
Fix For: 2.0.0
I have encountered this problem during ejb3 sfsb port of JBC1.4. This is what happened:
In ActivationInterceptor.java, we have:
if (n != null && !n.containsKey(TreeCache.UNINITIALIZED)) {
if (n.hasChildren()) {
if (allInitialized(n)) {
log.debug("children all initialized");
remove(fqn);
}
} else if (loaderNoChildren(fqn)) {
log.debug("no children " + n);
remove(fqn);
}
}
}
}
return retval;
}
private void remove(Fqn fqn) throws Exception {
loader.remove(fqn);
cache.notifyNodeActivate(fqn, false);
if (cache.getUseInterceptorMbeans()&& statsEnabled)
m_activations++;
}
problem arises when loader.remove(fqn) fails (can be a file lock there, e.g.), then if I
have a Cache listener to receive nodeActivate event, and in there, I will have to retrieve
the node value, e.g.,
cache.get(fqn, key)
to process some logic, then get(fqn, key) will come back to ActivationInterceptor and
attempt another .remove() and therefore the recursion.
A proposed fix is we should throw exception when removing the node fails in CacheLoader
(I am using FileCacheLoader), e.g., DataNotRemovedException. That way,
ActivationInterceptor can catch it here and skip event notification (since it won't be
valid anyway).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
9 a.m.
New subject: [JBoss JIRA] Commented: (JBCACHE-710) CacheLoader passivation/activation produces recursive exception when loader.remove fails
[ http://jira.jboss.com/jira/browse/JBCACHE-710?page=comments#action_12345786 ]
Manik Surtani commented on JBCACHE-710:
---------------------------------------
Also, I don't quite understand this problem - if loader.remove() fails, the
notification should not be called as the exception should be thrown. Is this not the
case?
CacheLoader passivation/activation produces recursive exception when
loader.remove fails
----------------------------------------------------------------------------------------
Key: JBCACHE-710
URL: http://jira.jboss.com/jira/browse/JBCACHE-710
Project: JBoss Cache
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Cache loaders
Affects Versions: 1.4.0
Reporter: Ben Wang
Assigned To: Manik Surtani
Priority: Critical
Fix For: 2.0.0
I have encountered this problem during ejb3 sfsb port of JBC1.4. This is what happened:
In ActivationInterceptor.java, we have:
if (n != null && !n.containsKey(TreeCache.UNINITIALIZED)) {
if (n.hasChildren()) {
if (allInitialized(n)) {
log.debug("children all initialized");
remove(fqn);
}
} else if (loaderNoChildren(fqn)) {
log.debug("no children " + n);
remove(fqn);
}
}
}
}
return retval;
}
private void remove(Fqn fqn) throws Exception {
loader.remove(fqn);
cache.notifyNodeActivate(fqn, false);
if (cache.getUseInterceptorMbeans()&& statsEnabled)
m_activations++;
}
problem arises when loader.remove(fqn) fails (can be a file lock there, e.g.), then if I
have a Cache listener to receive nodeActivate event, and in there, I will have to retrieve
the node value, e.g.,
cache.get(fqn, key)
to process some logic, then get(fqn, key) will come back to ActivationInterceptor and
attempt another .remove() and therefore the recursion.
A proposed fix is we should throw exception when removing the node fails in CacheLoader
(I am using FileCacheLoader), e.g., DataNotRemovedException. That way,
ActivationInterceptor can catch it here and skip event notification (since it won't be
valid anyway).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
9 a.m.
New subject: [JBoss JIRA] Commented: (JBCACHE-710) CacheLoader passivation/activation produces recursive exception when loader.remove fails
[ http://jira.jboss.com/jira/browse/JBCACHE-710?page=comments#action_12345787 ]
Manik Surtani commented on JBCACHE-710:
---------------------------------------
Also, is this specific to the FCL?
CacheLoader passivation/activation produces recursive exception when
loader.remove fails
----------------------------------------------------------------------------------------
Key: JBCACHE-710
URL: http://jira.jboss.com/jira/browse/JBCACHE-710
Project: JBoss Cache
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Cache loaders
Affects Versions: 1.4.0
Reporter: Ben Wang
Assigned To: Manik Surtani
Priority: Critical
Fix For: 2.0.0
I have encountered this problem during ejb3 sfsb port of JBC1.4. This is what happened:
In ActivationInterceptor.java, we have:
if (n != null && !n.containsKey(TreeCache.UNINITIALIZED)) {
if (n.hasChildren()) {
if (allInitialized(n)) {
log.debug("children all initialized");
remove(fqn);
}
} else if (loaderNoChildren(fqn)) {
log.debug("no children " + n);
remove(fqn);
}
}
}
}
return retval;
}
private void remove(Fqn fqn) throws Exception {
loader.remove(fqn);
cache.notifyNodeActivate(fqn, false);
if (cache.getUseInterceptorMbeans()&& statsEnabled)
m_activations++;
}
problem arises when loader.remove(fqn) fails (can be a file lock there, e.g.), then if I
have a Cache listener to receive nodeActivate event, and in there, I will have to retrieve
the node value, e.g.,
cache.get(fqn, key)
to process some logic, then get(fqn, key) will come back to ActivationInterceptor and
attempt another .remove() and therefore the recursion.
A proposed fix is we should throw exception when removing the node fails in CacheLoader
(I am using FileCacheLoader), e.g., DataNotRemovedException. That way,
ActivationInterceptor can catch it here and skip event notification (since it won't be
valid anyway).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:18 a.m.
New subject: [JBoss JIRA] Commented: (JBCACHE-710) CacheLoader passivation/activation produces recursive exception when loader.remove fails
[ http://jira.jboss.com/jira/browse/JBCACHE-710?page=comments#action_12345897 ]
Ben Wang commented on JBCACHE-710:
----------------------------------
This problem arises during development where there are all sorts of exception conditions
and resboot of the AS leaves the .dat file in bad state. Next time around, the recursive
loop occurs. This doesn't happen often but is deadly nonetheless.
Since I only test the file cache loader so I can't say for the rest. But I think it is
a good idea anyway to throw "DataNotRemovedException" as a runtime exception to
alert the user of this problem.
CacheLoader passivation/activation produces recursive exception when
loader.remove fails
----------------------------------------------------------------------------------------
Key: JBCACHE-710
URL: http://jira.jboss.com/jira/browse/JBCACHE-710
Project: JBoss Cache
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Cache loaders
Affects Versions: 1.4.0
Reporter: Ben Wang
Assigned To: Manik Surtani
Priority: Critical
Fix For: 2.0.0
I have encountered this problem during ejb3 sfsb port of JBC1.4. This is what happened:
In ActivationInterceptor.java, we have:
if (n != null && !n.containsKey(TreeCache.UNINITIALIZED)) {
if (n.hasChildren()) {
if (allInitialized(n)) {
log.debug("children all initialized");
remove(fqn);
}
} else if (loaderNoChildren(fqn)) {
log.debug("no children " + n);
remove(fqn);
}
}
}
}
return retval;
}
private void remove(Fqn fqn) throws Exception {
loader.remove(fqn);
cache.notifyNodeActivate(fqn, false);
if (cache.getUseInterceptorMbeans()&& statsEnabled)
m_activations++;
}
problem arises when loader.remove(fqn) fails (can be a file lock there, e.g.), then if I
have a Cache listener to receive nodeActivate event, and in there, I will have to retrieve
the node value, e.g.,
cache.get(fqn, key)
to process some logic, then get(fqn, key) will come back to ActivationInterceptor and
attempt another .remove() and therefore the recursion.
A proposed fix is we should throw exception when removing the node fails in CacheLoader
(I am using FileCacheLoader), e.g., DataNotRemovedException. That way,
ActivationInterceptor can catch it here and skip event notification (since it won't be
valid anyway).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
7:40 a.m.
New subject: [JBoss JIRA] Commented: (JBCACHE-710) CacheLoader passivation/activation produces recursive exception when loader.remove fails
[ http://jira.jboss.com/jira/browse/JBCACHE-710?page=comments#action_12345908 ]
Manik Surtani commented on JBCACHE-710:
---------------------------------------
From Ben:
"Since now that we have documented the FCL limitation, maybe we can downgrade the
serverity and push it back to later releases. This is a bug associated mostly with FLC. If
I run into that problem again, I will raise it up."
CacheLoader passivation/activation produces recursive exception when
loader.remove fails
----------------------------------------------------------------------------------------
Key: JBCACHE-710
URL: http://jira.jboss.com/jira/browse/JBCACHE-710
Project: JBoss Cache
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Cache loaders
Affects Versions: 1.4.0
Reporter: Ben Wang
Assigned To: Manik Surtani
Priority: Critical
Fix For: 2.0.0
I have encountered this problem during ejb3 sfsb port of JBC1.4. This is what happened:
In ActivationInterceptor.java, we have:
if (n != null && !n.containsKey(TreeCache.UNINITIALIZED)) {
if (n.hasChildren()) {
if (allInitialized(n)) {
log.debug("children all initialized");
remove(fqn);
}
} else if (loaderNoChildren(fqn)) {
log.debug("no children " + n);
remove(fqn);
}
}
}
}
return retval;
}
private void remove(Fqn fqn) throws Exception {
loader.remove(fqn);
cache.notifyNodeActivate(fqn, false);
if (cache.getUseInterceptorMbeans()&& statsEnabled)
m_activations++;
}
problem arises when loader.remove(fqn) fails (can be a file lock there, e.g.), then if I
have a Cache listener to receive nodeActivate event, and in there, I will have to retrieve
the node value, e.g.,
cache.get(fqn, key)
to process some logic, then get(fqn, key) will come back to ActivationInterceptor and
attempt another .remove() and therefore the recursion.
A proposed fix is we should throw exception when removing the node fails in CacheLoader
(I am using FileCacheLoader), e.g., DataNotRemovedException. That way,
ActivationInterceptor can catch it here and skip event notification (since it won't be
valid anyway).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
7:40 a.m.
New subject: [JBoss JIRA] Updated: (JBCACHE-710) FileCacheLoader passivation/activation produces recursive exception when loader.remove fails
[ http://jira.jboss.com/jira/browse/JBCACHE-710?page=all ]
Manik Surtani updated JBCACHE-710:
----------------------------------
Summary: FileCacheLoader passivation/activation produces recursive exception when
loader.remove fails (was: CacheLoader passivation/activation produces recursive exception
when loader.remove fails)
Priority: Minor (was: Critical)
FileCacheLoader passivation/activation produces recursive exception
when loader.remove fails
--------------------------------------------------------------------------------------------
Key: JBCACHE-710
URL: http://jira.jboss.com/jira/browse/JBCACHE-710
Project: JBoss Cache
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Cache loaders
Affects Versions: 1.4.0
Reporter: Ben Wang
Assigned To: Manik Surtani
Priority: Minor
Fix For: 2.0.0
I have encountered this problem during ejb3 sfsb port of JBC1.4. This is what happened:
In ActivationInterceptor.java, we have:
if (n != null && !n.containsKey(TreeCache.UNINITIALIZED)) {
if (n.hasChildren()) {
if (allInitialized(n)) {
log.debug("children all initialized");
remove(fqn);
}
} else if (loaderNoChildren(fqn)) {
log.debug("no children " + n);
remove(fqn);
}
}
}
}
return retval;
}
private void remove(Fqn fqn) throws Exception {
loader.remove(fqn);
cache.notifyNodeActivate(fqn, false);
if (cache.getUseInterceptorMbeans()&& statsEnabled)
m_activations++;
}
problem arises when loader.remove(fqn) fails (can be a file lock there, e.g.), then if I
have a Cache listener to receive nodeActivate event, and in there, I will have to retrieve
the node value, e.g.,
cache.get(fqn, key)
to process some logic, then get(fqn, key) will come back to ActivationInterceptor and
attempt another .remove() and therefore the recursion.
A proposed fix is we should throw exception when removing the node fails in CacheLoader
(I am using FileCacheLoader), e.g., DataNotRemovedException. That way,
ActivationInterceptor can catch it here and skip event notification (since it won't be
valid anyway).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
7:40 a.m.
New subject: [JBoss JIRA] Closed: (JBCACHE-710) FileCacheLoader passivation/activation produces recursive exception when loader.remove fails
[ http://jira.jboss.com/jira/browse/JBCACHE-710?page=all ]
Manik Surtani closed JBCACHE-710.
---------------------------------
Resolution: Cannot Reproduce Bug
Sufficiently trivial and the FCL is not recommended for public use anyway.
FileCacheLoader passivation/activation produces recursive exception
when loader.remove fails
--------------------------------------------------------------------------------------------
Key: JBCACHE-710
URL: http://jira.jboss.com/jira/browse/JBCACHE-710
Project: JBoss Cache
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Cache loaders
Affects Versions: 1.4.0
Reporter: Ben Wang
Assigned To: Manik Surtani
Priority: Minor
Fix For: 2.0.0
I have encountered this problem during ejb3 sfsb port of JBC1.4. This is what happened:
In ActivationInterceptor.java, we have:
if (n != null && !n.containsKey(TreeCache.UNINITIALIZED)) {
if (n.hasChildren()) {
if (allInitialized(n)) {
log.debug("children all initialized");
remove(fqn);
}
} else if (loaderNoChildren(fqn)) {
log.debug("no children " + n);
remove(fqn);
}
}
}
}
return retval;
}
private void remove(Fqn fqn) throws Exception {
loader.remove(fqn);
cache.notifyNodeActivate(fqn, false);
if (cache.getUseInterceptorMbeans()&& statsEnabled)
m_activations++;
}
problem arises when loader.remove(fqn) fails (can be a file lock there, e.g.), then if I
have a Cache listener to receive nodeActivate event, and in there, I will have to retrieve
the node value, e.g.,
cache.get(fqn, key)
to process some logic, then get(fqn, key) will come back to ActivationInterceptor and
attempt another .remove() and therefore the recursion.
A proposed fix is we should throw exception when removing the node fails in CacheLoader
(I am using FileCacheLoader), e.g., DataNotRemovedException. That way,
ActivationInterceptor can catch it here and skip event notification (since it won't be
valid anyway).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:47 a.m.
New subject: [JBoss JIRA] Commented: (JBCACHE-710) FileCacheLoader passivation/activation produces recursive exception when loader.remove fails
[ http://jira.jboss.com/jira/browse/JBCACHE-710?page=comments#action_12351095 ]
Galder Zamarreno commented on JBCACHE-710:
------------------------------------------
Yeah, but EJB3 uses FLC for passivation of SFSB....
FileCacheLoader passivation/activation produces recursive exception
when loader.remove fails
--------------------------------------------------------------------------------------------
Key: JBCACHE-710
URL: http://jira.jboss.com/jira/browse/JBCACHE-710
Project: JBoss Cache
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Cache loaders
Affects Versions: 1.4.0.GA
Reporter: Ben Wang
Assigned To: Manik Surtani
Priority: Minor
Fix For: 2.0.0.GA
I have encountered this problem during ejb3 sfsb port of JBC1.4. This is what happened:
In ActivationInterceptor.java, we have:
if (n != null && !n.containsKey(TreeCache.UNINITIALIZED)) {
if (n.hasChildren()) {
if (allInitialized(n)) {
log.debug("children all initialized");
remove(fqn);
}
} else if (loaderNoChildren(fqn)) {
log.debug("no children " + n);
remove(fqn);
}
}
}
}
return retval;
}
private void remove(Fqn fqn) throws Exception {
loader.remove(fqn);
cache.notifyNodeActivate(fqn, false);
if (cache.getUseInterceptorMbeans()&& statsEnabled)
m_activations++;
}
problem arises when loader.remove(fqn) fails (can be a file lock there, e.g.), then if I
have a Cache listener to receive nodeActivate event, and in there, I will have to retrieve
the node value, e.g.,
cache.get(fqn, key)
to process some logic, then get(fqn, key) will come back to ActivationInterceptor and
attempt another .remove() and therefore the recursion.
A proposed fix is we should throw exception when removing the node fails in CacheLoader
(I am using FileCacheLoader), e.g., DataNotRemovedException. That way,
ActivationInterceptor can catch it here and skip event notification (since it won't be
valid anyway).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
1:34 p.m.
New subject: [JBoss JIRA] Reopened: (JBCACHE-710) FileCacheLoader passivation/activation produces recursive exception when loader.remove fails
[ http://jira.jboss.com/jira/browse/JBCACHE-710?page=all ]
Manik Surtani reopened JBCACHE-710:
-----------------------------------
Assignee: (was: Manik Surtani)
FileCacheLoader passivation/activation produces recursive exception
when loader.remove fails
--------------------------------------------------------------------------------------------
Key: JBCACHE-710
URL: http://jira.jboss.com/jira/browse/JBCACHE-710
Project: JBoss Cache
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Cache loaders
Affects Versions: 1.4.0.GA
Reporter: Ben Wang
Priority: Minor
Fix For: 2.0.0.GA
I have encountered this problem during ejb3 sfsb port of JBC1.4. This is what happened:
In ActivationInterceptor.java, we have:
if (n != null && !n.containsKey(TreeCache.UNINITIALIZED)) {
if (n.hasChildren()) {
if (allInitialized(n)) {
log.debug("children all initialized");
remove(fqn);
}
} else if (loaderNoChildren(fqn)) {
log.debug("no children " + n);
remove(fqn);
}
}
}
}
return retval;
}
private void remove(Fqn fqn) throws Exception {
loader.remove(fqn);
cache.notifyNodeActivate(fqn, false);
if (cache.getUseInterceptorMbeans()&& statsEnabled)
m_activations++;
}
problem arises when loader.remove(fqn) fails (can be a file lock there, e.g.), then if I
have a Cache listener to receive nodeActivate event, and in there, I will have to retrieve
the node value, e.g.,
cache.get(fqn, key)
to process some logic, then get(fqn, key) will come back to ActivationInterceptor and
attempt another .remove() and therefore the recursion.
A proposed fix is we should throw exception when removing the node fails in CacheLoader
(I am using FileCacheLoader), e.g., DataNotRemovedException. That way,
ActivationInterceptor can catch it here and skip event notification (since it won't be
valid anyway).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
1:46 p.m.
New subject: [JBoss JIRA] Closed: (JBCACHE-710) FileCacheLoader passivation/activation produces recursive exception when loader.remove fails
[ http://jira.jboss.com/jira/browse/JBCACHE-710?page=all ]
Manik Surtani closed JBCACHE-710.
---------------------------------
Fix Version/s: (was: 2.0.0.GA)
Resolution: Rejected
FileCacheLoader passivation/activation produces recursive exception
when loader.remove fails
--------------------------------------------------------------------------------------------
Key: JBCACHE-710
URL: http://jira.jboss.com/jira/browse/JBCACHE-710
Project: JBoss Cache
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Cache loaders
Affects Versions: 1.4.0.GA
Reporter: Ben Wang
Priority: Minor
I have encountered this problem during ejb3 sfsb port of JBC1.4. This is what happened:
In ActivationInterceptor.java, we have:
if (n != null && !n.containsKey(TreeCache.UNINITIALIZED)) {
if (n.hasChildren()) {
if (allInitialized(n)) {
log.debug("children all initialized");
remove(fqn);
}
} else if (loaderNoChildren(fqn)) {
log.debug("no children " + n);
remove(fqn);
}
}
}
}
return retval;
}
private void remove(Fqn fqn) throws Exception {
loader.remove(fqn);
cache.notifyNodeActivate(fqn, false);
if (cache.getUseInterceptorMbeans()&& statsEnabled)
m_activations++;
}
problem arises when loader.remove(fqn) fails (can be a file lock there, e.g.), then if I
have a Cache listener to receive nodeActivate event, and in there, I will have to retrieve
the node value, e.g.,
cache.get(fqn, key)
to process some logic, then get(fqn, key) will come back to ActivationInterceptor and
attempt another .remove() and therefore the recursion.
A proposed fix is we should throw exception when removing the node fails in CacheLoader
(I am using FileCacheLoader), e.g., DataNotRemovedException. That way,
ActivationInterceptor can catch it here and skip event notification (since it won't be
valid anyway).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
6136
days inactive
6509
days old
10 comments
4 participants
participants (4)
-
Ben Wang (JIRA) -
Galder Zamarreno (JIRA)
-
Manik Surtani (JIRA) -
Manik Surtani (JIRA)