In the struts documentation they are saying that by setting
<constant name="struts.devMode" value="true" />
This will cause the site to load fastly.
So my question is is it possible to put this constant in live site so that it will load the live site fastly. Is there any problem with that?
Thanks
You took it all wrong,struts.devMode when enabled, acts much friendlier, which can significantly speed up development.
When you have made the devMode=true in your config file this will help you in following steps
Struts 2 will reload your resource bundles on every request (meaning you can change your .properties files, save them, and see the changes reflected on the next request).
It will also reload your xml configuration files (struts.xml), your validation files, etc, on every request. This is useful for testing or finetuning your configuration, without having to redeploy your application every time.
it will raise the level of debug or normally ignorable problems to errors.
In Short it is a weapon for the developer for enhance his development process by figuring out any error, as when enabled it will show yo much friendly and detailed error underlying the cause and any suggestion.
Here are more details for devMode
Struts2 Development mode
It is never recommended to enabled this in your production as enabling this means you are reloading your configuration file /any other property files on each request which will definitely slow down the overall portal.
By default, the development mode is disabled, because it has a significant impact on performance, since the entire configuration will be reloaded on every request.
The development mode is only suitable in a development or debugging environment. In a production environment, you have to disable it. It will cause significant impact on performance, because the entire application configuration and properties files will be reloaded on every request and extra logging and debugging information will also be provided.
Related
I am getting below error when I try to deploy to the azure. I am doing basic hello world app. Can someone please give some insights. I have attached the logs below.
I am using :: Version 1.1.0-beta2
The silos start properly as per the log files but it cant initialize the Client in azure. I am using the below config file in the Client.
<?xml version="1.0" encoding="utf-8" ?>
<!--
This is a sample client configuration file for use by an Azure web role acting as an Orleans client.
The comments illustrate common customizations.
Elements and attributes with no comments should not usually need to be modified.
For a detailed reference, see "Orleans Configuration Reference.html".
-->
<ClientConfiguration xmlns="urn:orleans">
<!--
To turn tracing off, set DefaultTraceLevel="Off" and have no overrides. To see a minimum of messages, set DefaultTraceLevel="Error".
For the trace log file name, {0} is the silo name and {1} is the current time.
Setting WriteTraces to true will cause detailed performance information to be collected and logged about the individual steps in the
message lifecycle. This may be useful debugging performance issues.
-->
<Tracing DefaultTraceLevel="Off" TraceToConsole="false" TraceToFile="{0}-{1}.log" WriteTraces="false">
<!--
To get more detailed application logging, you can change the TraceLevel attribute value to "Verbose" or "Verbose2".
Depending on the log levels you have used in your code, this will cause additional messages to be written to the log.
-->
<TraceLevelOverride LogPrefix="Application" TraceLevel="Info" />
</Tracing>
</ClientConfiguration>
PS::
I figured it out after enabling the fusion logs. I could see 1 dll was not loaded properly. The issue is fixed.
You should be using AzureClient. It handles all configuration automatically.
Please refer to https://github.com/dotnet/orleans/tree/master/Samples/AzureWebSample and follow the same setup as there. The best way is to close that AzureWebSample and add your own grains and logic.
What version of Orleans are you using? If you included http://www.nuget.org/packages/Microsoft.Orleans.Templates.Interfaces/ in the project, the invoker class should have been generated at compile time. Try cleaning up Properties\orleans.codegen.cs files and rebuilding the project.
I'm creating a simple MVC CMS for which I need a first time run configuration (to set up the database and admin user account, etc.).
The setup screen will ask them for the database connection string, so at first run, there is no knowledge of a database store.
How would I detect that this is the first time the application is being run, and take them to that setup screen?
Should I put a setting in the web.config with an initial value of false:
<add key="SetupComplete" value="false" />
And once the setup is complete, I can change it via:
ConfigurationManager.AppSettings.Set("SetupComplete", "True");
The downfall of this method is that, if the application is restarted, the config value will default to "false". What is a good solution to this problem?
Many PHP CMS doing the same thing you want to do, as it is the initial setup it would be OK that the admin change this value manually or you simply check the existence of a file which must be deleted manually.
As it is IIS app I would build a deployment package, so you can setup the the initial settings during the installation process, which is the common way for IIS apps I think.
In the past, I implemented a custom SettingsProvider (an example is here and here). Special care was taken regarding security, ensuring keys are encrypted. The samples isn't perfect. You can use the Application Settings provided by Visual Studio and .NET 2.0 to store settings in the format (e.g. xml) and location of your choosing (e.g. AppData).
It is a tad more secure than allowing your application to modify your web.config, since doing the latter means you have to elevate the privileges of your process which may be rather dangerous when your application is exposed on the internet.
It also simplify backups and upgrades.
I'm using Microsoft's Web Deploy Remote Agent service to allow me to easily publish code to the server from within Visual Studio.
The web site I am deploying is using log4net to log messages to log files, and every time I try to deploy a new version of the code, I get this error in Visual Studio stating that the current log4net log file is in use:
An error occurred when the request was processed on the remote
computer. The file 'Web.log' is in use.
The process cannot access 'C:\inetpub\wwwroot\Logs\Web.log' because it
is being used by another process.
I can solve this by going onto the server and doing an iisreset before publishing... but that is kind of defeating the point of 'easy' publishing from Visual Studio :)
Is there some way I can get the publish task to issue an iisreset automatically, or some other way I can work round this?
I kept poking around and found some tidbits around the file being locked in a few other forums. Have you tried adding
<lockingModel type="log4net.Appender.FileAppender+MinimalLock" />
To your <appender> element in the web.config file? From the Apache docs
Opens the file once for each AcquireLock/ReleaseLock cycle,
thus holding the lock for the minimal amount of time. This method of
locking is considerably slower than FileAppender.ExclusiveLock but
allows other processes to move/delete the log file whilst logging
continues.
As far as the performance considerations, I suppose you would need to test if this will affect you or not as I am assuming it really depends on how often you are writing to the log file as to how much this will impact performance. I can't believe that getting/releasing a lock could take all that much time though.
There is a MSDEPLOY provider called recycleApp which is used exactly for this. You can include this in your deployment manifest.
Another option is to use ignoreOnErrors flag which will skip the file in use and continue with the deployment.
We have four different environments - dev VMs, dev, QA and prod. All environments have the following setting for the "website" site:
<site name="website" virtualFolder="/" physicalFolder="/"
rootPath="/sitecore/content" startItem="/home" database="master"
domain="extranet" allowDebug="true" cacheHtml="false"
htmlCacheSize="10MB" registryCacheSize="0" viewStateCacheSize="0"
xslCacheSize="5MB" filteredItemsCacheSize="2MB" enablePreview="true"
enableWebEdit="true" enableDebugger="true"
disableClientData="false" loginPage="/" hostName="www.site.com"
enableFallback="true" enforceVersionPresence="true"/>.
So on VM and prod, www.site.com/en/home/press and www.site.com/en/press work.
But on dev and QA, www.site.com/en/home/press works but www.site.com/en/press doesn't work. (Works with startItem but gets a 404 without it).
This is happening with ISAPI enabled and disabled both (no exceptions).
I am not sure what is going on here or where else to look except to make sure that my start item is in good shape which it seems to be.
What can I do to resolve this? If you need more information please let me know.
Thanks
Try looking at the:
"linkManager" tag in the web.config, there is a property called:
languageEmbedding: asNeeded | always | never
which could be set differently on those solutiuons.
If you have Multi-Language website it is recommended to go with
languageEmbedding: always
Advantages :
Some time in IE8 the Language cookie is destroyed, because of that
the language displayed is change randomly.(We have faced this issue
in our environment) LanguageEmbadding : Always will keep the Information and will work without any Issue.
If you have set asNeeded then First time the Language will be displayed and next time onward it will be hidden. But this will create issue with Google Analytics. In GA you will have 2 diff URL with same page content so your analysis will be unnecessarily divided in to 2 pages.
And Yes you can check if there is any difference is Config files. As Mentioned by Martijn you can use the www.site.com/sitecore/admin/showconfig.aspx Copy the Config, compare it using any file compare tool like WinMerge etc.
What is the Hierarchy in your project?
Sitecore-Content-home-Press or
Sitecore-Content-home-Home-Press?
In my project the setting you have mentioned has database = web.
I can't add a comment, but as Martijn says you need to compare the configs. Now this should be very easy since you should be using config include files and so the changes between the environments should be very minimal. If you are not using them then you should start using them, it makes life much easier to figure out the differences from default Sitecore installation and will also make your upgrades much easier in the future. Or maybe you are using them for the other environments and that is what is causing the issue?
All About web.config Include Files with the Sitecore ASP.NET CMS
As for comparing the configs, use a file comparison tool like WinMerge as already metioned, that should weed out the differences much more easily.
Also, as Maulik says, default config has: database="web" content="master"
This seems like config differences. Compare the live configs by using www.site.com/sitecore/admin/showconfig.aspx. This way you can see the actual config which also includes all your /app_config/include/ files
I've set up some log4net logging on an asp.net mvc application i've had running for a little over a month now.
I've set up rolling file (and smtp) appender on it.
The application is hit several thousand times a day - alot of actions are logged. On top of these a number of batch jobs are run as part of the application that also write to the log.
Now - as i've been occupied with other work, i've not attended to this application much assuming things to be working based on my test setup.
Unfortunately i discover that the rolling file appender on my production server seems to be skipping every other day.
Ie i have logs :
10/4/2010,
10/4/2010.1,
10/4/2010.2,
12/4/2010,
12/4/2010.1 ,
14/4/2010,
14/4/2010.1
etc.
Any idea what could be causing this? It is absolutely impossible that there has no action on these odd days for the lifetime of the application.
Cheers
If your batch jobs are writing to the same files as the asp.net mvc app, then it might be a locking issue. Make sure that you have the minimal lock setting in all of your config files.