Hello! 1. Unfortunately, it's complicated: - With JDBC, we don't really offer complete reasoning for a problem, *especially* if it is Ignite internal problem or expectations mismatch, which is frequent case. - With ODBC, we don't have ways to offer full Java stack trace to client, neither expectations that client will display them anywhere. - With HTTP client will usually disconnect as soon it sees 500 status code, and will swallow error messages even if we had them. - With other platforms' clients I assume we will lose error messages almost always.
In short this will mean that error messages will be unrecovered when people come with their issues but they have default logging. 2. Malfunctioning client is usually a case for alert. Most of Ignite installations are single-purpose, and if there are errors in log there must be problems with this sole purpose. 3. It's hard to remove noise but keep useful information. Maybe we could throttle such messages? We could try and create an IEP about those logging concerns. Regards, -- Ilya Kasnacheev сб, 29 дек. 2018 г. в 13:34, Gerus <age...@gridgain.com>: > I think that this case is serious gap in Ignite maintainability > 1. This is business as usual case and client application can create an > incorrect API call. User error should be returned back to user via the same > API > 2. Exception in the Ignite log file should cause an alert for application > operations. Most common case for monitoring setup is to parse log file in > realtime and create an incident in case if ERROR or Exception is detected. > The only way for admin is to mute the false alert, and > 3. Current approach is adding a lot of noise into the application logs and > significantly increasing logfile size. Taking in account log rotation as a > good practice, we may have less useful information to maintain Ignite > > > > -- > Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/ >
