Комментарии 10
А в сторону hawt.io не смотрели? По крайней мере некая статистика и роуты в нем визуально оценить можно. Может даже допилить под себя…
Всегда интересовала целевая задача, где бы появлялось много сложных маршрутов и был необходим роутинг. Возможно это процессинг и анализ большого числа потоковых данных.
Эк вы ловко объединили два jms:topic в один, из разных контекстов. Я догадываюсь, что у вас наверное возможно такое — но в общем случае это могут быть совсем разные топики на разных jms серверах. И простое объединение узлов графа на базе их названий в camel некорректно (а другого способа не существует, потому что у нас например соединение проходит через qpid, и там внутри тоже существует обработка — которую в подобный граф не включить.
Эк вы ловко объединили два jms:topic в один, из разных контекстов
Почему из разных? Общий jms брокер. И в рамках одного брокера всякий jms:topic:foo ссылается на один и тот же топик foo.
И простое объединение узлов графа на базе их названий в camel некорректно
Да, некорректно. И я так не делаю. Информации, чтобы отличать похожие узлы, достаточно и я их отличаю. Но я прячу детали от пользователя и использую, например, цвета, чтобы визуально показать, что это разные сервисы или контексты.
>Почему из разных
Потому что по тексту это выглядит как объединение двух разных routes из разных контекстов (ну, во всяком случае я вас так понял). А в разных контекстах jms:topic:foo вовсе не обязаны быть двумя одинаковыми брокерами.
Ну то есть, я не говорю что так нельзя, но скажем на нашей шине такое бы не прокатило, потому что jms: (или в нашем случае amqp:) это всего-лишь имя в некотором camel registry, и два разных jms вполне могут ссылаться как на один брокер, так и на разные, и понять это можно только если залезть в определение самого jms, и даже там это будет не очевидно.
Потому что по тексту это выглядит как объединение двух разных routes из разных контекстов (ну, во всяком случае я вас так понял). А в разных контекстах jms:topic:foo вовсе не обязаны быть двумя одинаковыми брокерами.
Ну то есть, я не говорю что так нельзя, но скажем на нашей шине такое бы не прокатило, потому что jms: (или в нашем случае amqp:) это всего-лишь имя в некотором camel registry, и два разных jms вполне могут ссылаться как на один брокер, так и на разные, и понять это можно только если залезть в определение самого jms, и даже там это будет не очевидно.
Интересно, а как Вы отличаете jms брокеров тогда? Через connectionFactory?
Конечно. Ну то есть, я хочу сказать, что только посмотрев туда в свойства, вы точно можете сказать, один это брокер, или два разных. Впрочем, у нас такая задача не стояла, как у вас, и никто не пытался построить граф всех маршрутов, в первую очередь потому, что большая часть обработки была в qpid, и в других местах вне camel, поэтому даже если бы мы такой граф построили, от него было бы не очень много пользы. Поэтому нас вполне устроила hawt.io.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Граф маршрутов для Apache Camel