Open gregpakes opened 5 years ago
The only way I am able to get initialization with CacheInitParams to work in a web application is to make sure that there is a config.ncconf file in either:
I do not want to use either method as they don't work for me. I thought the whole point of the CacheInitParams was so that you could programatically initialize the cache?
Hi Greg,
CacheInitParams is used to programmatically populate only the client.ncconf parameters when initializing the cache from the client side. These parameters determine how the client will contact and coordinate with the server. Parameters that are set up for the server-side processes such as backing source providers setup, cache events, dynamic compact serialization etc. are in the config.ncconf file, even if the cache is in-proc. These parameters are not included in the CacheInitParams class definition. As such, for both in-proc as well as out-proc cache server processes, you need to have the config.ncconf file and there is no programmatic approach from the application side.
More information about the NCache configuration files can be found at the following link:
http://www.alachisoft.com/resources/docs/ncache/admin-guide/configure-files.html
I believe I have figured this out.
The NCache initialization seems to rely on the presence of HttpContext.Current in order to look in the root of the web application for the config file. See here:
If HttpContext.Current is null then it will not look for the config in the web application.
In my case, I am using StructureMap Dependency Injection container and I am initialising the my container (and therefore the cache) using the PreApplicationStartMethod
[assembly: PreApplicationStartMethod(typeof(StructuremapConfig), "Start")]
In this case, the start method is called without HttpContext.Current and therefore the cache will fail to initialise.
I believe that this is a bug and looking for the presence of a non-null HttpContext.Current to determine whether you are in a web application is sub-optimal.
In addition to the scenario I have outlined above, another scenario that will also fail is an application with SignalR.
If the first request to the application is made to SignalR, there will be no HttpContext.Current and the initialisation of the cache will fail.
This is only an issue if you have the config files bundled with your application.
It is a bug, nevertheless.
This highlights the exact issue and provides a solution:
https://stackoverflow.com/questions/3179716/how-determine-if-application-is-web-application#3179845
Hi Greg,
Thanks for the heads-up. I will convey to engineering your feedback.
Thanks.
Just so you know, this is a blocker for me. I am evaluating NCache in our product.
Hi Greg,
I have talked with engineering about the points you've raised and if you can provide us with a code sample showing how exactly your web application structure is set up and how NCache is being called, we'll work on it on our end and communicate with you on the matter.
You can send the application code solution to support@alachisoft.com and we'll take it from there.
I have posted an example here:
I think this might solve https://github.com/Alachisoft/NCache/issues/32 too
Hi Greg,
First of all, thanks for bringing this to our attention. I have conveyed all the information you have provided to engineering and from the initial discussions I have had with them, they will review the problem and work on it.
I will follow the progress and once I have something concrete to get back to you with, I will let you know.
Hi Greg,
Thanks for sharing all the details around this issue as it helped us a lot in order to review and fix it. This issue is fixed now and changes are committed on NCache Opensource branch nc-4.9-SP1 (commit id: f78eea8bcb057e6cef0c4f76daaeeb3c86a9a10c [f78eea8]).
According to the updated logic dealing with finding NCache config files for web applications, NCache configuration files are now searched as follows step by step and stops searching when it finds them:
1) Root folder of the web application at the same tier as the web.config file 2) In the Web_app bin\config folder 3) In the Web_app\bin folder 4) inetrsrv (In case of IIS Deployment) 5) NCache config folder in the NCache installation directory (In case of NCache installation)
So, in summary, if you have your config files at the web application level (1,2 and 3), search won't continue to the insertsrv (IIS server level) and NCache directories. This should resolve your requirements.
Hi Greg,
I have prepared a NuGet package for the patch that you can use for object caching that I am attaching with this thread. Please note that if you are going to use other NCache NuGets such as for NHibernate, SessionState etc. then please do let me know so I can work on getting patches for those as well since the current NCache NuGets for those integrations from nuget.org will not work with this patch. We will be rolling out NCache v5.0 soon and I can confirm that the scenarios you pointed out will be resolved. So thanks for the input.
IMPORTANT: Please make sure to clear the old NCache sdk from the .nuget folder before using the new NuGet package I am attaching.
This is great. Thanks so much - it unblocks me.
I will test it out and if I have any issues I will come back here.
Thanks again!
Hi,
I am trying to run NCache through a web application using an InProc cache mode. In this configuration, I don't see a need for the NCache Server portion (happy to be enlightened here). However, I simply can't get this to work.
I have tried using the CacheInitParams, but no matter what I try, it only works when there is an NCache Server present.
This is in contrast to my unit tests, where I simply put a config.ncconf file in the project and it works exactly how I would expect with no server running.
thanks