I've turned on tracing my JavaMail-based application, and I can see the trace, but it looks like garbage because it is in unicode and my machine only knows EBCDIC. Is there anyway I can get the trace to print out with the default encoding for my machine (EBCDIC)? Here is how I activate the trace:
session.setDebug(true);
By default the trace goes to System.out. If System.out isn't converting to EBCDIC, you can create your own PrintStream that does so and use the session.setDebugOut(ps) method to set it.
Related
I want to generate trace for performance log but I don't find where enable the trace.
Checking this documentation page https://help.hcltechsw.com/commerce/9.1.0/admin/refs/rlsperflog_dup.html it's mention that we need to use the following string: com.ibm.commerce.performance=fine.
In Logging and Tracing settings we don't have this class path to enable finest log.
I tried to perform some run command in ts-app like:
run set-dynamic-trace-specification com.ibm.commerce.performance=fine
run set-server-property com.ibm.commerce.performance fine
Keep not seeing the trace file in: WAS_profiledir/logs/performanceTrace.json.
Some tip ?
Best Regards
Document found:
https://help.hcltechsw.com/commerce/9.1.0/admin/tasks/tlslogging_txn.html
Basically, it's activated by PMT logs.
The documentation at https://www.ibm.com/support/knowledgecenter/en/SSEQTP_liberty/com.ibm.websphere.wlp.doc/ae/rwlp_logging.html lists the following config snippet for configuring logs to go to the console in JSON format (a useful configuration when Liberty is running inside a Linux container like in a kubernetes pod):
com.ibm.ws.logging.console.format=json
com.ibm.ws.logging.console.log.level=info
com.ibm.ws.logging.console.source=message,trace,accessLog,ffdc,audit
However, I noticed that when I increase the log level inside my server.xml (say to FINER to enable tracing), the trace messages are also emitted to the console. I assume its because the source is configured to pick up messages from the trace, but what I don't understand is whether/how that interacts with the consoleLogLevel setting.
Why specify a com.ibm.ws.logging.console.log.level if its just going to include everything from message and trace log files anyway?
The com.ibm.ws.logging.console.source bootstrap property controls which sources the console handler will subscribe to. This means, if there is any trace (typically levels FINE / FINER / FINEST) enabled by the traceSpecification, that content will be consumed by the console handler and output as JSON to console.
So, setting...
com.ibm.ws.logging.console.source=message,trace,accessLog,ffdc,audit
means that the console handler will receive any log, trace, access log, ffdc, and audit events that are generated by the system.
If com.ibm.ws.logging.console.log.level is specified, it controls which log events are filtered out by the console handler. By setting com.ibm.ws.logging.console.log.level=WARNING you won't see INFO level messages in the console output unless you also explicitly set consoleLogLevel=info in the server.xml.
Note that logging settings explicitly set in the <logging> element in the server.xml (which is processed when the config manager is ready) override any configuration set using environment variables or the bootstrap.properties file (which are processed very early in the server startup process). In practice this means you should use bootstrap.properties or environment variables for logging configuration, and just use the logging element in the server.xml file to specify things you want to override while the server is running.
I applied Glog to output some runtime information in my code, and I want to disable the stack trace function to protect the detail of the code. But I find the Glog is default to track the stack trace and log it to std err or log file, and there is no FLAGS_xx to disable it.
And I tried to #undef some of the stack trace related macro such as HAVE_STACKTRACE, but it doesn't work.
Do you have any elegant method to do this?
I use the GOOGLE_GLOG_DLL_DECL void InstallFailureFunction(void (*fail_func)()); to install a customized function to output some customized information instead of the stack trace.
But in the std output there is still a line *** Check failure stack trace: *** to remind the user, and I don't know how to shut it down. It's not elegant enough.
I am using PolyML compiler 5.6 Release on Mac OS. I'm compiling and running some code which raises an exception (Fail "undefined"). I am expecting my compiled app to exit with a stack trace when the exception is raised; but instead it exits silently.
How can I get PolyML to show stack traces or at least line numbers where the exception is raised?
Running your application under the debugger is the best way to find out where the exception is happening.
If you can't or don't want to use the debugger you can get line number and source file information by adding a handler and using PolyML.Exception.exceptionLocation to get the location from the exception packet. See http://polyml.org/documentation/Reference/PolyMLException.html
In Poly/ML 5.6 you can also use PolyML.exception_trace to get a trace of the calls that led to the exception but that's likely to be removed in the next release,
I'm using the logstashCollector-1.0 feature on Liberty 16.0.0.3 to collect logs on a ELK stack.
I followed instructions here for the setup:
http://www.ibm.com/support/knowledgecenter/SSAW57_9.0.0/com.ibm.websphere.wlp.nd.doc/ae/cwlp_analytics_collectors.html
All is working well, but I do not have any of the stacktraces I'm logging in the code.
I get the exception message in logstash, but not the stack.
The stack appears in message.log file on the server itself, but are not forwarded by the logstashCollector feature (neither in liberty_trace nor in liberty_message items).
Is there some configuration I can tweak to get the stacktraces, or is it impossible? Not having the stacks is a big showstopper for my devs...
Stack trace was not included to the liberty_message events prior to Liberty 17.0.0.1. There was no server configuration users can set to add this.
In Liberty 17.0.0.1, the stack trace has been appended to the message field of the liberty_message events. No configuration change is required.
See Liberty APAR PI76200 for more details.
HTH