How to print debug statments in Giraph - cloudera

I find the below statement before print log statement.
if (LOG.isDebugEnabled())
How can we enable or disable debug statements when running a Giraph program?
And where can one find the logs of these statements?

Setting the custom argument
-ca
giraph.logLevel=debug
Should do the work

To access the logs try something like
yarn logs --applicationId application_1399469361545_0003
where you can find the application ID in the console output.

Related

Minecraft console get wrong commands

I started a local server and want to add some simple commands with python, the server is running with forge 1.12 and a couple of mods.
My idea was it to catch wrong commands and send the right result instead.
An easy test command would be /echo Hello World with the result in the chat Hello World.
To get the command I am using the last line of the latest console log file, which is equal to the current console content. But in the console I cant read wrong commands. So if I run the echo command I get an message in the chat Unknown command. Try /help for a list of commands.
I think there could be two solutions:
Add in any register the command to get it in the console, prevent on this way the server to response and get the command in the console to use it.
Find a config to print also wrong commands in the console.
Thanks for helping
There is no way to 'cancel' commands through API, but there is a trick to effectively cancel commands anyways. You want to be listening to the Forge CommandEvent, modifying the command to another existing command that does nothing (you can create one yourself). This gives you a place to handle all commands (you'll have to filter for unexisting commands, otherwise you'd cancel all commands), and it will prevent the Unknown Command message from showing.

TDWALLETERROR(543): Teradata Wallet error. The helper process is already being traced

When I start my jobs using fast export they sometimes end with an error:
TDWALLETERROR(543): Teradata Wallet error. The helper process is already being traced
When I restart them, they work.
I'm using saved-key protection scheme.
Can someone explain to me why is that error occuring and how to fix it?
Looks like you have a trace activated in one of the scripts, run in the system.
Teradata has a shiffer code that attempts to validate if tracing is running during the wallet invocation - which triggers this error.

Print to console with Jetty

I am creating a simple Jetty server and am wondering how to print something into the console, like variables at specific times or when a user connects. I am compiling the Jetty server with a java class with jetty-all jar files. I am not using any xml currently. Could anyone tell me how to print something into the console? Such as, when a user connects say, "User connected"
Thanks.
You better should output to a log file, you could use log4j for that.
Use
LOGGER.info("user connected");
on linux you then can use
tail -f logfile.log
to live output the content to the console

Aviarc Debug command not working?

I've been trying to send some strings out to a file somewhere to help with testing, by doing something like:
<debug text="This is a test"/>
But I can't find where it outputs to. I've been looking in the aviarc-server.[date].log file, not sure where else it would go.
The command outputs at INFO level - what is your log level set to? You can change the log level setting in the Admin application under Server Configuration. It is set to WARN by default. You can also use the Realtime Log feature from the Admin app to see tail the log within the browser.

Return Codes from PeopleCode Exec Function

I am attempting to kick off a third party program using EXEC command in PeopleSoft. It is returning error code 127. When I kick the program off from Unix command line, I get no error. Does anybody know what code 127 is? Or have a list of all the return codes?
I think it is likely the Unix shell return code, in which case 127 is "command not found".
See http://tldp.org/LDP/abs/html/exitcodes.html
You may need to make sure your Exec call is specifying the correct path, relative or absolute, or that any expected environment variables are available. Possibly test with a simple program to see if calling through Exec is successful at all. On the server it would run under the ID that started the app server, and may be sourced differently than an individual user. If using relative paths I believe it would start in $PS_HOME.
If you can provide the code snippet someone may be able to also provide other suggestions.

Resources