Как соединитель источника Solace "tasks.max" подключается к очереди? - PullRequest
Новая
       14

Как соединитель источника Solace "tasks.max" подключается к очереди?

0 голосов
/ 04 апреля 2019

Мы реализуем тему Kafka, которая представляет собой кластер из 3 машин. Мы собираемся выйти из очереди Solace и задаемся вопросом, что делает параметр tasks.max и как он разделяет сообщения. У нас нет доступа к очереди утешения, и мы можем только позвонить и посмотреть, удаляем ли мы сообщения из буфера. любое понимание было бы здорово !! Текущая система в HornetQ, и она работает 5 потоков.

Enviroment:

  • Распределенный режим
  • 1 тема
  • 3 реплики
  • 5 разделов на машину

Утешение-Кафка-разъем источника-мастер * * 1016

Мы попробовали его в автономном режиме с одной задачей, и оно работает. Поскольку мы не контролируем очередь утешения, мы можем видеть, отбрасываем ли мы сообщения. 

{
    "name": "solaceSourceConnector",
    "config": {
        "connector.class":
"com.solace.source.connector.SolaceSourceConnector",
        "tasks.max": "1",
        "kafka.topic": "solacetest",
        "sol.host": "HOSTNAME",
        "sol.username": "USERNAME",
        "sol.password": "PASSWORD",
        "sol.vpn_name": "VPN IP",
        "sol.topics": "soltest, soltest1,solacetest2",
        "sol.queue": "testQ",
        "sol.message_processor_class": "com.solace.source.connector.msgProcessors.SolaceSampleKeyedMessageProcessor",
        "sol.generate_send_timestamps": "true",
        "sol.generate_rcv_timestamps": "true",
        "sol.sub_ack_window_size": "255",
        "sol.generate_sequence_numbers": "true",
        "sol.calculate_message_expiration": "true",
        "sol.subscriber_dto_override": "true",
        "sol.channel_properties.connect_retries": "-1",
        "sol.channel_properties.reconnect_retries": "-1",
        "sol.kafka_message_key": "DESTINATION",
        "sol.ssl_trust_store": "/opt/PKI/skeltonCA/heinz1.ts",
        "sol.ssl_trust_store_pasword": "sasquatch",
        "sol.ssl_trust_store_format": "JKS",
        "sol.ssl_key_store": "/opt/PKI/skeltonCA/heinz1.ks",
        "sol.ssl_key_store_password": "sasquatch",
        "sol.ssl_key_store_format": "JKS",
        "sol.ssl_key_store_normalized_format": "JKS",
        "sol.ssl_private_key_alias": "heinz1",
        "sol.ssl_private_key_password": "sasquatch"
    }

}

Я пытаюсь сделать так, чтобы мы не теряли сообщения в буфере.

1 Ответ

0 голосов
/ 05 апреля 2019

max.tasks 1 будет работать с исключительной очередью, так как в очереди такого типа Solace может быть только один активный подписчик. Это также гарантирует сохранение порядка сообщений из Утешения в Кафку.

Если очередь Solace является неисключительной (то есть общей), то при увеличении max.tasks будет определена верхняя граница числа одновременных клиентов Solace, потребляющих из очереди. Это позволяет горизонтальное масштабирование с использованием нескольких потребителей из очереди для лучшей пропускной способности. Однако Solace не гарантирует порядок сообщений для нескольких потребителей неисключительной очереди, поэтому порядок сообщений не может быть сохранен.

В любом случае сообщения не теряются, поскольку они не подтверждаются обратно в Утешение и удаляются до тех пор, пока они не будут успешно подтверждены для записи в Kafka.

...