Гремлин приостановил запись ответа, так как writeBufferHighWaterMark превышен на RequestMessage - PullRequest
1 голос
/ 19 июня 2019

Я использую клиент gremlin javascript (3.4.2) для запроса janusgraph через сервер gremlin. Я заметил, что после того, как сервер работал некоторое время во время разработки, некоторые из запросов, которые запрашивают график, начинают долго оставаться в ожидании (время ожидания, установленное на gremlin-server).

Глядя на консоль сервера, я вижу это сообщение:

 Pausing response writing as writeBufferHighWaterMark exceeded on RequestMessage{, requestId=9697c61a-34de-4764-a8c4-72d7f7a154ac, op='bytecode', processor='traversal', args={gremlin=[[], [V(), has(User, identityid, NQ05cGsB3uhLm-BIAGPq), outE(worked), choose([[], [values(dateto)]], [[], [project(vertexId, role, businessId, business, relationId, dateinsert, datefrom, dateto), by([[], [inV(), hasLabel(Job), id()]]), by([[], [inV(), hasLabel(Job), values(role)]]), by([[], [inV(), hasLabel(Job), outE(), hasLabel(at), inV(), id()]]), by([[], [inV(), hasLabel(Job), outE(), hasLabel(at), inV(), values(name)]]), by(id), by(dateinsert), by(datefrom), by(dateto)]], [[], [project(vertexId, role, businessId, business, relationId, dateinsert, datefrom), by([[], [inV(), hasLabel(Job), id()]]), by([[], [inV(), hasLabel(Job), values(role)]]), by([[], [inV(), hasLabel(Job), outE(), hasLabel(at), inV(), id()]]), by([[], [inV(), hasLabel(Job), outE(), hasLabel(at), inV(), values(name)]]), by(id), by(dateinsert), by(datefrom)]])]], aliases={g=refeenet}}} - writing will continue once client has caught up

И через некоторое время появляется таймаут ПРЕДУПРЕЖДЕНИЕ.

Я не уверен, почему это происходит, и я не нашел ничего полезного в поиске решения.

Я использую машинопись.

Это класс, который управляет источником обхода:

import gremlin from "gremlin";

const GREMLIN_URL = "ws://localhost:8182/gremlin";
const GRAPH_NAME = "maingraph";

const { Graph } = gremlin.structure;
const { DriverRemoteConnection } = gremlin.driver;

export class GremlinApi {

    public static g: gremlin.process.GraphTraversalSource;
    public static connection: gremlin.driver.DriverRemoteConnection;

    public static getTraversalSource() {
        if (!GremlinApi.g) {
            const graph = new Graph();
            GremlinApi.connection = new DriverRemoteConnection(GREMLIN_URL, { traversalSource: GRAPH_NAME });
            GremlinApi.g = graph.traversal().withRemote(GremlinApi.connection);
        }
        return GremlinApi.g;
    }

    public static closeTraversal() {
        if (GremlinApi.connection && GremlinApi.connection.close) {
            GremlinApi.connection.close();
            GremlinApi.connection = null;
            GremlinApi.g = null;
        }
    }

}

И это пример того, как я обычно использую обход:


import { GremlinApi } from "../db/gremlinApi/gremlinApi";

// Get the traversal
const g = GremlinApi.getTraversalSource();
// Do something with the traversal
GremlinApi.closeTraversal();

Это обычно случается, когда что-то вроде 3/4 запросов действительно близко друг к другу Некоторые из них уходят в тайм-аут.

Есть идеи о том, что может быть причиной этой проблемы?

1 Ответ

1 голос
/ 20 июня 2019

Это сообщение обычно означает, что клиент не успевает за тем, что сервер пытается записать, поэтому сервер приостанавливает свой ответ до тех пор, пока клиент не обнаружит, что находится в буфере. Я полагаю, что это может быть медленный клиент, вызывающий проблемы или, возможно, проблемы с сетью, но в любом случае смысл приостановки состоит в том, чтобы избежать ошибок памяти на сервере, продолжая буферизовать результаты в памяти. С учетом этого контекста, я думаю, вы могли понять, почему интервал между вашими запросами помогает, как вы упомянули в комментарии к вашему вопросу.

Вы можете точно настроить "водяные знаки" в файле yaml сервера Gremlin - writeBufferHighWaterMark и writeBufferLowWaterMark. Вы также можете посмотреть на обход, который вы отправляете. Вы не указываете, что это такое, но вы должны посмотреть, сможете ли вы похудеть или исключить возвращаемые результаты. Обычно я вижу, как пользователи получают эту проблему при загрузке данных, и много раз ее можно устранить, просто игнорируя возвращаемый результат, вызывая iterate() в конце обхода, а не next(), toList() и т. Д., Которые требуют возврата фактического результат, который они не используют на клиентской стороне в любом случае.

...