Remove stdout log capture
Bug #802396 reported by
Lars Butler
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenQuake (deprecated) |
Fix Released
|
Medium
|
Mattia Barbon |
Bug Description
Recently, we revised our logging methods to capture (in a unified fashion) logging info from Python stdout, Python logging, Java stdout, and Java logging. The unified logging is good, but I think we should not be capturing stdout. Here's why:
If you run the OQ engine with cProfile, all of the nice cProfile formatted output is destroyed and gets turned into logging messages.
To reproduce, run this:
$ python -m cProfile bin/openquake --config_
Changed in openquake: | |
milestone: | none → 0.4.3 |
Changed in openquake: | |
status: | Confirmed → In Progress |
assignee: | nobody → Mattia Barbon (mattia.barbon) |
Changed in openquake: | |
status: | In Progress → Fix Committed |
Changed in openquake: | |
status: | Fix Committed → Fix Released |
To post a comment you must log in.
I agree, capturing stdout make lots of stuff messy (another example is using
the pdb debugger).
The current situation was intended as an intermediate step anyway, with the aim
of using rabbitmq for logging eventually.
I think we are very close: after landing /github. com/gem/ openquake/ pull/150 and /github. com/gem/ openquake/ pull/304 all the logging output will be going
https:/
https:/
through the logging modules of python and java (no more prints to stdout).
Sending the output to rabbitmq will be a matter of configuring the logging
modules to use the proper backend.
For log4j I found this http:// github. com/jbrisbin/ vcloud/ tree/master/ amqp-appender/
and for python this http:// notes.variogr. am/post/ 143623387/ broadcasting- your-logs- with-rabbitmq- and-python .
BTW pull request https:/ /github. com/gem/ openquake/ pull/150 is actually just
removing some obsoleted files. These files have been modified in the meantime,
making the automatic merge impossible. The gist of the pull request would be
on the other hand really easy to replicate, with a simple rm. Thus I suggest
landing 304 and then open another pull request to remove the files, without
bothering with 150 anymore.