telnet API should return message after successful PUT

[simao]

Hello,

I am trying to write a client for opentsdb using the telnet interface.

When the put instruction causes an error opentsdb returns a message with the error description, but when put succeeds nothing is returned. This is a problem for clients as it's difficult to know if the command was Acked.

Are there any plans to change this?

Thanks

[mxk1235]

we use presence of data on the incoming socket as an indicator of error, and absence as success. I think this is a simpler protocol than checking for a valid response. If you require an Ack in your design, I think I would switch to use the REST endpoint.

[simao]

I don't think the absence of data is a good choice for success, what timeout would you use then? If it's like 1 sec, the request can still fail before after the timeout.

I am trying to use telnet instead of REST because it's more lightweight, I just need to write a put statement.

Cheers, Simao

On Wed, Jun 3, 2015, at 19:30, mxk1235 wrote:

we use presence of data on the incoming socket as an indicator of error, and absence as success. I think this is a simpler protocol than checking for a valid response. If you require an Ack in your design, I think I would switch to use the REST endpoint.

— Reply to this email directly or view it on GitHub[1].

Links:

1. https://github.com/OpenTSDB/opentsdb/issues/515#issuecomment-108537043

[manolama]

Benoit keeps saying the telnet interface was just a quick hack to get data in but it sure is popular :)

Anyway, we don't have plans to add it but if you have time to tweak the code we can certainly include it. The idea would be to have a config flag that would enable the acks then just return an "OK" or whatever when the value is spooled to HBase.

[mxk1235]

@simao this does sound useful for some use-cases, but there is also a use case when you can write multiple metrics out and not have to worry if any of them get lost, and unblock the thread to do something else. if small amounts of data get dropped, it may not mean very much for averages or monitoring, and retrying can be very expensive. the idea is similar to systems like statsd accepting data over UDP. we have a separate thread draining the input stream and logging the errors every once in a while.

@manolama yeah, that sounds like a good compromise, until someone requests for one server to support both an ack'ing and non-ack'ing telnet interface. ;)