I have posted olap4j-1.2.0 to maven central[1].
I kept the jar identical to the existing 1.2.0 release; to satisfy
sonatype I needed to add extra information to the pom, and I created
dummy (basically empty) sources and javadoc jars.
Please let me know whether it works.
Tom, Can you start the ball rolling for an olap4j 1.3.0? (After that I
would also like to release olap4j-2.0.0-alpha and
olap4j-server-1.3.0.)
Julian
[1] http://search.maven.org/#artifactdetails%7Corg.olap4j%7Colap4j%7C1.2.0%7Cjar

Hello all! It's been a while.
I noticed a couple of things about olap4j.
First, browsing github[1], I noticed there are a few forks of olap4j
doing interesting stuff, such as DAX support, and XMLA fixes.
Second, that olap4j (still!) isn't published to Maven Central[2]. That
makes it pretty difficult to use, given that everyone uses maven these
days and expects everything useful to be in Maven Central.
So, how about pulling together to make a release? If there is
interest, I can get permissions from Maven Central to publish
releases. And, I would like to create an Apache-style meritocracy.
People who are doing the work get the right to commit, and review each
other's commits. What we all get out of it is regular, high-quality
releases, incorporating everyone's bug fixes and added features.
What do you all think?
(Please feel free to forward this message to folks developing & using
olap4j who are not on this list.)
Julian
[1] https://github.com/olap4j/olap4j/network
[2] http://search.maven.org/

I just now included a pull request
When using XMLA, the Measures Metadata should be loaded in Deffered mode #33
Alexander Schurman
Enterprise Architecture Team
​[cid:3bf163d0-be85-46b2-9b57-d4e3e33ad39f]
Direct: +34 627.294.748
Skype: aschurman​
From: Paul Stoellberger [mailto:p.stoellberger@...]
Sent: Friday, January 16, 2015 4:38 PM
To: Alexander Schurman
Cc: olap4j-devel@...
Subject: Re: [Olap4j-devel] Olap4j - XMLA Cube Metadata Loader causes performance issue
did you commit them or sent a pull request?
On 15.01.2015, at 17:19, Alexander Schurman <aschurman@...<mailto:aschurman@...>> wrote:
Hello Team,
I did this code changes and looks like this solves the issue, please let me know if you like them
Alexander Schurman
Enterprise Architecture Team
​<image001.png>
Direct: +34 627.294.748
Skype: aschurman​
From: Alexander Schurman [mailto:aschurman@...]
Sent: Wednesday, January 07, 2015 5:11 PM
To: Luc Boudreau
Cc: olap4j-devel@...<mailto:olap4j-devel@...>
Subject: Re: [Olap4j-devel] Olap4j - XMLA Cube Metadata Loader causes performance issue
I agree with you that a combination is the best scenario. Just one additional comment
Currently if we have 20 cubes, that generates 21 XMLA request (1 for get list of cubes and 1 for each cube loading the measures), so fixing issue A, reduces 90% of the performance issue.
Alexander Schurman
Enterprise Architecture Team
​<image001.png>
Direct: +34 627.294.748
Skype: aschurman​
From: Luc Boudreau [mailto:lucboudreau@...]
Sent: Wednesday, January 07, 2015 5:03 PM
To: Alexander Schurman
Cc: olap4j-devel@...<mailto:olap4j-devel@...>
Subject: Re: [Olap4j-devel] Olap4j - XMLA Cube Metadata Loader causes performance issue
I think the solution is a mix of A and B.
A) It's a good idea to make this collection lazy, unless we know for certain that we will trigger it lower down. We'll look at the code and figure it out. But fixing this won't help much without B) because we would still ask for all cubes.
B) We should pass the cube object to the CellSet in its constructor without iterating. If it's too early in the process and the cube object is not readily available, we should issue a single metadata request for that single cube. (MDSCHEMA_CUBES w/ restrictions).
On Wed, Jan 7, 2015 at 10:24 AM, Alexander Schurman <aschurman@...<mailto:aschurman@...>> wrote:
Hello OLAP4j Team,
I was on conversation with Luc Boudreau about a performance issue I was getting for a large XMLA dependent app.
BASIC INFO:
Server is a Pentaho 5.2 XMLA provider (based on Mondrian 3.8.x)
There is only 1 schema, but with 20 cubes, and 20-30 measures each cube.
USE CASE:
Send MDX queries and parse the result values.
THE ISSUE:
Basically the Issue is that the FIRST MDX query is taking a long time because it is LOADING all the Schema info for all the Cubes. The MDX query it-self only takes 1s, but the response from “”….executeOlapQuery(mdx1);” takes like 1 minute.
HOW TO REPRODUCE:
Just take any SCHEMA use for testing on the SERVER side and copy one of the CUBES many times just with different names. The more Cubes you add the slower MDX 1 is.
THE CAUSE DETECTED:
When the XmlaOlap4jCellSet class is called to load the MDX data, it calls a method called lookupCube. The issue is that this LOOKUPCUBE is actually using internally a FOREACH cube in the Schema:
LINE 576: for (Cube cube : databaseMetaData.olap4jConnection.getOlapSchema().getCubes())
Reading a little more about what the getCubes() does I checked that most of the Dimensions info is loaded with a deferred lazy method, which is good, except Measures, with say in the code and I state it:
Line 119: File: XmlaOlap4jCube.java
// populate measures up front; a measure is needed in every query
olap4jConnection.populateList(
measures,
context,
XmlaOlap4jConnection.MetadataRequest.MDSCHEMA_MEASURES,
new XmlaOlap4jConnection.MeasureHandler(),
restrictions);
for (XmlaOlap4jMeasure measure : measures) {
measuresMap.put(measure.getUniqueName(), measure);
}
Which it is not deferred.
I Commented this PART to check if it had an impact on the RESULT time and furthermore if the MDX result is affected by not having this info and the First MDX speed was reduced to 3 seconds aprox. (XMLA is still loading all the CUBES, but not loading the Metadata of the Measures that we are not using or not requesting from the Metadata.)
POSSIBLE SOLUTIONS:
I believe we have the following options:
A. We change the MEASURES to be also part of the Lazy loader like other dimensions. But I do not know for what it is used the measureMap loaded after load
B. We do not read ALL the cubes when we are doing an MDX to only 1 cube.
C. Any other ideas are welcome
Regards, alex
Alexander Schurman
Enterprise Architecture Team
​<image001.png>
Direct: +34 627.294.748<tel:%2B34%C2%A0627.294.748>
Skype: aschurman​
------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
olap4j-devel mailing list
olap4j-devel@...<mailto:olap4j-devel@...>
https://lists.sourceforge.net/lists/listinfo/olap4j-devel
<olap4j.diff>
------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
olap4j-devel mailing list
olap4j-devel@...<mailto:olap4j-devel@...>
https://lists.sourceforge.net/lists/listinfo/olap4j-devel

