Restricting users' access when using the Accelerator

Hello Dmytro,
thanks for your answer, build a proxy in my MVC/WebAPI and just redirect authenticated requests to Accelerator endpoint which will be available only locally was one on mine ideas. If you have integration of endpoint to ASP.NET it would be great if you could provide me the DLL, otherwise I think I will manage to write my own solution...
Regards,
Lukas

Hi Guys,
This is absolutely amazing, thanks a lot! I think this way - a DLL that can be referenced directly from the ASP.NET project and used without Accelerator installation - should be preferred way how to distribute the Accelerator. It makes our live much easier - no checking if prerequisites are installed, no running of Accelerator installers, easy update to newest version, no firewall settings, no service dependencies etc.
Thanks a lot once again!
Regards,
Lukas

I have just found one issue, which is probably also exists when I use Accelerator as a service...
When I open the Connect -> To OLAP dialog, it sends a request to my API endpoint which contains SOAP body. There are two issues - there is no defined default action for /api/endpoint/ , I have tried to set default to Handshake, but still it does not expect SOAP content and fails on some NullReferenceException.
But even when I have accelerator running and I fill http://localhost:50005 to the Proxy URL, it does not load list of Catalogs/Cubes, the HTTP response just returns a message that accelerator is running.
It's low priority, ideal case would be if we could change just the cube - catalog and Proxy URL should be hardcoded. For now we can do our custom function for that... 

Hello Tanya, 
Thanks for the reply. Adding API calls would be nice, however it's just a medium priority for now and adding support for Accelerator in the dialog is a low priority - we can write custom dialog for that.
Regards,
Lukas

Hi,
I have found one issue that causes us occasional errors - FlexmonsterProxyController is not thread safe. You have there static dictionaries like cachedAllMembers which can be accessed from multiple threads (multiple controllers - one per each request) and you are using regular Dictionary without locking. It can be quite easily fixed by changing it to ConcurrentDictionary...
If you want, I can rewrite it for you, if you send me the source code of FlexmonsterProxyController. Right now I have just decompiled version. I can fix it there, because I will have to fix it anyways before our go-live, but the merge to your version would be more complicated for you from decompiled version.
Regards,
Lukas

Hello Tanya,
Ok, thank you.
Regards,
Lukas

Hello guys,
Any chance that this issue will be fixed until 28th August? Our release is coming, so I would just like to know if we can count with the fix or not...
Regards,
Lukas

Hi Tanya,
Sorry for late reply, I did not get notification that you have replied...
Awesome, I would just need to get a Flexmonster.Accelerator.Core.dll which is not part of standard distribution - previously Ian added it to the sample that is linked above. 
The second thing I'm worried about is if 2.4 accelerator is working with 2.3 component - we do not plan to upgrade to 2.4 for this our release.
Regards,
Lukas

Hi Ian,
Thank you for DLL. However there are still issues and it's not fully working for me. I have looked yesterday into the code of FlexmonsterProxyController and I have probably understood how it works and applied an intermediary fix to the decompiled version...

• There are still normal Dictionaries in the controller, it has been fixed just for CacheManager, but it's probably not a big deal, the main issue I had was somewhere else...
• The dictionaries dataChunkFromIndex and dataChunkTotalRows are used to hold data between requests (to allow chunk processing), but the key can't distinguish the requests, imaging this scenario:
  • Two clients are requesting same report which is currently not in the cache (or cache is not used at all)
  • First request manages to process chunk 0 and 1 and starts processing chunk 2
  • Second request comes, data are not in the cache yet. Second request is starting the main part of Execute method and is processing chunk 0. It puts in these dictionaries data for chunk 0
  • First request while processing chunk 2 is trying to read data which stored in the dictionary in chunk 1, however they have been overwritten by second request and it reads data for chunk 0 instead.
  • In that case I was getting empty report body, in the worst case this incorrect result make it to the cache and we are getting empty reports forever.

The solution I have applied to your decompiled code is that in these dictionaries I'm using two keys:

• keyWithPrevuiousChunk = key + (args.chunkIndex-1) for reading
• keyWithCurrentChunk = key +args.chunkIndex for writing

So I have there e.g. 
dataChunkFromIndex[keyWithCurrentChunk] = dataChunkFromIndex[keyWithPrevuiousChunk] + num2;
Assuming that the data stored in these dictionaries are the same for the same chunks from different requests, the requests are potentially still overwriting the data across requests but with the same values. I'm just not removing these values when the processing is finished because I don't know if another request that is still being processed will need them or not. Also while writing this post it brings me to the question if the order of chunks (that chunk 0 is always processed before chunk 1 etc.) is guaranteed for one request, but I expect it is...
Also I have one suggestion for improvement in CacheManager. You have there method ContainsKey, which enumerates the whole dictionary and uses Equals on each item:
public bool ContainsKey(object key)
{
foreach (object key1 in (IEnumerable<object>) this.cache.Keys)
{
if (key1.Equals(key))
return true;
}
return false;
}
Which is pretty inefficient from performance point of view, you are loosing the advantage of dictionary that it can get item by the key very fast. If you would just pass it to underlying dictionary 
public bool ContainsKey(object key)
{
this.cache.ContainsKey(key);
}
It will behave the same, but it will be just much faster on large dictionaries. Or you can use TryAdd/TryGet methods on (Concurrent)Dictionary and you don't need ContainsKey at all and also you will get rid of dictionary double lookup issue.
Regards,
Lukas

Hello Ian,
You can find the FlexmonsterProxyController and CacheManager here - https://vistaentertainment-my.sharepoint.com/personal/lukas_navratil_vista_co/_layouts/15/guestaccess.aspx?folderid=113885a50d4f64a87a8756cb354d74262-fm&authkey=AfmeE0rEfLeMuL9uj-emQ1M . But it's from decompiled code (without having corresponding PDB file), so it can be quite difficult for you to apply the same changes - there are dummy variable names, there are strange casts and other constructs that decompiler has produced. I believe I can do the same changes again if I would give me the original code, it can be from 2.4 branch.
In the CacheManager I have removed the ContainsKey method and I have modified little bit the Cache limit - changed it from amount of memory to number of items. I just wanted to avoid so many calls of GC.Collect in our solution, because your controller is now sharing the same memory space with our app, and there can be a lot of memory allocated. It's just an interim solution... Ideal case would be if you could make the cacheManager as protected in the controller and change it to interface. In that case we could change the implementation of the cache in our controller which inherits from your controller. But probably we could still live with your CacheManager... 
Regards,
Lukas