Terracotta Discussion Forums (LEGACY READ-ONLY ARCHIVE)

Hi,

Due to a complicated integration with some closed-source software, there is an object in my session which I don't want to cluster because it hangs off a custom classloader.

Is it possible to specify that only certain objects shall be clusterable? If I don't instrument the class in question, I get:

Code:

com.tc.exception.TCNonPortableObjectError: 
 *******************************************************************************
 Attempt to share an instance of a non-portable class by passing it as an argument to a method of a
 logically-managed class. This unshareable class has not been included for sharing in the
 configuration. Please add this class to the <includes> section of the configuration file.

...and if I instrument it, I get:

Code:

java.lang.RuntimeException: No loader description for [MyClassLoader]@3b19e82c

Thanks for any help...

kikibobo,

Yes definitely - you should try setting it as transient - there's a discussion on this thread that should give you some details on how to set that object as transient:

http://forums.terracotta.org/forums/posts/list/193.page

Let me know if that helps.

I'm not sure this is what I need.

This seems to describe how to mimic a transient keyword in a class declaration.

I think what I want is something equivalent to not making my session object implement Serializable. When this library puts its object into the session, I'd like Terracotta to just ignore the object entirely.

Is that possible?

Thanks,
Eric

That's what transient does - when you make it transient the object does not become a part of the shared graph.

Try it.

Thanks!

How do I do that? Apologies if I'm misreading it, but I just don't see how to accomplish that -- I'd try it if I could tell what to try!

You're right, sorry, the discussion I referenced doesn't show how to set arbitrary fields as transient. That is done with the transient fields option described in the config reference here: Config Reference

I think you're not understanding me. I know how to make fields transient; that's not what I'm trying to do.

Code under which I have no control is putting objects in the session which I want Terracotta to ignore. Not fields in those objects, the objects themselves. I don't want them to replicate. As I noted above, if I don't DSO-enable those objects, I get one kind of exception, and if I do DSO-enable them, I get a different exception. I'm looking for a third alternative: no exception, just ignores the object.

This is more analogous to putting objects into a session which are not Serializable, as opposed to putting objects into a session which include transient fields.

Thanks,
Eric

I see what you are saying. What would you expect to happen on the replicated side of things? A null reference for the attribute? Just ignore the put entirely so the Session never has the attribute?

I don't quite follow how the application will work correctly without these objects being replicated (presumably the code you are using is putting these objects into the Session for a reason?)

I want the object to be in the session only for the JVM that put it there. Each JVM will create the object as it needs it ... in this case, I happen to know this is safe.

This is very similar to what happens in something like WebLogic if you put an object in the session which doesn't implement Serializable -- the object is there in that JVM only.

Thanks,
Eric

I see. There is no direct product support for this kind of behavior. I just talked with one of our engineers there are a few approaches you could take.

We do have an internal API that puts attributes as transient attributes, which means they are local to the JVM itself. We could only think of two ways to interface to this API.

One would be to hack on the code directly to intercept the attribute name and put it as a transient attribute rather than a replicated attribute, the other would be for you to wrap the SessionManager yourself and install it using a Filter or some other mechanism. This wrapped SessionManager could intercept the attributes and get/set them from a different location or compile against the tc.jar directly and shunt the get/setattribute to the transient session.

Ok, I can do that ... was hoping TC could do it for me. :)

Thanks for your help,
Eric

Eric,

I have created a JIRA to track this feature.

http://jira.terracotta.org/jira/browse/CDV-226

Thanks for that ... I got it working using HttpServletRequestWrapper and implementing an InvocationHandler around HttpSession, but it's pretty ugly. I don't suppose many people need this; if I'm wrong, then it would be much nicer if TC could do it for me.

On the other hand, I'd MUCH rather have TC support relatively arbitrary classloaders! Is that in the roadmap, or is it just too hard? If nothing else, it would be nice if it could just replicate through serialization or something in that case, which is what I may end up needing to implement myself anyhow if I run into something that actually does need to replicate, but is hanging off this wacky classloader I have to live with.

cheers,
Eric

For anybody actually following along, it wasn't too hard to put my own serialization layer between the application and Terracotta. For objects hanging off custom classloaders, it was easy enough for me to serialize them myself and stick byte[] blobs into the real session, while keeping a per-JVM map of the real object around. Not ideal but it got us all the way there, and for small sessions that don't change much, it shouldn't be a big deal.

Eric,

Good to hear you got it working without too much effort. I'll also point out that we are more than willing to implement this feature, as long as there's enough interest to justify it.

So an additional note for anyone following along, please make your voice heard so we know how to prioritize. Thanks!