does EL Logging have a troubleshooting tool like Nlog internal log? - enterprise-library

NLog has an internal log that the developer can use to troubleshoot issues with logging. Does Enterprise Library Logging have anything like that that I can use to figure out why my log messages aren't going anywhere?

There's a "Logging Errors and Warnings" special category. If there's a problem with the logging infrastructure itself, it'll get logged there. You can point this at any trace listener - by default it goes to the Windows event log.
Of course, if you have a problem with the trace listener for the errors, things get lost. There's only so many turtles you can stack on this one.

Related

How to enable gRPC logging for akka.grpc?

Unsure if I have done the right thing. I found this link : https://doc.akka.io/docs/akka-grpc/current/client/configuration.html#debug-logging and followed the steps exactly but do not see any "FINE" logging being printed on the console. I don't see any stream-like data being printed on my console. In my application I have a couple of libraries which invoke GRPC calls to external services and I'd like to enable debugging so I can see the output being received.
Is there something else I need to do?

jBoss is hanging at "Loading profile..." output line

I am trying to start a jBoss 5.1.0.GA instance and the output console is hanging on the [ProfileServiceBootstrap] Loading profile: ProfileKey#3f5f852e[domain=default, server=default, name=default] line.
The jBoss instance is copied from a remote server on which it works well.
There is not so much work logged (no more than 50 rows) and No error is displayed in console while starting up.
I understand that there may be some dependencies/connections/etc that it needs and are not satisfied, but I would expect an error to be thrown. Instead, it only hangs, without any other issue being reported.
I hope that this message will sound familiar to others that have worked more with older versions of jBoss and may direct me to investigate potential root causes.
Not proud of my findings... :) the issue was in fact that the logs were set not to write into the console. So, after looking for other log files, I found that the server started with the very well known statement Started in 1m:21s:836ms...
It is not really an issue nor an answer, but I leave this here in case others will find themselves in the same "I do not see the logs" situation (which should be also the title).
Note: in order logs to be shown, I have modified /server/default/conf/jboss-log4j.xml

"Exception code: C0000005 ACCESS_VIOLATION" in progress application, application terminated

Progress application terminated during execution. Here is the protrace:
Exception code: C0000005 ACCESS_VIOLATION
Fault address: 101DA9BF 01:001D99BF C:\Ultra\dlc91e\bin\prow32.dll
How to find what program caused this issue? Is there any way to debug and find the problematic code?
If it was a 4gl session that crashed there should be a "procore" or a "protrace" file in the working directory of the session that crashed. It might also be in the temp directory (specified with the -T startup parameter).
If you can find the protrace file it has a 4gl stack trace which ought to tell you where the problem originated.
Some notes here:
9.1e is truly ancient. But still Progress has a history of supporting older versions a long time. It's actually set to be "retired" October 2015.
So if you have an active license you shouldn't hesitate to contact support.
There's also the knowledgebase to search. I found this that might be something similar. First of all you should think of all things that have changed since the system worked (file system layouts, installation of software like antivirus and firewalls, operating system upgrades, security changes etc etc).
Knowledge base home: http://knowledgebase.progress.com/.
I never use the internal search, I always Google with:
site:knowledgebase.progress.com

error 404 on hitting http://<host>:8080/cs/REST/

I had successfully configured Oracle webcenter on some of my VM.
To access it from my local machine I did some changes in firewell setting.
Then after the home page is not accessible and i get 404 error.
i.e.,
http://:8080/cs/REST/ is not accessible where as some other REST URLs are accessible such as :
http://:8080/cs/REST/types/
http://:8080/cs/REST/sites/
http://:8080/cs/REST/sites/FirstSiteII/
I think something wrong with my asset type configuration. How to resolve?
Any idea would work for me.
You should be looking at log files which can be generated by the content server.
The “View Server Output” menu provides access to the most recent server output logs.
Iirc, you can set different levels of tracing and you should select the option(s) which are relevant to you issue - otherwise the trace log file will generate a huge amount of text - much of it irrelevant to you & making it particularly hard to read.
The log file is timestamped but it would be better served if you have a single-user make a single attempt to land on your URL(s).
Server output also contains tracing output if enabled. Tracing is typically enabled while
debugging errors. If server output is being captured in a file, the file could grow large if tracing options are enabled. Consider disabling all server tracing options (especially if “verbose” option is checked), to keep server output file size in check.
I don't believe that there's anything served at /cs/REST/ - what would you expect to see?

AppFabric Resume command failure

In AppFabric we see some suspended workflows. When we try manually to resume them we get error:
There was no endpoint listening at net.pipe://[server]/[webSite]/[folder]/[workflowFile].xamlx/System.ServiceModel.Activities_IWorkflowInstanceManagement that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details.
What could be the reason for this error? Where should be this endpoint defined?
This could be the result of net.pipe not being enabled on the site or application (bindings). If you enable full WCF diagnostic tracing you will see what the underlying problem is.
It can also be the result of a messed up config file. I once had to explicitly add the workflow control endpoint to the config myself.