did you commit them or sent a pull request?
> On 15.01.2015, at 17:19, Alexander Schurman <aschurman@...> wrote:
>
> Hello Team,
>
> I did this code changes and looks like this solves the issue, please let me know if you like them
>
>
>
> Alexander Schurman
> Enterprise Architecture Team
>
> ​<image001.png>
> Direct: +34 627.294.748
> Skype: aschurman​
>
> From: Alexander Schurman [mailto:aschurman@...]
> Sent: Wednesday, January 07, 2015 5:11 PM
> To: Luc Boudreau
> Cc: olap4j-devel@...
> Subject: Re: [Olap4j-devel] Olap4j - XMLA Cube Metadata Loader causes performance issue
>
> I agree with you that a combination is the best scenario. Just one additional comment
>
> Currently if we have 20 cubes, that generates 21 XMLA request (1 for get list of cubes and 1 for each cube loading the measures), so fixing issue A, reduces 90% of the performance issue.
>
> Alexander Schurman
> Enterprise Architecture Team
>
> ​<image001.png>
> Direct: +34 627.294.748
> Skype: aschurman​
>
> From: Luc Boudreau [mailto:lucboudreau@...]
> Sent: Wednesday, January 07, 2015 5:03 PM
> To: Alexander Schurman
> Cc: olap4j-devel@...
> Subject: Re: [Olap4j-devel] Olap4j - XMLA Cube Metadata Loader causes performance issue
>
> I think the solution is a mix of A and B.
>
> A) It's a good idea to make this collection lazy, unless we know for certain that we will trigger it lower down. We'll look at the code and figure it out. But fixing this won't help much without B) because we would still ask for all cubes.
>
> B) We should pass the cube object to the CellSet in its constructor without iterating. If it's too early in the process and the cube object is not readily available, we should issue a single metadata request for that single cube. (MDSCHEMA_CUBES w/ restrictions).
>
>
>
> On Wed, Jan 7, 2015 at 10:24 AM, Alexander Schurman <aschurman@...> wrote:
> Hello OLAP4j Team,
>
> I was on conversation with Luc Boudreau about a performance issue I was getting for a large XMLA dependent app.
>
> BASIC INFO:
> Server is a Pentaho 5.2 XMLA provider (based on Mondrian 3.8.x)
> There is only 1 schema, but with 20 cubes, and 20-30 measures each cube.
>
> USE CASE:
> Send MDX queries and parse the result values.
>
> THE ISSUE:
> Basically the Issue is that the FIRST MDX query is taking a long time because it is LOADING all the Schema info for all the Cubes. The MDX query it-self only takes 1s, but the response from “”….executeOlapQuery(mdx1);” takes like 1 minute.
>
> HOW TO REPRODUCE:
> Just take any SCHEMA use for testing on the SERVER side and copy one of the CUBES many times just with different names. The more Cubes you add the slower MDX 1 is.
>
>
> THE CAUSE DETECTED:
> When the XmlaOlap4jCellSet class is called to load the MDX data, it calls a method called lookupCube. The issue is that this LOOKUPCUBE is actually using internally a FOREACH cube in the Schema:
> LINE 576: for (Cube cube : databaseMetaData.olap4jConnection.getOlapSchema().getCubes())
>
> Reading a little more about what the getCubes() does I checked that most of the Dimensions info is loaded with a deferred lazy method, which is good, except Measures, with say in the code and I state it:
> Line 119: File: XmlaOlap4jCube.java
> // populate measures up front; a measure is needed in every query
> olap4jConnection.populateList(
> measures,
> context,
> XmlaOlap4jConnection.MetadataRequest.MDSCHEMA_MEASURES,
> new XmlaOlap4jConnection.MeasureHandler(),
> restrictions);
> for (XmlaOlap4jMeasure measure : measures) {
> measuresMap.put(measure.getUniqueName(), measure);
> }
>
> Which it is not deferred.
> I Commented this PART to check if it had an impact on the RESULT time and furthermore if the MDX result is affected by not having this info and the First MDX speed was reduced to 3 seconds aprox. (XMLA is still loading all the CUBES, but not loading the Metadata of the Measures that we are not using or not requesting from the Metadata.)
>
>
> POSSIBLE SOLUTIONS:
> I believe we have the following options:
> A. We change the MEASURES to be also part of the Lazy loader like other dimensions. But I do not know for what it is used the measureMap loaded after load
>
> B. We do not read ALL the cubes when we are doing an MDX to only 1 cube.
>
> C. Any other ideas are welcome
>
>
>
> Regards, alex
>
>
>
>
> Alexander Schurman
> Enterprise Architecture Team
>
> ​<image001.png>
> Direct: +34 627.294.748
> Skype: aschurman​
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming! The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net
> _______________________________________________
> olap4j-devel mailing list
> olap4j-devel@...
> https://lists.sourceforge.net/lists/listinfo/olap4j-devel
>
>
> <olap4j.diff>
> ------------------------------------------------------------------------------
> New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
> GigeNET is offering a free month of service with a new server in Ashburn.
> Choose from 2 high performing configs, both with 100TB of bandwidth.
> Higher redundancy.Lower latency.Increased capacity.Completely compliant.
> http://p.sf.net/sfu/gigenet
> _______________________________________________
> olap4j-devel mailing list
> olap4j-devel@...
> https://lists.sourceforge.net/lists/listinfo/olap4j-devel

