[
http://jira.jboss.com/jira/browse/JBCACHE-767?page=all ]
Manik Surtani updated JBCACHE-767:
----------------------------------
Workaround Description: This should be nothing more than an unnecessary and scary
stack trace in your log file. It should not affect operation of the cache, and can safely
be ignored.
Workaround: [Workaround Exists]
Fail more silently when setting node versions
---------------------------------------------
Key: JBCACHE-767
URL:
http://jira.jboss.com/jira/browse/JBCACHE-767
Project: JBoss Cache
Issue Type: Bug
Security Level: Public(Everyone can see)
Affects Versions: 1.4.0.SP1
Reporter: Owen Taylor
Assigned To: Manik Surtani
Priority: Minor
Fix For: 2.0.0, 1.4.0.SP2
Attachments: jbosscache-fail-more-silently-20060912.patch
Hibernate's OptimisticTreeCache.writeUpdate does:
Option option = new Option();
option.setFailSilently( true );
option.setDataVersion( NonLockingDataVersion.INSTANCE );
cache.remove( new Fqn( regionFqn, key ), "ITEM", option
);
Which you would expect would remove the item if it exists, while setting the data
version,
and silently do nothing otherwise. But it ends up, logging at level INFO:
12:55:38,360 INFO [org.jboss.cache.interceptors.TxInterceptor] (http-127.0.0.1-8080-1):
There was a problem handling this request
java.lang.NullPointerException
at
org.jboss.cache.interceptors.OptimisticNodeInterceptor.invoke(OptimisticNodeInterceptor.java:68)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at
org.jboss.cache.interceptors.EvictionInterceptor.invoke(EvictionInterceptor.java:84)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at
org.jboss.cache.interceptors.OptimisticCreateIfNotExistsInterceptor.invoke(OptimisticCreateIfNotExistsInterceptor.java:69)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at
org.jboss.cache.interceptors.OptimisticValidatorInterceptor.invoke(OptimisticValidatorInterceptor.java:75)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at
org.jboss.cache.interceptors.OptimisticLockingInterceptor.invoke(OptimisticLockingInterceptor.java:122)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at
org.jboss.cache.interceptors.OptimisticReplicationInterceptor.invoke(OptimisticReplicationInterceptor.java:136)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at
org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:345)
at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:156)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at
org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:183)
at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5530)
at org.jboss.cache.TreeCache.remove(TreeCache.java:3742)
at org.jboss.cache.TreeCache.remove(TreeCache.java:3297)
at
org.hibernate.cache.OptimisticTreeCache.writeLoad(OptimisticTreeCache.java:76)
There are some differences of opinion as to what should be logged at level INFO, but
that's pretty clearly
too much and too scary looking. My assumption is that any NullPointerException in the
logs is a serious
problem.
What the attached patch does is if the failSiliently option is set and the node
doesn't exist, just skip
setting the version. If failSilenlty isn't set, then it throws a CacheException
rather than the current
NullPointerException.
--
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