You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Alberto Gomez <al...@est.tech> on 2022/03/24 15:29:03 UTC
[PROPOSAL] Remove warning logs from FunctionException
Hi,
Regarding how to implement a Function in Apache Geode and coding the execute method, 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.
For the above reasons, I would like to propose to change the level of these messages to debug level. A configuration parameter to enable this possibility could be provided for backward compatibility.
Please, feel free to comment on this proposal.
Thanks,
Alberto
[1] https://geode.apache.org/docs/guide/114/developing/function_exec/function_execution.html
[2] https://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/execute/FunctionException.html
Re: [PROPOSAL] Remove warning logs from FunctionException
Posted by Kirk Lund <kl...@apache.org>.
Hi Alberto,
I don't really know if this change is good or bad but I do have some
thoughts about logging and changing behavior like this.
First off, we might think about whether or not logging these warnings is
currently expected behavior. Would removing/changing it cause surprise for
any users upgrading to the version that removes it? Would it make things
more difficult for the vendor or Apache Geode to provide support to a user
having issues in FunctionExecution?
It might make more sense to refactor the code that issues these warnings to
use a pluggable mechanism for handling exceptions and error conditions in
FunctionExecution? For example, you might consider introducing an SPI for a
new FunctionExecutionErrorHandler. The default implementation would log the
exceptions at warning level. Since it's an SPI (using Java Service Loader
to load an implementation), you could provide your own implementation that
does anything you want in response, including the possibility of logging it
at debug level instead of warning.
This also highlights a bigger issue in Apache Geode. There has never been a
policy or even set of recommendations on the logging performed by Geode
classes and components. There is also no standard or recommendations for
formatting or wording of log statements. I believe the issue involving
exception logging in FunctionExecution is a direct result of this. Geode
needs detailed guidelines about log levels, log statement wording,
inclusion of exception stacks, use of Markers, etc. Not just per class, but
probably per Geode component or service or layer as well. Geode also needs
some devs to spend time experimenting with specifying custom log4j2.xml
configuration files, finding usability problems and hopefully improving how
this currently works so that it becomes easy for users to customize what
information is actually being logged.
For example, there are problems with how Log4j is currently used by Geode
such as using Markers at TRACE or DEBUG levels instead of at INFO level --
in order to enable Marker controlled logging, one would have to set the
log-level to DEBUG and then also enable the Marker. Since we know DEBUG
level already produces too much logging (much of it useless noise), this
just exacerbates the problem when what is really wanted is well-behaved,
consistent INFO level logging AND the ability to enable Marked controlled
logging without having to use a finer log-level. It's possible the solution
to Marker usage in Geode is to move Marker controlled log statements to
INFO level. That way you could leave the logging at INFO level and just
enable one or more Markers to increase logging from specific areas.
I primarily wanted to point out that you may be trying to address a smaller
part of the real problem here and that you should always consider pluggable
mechanisms for customizing behavior rather than just considering changes
that would directly alter the current behavior. Also, remember to think
about whether a change like this would be best in a major, minor or patch
release. Some users or the devs supporting them may rely on this
information (I'm not saying they do in this case, just that it's possible).
Thanks,
Kirk
On Thu, Apr 28, 2022 at 3:00 AM Alberto Gomez <al...@est.tech>
wrote:
> Hi Barry,
>
> If the exception is returned by passing it to the ResultCollector's
> sendException() method then the exception is not logged. If the exception
> is returned by passing it to the lastResult() method then the exception
> (and the stack trace) is logged. I am assuming that when you say that the
> exception is returned in its result is done by means of the sendException()
> method.
>
> I agree with you that Geode must be consistent and if an exception is
> thrown by the function, then the exception should be logged no matter if
> isHA is returning false or true. Like you, I have also observed that when
> isHA is returning false the exception is not logged.
>
> I also think it is worth to at least make this logging of the exception
> configurable for those cases where functions prefer to throw the exception
> instead of sending it and still do not want to see those exceptions logged.
>
> Thanks,
>
> Alberto
> ________________________________
> From: Barry Oglesby <bo...@vmware.com>
> Sent: Thursday, April 28, 2022 2:32 AM
> To: Alberto Gomez <al...@est.tech>; dev@geode.apache.org <
> dev@geode.apache.org>
> Subject: Re: [PROPOSAL] Remove warning logs from FunctionException
>
> A function can throw an exception and can also return an exception in its
> result. I'm not sure I've seen too many functions where throwing an
> exception is the expected result. In my very quick testing, I see the
> exception and stack logged if the exception is thrown by the function but
> not if the exception is returned. Are you seeing that same behavior, or are
> both cases logging the exception? I also see the behavior you described
> where isHA returning false does not log the exception. I guess I would say
> if an exception is thrown in either case, it should be logged. If it is
> returned in the result, it shouldn't.
>
> ________________________________
> From: Alberto Gomez <al...@est.tech>
> Sent: Tuesday, April 5, 2022 4:03 AM
> To: dev@geode.apache.org <de...@geode.apache.org>; Barry Oglesby <
> boglesby@vmware.com>
> Subject: Re: [PROPOSAL] Remove warning logs from FunctionException
>
>
> ⚠ External Email
>
> Thanks for your proposal, Juan.
>
> I still think that it makes sense to remove these warning logs altogether.
> Even if the stack trace is removed, the amount of logs could still be huge
> if the operations received is high and the percentage of exceptions
> significant.
>
> One more factor to add to this discussion is that these warning logs are
> only generated if the function is HA. If the function returns false to
> isHA() then the log does not appear.
>
> I would say this is one more reason in favor of removing these logs so
> that the system is consistent.
>
> @Barrett Oglesby<ma...@vmware.com> are you still in favor of
> keeping these warning logs?
>
> More opinions on this topic are very welcome in order to be able to decide.
>
> Thanks,
>
> Alberto
> ________________________________
> From: Ju@N <ju...@gmail.com>
> Sent: Wednesday, March 30, 2022 7:04 PM
> To: dev@geode.apache.org <de...@geode.apache.org>
> Subject: Re: [PROPOSAL] Remove warning logs from FunctionException
>
> Hello all,
>
> What about something in the middle?: log a WARNING level message stating
> that the Function named XXX failed and also log the details (including the
> stack trace) using DEBUG log level?. This would reduce the amount of logs
> for functions that fail frequently, and will also allow the person
> troubleshooting/debugging issues to easily tell that something is wrong
> with function XXX.
> Cheers.
>
>
>
> On Wed, 30 Mar 2022 at 17:52, Jacob Barrett <ja...@vmware.com> wrote:
>
> >
> >
> > On Mar 30, 2022, at 9:45 AM, Alberto Gomez <alberto.gomez@est.tech
> <mailto:
> > alberto.gomez@est.tech>> wrote:
> >
> > The idea would not be to remove the logs but rather to change the level
> of
> > these logs from warning to debug level.
> >
> > I agree, if any exception is expected as part user provided action it
> > should not produce verbose logging.
> >
> > -Jake
> >
> >
>
> --
> Ju@N
>
> ________________________________
>
> ⚠ External Email: This email originated from outside of the organization.
> Do not click links or open attachments unless you recognize the sender.
>
Re: [PROPOSAL] Remove warning logs from FunctionException
Posted by Alberto Gomez <al...@est.tech>.
Hi Barry,
If the exception is returned by passing it to the ResultCollector's sendException() method then the exception is not logged. If the exception is returned by passing it to the lastResult() method then the exception (and the stack trace) is logged. I am assuming that when you say that the exception is returned in its result is done by means of the sendException() method.
I agree with you that Geode must be consistent and if an exception is thrown by the function, then the exception should be logged no matter if isHA is returning false or true. Like you, I have also observed that when isHA is returning false the exception is not logged.
I also think it is worth to at least make this logging of the exception configurable for those cases where functions prefer to throw the exception instead of sending it and still do not want to see those exceptions logged.
Thanks,
Alberto
________________________________
From: Barry Oglesby <bo...@vmware.com>
Sent: Thursday, April 28, 2022 2:32 AM
To: Alberto Gomez <al...@est.tech>; dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: [PROPOSAL] Remove warning logs from FunctionException
A function can throw an exception and can also return an exception in its result. I'm not sure I've seen too many functions where throwing an exception is the expected result. In my very quick testing, I see the exception and stack logged if the exception is thrown by the function but not if the exception is returned. Are you seeing that same behavior, or are both cases logging the exception? I also see the behavior you described where isHA returning false does not log the exception. I guess I would say if an exception is thrown in either case, it should be logged. If it is returned in the result, it shouldn't.
________________________________
From: Alberto Gomez <al...@est.tech>
Sent: Tuesday, April 5, 2022 4:03 AM
To: dev@geode.apache.org <de...@geode.apache.org>; Barry Oglesby <bo...@vmware.com>
Subject: Re: [PROPOSAL] Remove warning logs from FunctionException
⚠ External Email
Thanks for your proposal, Juan.
I still think that it makes sense to remove these warning logs altogether. Even if the stack trace is removed, the amount of logs could still be huge if the operations received is high and the percentage of exceptions significant.
One more factor to add to this discussion is that these warning logs are only generated if the function is HA. If the function returns false to isHA() then the log does not appear.
I would say this is one more reason in favor of removing these logs so that the system is consistent.
@Barrett Oglesby<ma...@vmware.com> are you still in favor of keeping these warning logs?
More opinions on this topic are very welcome in order to be able to decide.
Thanks,
Alberto
________________________________
From: Ju@N <ju...@gmail.com>
Sent: Wednesday, March 30, 2022 7:04 PM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: [PROPOSAL] Remove warning logs from FunctionException
Hello all,
What about something in the middle?: log a WARNING level message stating
that the Function named XXX failed and also log the details (including the
stack trace) using DEBUG log level?. This would reduce the amount of logs
for functions that fail frequently, and will also allow the person
troubleshooting/debugging issues to easily tell that something is wrong
with function XXX.
Cheers.
On Wed, 30 Mar 2022 at 17:52, Jacob Barrett <ja...@vmware.com> wrote:
>
>
> On Mar 30, 2022, at 9:45 AM, Alberto Gomez <alberto.gomez@est.tech<mailto:
> alberto.gomez@est.tech>> wrote:
>
> The idea would not be to remove the logs but rather to change the level of
> these logs from warning to debug level.
>
> I agree, if any exception is expected as part user provided action it
> should not produce verbose logging.
>
> -Jake
>
>
--
Ju@N
________________________________
⚠ External Email: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender.
Re: [PROPOSAL] Remove warning logs from FunctionException
Posted by Barry Oglesby <bo...@vmware.com>.
A function can throw an exception and can also return an exception in its result. I'm not sure I've seen too many functions where throwing an exception is the expected result. In my very quick testing, I see the exception and stack logged if the exception is thrown by the function but not if the exception is returned. Are you seeing that same behavior, or are both cases logging the exception? I also see the behavior you described where isHA returning false does not log the exception. I guess I would say if an exception is thrown in either case, it should be logged. If it is returned in the result, it shouldn't.
________________________________
From: Alberto Gomez <al...@est.tech>
Sent: Tuesday, April 5, 2022 4:03 AM
To: dev@geode.apache.org <de...@geode.apache.org>; Barry Oglesby <bo...@vmware.com>
Subject: Re: [PROPOSAL] Remove warning logs from FunctionException
⚠ External Email
Thanks for your proposal, Juan.
I still think that it makes sense to remove these warning logs altogether. Even if the stack trace is removed, the amount of logs could still be huge if the operations received is high and the percentage of exceptions significant.
One more factor to add to this discussion is that these warning logs are only generated if the function is HA. If the function returns false to isHA() then the log does not appear.
I would say this is one more reason in favor of removing these logs so that the system is consistent.
@Barrett Oglesby<ma...@vmware.com> are you still in favor of keeping these warning logs?
More opinions on this topic are very welcome in order to be able to decide.
Thanks,
Alberto
________________________________
From: Ju@N <ju...@gmail.com>
Sent: Wednesday, March 30, 2022 7:04 PM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: [PROPOSAL] Remove warning logs from FunctionException
Hello all,
What about something in the middle?: log a WARNING level message stating
that the Function named XXX failed and also log the details (including the
stack trace) using DEBUG log level?. This would reduce the amount of logs
for functions that fail frequently, and will also allow the person
troubleshooting/debugging issues to easily tell that something is wrong
with function XXX.
Cheers.
On Wed, 30 Mar 2022 at 17:52, Jacob Barrett <ja...@vmware.com> wrote:
>
>
> On Mar 30, 2022, at 9:45 AM, Alberto Gomez <alberto.gomez@est.tech<mailto:
> alberto.gomez@est.tech>> wrote:
>
> The idea would not be to remove the logs but rather to change the level of
> these logs from warning to debug level.
>
> I agree, if any exception is expected as part user provided action it
> should not produce verbose logging.
>
> -Jake
>
>
--
Ju@N
________________________________
⚠ External Email: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender.
Re: [PROPOSAL] Remove warning logs from FunctionException
Posted by Alberto Gomez <al...@est.tech>.
Thanks for your proposal, Juan.
I still think that it makes sense to remove these warning logs altogether. Even if the stack trace is removed, the amount of logs could still be huge if the operations received is high and the percentage of exceptions significant.
One more factor to add to this discussion is that these warning logs are only generated if the function is HA. If the function returns false to isHA() then the log does not appear.
I would say this is one more reason in favor of removing these logs so that the system is consistent.
@Barrett Oglesby<ma...@vmware.com> are you still in favor of keeping these warning logs?
More opinions on this topic are very welcome in order to be able to decide.
Thanks,
Alberto
________________________________
From: Ju@N <ju...@gmail.com>
Sent: Wednesday, March 30, 2022 7:04 PM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: [PROPOSAL] Remove warning logs from FunctionException
Hello all,
What about something in the middle?: log a WARNING level message stating
that the Function named XXX failed and also log the details (including the
stack trace) using DEBUG log level?. This would reduce the amount of logs
for functions that fail frequently, and will also allow the person
troubleshooting/debugging issues to easily tell that something is wrong
with function XXX.
Cheers.
On Wed, 30 Mar 2022 at 17:52, Jacob Barrett <ja...@vmware.com> wrote:
>
>
> On Mar 30, 2022, at 9:45 AM, Alberto Gomez <alberto.gomez@est.tech<mailto:
> alberto.gomez@est.tech>> wrote:
>
> The idea would not be to remove the logs but rather to change the level of
> these logs from warning to debug level.
>
> I agree, if any exception is expected as part user provided action it
> should not produce verbose logging.
>
> -Jake
>
>
--
Ju@N
Re: [PROPOSAL] Remove warning logs from FunctionException
Posted by "Ju@N" <ju...@gmail.com>.
Hello all,
What about something in the middle?: log a WARNING level message stating
that the Function named XXX failed and also log the details (including the
stack trace) using DEBUG log level?. This would reduce the amount of logs
for functions that fail frequently, and will also allow the person
troubleshooting/debugging issues to easily tell that something is wrong
with function XXX.
Cheers.
On Wed, 30 Mar 2022 at 17:52, Jacob Barrett <ja...@vmware.com> wrote:
>
>
> On Mar 30, 2022, at 9:45 AM, Alberto Gomez <alberto.gomez@est.tech<mailto:
> alberto.gomez@est.tech>> wrote:
>
> The idea would not be to remove the logs but rather to change the level of
> these logs from warning to debug level.
>
> I agree, if any exception is expected as part user provided action it
> should not produce verbose logging.
>
> -Jake
>
>
--
Ju@N
Re: [PROPOSAL] Remove warning logs from FunctionException
Posted by Jacob Barrett <ja...@vmware.com>.
On Mar 30, 2022, at 9:45 AM, Alberto Gomez <al...@est.tech>> wrote:
The idea would not be to remove the logs but rather to change the level of these logs from warning to debug level.
I agree, if any exception is expected as part user provided action it should not produce verbose logging.
-Jake
Re: [PROPOSAL] Remove warning logs from FunctionException
Posted by Alberto Gomez <al...@est.tech>.
Thanks for your answer, Barry.
The idea would not be to remove the logs but rather to change the level of these logs from warning to debug level.
Given that according to the Geode documentation, FunctionExceptions are part of the "contract" between the execute methods and Geode, I think that Geode getting a FunctionException from an execute method is nothing out of the ordinary, so there is no reason for Geode to log it with a warning message; Geode should just "transmit the exception back to the caller as if it had been thrown on the calling side" (I'm quoting from the Geode docs).
I agree that for debugging purposes it is great to have as much information as possible. But the amount of information comes at a cost and that's the reason why normally in production debug logs are not activated.
Alberto
________________________________
From: Barry Oglesby <bo...@vmware.com>
Sent: Wednesday, March 30, 2022 6:31 PM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: [PROPOSAL] Remove warning logs from FunctionException
I guess I would vote for not removing any information from a server log file that might be useful for debugging purposes. That would include exceptions occurring functions.
________________________________
From: Alberto Gomez <al...@est.tech>
Sent: Wednesday, March 30, 2022 4:35 AM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: [PROPOSAL] Remove warning logs from FunctionException
⚠ External Email
Hi all,
I have not received any feedback on this proposal so far.
Does anybody have anything against it? Otherwise, I would like to proceed with the implementation of it.
Thanks,
Alberto
________________________________
From: Alberto Gomez <al...@est.tech>
Sent: Thursday, March 24, 2022 4:29 PM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: [PROPOSAL] Remove warning logs from FunctionException
Hi,
Regarding how to implement a Function in Apache Geode and coding the execute method, 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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgeode.apache.org%2Freleases%2Flatest%2Fjavadoc%2Forg%2Fapache%2Fgeode%2Fcache%2Fexecute%2FFunctionException.html&data=04%7C01%7Cboglesby%40vmware.com%7C80f0e02fe7e5412f910508da12416e95%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637842369486109461%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=tmj3jxYHzDUFCfK07I%2BiL9u2Ie4dluvlp4m%2FsCulnZk%3D&reserved=0> 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.
For the above reasons, I would like to propose to change the level of these messages to debug level. A configuration parameter to enable this possibility could be provided for backward compatibility.
Please, feel free to comment on this proposal.
Thanks,
Alberto
[1] https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgeode.apache.org%2Fdocs%2Fguide%2F114%2Fdeveloping%2Ffunction_exec%2Ffunction_execution.html&data=04%7C01%7Cboglesby%40vmware.com%7C80f0e02fe7e5412f910508da12416e95%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637842369486109461%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=S4uw77glRhcgSGereSnxbrxPoyEQaJXNeKmHCc8D%2BFw%3D&reserved=0
[2] https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgeode.apache.org%2Freleases%2Flatest%2Fjavadoc%2Forg%2Fapache%2Fgeode%2Fcache%2Fexecute%2FFunctionException.html&data=04%7C01%7Cboglesby%40vmware.com%7C80f0e02fe7e5412f910508da12416e95%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637842369486109461%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=tmj3jxYHzDUFCfK07I%2BiL9u2Ie4dluvlp4m%2FsCulnZk%3D&reserved=0
________________________________
⚠ External Email: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender.
Re: [PROPOSAL] Remove warning logs from FunctionException
Posted by Barry Oglesby <bo...@vmware.com>.
I guess I would vote for not removing any information from a server log file that might be useful for debugging purposes. That would include exceptions occurring functions.
________________________________
From: Alberto Gomez <al...@est.tech>
Sent: Wednesday, March 30, 2022 4:35 AM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: [PROPOSAL] Remove warning logs from FunctionException
⚠ External Email
Hi all,
I have not received any feedback on this proposal so far.
Does anybody have anything against it? Otherwise, I would like to proceed with the implementation of it.
Thanks,
Alberto
________________________________
From: Alberto Gomez <al...@est.tech>
Sent: Thursday, March 24, 2022 4:29 PM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: [PROPOSAL] Remove warning logs from FunctionException
Hi,
Regarding how to implement a Function in Apache Geode and coding the execute method, 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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgeode.apache.org%2Freleases%2Flatest%2Fjavadoc%2Forg%2Fapache%2Fgeode%2Fcache%2Fexecute%2FFunctionException.html&data=04%7C01%7Cboglesby%40vmware.com%7C80f0e02fe7e5412f910508da12416e95%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637842369486109461%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=tmj3jxYHzDUFCfK07I%2BiL9u2Ie4dluvlp4m%2FsCulnZk%3D&reserved=0> 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.
For the above reasons, I would like to propose to change the level of these messages to debug level. A configuration parameter to enable this possibility could be provided for backward compatibility.
Please, feel free to comment on this proposal.
Thanks,
Alberto
[1] https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgeode.apache.org%2Fdocs%2Fguide%2F114%2Fdeveloping%2Ffunction_exec%2Ffunction_execution.html&data=04%7C01%7Cboglesby%40vmware.com%7C80f0e02fe7e5412f910508da12416e95%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637842369486109461%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=S4uw77glRhcgSGereSnxbrxPoyEQaJXNeKmHCc8D%2BFw%3D&reserved=0
[2] https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgeode.apache.org%2Freleases%2Flatest%2Fjavadoc%2Forg%2Fapache%2Fgeode%2Fcache%2Fexecute%2FFunctionException.html&data=04%7C01%7Cboglesby%40vmware.com%7C80f0e02fe7e5412f910508da12416e95%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637842369486109461%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=tmj3jxYHzDUFCfK07I%2BiL9u2Ie4dluvlp4m%2FsCulnZk%3D&reserved=0
________________________________
⚠ External Email: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender.
Re: [PROPOSAL] Remove warning logs from FunctionException
Posted by Alberto Gomez <al...@est.tech>.
Hi all,
I have not received any feedback on this proposal so far.
Does anybody have anything against it? Otherwise, I would like to proceed with the implementation of it.
Thanks,
Alberto
________________________________
From: Alberto Gomez <al...@est.tech>
Sent: Thursday, March 24, 2022 4:29 PM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: [PROPOSAL] Remove warning logs from FunctionException
Hi,
Regarding how to implement a Function in Apache Geode and coding the execute method, 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.
For the above reasons, I would like to propose to change the level of these messages to debug level. A configuration parameter to enable this possibility could be provided for backward compatibility.
Please, feel free to comment on this proposal.
Thanks,
Alberto
[1] https://geode.apache.org/docs/guide/114/developing/function_exec/function_execution.html
[2] https://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/execute/FunctionException.html