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','
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 expectat
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
@ignite.apache.org
Subject: RE: REST GridCacheCommandHandler writes ERROR in log in caseofbaduser
input
I think that the error detected in the server’s SQL engine is INFO or even
DEBUG – for the server it is just a normal workflow.
At the same time the error needs to be propagated to the client
.
Stan
From: Ilya Kasnacheev
Sent: 20 декабря 2018 г. 17:25
To: dev@ignite.apache.org
Subject: Re: REST GridCacheCommandHandler writes ERROR in log in caseofbaduser
input
Hello!
We often rely on server nodes' logs since there is always possibility that
client will swallow our error, especially
