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 <bogle...@vmware.com> Sent: Wednesday, March 30, 2022 6:31 PM To: dev@geode.apache.org <dev@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 <alberto.go...@est.tech> Sent: Wednesday, March 30, 2022 4:35 AM To: dev@geode.apache.org <dev@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 <alberto.go...@est.tech> Sent: Thursday, March 24, 2022 4:29 PM To: dev@geode.apache.org <dev@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.
