[
https://jira.terracotta.org/jira//browse/CDV-731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abhishek Singh resolved CDV-731.
--------------------------------
Fixed In Revision: 9472 (was: 9424)
Resolution: Fixed
Made <caller> element in <runtime-output-options> deprecated.
trunk rev-9472
> RuntimeLoggerImpl is too strict in trimming the stack trace on lock acquires
> producing spurious warnings
> --------------------------------------------------------------------------------------------------------
>
> Key: CDV-731
> URL: https://jira.terracotta.org/jira//browse/CDV-731
> Project: Community Development
> Issue Type: Bug
> Components: DSO:L1
> Affects Versions: 2.6-stable0
> Reporter: Alex Miller
> Assignee: Issue Review Board
> Fix For: trunk-nightly
>
>
> 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.terracotta.org/jira//secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
tc-dev mailing list
[email protected]
http://lists.terracotta.org/mailman/listinfo/tc-dev