Hello Team,
I did this code changes and looks like this solves the issue, please let me know if you like them
Alexander Schurman
Enterprise Architecture Team
​[cid:3bf163d0-be85-46b2-9b57-d4e3e33ad39f]
Direct: +34 627.294.748
Skype: aschurman​
From: Alexander Schurman [mailto:aschurman@...]
Sent: Wednesday, January 07, 2015 5:11 PM
To: Luc Boudreau
Cc: olap4j-devel@...
Subject: Re: [Olap4j-devel] Olap4j - XMLA Cube Metadata Loader causes performance issue
I agree with you that a combination is the best scenario. Just one additional comment
Currently if we have 20 cubes, that generates 21 XMLA request (1 for get list of cubes and 1 for each cube loading the measures), so fixing issue A, reduces 90% of the performance issue.
Alexander Schurman
Enterprise Architecture Team
​[cid:3bf163d0-be85-46b2-9b57-d4e3e33ad39f]
Direct: +34 627.294.748
Skype: aschurman​
From: Luc Boudreau [mailto:lucboudreau@...]
Sent: Wednesday, January 07, 2015 5:03 PM
To: Alexander Schurman
Cc: olap4j-devel@...<mailto:olap4j-devel@...>
Subject: Re: [Olap4j-devel] Olap4j - XMLA Cube Metadata Loader causes performance issue
I think the solution is a mix of A and B.
A) It's a good idea to make this collection lazy, unless we know for certain that we will trigger it lower down. We'll look at the code and figure it out. But fixing this won't help much without B) because we would still ask for all cubes.
B) We should pass the cube object to the CellSet in its constructor without iterating. If it's too early in the process and the cube object is not readily available, we should issue a single metadata request for that single cube. (MDSCHEMA_CUBES w/ restrictions).
On Wed, Jan 7, 2015 at 10:24 AM, Alexander Schurman <aschurman@...<mailto:aschurman@...>> wrote:
Hello OLAP4j Team,
I was on conversation with Luc Boudreau about a performance issue I was getting for a large XMLA dependent app.
BASIC INFO:
Server is a Pentaho 5.2 XMLA provider (based on Mondrian 3.8.x)
There is only 1 schema, but with 20 cubes, and 20-30 measures each cube.
USE CASE:
Send MDX queries and parse the result values.
THE ISSUE:
Basically the Issue is that the FIRST MDX query is taking a long time because it is LOADING all the Schema info for all the Cubes. The MDX query it-self only takes 1s, but the response from “”….executeOlapQuery(mdx1);” takes like 1 minute.
HOW TO REPRODUCE:
Just take any SCHEMA use for testing on the SERVER side and copy one of the CUBES many times just with different names. The more Cubes you add the slower MDX 1 is.
THE CAUSE DETECTED:
When the XmlaOlap4jCellSet class is called to load the MDX data, it calls a method called lookupCube. The issue is that this LOOKUPCUBE is actually using internally a FOREACH cube in the Schema:
LINE 576: for (Cube cube : databaseMetaData.olap4jConnection.getOlapSchema().getCubes())
Reading a little more about what the getCubes() does I checked that most of the Dimensions info is loaded with a deferred lazy method, which is good, except Measures, with say in the code and I state it:
Line 119: File: XmlaOlap4jCube.java
// populate measures up front; a measure is needed in every query
olap4jConnection.populateList(
measures,
context,
XmlaOlap4jConnection.MetadataRequest.MDSCHEMA_MEASURES,
new XmlaOlap4jConnection.MeasureHandler(),
restrictions);
for (XmlaOlap4jMeasure measure : measures) {
measuresMap.put(measure.getUniqueName(), measure);
}
Which it is not deferred.
I Commented this PART to check if it had an impact on the RESULT time and furthermore if the MDX result is affected by not having this info and the First MDX speed was reduced to 3 seconds aprox. (XMLA is still loading all the CUBES, but not loading the Metadata of the Measures that we are not using or not requesting from the Metadata.)
POSSIBLE SOLUTIONS:
I believe we have the following options:
A. We change the MEASURES to be also part of the Lazy loader like other dimensions. But I do not know for what it is used the measureMap loaded after load
B. We do not read ALL the cubes when we are doing an MDX to only 1 cube.
C. Any other ideas are welcome
Regards, alex
Alexander Schurman
Enterprise Architecture Team
​[cid:3bf163d0-be85-46b2-9b57-d4e3e33ad39f]
Direct: +34 627.294.748<tel:%2B34%C2%A0627.294.748>
Skype: aschurman​
------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
olap4j-devel mailing list
olap4j-devel@...<mailto:olap4j-devel@...>
https://lists.sourceforge.net/lists/listinfo/olap4j-devel

