• New Feature
  • Status: Open
  • 2 Major
  • Resolution:
  • DSO:L1
  • prodmgmt
  • Reporter: wharley
  • May 11, 2009
  • 0
  • Watchers: 1
  • March 19, 2010

Description

The error message for a NonPortableObjectError is quite helpful but not entirely smart. For example, from http://forums.terracotta.org/forums/posts/list/2124.page#12709:

com.tc.exception.TCNonPortableObjectError: ******************************************************************************* Attempt to share an instance of a non-portable class referenced by a portable class. This unshareable class has a super-class that is uninstrumented. Subclasses of uninstrumented classes cannot be shared.

For more information on this issue, please visit our Troubleshooting Guide at: http://terracotta.org/kit/troubleshooting

Referring class : java.util.HashMap Thread : http-8090-Processor25 JVM ID : VM(0) Unshareable class : org.hibernate.tuple.entity.PojoEntityTuplizer Classes to add to the configuration: org.hibernate.tuple.entity.AbstractEntityTuplizer

Under most circumstances, you should only be adding classes for your application. If you are adding classes for frameworks or code not written by you, then you should consider finding a Terracotta Integration Module (TIM) that matches the framework you are using.

As an example, if the non-portable class listed below is net.sf.ehcache.CacheManager, you should consider using the ehcache TIM.

It is possible that some or all of the super classes above are truly non-portable, the solution is then to mark the referring field(s) as transient.

Action to take:

1) Reconfigure to include the unshareable super-class(es) * edit your tc-config.xml file * locate the element \* add this snippet inside the element

   <instrumented-classes>
     <include>
       <class-expression>org.hibernate.tuple.entity.AbstractEntityTuplizer</class-expression>
     </include>
   </instrumented-classes>

* if there is already an element present, simply add the new includes inside it

*******************************************************************************

Notice that in this error, the user is asked to instrument “org.hibernate.tuple.entity.AbstractEntityTuplizer”. We provide the generic advice to only instrument user classes, but the specific advice here is to instrument an org.hibernate class.

It seems that we could have a list of “well-known problem classes”, culled from forum issues and Jiras, that could have more specific advice. For example, a user should essentially NEVER instrument an org.hibernate class, except by adding tim-hibernate; and this class in particular, org.hibernate.tuple.entity.AbstractEntityTuplizer, is explicitly excluded in the tim-hibernate-commons TIM.

One can imagine arbitrarily fancy schemes where TIMs, the tim-get index, and TC core code collaborate to come up with a list of specific advices. As a start, I would suggest we should never tell someone to instrument a class that is already excluded. Instead, the advice needs to involve further troubleshooting.

Comments

Taylor Gautier 2009-05-11

I agree, but the message does say:

Under most circumstances, you should only be adding classes for your application. If you are adding classes for frameworks or code not written by you, then you should consider finding a Terracotta Integration Module (TIM) that matches the framework you are using.

As an example, if the non-portable class listed below is net.sf.ehcache.CacheManager, you should consider using the ehcache TIM. ——————————————————–

Which applies in this situation. Furthermore, while I like your suggestion, it seems like a bit of a catch-22. If you don’t have xyz TIM installed that knows how to work with classes xyz, then how does the system then know that xyz is the TIM that works with xyz classes?

I can think of some elaborate schemes of exporting that knowledge, and forcing the core to load that exported data, but it certainly seems cumbersome. And of course it will by definition always be out of date - where the out of dateness is the publishing frequency (and update freshness) of said knowledge “repository”?

I don’t know - I am not against making this better - I definitely would like to - but it seems to be a rather difficult problem to solve.

Walter Harley 2009-05-11

The specific suggestion of not recommending to include classes which are already excluded in an (included) TIM is simple and straightforward to implement. (I should have been more clear that in the particular case that led to my example, tim-hibernate was already included.) Should I create a separate Jira for that? It’s almost a bug rather than a feature request.

I agree that doing better than that, for instance being able to recommend a particular TIM, is harder and would need some design effort as well as some compromise; we won’t solve it all in any one way. An example of an idea that could help would be if the tim-get tool were enhanced to be able to take the name of an offending class and make some suggestions (based on information that could be added to the tim index); the message would then also have to change, to tell people how to feed the info into tim-get.