[CDRIVER-503] debug messages Created: 12/Jan/15  Updated: 11/Sep/19  Resolved: 28/Aug/15

Status: Closed
Project: C Driver
Component/s: docs
Affects Version/s: None
Fix Version/s: 1.2-beta1

Type: Task Priority: Major - P3
Reporter: John Page Assignee: Unassigned
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

How do I stop the debug messages from the C driver
I compiled it with configure --no-debugging but that didnt work.

2015/01/12 17:44:14.0105: [27912]: DEBUG: cluster: Client initialized in direct mode.



 Comments   
Comment by Hannes Magnusson [ 28/Aug/15 ]

Improved the docs for 1.2, and the original message is no longer an issue in 1.2.

I consider this ticket to be fixed now.

Comment by Githook User [ 28/Aug/15 ]

Author:

{u'username': u'bjori', u'name': u'Hannes Magnusson', u'email': u'bjori@php.net'}

Message: CDRIVER-794: document mongoc_log_trace_enable / disable

Also touch on CDRIVER-503 by noting how to disable all logging
Branch: 1.2.0-dev
https://github.com/mongodb/mongo-c-driver/commit/8005ba530be1debfa56cd566d0c84802fe104d35

Comment by A. Jesse Jiryu Davis [ 05/Aug/15 ]

We'll silence DEBUG-level messages by default in 1.3, and improve documentation for how to silence or redirect log messages.

Comment by A. Jesse Jiryu Davis [ 05/Aug/15 ]

The "unexpected" message is a minor bug: the driver (correctly) considers any connection string with multiple hosts and no "replicaSet" option to be a list of mongoses, but it (incorrectly) logs a warning if the connection string has a single host that is discovered to be a mongos, rather than a mongod. As Hannes said, this will be fixed when we release 1.2, which implements the Server Discovery And Monitoring Spec and has a rigorously defined set of expectations about your server topology:

http://blog.mongodb.org/post/99058181018/announcing-the-server-discovery-and-monitoring

Comment by John Page [ 05/Aug/15 ]

I think info and debug should go nowhere unless asked. Critical, error and warning should possibly go to standarderror but I'd rather enforce creating or at least enabling the error handler/level.

C is about getting a failure return code and requesting the error message, not about handling exceptions (unless you want to start raising signals of course)

I'm more curious why it puts out info on connecting to a shared cluster that it's 'unexpected' what's unexpected about it.

Comment by Hannes Magnusson [ 05/Aug/15 ]

Are you suggesting that the default log handler should be NULL? I'm not opposed that idea.. Not sure if that constitutes as a BC break though?
In that case, what do you suggest we handle CRITICAL/ERROR/WARNING messages?

The 1.2 branch implements the SDAM spec, so the topology discovery assumptions and expectations – along with the messaging – is completely different, so this should already be fixed there.

Comment by John Page [ 05/Aug/15 ]

For me C means following UNIX principles and Info messages should have to be explicitly requested - I don't NEED to know them.

Equally - what should I do when connecting to a sharded cluster so it doesn't tell me? How can I tell the C driver this is a Sharded cluster so it doesn't get a surprised and IS expecting it.

Comment by Hannes Magnusson [ 30/Jul/15 ]

john.page Thats really two different things.

The debug message (MONGOC_LOG_LEVEL_DEBUG) does indeed feel awkward to print in builds without --enable-debug.
Similar to MONGOC_LOG_LEVEL_TRACE, it should only be printed in --enable-debug builds.

As for

"connect to a sharded cluster telling me its not expecting it!"

, this is a MONGOC_LOG_LEVEL_INFO message.

MONGOC_LOG_LEVEL_MESSAGE, MONGOC_LOG_LEVEL_WARNING, MONGOC_LOG_LEVEL_CRITICAL, and MONGOC_LOG_LEVEL_ERROR should however be issued as normal.

The default log handler mongoc provides writes MONGOC_LOG_LEVEL_ERROR, MONGOC_LOG_LEVEL_CRITICAL & MONGOC_LOG_LEVEL_WARNING to stderr, while the other log levels are written to stdout.

I highly suggest you provide your own log handler to catch/store/write these message and act on the CIRITICAL and ERROR levels at the very least.
At the moment though.. We only issue MONGOC_LOG_LEVEL_ERROR when we fail to initialize SSL, in which case I imagine a world of weird errors when establishing connection......
CRITICAL is currently never issued.

Btw, that "Client initialized in direct mode" is no longer in 1.2+

Comment by A. Jesse Jiryu Davis [ 13/Jul/15 ]

This will be fixed, with clear instructions, in the next minor release.

Comment by John Page [ 13/Jul/15 ]

That seems strange default behaviour, none of the other drivers randomly emit info messages as far as I can see. The most annoying is it complaining if I connect to a sharded cluster telling me its not expecting it!

Comment by Mira Carey [ 25/Feb/15 ]

Hi,

Disabling logging messages for libmongoc is somewhat cumbersome. The trick is to define an empty log handler to pass to mongoc_log_set_handler()

void        mongoc_log_set_handler     (mongoc_log_func_t   log_func,
                                        void               *user_data);
 
/* The type for log_func_t : */
typedef void (*mongoc_log_func_t) (mongoc_log_level_t  log_level,
                                   const char         *log_domain,
                                   const char         *message,
                                   void               *user_data);

I'll make a point of adding to the api documentation to make that more clear in the future.

Regards,
Jason

Comment by Chengcheng Pei [ 12/Jan/15 ]

Yes, I also need to disable the debugging messages. but I have no idea how to.

Generated at Wed Feb 07 21:09:42 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.