Travis Gockel created ZOOKEEPER-2969:
----------------------------------------
Summary: C API Log Callback Lacks Context
Key: ZOOKEEPER-2969
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2969
Project: ZooKeeper
Issue Type: Bug
Affects Versions: 3.5.3, 3.5.2, 3.6.0
Reporter: Travis Gockel
Attachments: c_log_callback_ext.patch
I have two zhandle_ts connected to two different ZK ensembles. Differentiating
between log messages of the two is quite difficult, as the callback only gives
you the message, with no reasonable way to grab connection that created it (the
address of the handle is in the log message, but parsing this value seems
rather error-prone). It would be nice if the log callback gave me the handle.
I attached a patch for a potential fix...it adds a few functions without
breaking backwards compatibility:
{{typedef void (*log_callback_ext_fn)(const zhandle_t *zh,}}
{{ const void *log_context, ZooLogLevel level, const char
*message);}}{{ZOOAPI void zoo_get_log_callback_ext(const zhandle_t *zh,}}
{{ log_callback_ext_fn *callback, const void **context);}}{{ZOOAPI void
zoo_set_log_callback_ext(zhandle_t *zh,}}
{{ log_callback_ext_fn callback, const void *context);}}{{ZOOAPI zhandle_t
*zookeeper_init3(const char *host, watcher_fn fn,}}
{{ int recv_timeout, const clientid_t *clientid, void *context, int flags,}}
{{ log_callback_ext_fn log_callback, const void *log_callback_context);}}
The fallback ordering is changed to: log_callback_ext_fn -> log_callback_fn ->
global stream.
Let me know if this is completely crazy.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
