Re: REST GridCacheCommandHandler writes ERROR in log in caseofbaduser input

[Ilya Kasnacheev <il...@gmail.com>]

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 <ag...@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/
>

Re: REST GridCacheCommandHandler writes ERROR in log in caseofbaduser input

[Ilya Kasnacheev <il...@gmail.com>]

Hello!

I have found one more relevant case:

[17:03:16,141][SEVERE][jdbc-request-handler-worker-#78][JdbcRequestHandler]
Failed to execute SQL query [reqId=0, req=JdbcQueryExecuteRequest
[schemaName=PUBLIC, pageSize=1024, maxRows=0, sqlQry=merge INTO
city2(id,name,name1) VALUES(2,'1','1'),(1,'1','1'), args=[],
stmtType=UPDATE_STMT_TYPE, autoCommit=true]]
class org.apache.ignite.internal.processors.query.IgniteSQLException:
Cannot serialize transaction due to write conflict (transaction is marked
for rollback)
        at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.serializationError(GridCacheMapEntry.java:6759)
        at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.mvccSet(GridCacheMapEntry.java:1117)

MVCC update conflicts are entirely normal, and will never be a case of
concern of DevOps since they are recoverable (just retry the statement or
batch).

There's no reason for such SEVERE log level. This one should only merit an
INFO.

Regards,
-- 
Ilya Kasnacheev


пт, 11 янв. 2019 г. в 19:26, Ilya Kasnacheev <il...@gmail.com>:

> 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 <ag...@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/
>>
>