Это про то, что связные списки, деревья, графы и любые прочие неплоские структуры данных как один из способов - это в арене гонять?
Читать полностью…Передадим ваше обращение нормальным языкам, воспроизводящим лейаут схемы и позволяющим прямую запись
Читать полностью…Вам пруф что прямая запись куском в память быстрее разбора по типам и проставления их по отдельности?
Читать полностью…производительность это другой вопрос. речь было про
независимость от спринга и в целом языковЧитать полностью…
У нас подход такой был, мы берем бинарный формат (thrift, protobuf etc) и шлем в кафку сообщения в этом формате. Форматы популярные, есть для многих ЯП, и дальше просто десеарилизуем с помощью нужных инструментов
Читать полностью…Немного не догоняю, для чего мне avro, так как сконвертить в нужный java класс получается легко, а консюмеры не понимают, какое из сконверченных сообщений их и кушают все.
Предположу, что это из за того, что десериализатор у меня Object возвращает …
нет, я про общий подход с аренами в любой ситуации, где тебе нужен потенциально циклический граф ссылок
Читать полностью…https://knowyourmeme.com/memes/look-what-they-need-to-mimic-a-fraction-of-our-power
Читать полностью…В джаве производительность должна быть сильно печальнее других языков (пока в ансейф не лезут), потому что в анменеджед языках можно просто переписывать шмат памяти по адресу -_-
Но json все равно далеко позади, хоть я и за человекочитаемые форматы
как будто бинарники более производительны с точки зрения скорости и памяти, но я не буду утверждать, потому что когда я пришёл уже так делали
Читать полностью…в итоге получаем обратную своместимость протокола, и независимость от спринга и в целом языков
Читать полностью…Тупой вопрос. Зачем нам
- Постоянное использование invokedynamic в байткоде, сгенерированном javac
- Бутстрап-методы
? Какие бенефиты перед обычным тулсетом?
@evgen_smirnov Загадка Жака Фреско: сколько будет 2 + 7 = ? На ответ даётся 10 секунд.
При поддержке 1inch
аналогично для Json будет, но желательно избегать TypeId вендор лока - ваши топики могут читать не спринг прирложения
Читать полностью…сори, что прерываю чатик :)
доп.вопрос появился, если есть соображения, буду рад прочитать:
по итогу сделал через DelegatingDeserializer, десериализация работает, однако, два консюмера, которые слушают этот топик, по очереди кушают сообщение и соответственно, в одном получается ClassCastException, а во втором все ок.
консюмеры реализованы через функциональщину (в проекте spring.cloud используется, поэтому настройки кафки идут через бинды и создание консюмеров через функциональный интерфейс), аннотация KafkaListener не используется (просто бины создаются через Bean) - если это важно.
Сигнатуры методов
Consumer<Message<Foo>> consumerFoo
Consumer<Message<Boo>> consumerBoo
А вопрос: что нужно докрутить, чтобы каждый консюмер кушал только свое сообщение?
Спасибо заранее.