[Mondrian] Re:VirtualCubeTest.testCalculatedMemberAcrossCubesfailing on SMP

Pappyn Bart Bart.Pappyn at vandewiele.com
Fri Jan 26 02:44:02 EST 2007

Change 8582 introduces ThreadLocal, I do not use thread-id any more, so I guess your changes are redundant.  
However, the change does more than the previous one.
Like already told in the mailing list last week, I was busy with also implementing the data change listener plugin to support flushing
of aggregate cache.  That part is finished (however, I noticed I need to put a few things public to let my plugin access to necessary
data, something I will likely check in today) en is in change 8582.
RolapStarAggregationKey is not obsolete any more, since in my latest implementation, I must besides the BitKey also remember
the timeStamp the aggregation was registered the first time in the star.  
This is because I have implemented the following :
* When a query starts, changes are checked (using the plugin).  When changes are detected, a thread local aggregation is made,
the thread will fill this one up.  It will not change the global cache any more, because an other thread my depend on that data.
* After the query finishes, it will first cleanup aggregates belonging to a star that does not maintain any cache.
* Afterwards, it will try to push thread local cache to global cache in case the global aggregate is not used by any thread.  If this
is not the cache, it will be moved to pending cache (that is not thread local).
* After each query, pending cache is checked again to see if it can be checked in global cache.
The RolapStarAggregationKey is needed, because the timeStamp is used to only check in the latest version of the cache into
global cache.
This is the first step into an attempt to make mondrian A) work better in multi-user environments B) live along a dynamic database.
The only thing that needs to be done is the introduction of transactions and better control of how jdbc connections are used.
The biggest problem up to now, is the fact that hierarchy cache is not in sync with a mdx query.  So a mdx query might depend on
different data.  In my project, I don't see any errors, this is of course largely due to the fact how the database is structured and filled.
I have ran junit tests at least 10 times on different machines.  I also ran in JIT 'server mode' on a SMP machine, because the behavior is different.
All works up to now.
Kind regards,


From: mondrian-bounces at pentaho.org [mailto:mondrian-bounces at pentaho.org] On Behalf Of Julian Hyde
Sent: donderdag 25 januari 2007 22:00
To: mondrian at pentaho.org
Subject: RE: [Mondrian] Re:VirtualCubeTest.testCalculatedMemberAcrossCubesfailing on SMP

Your change 8582 clashes with the stuff I referred to in the last paragraph of this message. The only reason I didn't check it in was because it wasn't sufficient -- on its own -- to fix the test failure, and now I either have to merge or discard my changes.
My change was to obsolete RolapStarAggregationKey and revert to BitKey to identify aggregations. Any aggregations which belong to a particular thread are in a collection specific to that thread. I am convinced that using thread-id is unsound - in particular, things will tend to stay in the cache after their thread has died, a problem which ThreadLocal neatly avoids.
I'd like either you to make that change -- or stop making changes in that area and let me the go-ahead to make that change. Which do you prefer?


	From: Julian Hyde [mailto:julianhyde at speakeasy.net] 
	Sent: Tuesday, January 23, 2007 2:57 AM
	To: 'Mondrian developer mailing list'
	Subject: RE: [Mondrian] Re: VirtualCubeTest.testCalculatedMemberAcrossCubesfailing on SMP
	I think the problem is with how mondrian evaluates members using multiple passes. When the measures are coming from a virtual cube, of course there are multiple real cubes, and each of those has a cell reader. But the code in RolapResult assumes there is only one cell reader.
	Mondrian should check the cell readers for all applicable cubes, and only emit a result when all cell readers have been populated.
	I haven't implemented the fix yet, but this cause seems very plausible to me.
	I'm not exactly sure why this problem surfaced after Bart's change - maybe thread-local caches increased the chances of one cache being populated and another not - or why it appears on SMP machines.
	By the way, in an effort to get this working, I removed Bart's RolapStarAggregationKey (a compound key of BitKey and thread id) and moved to a two-tier hashing scheme. The first tier is a ThreadLocal of maps, and the second tier is a map. Threads which want access to the global map just skip the first tier. Given the difficulties obtaining a unique id for a thread, using a ThreadLocal seemed cleaner. So, even though this didn't fix the bug, I'm going to check in.


		From: mondrian-bounces at pentaho.org [mailto:mondrian-bounces at pentaho.org] On Behalf Of michael bienstein
		Sent: Monday, January 22, 2007 12:06 PM
		To: Mondrian developer mailing list
		Subject: Re : [Mondrian] Re: VirtualCubeTest.testCalculatedMemberAcrossCubesfailing on SMP
		I've seen issues with server mode JIT before related to memory boundaries and multiple threads.  But that's mutiple threads and it was in JDK 1.4 (the memory model changed in 1.5 I think).  The issue is that the instructions in the Java code can be run out of order to the way you've coded them.  E.g. a=1; b=2; a=b; can be run just a=2; b=2; because that's what it is equivalent to.  The only way to force it to do what you really expected is to synchronize your accesses because that prevents the instruction re-ordering across the memory boundary.  This was an issue in Apache Struts at one point because they used a custom Map implementation called "FastHashMap" which gets filled with values and then flipped to be in immutable mode.  The problem was that the get() method tested if it was flipped already without synchronizing which looked safe because the flip flag was set only after the insertion code.  But the JIT reversed the order and the flip was done before the last insertions leading to certain problems on high-end servers.
		All that's a moot point if we can't see how multiple threads are being used.
		----- Message d'origine ----
		De : John V. Sichi <jsichi at gmail.com>
		À : Pappyn Bart <Bart.Pappyn at vandewiele.com>
		Cc : Mondrian developer mailing list <mondrian at pentaho.org>
		Envoyé le : Lundi, 22 Janvier 2007, 20h10mn 24s
		Objet : [Mondrian] Re: VirtualCubeTest.testCalculatedMemberAcrossCubes failing on SMP
		Something interesting:  I noticed that HotSpot was automatically 
		selecting Server mode on the SMP machine (whereas on my laptop it 
		autoselects Client mode).  I changed build.xml to force usage of Client 
		mode, and then "ant test" ran through with no failures.
		Haven't tried forcing Server mode on laptop yet; if it's timing-related, 
		it may just be that it takes the combination of a very fast machine plus 
		Server mode to hit it.
		Also, Bart, if you want to send me code modifications to enable tracing 
		targeted at debugging the problem, please do, and I'll run it through on 
		the SMP machine and send you the output.
		John V. Sichi wrote:
		> Pappyn Bart wrote:
		>> John,
		>> Could you tell me what kind of OS is running on your
		>> 4-way SMP machine ?  And on you laptop ?
		> SMP:  Red Hat Enterprise Linux (not sure of version); JVM is HotSpot 
		> 1.5.0_10-b03
		> Laptop:  Edgy Eft version of Ubuntu Linux; JVM is HotSpot 1.5.0_04-b05
		> My guess is that it's likely to be a timing-sensitive thing.  The 
		> property trigger stuff looked suspicious, but I tried disabling that out 
		> and it still happens.  I also tried disabling 
		> testFormatStringExpressionCubeNoCache (since it runs just before and has 
		> cache disabled on a base cube underlying a virtual cube) but the failure 
		> still occurred.
		> JVS
		Mondrian mailing list
		Mondrian at pentaho.org


		Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses <http://fr.rd.yahoo.com/evt=42054/*http://fr.answers.yahoo.com> .

This email has been scanned by the Email Security System.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.pentaho.org/pipermail/mondrian/attachments/20070126/cc5975ee/attachment.html 

More information about the Mondrian mailing list