[
https://issues.apache.org/jira/browse/GEODE-10231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleksii Sitnianskyi updated GEODE-10231:
----------------------------------------
Description:
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}
was:
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.
The improvement for server side logging is adding system property configuration
for surprising FunctionException logging.
Property example:
{code}
gemfire.logging.suppressFunctionExceptionLogging=true
{code}
> 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.1#820001)
