[
https://jira.terracotta.org/jira//browse/CDV-731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abhishek Singh reopened CDV-731:
--------------------------------
Assignee: Issue Review Board (was: Abhishek Singh)
Need to deprecate use of <caller> in <runtime-output-options>
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
>> <runtime-output-options> (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? :-)
>>
>>
>> <mime-attachment.eml>
>
> 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
