[Mondrian] mondrian clear cache from other servlet

Luc Boudreau lucboudreau at gmail.com
Thu Jul 11 15:36:58 EDT 2013


Not sure where in that chain the problem is, but I can recommend some best
practices which might help.

You can override the servlet code and get a handle on the mondrian instance
which creates the connections for the servlet. Use that access point to
share somehow the MondrianServer instance to your RPC service. Or you can
also use the connection parameter called Instance, where you pass the
unique ID of a MondrianServer instance. I would do it the first way,
because it will be statically typed and will fail hard if it has to.

The olap4j-xmlaservlet is a spinoff of the same code. It allows you to pass
any olap4j connection to a generic servlet and turn it into an XMLA service.

Hope this helps.


On Thu, Jul 11, 2013 at 3:39 AM, Martijn van den Broek <martijn at basesoft.com
> wrote:

>  I sure dont hope we're dealing with giant-zombie-ghosts here. I almost
> lost a leg last time I encountered those.
>
> Our setup is as following: A typical tomcat setup where the mondrian.jar
> (git master) lives in the WEB-INF/lib together with its dependencies. In
> web.xml the xmla servlet is defined using the class from the mondrian.jar
> package: mondrian.xmla.impl.DynamicDatasourceXmlaServlet . So no
> subclassing there. I have also commented callbacks.
> I havent yet looked into olap4j-xmlaservet. Is this preferred or required
> for the JdbcConnectionUuid? Will that still work with datasources.xml and
> reloading and such?
>
> And then there is the XmlRpcServlet with the clearCache() functions. It
> gets the mondrian connection like how I described in my first post:
> mondrian.olap.Connection conn =
> mondrian.olap.DriverManager.getConnection(datasource_info, null);
>
> I sense some deprecation here. Should I be using the olap4j api to get the
> connection? And then unwrap it to a mondrian.olap.Connection to access the
> caching methods?
>
>
>
>
> On 10/07/13 17:17, Luc Boudreau wrote:
>
> If the cache is empty but you get MDX results back, then yes, something is
> wrong. Could be ghosts, or worse, giant-zombie-ghosts; Half giant, half
> zombie, half ghost.
>
>  Can you give more details on how things are setup? I'm not certain I
> understand exactly how you've setup things. How are you creating the
> Mondrian instance? Are you using the olap4j-xmlaservet project? Have you
> subclasses the servlet with your own code?
>
>
> On Wed, Jul 10, 2013 at 11:10 AM, Martijn van den Broek <
> martijn at basesoft.com> wrote:
>
>>  Thanks for your quick reply. I forgot to mention I also have tried the
>> JdbcConnectionUuid. Ive tried again:
>>
>> If I understand correctly, for XMLA no changes are needed except a
>> modification in datasources.xml which now looks like:
>>
>>
>> <DataSourceInfo>Provider=mondrian;JdbcDrivers=com.mysql.jdbc.Driver;Jdbc=jdbc:mysql://
>> 127.0.0.1:3306/iqportal?user=xxx&amp;password=xxx;Catalog=<http://127.0.0.1:3306/iqportal?user=xxx&password=xxx;Catalog=>
>> file:///home/martijn/workspace_ee/.metadata/.plugins/org.eclipse.wst.server.core/tmp2/wtpwebapps/iqube/WEB-INF/queries/basesoft.settings.martijn.IQuest.xml;UseContentChecksum=true;JdbcConnectionUuid=basesoft.settings.martijn.IQuest
>> </DataSourceInfo>
>>
>> The datasource_info that the XMLRPC servlet uses is now:
>>
>> Provider=mondrian;JdbcDrivers=com.mysql.jdbc.Driver;Jdbc=jdbc:mysql://
>> 127.0.0.1:3306/iqportal?user=root&password=f00b4r;Catalog=
>> file:///home/martijn/workspace_ee/.metadata/.plugins/org.eclipse.wst.server.core/tmp2/wtpwebapps/iqube/WEB-INF/queries/basesoft.settings.martijn.IQuest.xml;UseContentChecksum=true;JdbcConnectionUuid=basesoft.settings.martijn.IQuest
>>
>> However XMLRPC servlet cache still seems to be empty. Also re-executing
>> the MDX query does no SQL queries against the database. Could anything else
>> be wrong here?
>>
>>
>>
>>
>>
>> On 10/07/13 15:37, Luc Boudreau wrote:
>>
>> You might not be hitting the same schema in cache. Using the datasource +
>> checksum is tricky. If a single character changes in the schema, the
>> checksum changes and you can't get a cache hit anymore, thus fragmenting
>> your cache by creating a bunch of different schemas.
>>
>>  One thing you might look into, the JdbcConnectionUuid connection
>> property. If defined, it forces Mondrian to use a given schema from the
>> pool. Be wary though, make sure that you don't assign the same UUID to two
>> different schemas, or you'll get weird things happening.
>>
>>  Luc
>>
>>
>> On Wed, Jul 10, 2013 at 5:08 AM, Martijn van den Broek <
>> martijn at basesoft.com> wrote:
>>
>>> Hello fellow mondrians,
>>>
>>> We are running Mondrian using XMLA (compiled current git master) in a
>>> Tomcat 6 instance defined as following in web.xml:
>>>
>>>   <servlet>
>>>     <servlet-name>MondrianXmlaServlet</servlet-name>
>>>
>>>
>>> <servlet-class>mondrian.xmla.impl.DynamicDatasourceXmlaServlet</servlet-class>
>>>      ...
>>>   </servlet>
>>>
>>> Next to that in the same web.xml, we have our own XMLRPC servlet for
>>> controlling various mondrian tasks like writing schema files and
>>> controlling cache:
>>>
>>>   <servlet>
>>>     <servlet-name>IQubeXmlRpcServlet</servlet-name>
>>>
>>> <servlet-class>com.basesoft.iqube.xml.IQubeXmlRpcServlet</servlet-class>
>>>      ...
>>>  </servlet>
>>>
>>> In that second xmlrpc servlet a clearCache method is defined which
>>> accepts a mondrian connectionstring similar as the code below:
>>>
>>>         String datasource_info =
>>> "Provider=mondrian;JdbcDrivers=com.mysql.jdbc.Driver;Jdbc=jdbc:mysql://
>>> 127.0.0.1:3306/iqportal?user=xxx&password=xxx;Catalog=file:///home/martijn/workspace_ee/.metadata/.plugins/org.eclipse.wst.server.core/tmp2/wtpwebapps/iqube/WEB-INF/queries/basesoft.settings.martijn.IQuest.xml;UseContentChecksum=true
>>> ;";
>>>
>>>         Connection conn = DriverManager.getConnection(datasource_info,
>>> null);
>>>         PrintWriter pw = new PrintWriter(System.out, true);
>>>         CacheControl cacheControl = conn.getCacheControl(pw);
>>>
>>>         for (Cube cube : conn.getSchema().getCubes()) {
>>>
>>>             CacheControl.CellRegion region =
>>> cacheControl.createMeasuresRegion(cube);
>>>
>>>             System.out.println("!! clearMemberCache: cache state
>>> before:");
>>>             cacheControl.printCacheState(pw, region);
>>>
>>>             cacheControl.flush(region);
>>>
>>>             System.out.println("!! clearMemberCache: cache state
>>> after:");
>>>             cacheControl.printCacheState(pw, region);
>>>
>>>             System.out.println("Cleared cache for cube '" +
>>> cube.getName() + "'");
>>>         }
>>>
>>> Now if an MDX query is executed against the XMLA server and then the
>>> clearCache() method on the XMLRPC servlet is called, the cache state is
>>> printed as empty. It is not possible to clear the mondrian cache this
>>> way anymore. This code used to work in mondrian 3.5 but it seems the API
>>> has changed. My guess is that I am requesting the mondrian connection
>>> wrong due to the recent olap4j changes.
>>>
>>> Any hints on how to get a proper connection? Any help is appreciated.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Kind regards,
>>>
>>> Martijn van den Broek
>>> BaseSoft Solutions B.V.
>>>
>>> Herengracht 564
>>> 1017 CH Amsterdam
>>> The Netherlands
>>>
>>> http://www.basesoftsolutions.com/
>>> +31(0)206847087
>>>
>>> Confidentiality notice
>>> **********************************************************************
>>> This email and any files transmitted with it are confidential and
>>> intended solely for the use of the individual or entity to whom they
>>> are addressed. If you have received this email in error please notify
>>> the system manager.
>>> **********************************************************************
>>>
>>>
>>>
>>> _______________________________________________
>>> Mondrian mailing list
>>> Mondrian at pentaho.org
>>> http://lists.pentaho.org/mailman/listinfo/mondrian
>>>
>>
>>
>>
>> _______________________________________________
>> Mondrian mailing listMondrian at pentaho.orghttp://lists.pentaho.org/mailman/listinfo/mondrian
>>
>>
>>
>> --
>> Kind regards,
>>
>> Martijn van den Broek
>> BaseSoft Solutions B.V.
>>
>> Herengracht 564
>> 1017 CH Amsterdam
>> The Netherlands
>> http://www.basesoftsolutions.com/
>> +31(0)206847087
>>
>> Confidentiality notice
>> **********************************************************************
>> This email and any files transmitted with it are confidential and
>> intended solely for the use of the individual or entity to whom they
>> are addressed. If you have received this email in error please notify
>> the system manager.
>> **********************************************************************
>>
>>
>>
>>
>>
>> _______________________________________________
>> Mondrian mailing list
>> Mondrian at pentaho.org
>> http://lists.pentaho.org/mailman/listinfo/mondrian
>>
>>
>
>
> _______________________________________________
> Mondrian mailing listMondrian at pentaho.orghttp://lists.pentaho.org/mailman/listinfo/mondrian
>
>
>
> --
> Kind regards,
>
> Martijn van den Broek
> BaseSoft Solutions B.V.
>
> Herengracht 564
> 1017 CH Amsterdam
> The Netherlands
> http://www.basesoftsolutions.com/
> +31(0)206847087
>
> Confidentiality notice
> **********************************************************************
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please notify
> the system manager.
> **********************************************************************
>
>
>
>
>
> _______________________________________________
> Mondrian mailing list
> Mondrian at pentaho.org
> http://lists.pentaho.org/mailman/listinfo/mondrian
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.pentaho.org/pipermail/mondrian/attachments/20130711/13439de1/attachment-0001.html 


More information about the Mondrian mailing list