I agree with you that a combination is the best scenario. Just one additional comment
Currently if we have 20 cubes, that generates 21 XMLA request (1 for get list of cubes and 1 for each cube loading the measures), so fixing issue A, reduces 90% of the performance issue.
Alexander Schurman
Enterprise Architecture Team
​[cid:3bf163d0-be85-46b2-9b57-d4e3e33ad39f]
Direct: +34 627.294.748
Skype: aschurman​
From: Luc Boudreau [mailto:lucboudreau@...]
Sent: Wednesday, January 07, 2015 5:03 PM
To: Alexander Schurman
Cc: olap4j-devel@...
Subject: Re: [Olap4j-devel] Olap4j - XMLA Cube Metadata Loader causes performance issue
I think the solution is a mix of A and B.
A) It's a good idea to make this collection lazy, unless we know for certain that we will trigger it lower down. We'll look at the code and figure it out. But fixing this won't help much without B) because we would still ask for all cubes.
B) We should pass the cube object to the CellSet in its constructor without iterating. If it's too early in the process and the cube object is not readily available, we should issue a single metadata request for that single cube. (MDSCHEMA_CUBES w/ restrictions).
On Wed, Jan 7, 2015 at 10:24 AM, Alexander Schurman <aschurman@...<mailto:aschurman@...>> wrote:
Hello OLAP4j Team,
I was on conversation with Luc Boudreau about a performance issue I was getting for a large XMLA dependent app.
BASIC INFO:
Server is a Pentaho 5.2 XMLA provider (based on Mondrian 3.8.x)
There is only 1 schema, but with 20 cubes, and 20-30 measures each cube.
USE CASE:
Send MDX queries and parse the result values.
THE ISSUE:
Basically the Issue is that the FIRST MDX query is taking a long time because it is LOADING all the Schema info for all the Cubes. The MDX query it-self only takes 1s, but the response from “”….executeOlapQuery(mdx1);” takes like 1 minute.
HOW TO REPRODUCE:
Just take any SCHEMA use for testing on the SERVER side and copy one of the CUBES many times just with different names. The more Cubes you add the slower MDX 1 is.
THE CAUSE DETECTED:
When the XmlaOlap4jCellSet class is called to load the MDX data, it calls a method called lookupCube. The issue is that this LOOKUPCUBE is actually using internally a FOREACH cube in the Schema:
LINE 576: for (Cube cube : databaseMetaData.olap4jConnection.getOlapSchema().getCubes())
Reading a little more about what the getCubes() does I checked that most of the Dimensions info is loaded with a deferred lazy method, which is good, except Measures, with say in the code and I state it:
Line 119: File: XmlaOlap4jCube.java
// populate measures up front; a measure is needed in every query
olap4jConnection.populateList(
measures,
context,
XmlaOlap4jConnection.MetadataRequest.MDSCHEMA_MEASURES,
new XmlaOlap4jConnection.MeasureHandler(),
restrictions);
for (XmlaOlap4jMeasure measure : measures) {
measuresMap.put(measure.getUniqueName(), measure);
}
Which it is not deferred.
I Commented this PART to check if it had an impact on the RESULT time and furthermore if the MDX result is affected by not having this info and the First MDX speed was reduced to 3 seconds aprox. (XMLA is still loading all the CUBES, but not loading the Metadata of the Measures that we are not using or not requesting from the Metadata.)
POSSIBLE SOLUTIONS:
I believe we have the following options:
A. We change the MEASURES to be also part of the Lazy loader like other dimensions. But I do not know for what it is used the measureMap loaded after load
B. We do not read ALL the cubes when we are doing an MDX to only 1 cube.
C. Any other ideas are welcome
Regards, alex
Alexander Schurman
Enterprise Architecture Team
​[cid:3bf163d0-be85-46b2-9b57-d4e3e33ad39f]
Direct: +34 627.294.748<tel:%2B34%C2%A0627.294.748>
Skype: aschurman​
------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
olap4j-devel mailing list
olap4j-devel@...<mailto:olap4j-devel@...>
https://lists.sourceforge.net/lists/listinfo/olap4j-devel

I think the solution is a mix of A and B.
A) It's a good idea to make this collection lazy, unless we know for
certain that we will trigger it lower down. We'll look at the code and
figure it out. But fixing this won't help much without B) because we would
still ask for all cubes.
B) We should pass the cube object to the CellSet in its constructor without
iterating. If it's too early in the process and the cube object is not
readily available, we should issue a single metadata request for that
single cube. (MDSCHEMA_CUBES w/ restrictions).
On Wed, Jan 7, 2015 at 10:24 AM, Alexander Schurman <aschurman@...>
wrote:
> Hello OLAP4j Team,
>
>
>
> I was on conversation with Luc Boudreau about a performance issue I was
> getting for a large XMLA dependent app.
>
>
>
> *BASIC INFO:*
>
> Server is a Pentaho 5.2 XMLA provider (based on Mondrian 3.8.x)
>
> There is only 1 schema, but with 20 cubes, and 20-30 measures each cube.
>
>
>
> *USE CASE:*
>
> Send MDX queries and parse the result values.
>
>
>
> *THE ISSUE:*
>
> Basically the Issue is that the FIRST MDX query is taking a long time
> because it is LOADING all the Schema info for all the Cubes. The MDX query
> it-self only takes 1s, but the response from “”….executeOlapQuery(mdx1);”
> takes like 1 minute.
>
>
>
> *HOW TO REPRODUCE:*
>
> Just take any SCHEMA use for testing on the SERVER side and copy one of
> the CUBES many times just with different names. The more Cubes you add the
> slower MDX 1 is.
>
>
>
>
>
> *THE CAUSE DETECTED:*
>
> When the *XmlaOlap4jCellSet* class is called to load the MDX data, it
> calls a method called *lookupCube. *The issue is that this LOOKUPCUBE is
> actually using internally a FOREACH cube in the Schema:
>
> LINE 576: *for (Cube cube :
> databaseMetaData.olap4jConnection.getOlapSchema().getCubes())*
>
>
> Reading a little more about what the *getCubes() * does I checked that
> most of the Dimensions info is loaded with a deferred lazy method, which is
> good, except Measures, with say in the code and I state it:
>
> Line 119: File: XmlaOlap4jCube.java
>
> * // populate measures up front; a measure is needed in every
> query *
>
> * olap4jConnection.populateList(*
>
> * measures,*
>
> * context,*
>
> * XmlaOlap4jConnection.MetadataRequest.MDSCHEMA_MEASURES,*
>
> * new XmlaOlap4jConnection.MeasureHandler(),*
>
> * restrictions);*
>
> * for (XmlaOlap4jMeasure measure : measures) {*
>
> * measuresMap.put(measure.getUniqueName(), measure);*
>
> * }*
>
>
>
> Which it is not deferred.
>
> I Commented this PART to check if it had an impact on the RESULT time and
> furthermore if the MDX result is affected by not having this info and the
> First MDX speed was reduced to 3 seconds aprox. (XMLA is still loading all
> the CUBES, but not loading the Metadata of the Measures that we are not
> using or not requesting from the Metadata.)
>
>
>
>
>
> *POSSIBLE SOLUTIONS:*
>
> I believe we have the following options:
>
> A. We change the MEASURES to be also part of the Lazy loader like
> other dimensions. But I do not know for what it is used the *measureMap*
> loaded after load
>
> B. We do not read ALL the cubes when we are doing an MDX to only 1
> cube.
>
> C. Any other ideas are welcome
>
>
>
>
>
> Regards, alex
>
>
>
>
>
>
>
>
>
> Alexander Schurman
>
> Enterprise Architecture Team
>
>
>
> ​[image: cid:3bf163d0-be85-46b2-9b57-d4e3e33ad39f]
>
> Direct: +34 627.294.748
>
> Skype: aschurman​
>
>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming! The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is
> your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net
> _______________________________________________
> olap4j-devel mailing list
> olap4j-devel@...
> https://lists.sourceforge.net/lists/listinfo/olap4j-devel
>
>

