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.
Related
I'm trying to configure a Topshelf-based Windows service to log to a custom event log using Topshelf.Log4Net and log4net. This works fine if I run the application in command-line mode. When I try to install the service with BillsTestService.exe install, I get:
INFO Topshelf v3.1.107.0, .NET Framework v4.0.30319.18052
DEBUG Attempting to install 'BillsTestService'
Running a transacted installation.
...
Service BillsTestService has been successfully installed.
Creating EventLog source BillsTestService in log Application...
An exception occurred during the Install phase.
System.ArgumentException: Source BillsTestService already exists on the local computer.
...
at System.Diagnostics.EventLog.CreateEventSource(EventSourceCreationData sourceData)
I've tried running EventLog.DeleteEventSource("BillsTestService"); in LINQPad before installing; that succeeds, but a subsequent service install still fails.
My log4net appender configuration is:
<appender name="ErrorEventLogAppender" type="log4net.Appender.EventLogAppender" >
<threshold value="ERROR" />
<logName value="MyCompanyServices" />
<applicationName value="BillsTestService" />
<layout type="log4net.Layout.PatternLayout">
<conversionPattern value="%-5level %logger - %message%newline" />
</layout>
</appender>
What am I doing wrong?
The intent is to have multiple services log errors to the same log name (with different application names); the log would be created by Operations.
Part of the issue is that Topshelf automatically creates an eventlog source named after the service when you install. Since the log4net appender applicationName is also used as an eventlog source, that cannot be the actual application/service name. The source must be unique on the local computer. I added a "Source" suffix to the name in the log4net configuration.
The other part is that the service does not have rights to create the log. It can create a new source, but not a new log. One way to do this is in code (I used LINQPad):
EventLog.CreateEventSource("FOODEBUG", "MyCoSvc");
EventLog mylog = new EventLog("MyCoSvc");
mylog.Source = "FOODEBUG";
mylog.WriteEntry("This is a test.");
EventLog.DeleteEventSource("FOODEBUG");
I'm not positive if you actually have to write to the log to create it; after spending over two days on this, I'd rather be safe.
Also note that log names are limited to 8 characters; you can go longer, but the system only considers the first 8 characters as significant.
There's no need to move the log4net initialization as Chris Patterson suggested. Simply including
configurator.DependsOnEventLog();
configurator.UseLog4Net("MyService.exe.config");
in the HostFactory.Run delegate is sufficient. (I'm using Topshelf.Log4Net.)
Finally, I'm reasonably sure that the entire Windows event logging system is flaky. Event Viewer's refresh doesn't work in all cases, at one point my Application log entries disappeared, and I believe I've seen different results after a reboot.
Move your log4net initialization to the ConstructUsing() configuration delegate for the service instead of specifying for use during install/uninstall which doesn't require the service class to be instantiated.
Or, only use the event log appender when the actual service is running, by either adding the appender outside of the config file or modifying the configuration to eliminate the event log appender unless an ERROR or FATAL event occurs.
My guess is the DEBUG/INFO level events are trying to log to the appender, and the source does not exist yet.
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.
Quite not sure why I see this error.
I navigate to my Login View like so http://test.staging.com/mywebsite/Login
My Login view was just redone using MVC but I have seen this same error message going to an aspx page as well...
If I use http I get the error message The specified request cannot be executed from current Application Pool.
If I use https://test.staging.com/mywebsite/Login, I'm good.
If I don't specify a protocol, test.staging.com/mywebsite/Login, I get the error as well
Is there an error happening under the covers and my custom error page can't be shown like discussed here?
What are some other causes of this error?
That usually means your custom errors are configured to run as a different AppPool.
You can read more at MSDN. (See section "Using Custom Errors from Another Application Pool").
There are two ways to correct this behavior. The first is possibly not one that you are interested in because it would require you to change your current architecture and run both sites in the same application pool (such as share the same worker process memory space). To do this, simply move the /errors virtual directory to run in the same application pool as the site for which it serves the custom error.
The second way is to make use of a registry key provided by IIS 6.0. This registry key makes sure IIS 6.0 does not check the metadata during the execution of the custom error and therefore allowing this to work.
See the article for information on the registry key fix.
It may also mean that you are using something along the lines of Server.Transfer to a page that is in a different AppPool.
It could be because you're using different versions of ASP.NET for one or many apps in the pool.
Make sure all apps in the pool use the same version of ASP (e.g. ASP 2.0.50727)
If you just added a new app, try changing the app momentarily to a different version of ASP, then back to same version. I experienced an issue where the displayed version was correct, but under the hood, a different version was used!
Check your event log, under Application, to get more details about the error.
The message would be caused by your page server-side redirecting to a page served by another application pool. Such as for example, in your link, the error page.
I know this is an old thread, but I stumbled upon it and found a different solution. Here's what worked for me: Make sure your application handles .asmx files correctly
From IIS:
Right Click on your project > Properties > Configuration
If necessary, add the .asmx file extension that maps to the aspnet_isapi.dll
Limit to: "GET,HEAD,POST,DEBUG" and restart.
Because I can't comment on vcsjones's answer, I'll add it down here. The DWORD value IgnoreAppPoolForCustomErrors needs to be set under HKLM\SYSTEM\CurrentControlSet\Services\W3SVC\ Parameters vs HKLM\SYSTEM\CurrentControlSet\Services\W3SVC referenced in that technet article. Set it to 1 and do an iisreset and you're good to go.
Source Blog Post
In my particular case, I received this error while trying to serve a content (non ASP.NET) website while it was an Application. Right-Clicking the virtual folder and removing the application fixed it for me.
In my case the application used the application pool that didn't exist. I have no idea how it's happened.
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.
I just started using VS 2010 to create a Cloud Service (HealthTracker), and I attached a MVC2 web project to it. When I hit Debug, the dev fabric was started and I was able to navigate my web app on my machine as expected.
I decided MVCWebRole2 was a bad name for my web app, so I renamed it to HealthTrackerMVC. I used Refactor --> Rename to change MVCWebRole2 to HealthTrackerMVC. I Built clean and now when I hit debug the dev fabric starts, and the web app never starts and eventually it exits debug mode without me doing anything.
How do I fix this? I'd rather not start over with everything...
UPDATE
I have checked the ServiceConfiguration.cscfg, the ServiceDefinition.csdef and the solution file. All the names match, and all the GUIDs match. I even renamed the folder that housed HealthTrackerMVC (formerly named MVCWebRole2) and edited the solution file to point to the new project. Everything loads and builds correctly. The Development Fabric shows HealthTrackerMVC starting, says it's busy, then shuts it down, rather quickly. See the attached screenshot:
So I know my web role is being started... why is it shutting down so quickly?
Check the Azure configuration files, as both reference the role name and I don't belive VS's refactor command hits. If your project is building and the role simply isn't launching, its most likely as a result of the role not knowing what to start.
In ServiceDefinition.csdef
<?xml version="1.0" encoding="utf-8"?>
<ServiceDefinition name="YourAzureService" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition">
<WebRole name="HealthTrackerMVC" vmsize="Small" enableNativeCodeExecution="true">
...
In ServiceConfiguration.cscfg
<?xml version="1.0"?>
<ServiceConfiguration serviceName="YourAzureService" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceConfiguration">
<Role name="HealthTrackerMVC">
...
If that doesn't work, right click on "Roles" under the Cloud Service Project in Solution Explorer. The ADD menu should have an option for "Web Role Project in Solution". Select that and link up your new role. Delete the old role as well at this point
If that still doesn't work, go to the file system where the project is stored and open the .ccproj file (Cloud Service Project) in a text editor.
Look for the reference to the previous role (ccproj are in MSBUILD format). It will be something like:
<ItemGroup>
<ProjectReference Include="Folder\MVCWebRole2.csproj">
<Name>YourAzureService</Name>
<Project>{26f72b59-1423-4175-b401-9c8f5f45db2a}</Project>
<Private>True</Private>
<RoleType>Web</RoleType>
<RoleName>MVCWebRole2</RoleName>
</ProjectReference>
</ItemGroup>
Change references to the new HealthTrackerMVC project (name and .csproj ref) and you should be good to go. Most likely the project GUID hasn't changed, but if somehow it did, just open up the SLN file to get that number.
Once you change on this VS should prompt to reload the Solution/Projects. If not, you should reload anyways.
I recommend to check Web.config and the actual start-up logic (i.e. Azure fabric is known to silently kill web projects with invalid web config without raising any errors; that's something that just made my life exciting a few times).
Just some ideas. For example you can try by starting web project alone (just like a usual project). If it works - drop an existing web role and add a new one to the solution (referencing this web project) and try running it in the dev fabric. If it does not, but web project runs alone - export it to a fresh solution and add to a new web role there.
This is a bit of a long shot, but if you have overwritten the RoleEntryPoint and overwritten the Run method, it should contain something like
public override void Run()
{
while (true)
{
Thread.Sleep(8000);
}
}
If this method ever returns, your application will stop.