# Client\_write\_error **URL:** \ **Category:** General Discussion\ **Created:** [April 10, 2020, 2:15pm UTC](https://discuss.aerospike.com/t/client-write-error/7320 "2020-04-10T14:15:59Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![Mikhail\_Pryakhin](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.aerospike.com/mikhail_pryakhin/32/1143_2.png) [@Mikhail\_Pryakhin](https://discuss.aerospike.com/u/Mikhail_Pryakhin)\ **Post date:** [April 10, 2020, 2:15pm UTC](https://discuss.aerospike.com/t/client-write-error/7320/1 "2020-04-10T14:15:59Z")
Hello, I’ve got a map operation that attempts to remove an entry from a bin of type Map. In case the record doesn’t exist I contract an exception with error code `ResultCode.KEY_NOT_FOUND_ERROR`. Such a scenario is normally acceptable from my business case perspective, so my app catches the error and proceeds. The only obstacle I face at the moment is a monitoring system which alerts me every time the server-side metric `client_write_error` value increases. According to the [Knowledge Base](https://discuss.aerospike.com/t/understanding-client-write-errors/4442), there are a number of reasons for the metric value to grow. And it would be a bad idea not to monitor its value completely. Is there a way to ask a server not to fail the request when a record doesn’t exist and not to increment the client\_write\_error metric for the cases when I expect the operation to fail? Is there a way to distinguish cases when something goes out of my control (like write\_queue depth exceeded or record too big or stop wrights threshold exceeded etc…) and normal cases when I expect a failure to happen? Would you please recommend the best practices to monitor this metric? Cheers, Mike. ---
**Author:** ![meher](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.aerospike.com/meher/32/1644_2.png) [@meher](https://discuss.aerospike.com/u/meher)\ **Post date:** [April 14, 2020, 11:19pm UTC](https://discuss.aerospike.com/t/client-write-error/7320/2 "2020-04-14T23:19:29Z")
Good question, or I guess questions. As you pointed out, your application should have the most specific error code and message and should be able to distinguish between the different situations (device overload, capacity issue – stop writes, key busy, etc…). So to the question on distinguishing something that is out of control of the app, that should already be in place. Or is there a specific error code/message that is mixing things up? From a monitoring perspective within the server itself, one would have to look at the other metrics you are pointing out (stop\_writes true/false, write\_q metrics, etc…). It would be too expensive (impacting performance) to have specific separate metrics for each individually. Finally, I believe there are client side policies to have some CDT operations not fail but I am not sure whether they would inform whether or not to increase the client\_write\_error metric. We certainly don’t have client policies that would directly inform whether an xxxx\_error metric should be ticked up or not. ---
**Author:** ![Mikhail\_Pryakhin](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.aerospike.com/mikhail_pryakhin/32/1143_2.png) [@Mikhail\_Pryakhin](https://discuss.aerospike.com/u/Mikhail_Pryakhin)\ **Post date:** [April 15, 2020, 10:54am UTC](https://discuss.aerospike.com/t/client-write-error/7320/3 "2020-04-15T10:54:46Z")
Thank you @meher ! Yes, there is no problem whatsoever of distinguishing error codes at the client-side. My main concern was that there was no differentiation between error codes in terms of the `client_write_errors` counter which we are looking at as the main metric to monitor the client to server communication issues. > [@meher](#): > > From a monitoring perspective within the server itself, one would have to look at the other metrics you are pointing out Thank you, seems the be the only option for us. > [@meher](#): > > It would be too expensive (impacting performance) to have specific separate metrics for each individually. I thought it could be enhanced by introducing a hashmap to track `client_write_errors` in context of error codes, allowing an ops engineer to rely on a specific set of codes he/she is interested in, couldn’t it? Like it’s perfectly done for a `write_q` counter which tracks a write queue value in the context of a device. > [@meher](#): > > Finally, I believe there are client side policies to have some CDT operations not fail Unfortunately, there is no way to explicitly pass Flags to [MapOperation#removeByKey](https://github.com/aerospike/aerospike-client-java/blob/7e654cceb01bfdbb6f02009ca8f73b0b950ec73c/client/src/com/aerospike/client/cdt/MapOperation.java#L238) method, unlike [MapOperation#put](https://github.com/aerospike/aerospike-client-java/blob/7e654cceb01bfdbb6f02009ca8f73b0b950ec73c/client/src/com/aerospike/client/cdt/MapOperation.java#L139) method which allows the policy to be passed. It seems to be a really nice to have feature, doesn’t it? Thank you, Mike. ---
**Author:** ![system](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.aerospike.com/system/32/2274_2.png) [@system](https://discuss.aerospike.com/u/system)\ **Post date:** [April 21, 2020, 10:54am UTC](https://discuss.aerospike.com/t/client-write-error/7320/4 "2020-04-21T10:54:49Z")
This topic was automatically closed 6 days after the last reply. New replies are no longer allowed. ---
**Author:** ![meher](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.aerospike.com/meher/32/1644_2.png) [@meher](https://discuss.aerospike.com/u/meher)\ **Post date:** [April 21, 2020, 10:26pm UTC](https://discuss.aerospike.com/t/client-write-error/7320/5 "2020-04-21T22:26:44Z")
Yes, that may be useful indeed. Let me pass the feedback! ---
**Author:** ![kporter](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.aerospike.com/kporter/32/515_2.png) [@kporter](https://discuss.aerospike.com/u/kporter)\ **Post date:** [April 22, 2020, 4:56pm UTC](https://discuss.aerospike.com/t/client-write-error/7320/6 "2020-04-22T16:56:30Z")