[
https://issues.apache.org/jira/browse/ZOOKEEPER-2969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Travis Gockel updated ZOOKEEPER-2969:
-------------------------------------
Description:
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.
was:
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.
> 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.2, 3.5.3, 3.6.0
> Reporter: Travis Gockel
> Priority: Minor
> 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)
