[Logo] Terracotta Discussion Forums (LEGACY READ-ONLY ARCHIVE)
  [Search] Search   [Recent Topics] Recent Topics   [Members]  Member Listing   [Groups] Back to home page 
[Register] Register / 
[Login] Login 
[Expert]
Messages posted by: amiller  XML
Profile for amiller -> Messages posted by amiller [657] Go to Page: 1, 2, 3  ...  42, 43, 44 Next 
Author Message
There have been a lot of fixes since 1.5 so I would first recommend trying with the latest Ehcache version (1.7.1 at the moment) to see if it's reproducible. APIs should be backwards-compatible so this should just be a jar change.

If you're still seeing the behavior, file a jira at http://jira.terracotta.org with the version info ehcache.xml, and relevant code if possible.
CDM is basically the same as CSM but it does not require string keys. It also has more options than the old CSM and has been through much more performance testing.
Well, it doesn't look like you're using replication or disk storage so your objects are never serialized by Ehcache. Ehcache doesn't actually know anything about your objects so it seems highly unlikely that the changes occur from Ehcache. It seems much more likely that your objects are referenced and modified by some other thread after they are put in the cache. The objects are not serialized or copied, so the actual instances you put in the cache can be modified by others holding references to it.

You could track this down in a debugger with a watchpoint or just modify your code in a setter to dump the stack trace when the object is modified with something like this:

Code:
try { throw new Exception(); } catch(Exception e) { e.printStackTrace(); }


I don't know anything about DataNucleus but it looks like an ORM so it is presumably doing the same kinds of object modification that you'd see in Hibernate too. Maybe you should post this question to them somehow?
Can you attach your ehcache.xml config file?

Are you using transient fields or other Serialization techniques?

Are you sure you're not modifying the object's fields in some other threads after it's been put in the cache?
Yep, that's a good summary.
What version of Ehcache are you using? Can you attach your ehcache.xml config (or the disk config at least)?
Yes, the canonical ehcache.xml reference (http://ehcache.org/ehcache.xml) describes this:

System property tokens can be specified in this file which are replaced when the configuration is loaded. For example multicastGroupPort=${multicastGroupPort} can be replaced with the System property either from an environment variable or a system property specified with a command line switch such as -DmulticastGroupPort=4446. 


Some examples of clustered things people use for cross-thread communication with Terracotta:

- CyclicBarrier
- CountdownLatch
- wait/notify or Condition
- LinkedBlockingQueue

Is that what you're looking for?
The Terracotta server just does the lock bookkeeping. It will never lock a lock itself, only in response to a client performing a lock operation.

One thing you might want to try is to connect to the Terracotta server with an MBean console (like jconsole that comes with the JDK) and dump the entire lock state. In jconsole, go to the org.terracotta.internal/Terracotta Server/L2Dumper MBean. Open the Operations tab and perform the doServerDump() operation. Then look at your Terracotta server log which should contain (among other things) a dump of all lock state. That would tell you which client and threadID were holding the lock, although it still might be challenging to figure out where to go from there.

These instances all seem to be related to your Terracotta-clustered Compass implementation. I'll try to find someone that knows more about that specifically.

Also, can you list your Terracotta version, app server version, any compass version info, and if possible attach your tc-config.xml?
Well, you know it's a ReentrantLock and it has to be clustered as well. Can you narrow down from your instrumentation all the possible clustered ReentrantLock instances?

Another way to figure this out would be to use the Lock Profiler in the console with a stack depth > 0. The lock profiler has a significant overhead so it's typically best to turn it on, then off for a relatively short time period. If you are collecting stack traces, you should be able to examine the path to all acquired locks and you might be able to figure out some options.

If you have some hunches, you could walk down through the objects in the object browser till you find it too. Unfortunately the lookup function can't go backwards up the object chain (I've wanted this too in the past but it would be prohibitively expensive to implement).
The instrumentation for LBQ is particularly complicated (a combination of physical field clustering and distributed logical operation). I suspect that you'll likely run into some issues with subclassing it. Have you considered using a decorator instead?
What you're seeing there is an object ID. If you go to the object browser, there is a pane in the bottom to look up an object by ID - you should be able to enter 4285 there and figure it out.
Maybe you could create an instrumentation config based on an annotation and then add the annotation when the stuff is dynamically generated? People use this technique now to specify instrumentation for dynamic loading scenarios.

If you want to see what Terracotta is doing with instrumentation of field operations, check out Transparency{Code,Class}Adapter.java in dso-l1-api.
When you're using Hibernate with a cache provider, the cache is not involved in the database or the driver at all - that's all in the Hibernate config. So, I don't think the issue here is Ehcache.

I assume you've changed the connection properties in your Hibernate config file?
You should take a look at tim-messaging for this sort of thing.

http://forge.terracotta.org/releases/projects/tim-messaging/
 
Profile for amiller -> Messages posted by amiller [657] Go to Page: 1, 2, 3  ...  42, 43, 44 Next 
Go to:   
Powered by JForum 2.1.7 © JForum Team