• Bug
  • Status: Closed
  • 2 Major
  • Resolution: Fixed
  • DSO:L1
  • hhuynh
  • Reporter: amiller
  • April 15, 2008
  • 0
  • Watchers: 1
  • August 04, 2008
  • July 24, 2008

Description

From looking at some customer logs on the forum (http://forums.terracotta.org/forums/posts/list/910.page), there are some warnings like this: tc_client_01.log:2008-04-13 16:55:04,251 [CacheInvalidator -
org.hibernate.cache.UpdateTimestampsCache invalidation thread0] WARN
com.tc.object.logging.RuntimeLoggerImpl - could not find proper stack
frame:
«com.tc.object.logging.RuntimeLoggerImpl.getTrimmedStack(RuntimeLoggerImpl.java:215)», «com.tc.object.logging.RuntimeLoggerImpl.appendCall(RuntimeLoggerImpl.java:113)»,
«com.tc.object.logging.RuntimeLoggerImpl.namedLockAcquired(RuntimeLoggerImpl.java:93)»,
«com.tc.object.logging.RuntimeLoggerImpl.lockAcquired(RuntimeLoggerImpl.java:86)», «com.tc.object.bytecode.ManagerImpl.begin(ManagerImpl.java:323)»,
«com.tc.object.bytecode.ManagerImpl.beginLock(ManagerImpl.java:298)», «com.tcclient.cache.Lock.writeLock(Lock.java:53)»,
«com.tcclient.cache.CacheEntryInvalidator.run(CacheEntryInvalidator.java:87)», «com.tcclient.cache.CacheInvalidationTimer$EvictionRunner.run(CacheInvalidationTimer.java:53)»,
«java.lang.Thread.run(Thread.java:619)»

The code in RuntimeLoggerImpl.getTrimmedStack() is attempting to prune
all of the stack below the call from
“com.tc.object.bytecode.ManagerUtil”. In the stack above
com.tcclient.cache.Lock.writeLock() is calling ManagerImpl directly instead of
going through ManagerUtil. I suspect that’s due to some refactoring I
did to make this more testable a while back (switching the call to the
static method in ManagerUtil to a call to an injected Manager instance).

We need to either stop trimming the stack at all, or be more flexible with when we filter, or change the ehcache code back to go through ManagerUtil.

Comments

Alex Miller 2008-07-15

Should be more flexible with what we filter here.

Tim Eck 2008-07-15

I’d actually vote for removing the “trimmed” stack thing completely. Makes this easy to solve :-)

Abhishek Singh 2008-07-22

Fixed in trunk rev-9424.

Abhishek Singh 2008-07-24

Need to deprecate use of in Below is mail transcript:

Alex Miller wrote:

I would deprecate it, add the warning, and file a jira for removal (including gui support in Eclipse if it’s there).

On Jul 23, 2008, at 7:02 PM, Tim Eck wrote:

I think this change needs a little more work. It’s my fault for not being very clear in the comment on the bug, but this change isn’t quite complete in my opinion.

We either need to remove the “caller” option from the (or preferably deprecate it, something we've never done though). If someone uses "caller" right now, they are going to get a log statement that describes the method in RuntimeLoggerImpl (not very useful).

It feels preferable to deprecate this option (and probably generate a warning about it if enabled) since removing it would be an incompatible change to tc-config.

Any thoughts? Does this message even make sense? :-)

Abhishek Singh 2008-07-24

Made element in deprecated.

trunk rev-9472