[
http://jira.jboss.com/jira/browse/JBCACHE-951?page=comments#action_12351658 ]
Brian Stansberry commented on JBCACHE-951:
------------------------------------------
This is a greater issue with 1.4.1.GA, since in that release a node insert/removal
acquires a WL on the parent. Thus short term locking conflicts are more likely.
IdentityLock logs at too high a level
-------------------------------------
Key: JBCACHE-951
URL:
http://jira.jboss.com/jira/browse/JBCACHE-951
Project: JBoss Cache
Issue Type: Bug
Security Level: Public(Everyone can see)
Affects Versions: 1.4.1.GA, 2.0.0.ALPHA2
Reporter: Brian Stansberry
Assigned To: Brian Stansberry
Fix For: 2.0.0.GA, 1.4.1.SP1
There are several examples of this kind of thing in IdentityLock:
boolean rc = lock_.writeLock().attempt(timeout);
// we don't need to synchronize from here on because we own the semaphore
if (rc == false) {
String errStr = "write lock for " + getFqn() + " could not be
acquired after " + timeout + " ms. " +
"Locks: " + map_.printInfo() + " (caller=" + caller
+ ", lock info: " + toString(true) + ')';
log.error(errStr);
throw new TimeoutException(errStr);
}
The logging should be at TRACE level. The contents of the log message are entirely
included in the exception, and are thus available to whatever code handles the exception.
They can be logged at that time. Logging at ERROR removes the flexibility for callers to
ignore some timeouts w/o disturbing the user via an ERROR logging.
This is particularly an issue for putForExternalRead() and evict(), where the goal is to
use a 0 ms timeout.
--
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