Delete timestamp via v2/api hangs Write api

We have system containing 4 bucket’s in v2.7.11 database and have been writing and deleting data to them successfully for 4 months. Until this week when 2 buckets stopped working properly. Queries work and writing new records work, but deleting timestamp in the measurement hangs the whole write Api

We are using method below for deleting data

http://localhost:8086/api/v2/delete?org=example-org&bucket=example-bucket

–header ‘Authorization: Token YOUR_API_TOKEN’
–header ‘Content-Type: application/json’
–data ‘{
“start”: “2020-03-01T00:00:00Z”,
“stop”: “2020-11-14T00:00:00Z”,
“predicate”: "_measurement=“example-measurement”
}’

My client java application uses java8 java.net.HttpURLConnection and I located the error to it’s getResponseCode() method. No exceptions thrown or anything else it just hangs there and returns nothing.

We fixed the problem by making a new buckets and everything started working again. But 4 months data is now lost from UI. Not very promising start with this database.

/**
 * Gets the status code from an HTTP response message.
 * For example, in the case of the following status lines:
 * <PRE>
 * HTTP/1.0 200 OK
 * HTTP/1.0 401 Unauthorized
 * </PRE>
 * It will return 200 and 401 respectively.
 * Returns -1 if no code can be discerned
 * from the response (i.e., the response is not valid HTTP).
 * @throws IOException if an error occurred connecting to the server.
 * @return the HTTP Status-Code, or -1
 */
public int getResponseCode() throws IOException {
    /*
     * We're got the response code already
     */
    if (responseCode != -1) {
        return responseCode;
    }

    /*
     * Ensure that we have connected to the server. Record
     * exception as we need to re-throw it if there isn't
     * a status line.
     */
    Exception exc = null;
    try {
        getInputStream();
    } catch (Exception e) {
        exc = e;
    }

    /*
     * If we can't a status-line then re-throw any exception
     * that getInputStream threw.
     */
    String statusLine = getHeaderField(0);
    if (statusLine == null) {
        if (exc != null) {
            if (exc instanceof RuntimeException)
                throw (RuntimeException)exc;
            else
                throw (IOException)exc;
        }
        return -1;
    }

    /*
     * Examine the status-line - should be formatted as per
     * section 6.1 of RFC 2616 :-
     *
     * Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase
     *
     * If status line can't be parsed return -1.
     */
    if (statusLine.startsWith("HTTP/1.")) {
        int codePos = statusLine.indexOf(' ');
        if (codePos > 0) {

            int phrasePos = statusLine.indexOf(' ', codePos+1);
            if (phrasePos > 0 && phrasePos < statusLine.length()) {
                responseMessage = statusLine.substring(phrasePos+1);
            }

            // deviation from RFC 2616 - don't reject status line
            // if SP Reason-Phrase is not included.
            if (phrasePos < 0)
                phrasePos = statusLine.length();

            try {
                responseCode = Integer.parseInt
                        (statusLine.substring(codePos+1, phrasePos));
                return responseCode;
            } catch (NumberFormatException e) { }
        }
    }
    return -1;
}

There was a fix for a deadlock issue in 2.7.12. I recommend upgrading to that.

I second the proposal to upgrade, it helped in my similar situation.

Then I would think about rebuilding the TSI index, it has helped in past “freeze” episodes: