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 <bogle...@vmware.com>
Sent: Thursday, April 28, 2022 2:32 AM
To: Alberto Gomez <alberto.go...@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 <alberto.go...@est.tech>
Sent: Tuesday, April 5, 2022 4:03 AM
To: dev@geode.apache.org <dev@geode.apache.org>; Barry Oglesby 
<bogle...@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<mailto:bogle...@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 <jujora...@gmail.com>
Sent: Wednesday, March 30, 2022 7:04 PM
To: dev@geode.apache.org <dev@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 <jabarr...@vmware.com> wrote:

>
>
> On Mar 30, 2022, at 9:45 AM, Alberto Gomez <alberto.go...@est.tech<mailto:
> alberto.go...@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.

Reply via email to