[
https://issues.apache.org/jira/browse/ZOOKEEPER-2227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14900138#comment-14900138
]
Chris Nauroth commented on ZOOKEEPER-2227:
------------------------------------------
Thank you again, [~arshad.mohammad].
The change proposed in this comment would be backwards-incompatible with the
functionality that existed before it was broken by the ZOOKEEPER-572 patch,
because it would change the parameter from a binary encoding to a text
encoding. My goal in this patch is to restore the broken functionality in the
3.4 line, not introduce new or different functionality.
I agree that the interface of {{stmk}} is awkward. We could consider a
backwards-incompatible improvement in version 3.5 or later. However, if we're
going to take the leap to a backwards-incompatible change, then I'd favor doing
something even bolder. For example, we could restructure the trace logging
into different Log4J categories, and then support it through dynamic
reconfiguration of Log4J. This is something that would be outside the scope of
this JIRA though, and tracked in a separate JIRA targeted to 3.5 or later.
Honestly, I have to believe almost no one is using {{stmk}} at this point. As
per ZOOKEEPER-2229, it is undocumented, and it has been broken for years. :-)
Even still, ZooKeeper has a formally published backwards-compatibility policy,
and I'd prefer that we stick to it.
https://cwiki.apache.org/confluence/display/ZOOKEEPER/ReleaseManagement
> stmk four-letter word fails execution at server while reading trace mask
> argument.
> ----------------------------------------------------------------------------------
>
> Key: ZOOKEEPER-2227
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2227
> Project: ZooKeeper
> Issue Type: Bug
> Components: server
> Affects Versions: 3.3.0
> Reporter: Chris Nauroth
> Assignee: Chris Nauroth
> Attachments: ZOOKEEPER-2227.001.patch, ZOOKEEPER-2227.002.patch
>
>
> When the server handles the {{stmk}} four-letter word, it attempts to read an
> 8-byte Java {{long}} from the request as the trace mask argument. The read
> fails, because the destination buffer's capacity is only 4 bytes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)