Apache Camel, конечная точка Netty4 как клиент - утечка памяти - PullRequest
0 голосов
/ 17 октября 2018

Я довольно новичок в Apache Camel и пытаюсь привести в действие некоторые маршруты.У меня есть TCP-сервер, который обслуживает большие JSON-сообщения (размером до ~ 30-50 КБ, где у меня нет никакого контроля над размером источника), которые содержат много данных измерений, которые я хочу обработать, используя определенные дополнительные работающие маршрутыхорошо.Я использую верблюд 2.20 в среде Spring-boot 1.5.7.Я столкнулся с проблемой, что если я закомментировал все остальные маршруты, кроме входящего сокращенного маршрута netty4 (только от и до счетчика), см. Ниже

@Bean
public RouteBuilder getRoute() {
    String fromSource = String.format("netty4:tcp://%s:%d?clientMode=true&textline=true&receiveBufferSize=64000&decoderMaxLineLength=64000",sourceIp,sourcePort);
    return new RouteBuilder() {
        from(fromSource)
        .to("metrics:counter:incomingCounter");


    };
}

Маршрут работает почти нормально, но потребляет все больше и больше кучи.пространство (около 2 МБ каждую секунду, где есть сообщения, обслуживаемые с частотой около 20–30 Гц), пока java не генерирует java.lang.OutOfMemoryError: пространство кучи Java.

Без какого-либо маршрута утечка памяти не была зарегистрирована,как я могу сосредоточить проблему на netty-route

Любая помощь будет оценена.Заранее спасибо.

1 Ответ

0 голосов
/ 18 октября 2018

Я сам нашел решение, отладив код.Я забыл установить свойство sync = false в конечной точке netty4-camel, так как я не хочу обрабатывать сообщение и отправлять ответ на сервер после обработки, просто потребляя - пока sync = true (настройки по умолчанию)буферизует все входящие данные для последующего ответа, который вызвал мою «утечку памяти».Поведение «sync» не совсем понятно из документации netty4-верблюда (http://camel.apache.org/netty4.html) - я предложу улучшить документацию (напишу письмо с предложением), чтобы сделать использование немного более понятным.

Может быть, это поможет кому-то другому, имеющему подобную проблему.

Лучше

...