You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When the data types change on the DB side without restarting the hakunapi service, for example a datetime->date change on a column will trigger above error in resultset parsing, but this is not indicated by HTTP 5xx status code.
The text was updated successfully, but these errors were encountered:
This is due to the current streaming implementation. I think we could change the logic so that we first buffer a set of features before commiting to writing 200 OK (e.g. change BufferedResultSet to eagerly fetch the first batch of features, not lazily during first call to hasNext() so that we fail before any bytes are written to the OutputStream provided to us by the JAX-RS impl). That might do the trick depending on how the JAX-RS implementation acts. Otherwise it's bit larger change to the logic: we'd have to buffer the serialization phase by trying to write first n bytes to memory before returning Response.ok() to the JAX-RS implementation. Still doable though.
The error might occur when writing nth feature so it's difficult to determine the right amount of buffering. One megabyte might solve most problems but not all.
Also the highlighted issue might not be something hakunapi even aims to support (handling changes in sources after startup). Obviously it might be difficult to recognize these sorts of errors if service monitoring is configured to just check the status code. Not sure what would be correct move here.
When the data types change on the DB side without restarting the hakunapi service, for example a datetime->date change on a column will trigger above error in resultset parsing, but this is not indicated by HTTP 5xx status code.
The text was updated successfully, but these errors were encountered: