• Bug
  • Status: Closed
  • 2 Major
  • Resolution: Fixed
  • hhuynh
  • Reporter:
  • October 11, 2007
  • 0
  • Watchers: 2
  • October 29, 2007
  • October 23, 2007



Refer to forum post


This is a problem with Spring enabled configuration. Find attached the code to reproduce it.

It is a bug with RenetrantReadWriteLock instrumentation. dsoLock is defined as transient inside ReentrantReadWriteLockTC.WriteLock and ReentrantReadWriteLockTC.ReadLock, but while instrumenting honorTransient is not set true. So in DSO configuration, dsoLock object is still shared by terracotta.

Somehow with Spring configuration, transient is honored and dsoLock object is not shared with terracotta and while dehyderating the ReentrantReadWriteLock inside another JVM, it fails with nullpointer exception as dsoLock is null.

ideally dsoLock object should not be transient. I tested by removing transient keyword for dsoLock and it works fine. Attached is the modified ReentrantReadWriteLockTC code that makes it work


Steve Harris 2007-10-13

I think I might remember spring having a default of honor transient true while the rest of dso had it false. I wonder if that is the cause of this issue?

njain 2007-10-15

Yeah, that should be the issue. But defining dsoLock as transient is not required in first place.

Eugene Kuleshov 2007-10-15

There is a class hierarchy walker that is responsible for automatically adding includes for classes referenced by the clustered Spring beans and it sets honor transient flag on those classes using DSOClientConfigHelper.addIncludeAndLockIfRequired(..) call

Though walker should be ignoring any classes that are included using or registered y any other means, which doesn't seem happening in your test project. My guess is that DSOClientConfigHelper.addIncludeAndLockIfRequired(..) is not respecting includes created trough getOrCreateSpec(..) call.

Eugene Kuleshov 2007-10-15

BTW, Nitin, you mentioned that issue is fixed in the nightly build. What was actually changed?

njain 2007-10-16

Eugene, some miscommunication here. In my opionion problem is yet to be fixed

Eugene Kuleshov 2007-10-16

I am just asking if any fix been actually pushed to the nightly build. Isn’t that your comment? http://forums.terracotta.org/forums/posts/list/521.page#2873

PS: please set “viewable by” field when replying if you don’t want comment to be visible to everyone.

njain 2007-10-17

I intended to say that it will be fixed soon and made available in nightly build. Nothing is fixed yet. May be I should not have made this statement without confirmation from Engineering.

Antonio Si 2007-10-23

dsoLock is transient so that a serialized TC version of ReentrantReadWriteLock could be de-serialized into a non-TC environment.

This issue is fixed by not adding to the include pattern if the class already has a spec for it in the StandardDsoClientConfig.