Hello OLAP4j Team,
I was on conversation with Luc Boudreau about a performance issue I was getting for a large XMLA dependent app.
BASIC INFO:
Server is a Pentaho 5.2 XMLA provider (based on Mondrian 3.8.x)
There is only 1 schema, but with 20 cubes, and 20-30 measures each cube.
USE CASE:
Send MDX queries and parse the result values.
THE ISSUE:
Basically the Issue is that the FIRST MDX query is taking a long time because it is LOADING all the Schema info for all the Cubes. The MDX query it-self only takes 1s, but the response from “”….executeOlapQuery(mdx1);” takes like 1 minute.
HOW TO REPRODUCE:
Just take any SCHEMA use for testing on the SERVER side and copy one of the CUBES many times just with different names. The more Cubes you add the slower MDX 1 is.
THE CAUSE DETECTED:
When the XmlaOlap4jCellSet class is called to load the MDX data, it calls a method called lookupCube. The issue is that this LOOKUPCUBE is actually using internally a FOREACH cube in the Schema:
LINE 576: for (Cube cube : databaseMetaData.olap4jConnection.getOlapSchema().getCubes())
Reading a little more about what the getCubes() does I checked that most of the Dimensions info is loaded with a deferred lazy method, which is good, except Measures, with say in the code and I state it:
Line 119: File: XmlaOlap4jCube.java
// populate measures up front; a measure is needed in every query
olap4jConnection.populateList(
measures,
context,
XmlaOlap4jConnection.MetadataRequest.MDSCHEMA_MEASURES,
new XmlaOlap4jConnection.MeasureHandler(),
restrictions);
for (XmlaOlap4jMeasure measure : measures) {
measuresMap.put(measure.getUniqueName(), measure);
}
Which it is not deferred.
I Commented this PART to check if it had an impact on the RESULT time and furthermore if the MDX result is affected by not having this info and the First MDX speed was reduced to 3 seconds aprox. (XMLA is still loading all the CUBES, but not loading the Metadata of the Measures that we are not using or not requesting from the Metadata.)
POSSIBLE SOLUTIONS:
I believe we have the following options:
A. We change the MEASURES to be also part of the Lazy loader like other dimensions. But I do not know for what it is used the measureMap loaded after load
B. We do not read ALL the cubes when we are doing an MDX to only 1 cube.
C. Any other ideas are welcome
Regards, alex
Alexander Schurman
Enterprise Architecture Team
​[cid:3bf163d0-be85-46b2-9b57-d4e3e33ad39f]
Direct: +34 627.294.748
Skype: aschurman​

This is the right PR:
https://github.com/olap4j/olap4j/pull/32
Cheers!
On Fri, Dec 5, 2014 at 12:18 PM, Luc Boudreau <lucboudreau@...> wrote:
> Seems my workspace wasn't in sync with the latest trunk. Please allow a
> few minutes so I can fix some issues before reviewing.
>
> Thanks!
>
> On Fri, Dec 5, 2014 at 12:15 PM, Luc Boudreau <lucboudreau@...>
> wrote:
>
>> Hello fellas,
>>
>> Below is a link to a pull request that I'd like to submit for review.
>> It's been a while since we released some important fixes for the XMLA
>> driver and it's time we do so. It addresses a few issues with the XMLA
>> driver.
>>
>> https://github.com/olap4j/olap4j/pull/31
>>
>> - Fixes an issue where DeferredNamedList would enter a stale state if an
>> unchecked exception was thrown.
>>
>> - Fixes an issue in XmlaOlap4jCube where Mondrian was not recognized as
>> the backend flavor and would not batch requests to MDSCHEMA_MEMBERS.
>>
>> - Makes XmlaOlap4jConnection.DEBUG configurable through system property:
>> "olap4j.xmla.debug"
>>
>> I'm planning on releasing these fixes some time next week. In the
>> meanwhile, please provide any feedback, or propose other fixes for this
>> release. We will not be changing anything related to the core API, so
>> please keep that in mind if you wanted to propose some novel and disruptive
>> idea.
>>
>> Luc
>>
>
>

Seems my workspace wasn't in sync with the latest trunk. Please allow a few
minutes so I can fix some issues before reviewing.
Thanks!
On Fri, Dec 5, 2014 at 12:15 PM, Luc Boudreau <lucboudreau@...> wrote:
> Hello fellas,
>
> Below is a link to a pull request that I'd like to submit for review. It's
> been a while since we released some important fixes for the XMLA driver and
> it's time we do so. It addresses a few issues with the XMLA driver.
>
> https://github.com/olap4j/olap4j/pull/31
>
> - Fixes an issue where DeferredNamedList would enter a stale state if an
> unchecked exception was thrown.
>
> - Fixes an issue in XmlaOlap4jCube where Mondrian was not recognized as
> the backend flavor and would not batch requests to MDSCHEMA_MEMBERS.
>
> - Makes XmlaOlap4jConnection.DEBUG configurable through system property:
> "olap4j.xmla.debug"
>
> I'm planning on releasing these fixes some time next week. In the
> meanwhile, please provide any feedback, or propose other fixes for this
> release. We will not be changing anything related to the core API, so
> please keep that in mind if you wanted to propose some novel and disruptive
> idea.
>
> Luc
>

