[
https://issues.apache.org/jira/browse/GEODE-10231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18021410#comment-18021410
]
Bryan Behrenshausen commented on GEODE-10231:
---------------------------------------------
Understood. Thanks, [~jinwoo]! We'll try to track down someone capable of
merging.
> Add configuration for suppressing FunctionException logging
> -----------------------------------------------------------
>
> Key: GEODE-10231
> URL: https://issues.apache.org/jira/browse/GEODE-10231
> Project: Geode
> Issue Type: Improvement
> Components: client/server, functions
> Reporter: Oleksii Sitnianskyi
> Assignee: Oleksii Sitnianskyi
> Priority: Major
> Labels: pull-request-available
>
> According to Apache Geode function implementation, the following is stated in
> [1]:
> "To propagate an error condition or exception back to the caller of the
> function, throw a FunctionException from the execute method. Geode transmits
> the
> exception back to the caller as if it had been thrown on the calling side. See
> the Java API documentation for
> FunctionException<[https://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/execute/FunctionException.html]>
> for more information."
> And as per [2]:
> "if a GemFire client executes a Function on a server, and the function's
> execute
> method throws a FunctionException, the server logs the exception as a warning,
> and transmits it back to the calling client, which throws it"
> So, for every FunctionException thrown by a user Server Function, the server
> logs the exception with the corresponding stack trace.
> This could imply, depending on the logic implemented in the user Server
> Function, that the log of the server is packed with these messages (which
> probably are not providing extra useful information given that the exception
> will reach the client), and making it difficult to analyze the logs to find
> other relevant events.
> Given that Apache Geode recommends the use of FunctionException as the means
> to
> propagate an error condition or exception back to the caller, we could argue
> if
> a FunctionException thrown by a user Function should have any reflection, at
> all, in the server logs. Besides, as said before, depending on the amount of
> the
> exceptions generated, this can complicate the analysis of log files, require
> much more space for logs storage and have a negative impact in performance.
> Solution:
> Add Log4j markers for all FunctionException logs to be able to handle them by
> Log4j filter configuration, eg. disable all function exception logs:
> {code:java}
> <MarkerFilter marker="FUNCTION_EXCEPTION_MARKER" onMatch="DENY"
> onMismatch="NEUTRAL"/> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
