asked on November 29, 2018
Hello, we are running flexmonster 2.6.8 with pentaho-mondrian accellerator running in binary mode. Accelerator is running with caching disabled in flexmonster.config.
We have a dashboard application where the user can drag multiple instances of flexmonster (widgets). These widgets can be configured individually but can run on the same datasource/cube (for the same role etc). The widgets are initialised with a default preset selection.
We notice something weird: For every other instance of flexmonster (the 2nd, 4th, 6th etc), the data result shows empty (see screenshot).
I tried to look at what is causing this behaviour. In the accellerator logfile I noticed the second widget is taking an initial strange offset which seems to return an empty result:
[2018-11-29 09:10:15] INFO: Execute 0 - false
[2018-11-29 09:10:15] INFO: chunk: 0, from: 366765, size: 2
[2018-11-29 09:10:15] INFO: query: ...
[2018-11-29 09:10:15] INFO: getConnectionString() datasource_id:5, roles:
[2018-11-29 09:10:15] INFO: Execute - empty [8 ms]
[2018-11-29 09:10:15] INFO: Execute end
I looked a bit in the decompiled Execute() code in FlexmonsterProxyServlet.class. In there it bases the 'from' on variable dataChunkFromIndex which has its key set by:
String dataChunkId = catalog + queryString + args.credentials + args.sessionId + args.roles + args.formatted;
This is when I noticed that sessionId is actually the same for all flexmonster instances (even in other browsers). So it looks like all instances share the same data chunks. This seems to be causing this behaviour.
I noticed the sessionId is sent to the client in DiscoverDimensions() and its taken from the static sessionId of FlexmonsterProxyServlet
protected static long sessionId = generateSessionId();
Is this the correct behaviour? Shouldn't each flexmonster instance get its own sessionId?
This could be fixed by letting DiscoverDimensions always return a new sessionId:
args.sessionId = generateSessionId();
This seems to fix the empty table result we are seeing. So is this a bug? Or am I doing something wrong?
⋅ November 29, 2018
Hello Martijn,
Thank you for such detailed information.
As for the sessionId, it is mainly used to handle updates of the underlying data. In case the data is updated during the user session, sessionId changed and data consistency can be handled.
As for the issue with empty table, we've tried to reproduce it using the following sample: http://jsfiddle.net/flexmonster/hef7w94j/, but without success.
Could you please help us to recreate the issue on our side?
Regards,
Ian
⋅ November 30, 2018
Hi Ian, Thank you for your quick reply.
Indeed with your example I cannot reproduce it. However, if I change the proxyUrl to our local server, the empty behaviour reappears. Are you sure the olap.flexmonster.com:8086 has caching disabled? I believe the disable caching is related to this issue.
To be sure it was nothing on our side, I downloaded the latest mondrian accellerator and ran it from a new directory. To see how I ran it and with which config, please see attached accelerator.txt.
I used the following fiddle which basically is yours, but only changed the proxyUrl: http://jsfiddle.net/hef7w94j/16/ . To reproduce the behaviour, just refresh it a few times until it happens (I get it almost every time). See screenshot.
But easier is this fiddle in which I made a button. Every second instance shows as empty for me: http://jsfiddle.net/hef7w94j/18/
⋅ November 30, 2018
see attached screenshot mentioned in previous reply
⋅ November 30, 2018
Hello, Martijn,
Thank you for providing more explanations. It really helped us to reproduce the issue on our side. Our development team will fix the issue and release an update on January the 2nd.
Please let me know in case of other questions.
Regards,
Tanya
⋅ January 3, 2019
Hello, Martijn,
We are glad to inform you that the version with the fix has already been released.
You are welcome to update the component.
Please note that you will also need to update the accelerator.
Let us know if everything works fine for you.
Regards,
Dmytro