Hello fellas,
Below is a link to a pull request that I'd like to submit for review. It's
been a while since we released some important fixes for the XMLA driver and
it's time we do so. It addresses a few issues with the XMLA driver.
https://github.com/olap4j/olap4j/pull/31
- Fixes an issue where DeferredNamedList would enter a stale state if an
unchecked exception was thrown.
- Fixes an issue in XmlaOlap4jCube where Mondrian was not recognized as
the backend flavor and would not batch requests to MDSCHEMA_MEMBERS.
- Makes XmlaOlap4jConnection.DEBUG configurable through system property:
"olap4j.xmla.debug"
I'm planning on releasing these fixes some time next week. In the
meanwhile, please provide any feedback, or propose other fixes for this
release. We will not be changing anything related to the core API, so
please keep that in mind if you wanted to propose some novel and disruptive
idea.
Luc

If you need to request members with unconventional predicates (such as this one) then the most flexible way is to run a query. E.g.
select subset([Customer].Members, 2000, 1000) on 0 from [Sales]
Julian

Hello!
We are software developers working on Pentaho technologies via olap4j / XML/A.
Because sometimes Mondrian is not appropriate we also use Microsoft SQL Server Analysis Services.
Situation:
We are running a XML/A client using olap4j 1.2 and Microsoft SQL Server Analysis Services 2012.
We have a simple star schema on SSAS but one dimension can have more then 1.000.000 members. I know ... bad design L ..., but the CUBES are made from another company.
So, when there is lots of members ... we get ERROR :
08:21:15.189 c.r.m.server.run.SchemaTester INFO Level: [Dokument - finančni].[Dokument - finančni].[Številka dokumenta] -> Type: REGULAR
Exception in thread "main" java.lang.OutOfMemoryError: Requested array size exceeds VM limit
at java.util.Arrays.copyOf(Arrays.java:2271)
at java.io.ByteArrayOutputStream.grow(ByteArrayOutputStream.java:113)
at java.io.ByteArrayOutputStream.ensureCapacity(ByteArrayOutputStream.java:93)
at java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:140)
at org.olap4j.driver.xmla.proxy.XmlaOlap4jHttpProxy.getResponse(XmlaOlap4jHttpProxy.java:150)
at org.olap4j.driver.xmla.proxy.XmlaOlap4jAbstractHttpProxy.get(XmlaOlap4jAbstractHttpProxy.java:181)
at org.olap4j.driver.xmla.proxy.XmlaOlap4jHttpProxy.get(XmlaOlap4jHttpProxy.java:42)
at org.olap4j.driver.xmla.XmlaOlap4jConnection.executeMetadataRequest(XmlaOlap4jConnection.java:876)
at org.olap4j.driver.xmla.XmlaOlap4jConnection.populateList(XmlaOlap4jConnection.java:851)
at org.olap4j.driver.xmla.DeferredNamedListImpl.populateList(DeferredNamedListImpl.java:136)
at org.olap4j.driver.xmla.DeferredNamedListImpl.getList(DeferredNamedListImpl.java:90)
at org.olap4j.driver.xmla.DeferredNamedListImpl.size(DeferredNamedListImpl.java:116)
at com.resevo.dev.olap.SchemaTester.main(SchemaTester.java:134)
Call line:for(Member child : member.getChildMembers()) {...}
The actual response from server is 97mb of gzip-ed data that gets extracted to about 1.25gb byte array. So we're breaching limit of single array instance, not limitations of memory available JVM (8gb).
Question:
Is there any other way to ... let's say load dimension members in smaller chunks like in SQL via [LIMIT { number | ALL }] [OFFSET number] or do you suggest any other way?
Are there any plans to change reading of XMLA responses from current DOM/Xerces implementation to a StAX/streaming one so we don't have to keep full response in memory?
Thanks in advance.
Kind regards,
ToMaZ
GSM: 041 334 356
Tomaž Bergant
ResEvo d.o.o.
Finžgarjeva 1a
SI-4248 Lesce
WEB: http://www.ResEvo.com <http://www.resevo.com/&gt;
email: tomaz.bergant@... <mailto:tomaz.bergant@...>

Hello!
We are software developers working on Pentaho technologies via olap4j / XML/A.
Because sometimes Mondrian is not appropriate we also use Microsoft SQL Server Analysis Services.
Situation:
We are running a XML/A client using olap4j 1.2 and Microsoft SQL Server Analysis Services 2012.
We have a simple star schema on SSAS but one dimension can have more then 1.000.000 members. I know ... bad design L ..., but the CUBES are made from another company.
So, when there is lots of members ... we get ERROR :
08:21:15.189 c.r.m.server.run.SchemaTester INFO Level: [Dokument - finančni].[Dokument - finančni].[Številka dokumenta] -> Type: REGULAR
Exception in thread "main" java.lang.OutOfMemoryError: Requested array size exceeds VM limit
at java.util.Arrays.copyOf(Arrays.java:2271)
at java.io.ByteArrayOutputStream.grow(ByteArrayOutputStream.java:113)
at java.io.ByteArrayOutputStream.ensureCapacity(ByteArrayOutputStream.java:93)
at java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:140)
at org.olap4j.driver.xmla.proxy.XmlaOlap4jHttpProxy.getResponse(XmlaOlap4jHttpProxy.java:150)
at org.olap4j.driver.xmla.proxy.XmlaOlap4jAbstractHttpProxy.get(XmlaOlap4jAbstractHttpProxy.java:181)
at org.olap4j.driver.xmla.proxy.XmlaOlap4jHttpProxy.get(XmlaOlap4jHttpProxy.java:42)
at org.olap4j.driver.xmla.XmlaOlap4jConnection.executeMetadataRequest(XmlaOlap4jConnection.java:876)
at org.olap4j.driver.xmla.XmlaOlap4jConnection.populateList(XmlaOlap4jConnection.java:851)
at org.olap4j.driver.xmla.DeferredNamedListImpl.populateList(DeferredNamedListImpl.java:136)
at org.olap4j.driver.xmla.DeferredNamedListImpl.getList(DeferredNamedListImpl.java:90)
at org.olap4j.driver.xmla.DeferredNamedListImpl.size(DeferredNamedListImpl.java:116)
at com.resevo.dev.olap.SchemaTester.main(SchemaTester.java:134)
Call line:for(Member child : member.getChildMembers()) {...}
The actual response from server is 97mb of gzip-ed data that gets extracted to about 1.25gb byte array. So we're breaching limit of single array instance, not limitations of memory available JVM (8gb).
Question:
Is there any other way to ... let's say load dimension members in smaller chunks like in SQL via [LIMIT { number | ALL }] [OFFSET number] or do you suggest any other way?
Are there any plans to change reading of XMLA responses from current DOM/Xerces implementation to a StAX/streaming one so we don't have to keep full response in memory?
Thanks in advance.
Kind regards,
ToMaZ
GSM: 041 334 356
Tomaž Bergant
ResEvo d.o.o.
Finžgarjeva 1a
SI-4248 Lesce
WEB: http://www.ResEvo.com <http://www.resevo.com/&gt;
email: tomaz.bergant@... <mailto:tomaz.bergant@...>

