I am running cluster machine in Virtual Box in domain, by default service is running under Network service , service stopped all the time with the following error in the event log.
please find the error details from error log below. any help will be great.
Log Name: System
Source: Service Control Manager
Date: 21-07-2010 16:42:07
Event ID: 7034
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer:
Description:
The AppFabric Caching Service service terminated unexpectedly. It has done this 5 time(s).
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Service Control Manager" Guid="{555908D1-A6D7-4695-8E1E-26931D2012F4}" EventSourceName="Service Control Manager" />
<EventID Qualifiers="49152">7034</EventID>
<Version>0</Version>
<Level>2</Level>
<Task>0</Task>
<Opcode>0</Opcode>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2010-07-21T14:42:07.000Z" />
<EventRecordID>13342</EventRecordID>
<Correlation />
<Execution ProcessID="0" ThreadID="0" />
<Channel>System</Channel>
<Computer>
<Security />
</System>
<EventData>
<Data Name="param1">AppFabric Caching Service</Data>
<Data Name="param2">5</Data>
</EventData>
</Event>
thanks for the support.
kazim
There is no much information in the above error to guess what went wrong. Try to take a look at events right before this particular event (maybe there will be hint/warning about something). Another thing might be not to look only at a regular eventlog Windows Logs > Application but also at eventlog Applications and Services Logs > Microsoft > Application Server-System Services.
[Resolved]
I got the same issue. Couldn't find a definite answer anywhere. However after looking at all the configurations and connections, I figured out the root cause.
For information, in my case, I was using a SQL Configuration.
The issue was that my AppFabric database was not part of a cluster and availability group which it should have been actually. Once I added it to the availability group and after it got replicated in all the SQL nodes, I re-configured app fabric on the cache servers (using configure app fabric tool) and stopped and started my cache cluster again.
This time, everything worked as expected.
Hope this helps you too!
P.S.: I'm not sure if the "reconfiguring app fabric using the tool" is a mandatory step. I just did it from my side. Perhaps you can try stopping and starting the cache cluster without doing this. Do let me know in case it is not mandatory so that I can update this answer accordingly.
Agreed with David that there is not much one could make out of this log entry.
Another thing worth checking would be to make sure that your configuration is available to AppFabric services. May it be an xml or SQL based configuration provider, AppFabric services should be able to access it. This is the most common reason of crashing services at the load time.
You can very easily check this by running your appFabric configuration wizard.
Related
I wrote microservices using spring boot. some time showing its active in status and sometimes showing inactive, I can't understand the behaviour of microservice and how can debug it
Have you tested running the microservice locally?
I've been getting inconsistent reports from the status tab in the UI. Sometimes it says the service is down when it's actually up. I check the /health endpoint to be sure(it's not available right after you upload the zip, takes 5-6 minutes).
The logs in the UI are a bit clunky, so I've added a rolling file appender to logback.xml and a rest endpoint to expose the log file for debugging.
Try to override health check timeout value (timeoutSeconds property of Probe). By default it's 1 second and it's often not enough. Please refer our specification: https://cumulocity.com/guides/reference/microservice-manifest/
In the administration application you will find the status details for each of your applications.
When the status is switching all the time probably the docker container is terminating all the time (probably because the application is crashing). You should the that on the status tab of the application in the event log (container is restarted all the time).
If you are on the newest Cumulocity version (9.19.x) you should also have access to the logs of the microservice at the same place in UI. You need to log to stdout in order to be able to get the logs through administration application.
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 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.
All WSDLs I have seen so far, use localhost to describe the services address. e.g.:
<wsdl:service name="SQLService">
<wsdl:port name="SQLServiceSoap" binding="tns:SQLServiceSoap">
<soap:address location="http://localhost:8080/rservice/services/SQLServiceSoap" />
</wsdl:port>
</wsdl:service>
But when the client of such service is run, it somehow knows where the real URL of that service, even if run on a remote machine!
How does CXF perform this "magic"?
IOW, how does the client JAR on a test machine which is not the machine on which the service runs, know where that server is and its address?
I grep-ed the source code and strings-ed the client's jar file and found no trace whatsoever to the server's URL.
So how does that work?
UPDATE: In my super natural detective efforts, I just found a file named config.xml in the directory where the client's JAR file is located. That config.xml contains the actual server's URL. So it appears that this is how this is done in the particular case of the project I inherited.
Now the question(s) is:
Is this the standard way of doing this?
Is there a standard (or recommended way) at all in CXF?
Or is it pretty much left to the developer to decide?
In many cases, the web service will have a production URL and a test/QA/UAT URL. The developer will develop against the test URL, and then once it's ready for production he will switch the URL to point to production.
It is up to the developer to decide how this is accomplished and there is no standard way of handling it.