At a member, the format string is an expression. At a cell, the format string is a value (obtained by evaluating the format string expressions of the current measure). So it's no surprise that they come out differently.
Usually the format string is a constant (say "#,###" or "(#,###);#,###") so people often don't notice this fine distinction. But members don't really have a FORMAT_STRING property. It's a cell property, and you shouldn't really be asking for it at a member. (I don't recall why it comes out of XMLA... probably to be compatible with a version of Microsoft XMLA ten years ago.)
Regarding why it's more complicated to get properties in olap4j versus Mondrian. Mondrian's list was fixed, because you are only dealing with a single version of a particular server; whereas olap4j's list could change between back-ends and versions.
Julian
On Mar 7, 2014, at 7:29 AM, Paul Stoellberger <p.stoellberger@...<mailto:p.stoellberger@...>> wrote:
It seems like olap4j is making things more complicated than it was in mondrian itself.
mondrian.olap.Property looks simpler than the olap4j classes.
And yeah, there are currently different approaches of looking up properties.
m.getProperties could be a simple map of String, Object - where a lookup enum can be used as well.
We could also make it more clear that there is a difference between a member property, and a cell property.
So instead of passing a Property object we could make it a getPropertyValue( <MemberProperty | CellProperty | DataTypeProperty> property ) depending on the object its executed on.
There would be less confusion on how and with what method / property object one can look up the value.
Additionally provide a getPropertyValue(String) for other / arbitrary properties that are not in the standard.
However the issue is more about mondrian olap4j not populating the FORMAT_STRING property of a Measure object in the first place, while a XmlaOlap4jMeasure does it.
Since SSAS seems to return the formatstring apparently when Measures are fetched, we should do the same in mondrian.
One could argue that a format string is as much of a vital method as fetching the aggregator or datatype of a measure, so we could add it directly as method in org.olap4j.metadata.Measure
-Paul
On Mar 7, 2014, at 4:10 PM, Luc Boudreau <lucboudreau@...<mailto:lucboudreau@...>> wrote:
Just to clarify, if m.getPropertyValue took a String, would that make the API saner?
Also, it seems that the bug you've identified is caused by passing the property enum instance inside of m.getPropertyValue while it needs the hydrated property object to get a match in a map somewhere. Dunno if it should take both. Anyways. Seems to me we have to cleanup the lookups of properties. Just need to figure out if the olap4j API is misleading, or the mondrian implementation.
Luc
On Fri, Mar 7, 2014 at 9:51 AM, Paul Stoellberger <p.stoellberger@...<mailto:p.stoellberger@...>> wrote:
Hi,
I was trying to fetch the format string of all measures in the cube, but that doesn't seem to be an easy thing to do.
The only way to get it via the Cell in a Cellset using cell Property FORMAT_STRING.
If you try to fetch it using this - directly on a cube Measure, it will be empty in mondrian:
private Format getMeasureFormat(Measure m) {
try {
String formatString = (String) m.getPropertyValue(Property.StandardCellProperty.FORMAT_STRING);
In XMLA the property should be clearly set: https://github.com/olap4j/olap4j/blob/master/src/org/olap4j/driver/xmla/XmlaOlap4jMeasure.java#L74
In mondrian I have to do this
private Format getMeasureFormat(Measure m) {
String formatString = (String) m.getPropertyValue(m.getProperties().get("FORMAT_EXP");
I don't really see a reason why this should be hidden when its there.
It seems like a standard property for measures that is even returned in the XMLA result.
>From my point of view it should work like it does for XMLA - using the StandardCellProperty on a Measure member.
What do you think?
-Paul
------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works.
Faster operations. Version large binaries. Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
_______________________________________________
olap4j-devel mailing list
olap4j-devel@...<mailto:olap4j-devel@...>
https://lists.sourceforge.net/lists/listinfo/olap4j-devel
------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works.
Faster operations. Version large binaries. Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk_______________________________________________
olap4j-devel mailing list
olap4j-devel@...
https://lists.sourceforge.net/lists/listinfo/olap4j-devel

It seems like olap4j is making things more complicated than it was in mondrian itself.
mondrian.olap.Property looks simpler than the olap4j classes.
And yeah, there are currently different approaches of looking up properties.
m.getProperties could be a simple map of String, Object - where a lookup enum can be used as well.
We could also make it more clear that there is a difference between a member property, and a cell property.
So instead of passing a Property object we could make it a getPropertyValue( <MemberProperty | CellProperty | DataTypeProperty> property ) depending on the object its executed on.
There would be less confusion on how and with what method / property object one can look up the value.
Additionally provide a getPropertyValue(String) for other / arbitrary properties that are not in the standard.
However the issue is more about mondrian olap4j not populating the FORMAT_STRING property of a Measure object in the first place, while a XmlaOlap4jMeasure does it.
Since SSAS seems to return the formatstring apparently when Measures are fetched, we should do the same in mondrian.
One could argue that a format string is as much of a vital method as fetching the aggregator or datatype of a measure, so we could add it directly as method in org.olap4j.metadata.Measure
-Paul
On Mar 7, 2014, at 4:10 PM, Luc Boudreau <lucboudreau@...> wrote:
> Just to clarify, if m.getPropertyValue took a String, would that make the API saner?
>
> Also, it seems that the bug you've identified is caused by passing the property enum instance inside of m.getPropertyValue while it needs the hydrated property object to get a match in a map somewhere. Dunno if it should take both. Anyways. Seems to me we have to cleanup the lookups of properties. Just need to figure out if the olap4j API is misleading, or the mondrian implementation.
>
> Luc
>
>
> On Fri, Mar 7, 2014 at 9:51 AM, Paul Stoellberger <p.stoellberger@...> wrote:
> Hi,
>
> I was trying to fetch the format string of all measures in the cube, but that doesn't seem to be an easy thing to do.
> The only way to get it via the Cell in a Cellset using cell Property FORMAT_STRING.
>
> If you try to fetch it using this - directly on a cube Measure, it will be empty in mondrian:
>
> private Format getMeasureFormat(Measure m) {
> try {
> String formatString = (String) m.getPropertyValue(Property.StandardCellProperty.FORMAT_STRING);
>
> In XMLA the property should be clearly set: https://github.com/olap4j/olap4j/blob/master/src/org/olap4j/driver/xmla/XmlaOlap4jMeasure.java#L74
>
> In mondrian I have to do this
>
> private Format getMeasureFormat(Measure m) {
> String formatString = (String) m.getPropertyValue(m.getProperties().get("FORMAT_EXP");
>
> I don't really see a reason why this should be hidden when its there.
> It seems like a standard property for measures that is even returned in the XMLA result.
>
> From my point of view it should work like it does for XMLA - using the StandardCellProperty on a Measure member.
>
> What do you think?
>
> -Paul
>
>
>
> ------------------------------------------------------------------------------
> Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
> With Perforce, you get hassle-free workflows. Merge that actually works.
> Faster operations. Version large binaries. Built-in WAN optimization and the
> freedom to use Git, Perforce or both. Make the move to Perforce.
> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
> _______________________________________________
> olap4j-devel mailing list
> olap4j-devel@...
> https://lists.sourceforge.net/lists/listinfo/olap4j-devel
>
>

Just to clarify, if m.getPropertyValue took a String, would that make the
API saner?
Also, it seems that the bug you've identified is caused by passing the
property enum instance inside of m.getPropertyValue while it needs the
hydrated property object to get a match in a map somewhere. Dunno if it
should take both. Anyways. Seems to me we have to cleanup the lookups of
properties. Just need to figure out if the olap4j API is misleading, or the
mondrian implementation.
Luc
On Fri, Mar 7, 2014 at 9:51 AM, Paul Stoellberger
<p.stoellberger@...>wrote:
> Hi,
>
> I was trying to fetch the format string of all measures in the cube, but
> that doesn't seem to be an easy thing to do.
> The only way to get it via the Cell in a Cellset using cell Property
> FORMAT_STRING.
>
> If you try to fetch it using this - directly on a cube Measure, it will be
> empty in mondrian:
>
> private Format getMeasureFormat(Measure m) {
> try {
> String formatString = (String)
> m.getPropertyValue(Property.StandardCellProperty.FORMAT_STRING);
>
> In XMLA the property should be clearly set:
> https://github.com/olap4j/olap4j/blob/master/src/org/olap4j/driver/xmla/XmlaOlap4jMeasure.java#L74
>
> In mondrian I have to do this
>
> private Format getMeasureFormat(Measure m) {
> String formatString = (String) m.getPropertyValue(m.getProperties().get(
> "FORMAT_EXP");
>
> I don't really see a reason why this should be hidden when its there.
> It seems like a standard property for measures that is even returned in
> the XMLA result.
>
> From my point of view it should work like it does for XMLA - using the
> StandardCellProperty on a Measure member.
>
> What do you think?
>
> -Paul
>
>
>
>
> ------------------------------------------------------------------------------
> Subversion Kills Productivity. Get off Subversion & Make the Move to
> Perforce.
> With Perforce, you get hassle-free workflows. Merge that actually works.
> Faster operations. Version large binaries. Built-in WAN optimization and
> the
> freedom to use Git, Perforce or both. Make the move to Perforce.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
> _______________________________________________
> olap4j-devel mailing list
> olap4j-devel@...
> https://lists.sourceforge.net/lists/listinfo/olap4j-devel
>
>

Hi,
I was trying to fetch the format string of all measures in the cube, but that doesn't seem to be an easy thing to do.
The only way to get it via the Cell in a Cellset using cell Property FORMAT_STRING.
If you try to fetch it using this - directly on a cube Measure, it will be empty in mondrian:
private Format getMeasureFormat(Measure m) {
try {
String formatString = (String) m.getPropertyValue(Property.StandardCellProperty.FORMAT_STRING);
In XMLA the property should be clearly set: https://github.com/olap4j/olap4j/blob/master/src/org/olap4j/driver/xmla/XmlaOlap4jMeasure.java#L74
In mondrian I have to do this
private Format getMeasureFormat(Measure m) {
String formatString = (String) m.getPropertyValue(m.getProperties().get("FORMAT_EXP");
I don't really see a reason why this should be hidden when its there.
It seems like a standard property for measures that is even returned in the XMLA result.
From my point of view it should work like it does for XMLA - using the StandardCellProperty on a Measure member.
What do you think?
-Paul

2 messages has been excluded from this view by a project administrator.