Как стать автором
Обновить
31
Карма
0
Рейтинг
Григорий Кошелев @gnkoshelev

Team Lead

  • Подписчики 22
  • Подписки

Представляем Amazon Corretto, бесплатный дистрибутив OpenJDK с долгосрочной поддержкой

Это в теории всё замечательно, но на практике разработчики сталкиваются с кучей проблем.

Представляем Amazon Corretto, бесплатный дистрибутив OpenJDK с долгосрочной поддержкой

Наблюдаю обратную тенденцию с переносом vendor-специфичных на светлую сторону, например, в Java 9 класс sun.misc.Unsafe переехал в другой пакет: jdk.internal.misc.Unsafe.

Представляем Amazon Corretto, бесплатный дистрибутив OpenJDK с долгосрочной поддержкой

  1. .NET Framework (множество версий, в том числе несовместимых)
  2. Mono
  3. .NET Core 1.x
  4. .NET Core 2.x
  5. .NET Standard 1.0
  6. .NET Standard 2.0

Мир C# ещё очень далёк от стандарта, в котором перестали бы ломать API. Через годик можно ещё попробовать присмотреться. Или мой анализатор сарказма сломался и это была шутка?)

Представляем Amazon Corretto, бесплатный дистрибутив OpenJDK с долгосрочной поддержкой

Для IBM имеется в виду IBM J9 и её опенсорсный вариант Eclipse OpenJ9? Если ничего не путаю, это не форк OpenJDK, а самостоятельная реализация.

Представляем Amazon Corretto, бесплатный дистрибутив OpenJDK с долгосрочной поддержкой

Первое уже произошло.

  1. Alibaba JDK
  2. Oracle OpenJDK (то, что скачивается с jdk.java.net/11)
  3. AdoptOpenJDK (Community Edition)
  4. Corretto
  5. Red Hat IcedTea
  6. Azul Zulu

Это то, что сходу удалось вспомнить. Наверняка, есть и другие не менее популярные.

Представляем Amazon Corretto, бесплатный дистрибутив OpenJDK с долгосрочной поддержкой

Мы пока используем в продакшене Java 8 от Oracle и планируем мигрировать на OpenJDK 11.

С появлением LTS-версии OpenJDK под CentOS — вариант с Corretto становится для нас весьма интересным.

[Екатеринбург, анонс] java.ural.Meetup @2 — анонс второго Java-митапа + видео докладов с java.ural.Meetup @1

Мне всегда казалось, что митапы нужны в первую очередь для нетворкинга. Для всего остального есть конференции (ок, в Екатеринбурге с этим не так здорово).

[Екатеринбург, анонс] java.ural.Meetup @2 — анонс второго Java-митапа + видео докладов с java.ural.Meetup @1

Есть самописная очередь Echelon, которая работает поверх самописной же базы Kanso (для которой идейным вдохновителем послужила Google FS). Когда-нибудь (я надеюсь), эти решения станут частью OpenSource-мира.

Vostok — это OpenSource, поэтому логично использовать в основе OpenSource-решение (например, Apache Kafka). Кроме того, Apache Kafka выдаёт огромные скорости благодаря zero-copy, когда упираемся либо в клиента, либо в сеть, либо в диск. В 2019 нам завезут серваки с 10 гигабитной сетью — посмотрим, что будет.

Я ничего не скажу за производительность и масштабируемость Echelon (потому что не знаю). Можно попробовать призвать Diafilm. :)

[Екатеринбург, анонс] java.ural.Meetup @2 — анонс второго Java-митапа + видео докладов с java.ural.Meetup @1

Соль больше не предоставляет площадку для таких мероприятий.

Из менее фатального:
  1. У Соли были довольно существенные ограничения по времени использования площадки.
  2. Конференц-зал в Контуре существенно больше и комфортнее.
  3. В коференц-зале есть всё необходимое оборудование (звук, скринкаст, видеосъёмка).
  4. Аренда стоит денег (существенных в масштабах митапа).


Изменение времени стало следствием смены площадки. В выходной день парковка способна принять несколько сотен машин, а добраться до офиса значительно проще, чем вечером буднего дня.

Разбор перформансных задач с JBreak (часть 3)

Баг был закрыт с резолюцией Won't fix:
Original issue JDK-8139758 is performance enhancement.
We will not be fixing this in 8.

Closing as wnf

Apache Kafka: обзор

1. Продюсеры пишут сообщение в конкретный топик и конкретную секцию
Producer может указать и конкретный топик, и конкретную партицию в нём. // Ответ на вопрос: "да"
2. Консюмеры опрашивают брокера на наличие новых сообщений в топике (без привязки к секции)
Consumer может работать как в режиме publish/subscribe, т.е. сколько угодно Consumer может читать одни и те же данные, так и в режиме message queue, когда одно сообщение читается ровно одним Consumer. В последнем случае все Consumer объединяются в Consumer Group для чтения из одного топика, и одновременно из каждой партиции читает ровно один Consumer (балансировщик контролирует, если один из Consumer отпадёт, то свободный Consumer будет читать сообщения). // Ответ на вопрос: "да"
3. Брокер отдает (одновременно) неограниченное количество сообщений из топика но не больше одного сообщения из конкретной секции.
Не понял смысла выделенного фрагмента. Это как-то коррелирует с моим комментарием по второму пункту относительно работы Consumer Group?

О стримах и таблицах в Kafka и Stream Processing, часть 1

* Мартин раньше работал в LinkedIn (не Confluent) над проектом Apache Samza, поэтому знаком с основателями Apache Kafka.
В остальном всё верно. :)

// gAmUssA, спасибо за уточнение.

Apache Kafka: обзор

Чему равно N (хотя бы порядок)? Какие есть требования помимо «порядок сообщений от каждого продюсера критично важен»?

Кафка предоставляет мощные инструменты для работы с данными (например, Kafka Streams или KSQL). При этом, в Кафка есть гарантия на порядок сообщений внутри одной партиции. Кроме того, в Кафке поддерживаются все три варианта семантик: at-most-once, at-least-once и exactly-once.

О стримах и таблицах в Kafka и Stream Processing, часть 1

В разделе «Turning the Database Inside-Out» / «База данных изнутри» есть ссылка на одноимённую статью-доклад от Martin Kleppmann (тоже из Confluent, как и Michael G. Noll) — Мартин довольно интересно рассказывает про устройство баз данных, и там тоже есть немного про стримы в БД.

Альтернативный взгляд на задачу от Одноклассников с JPoint 2018

Кстати, вместо варианта из оригинальной статьи:
return Math.abs( track.hashCode() % partitions );

я бы предложил такой вариант с обнулением бита, отвечающего за знак:
return (track.hashCode() & 0x7FFFFFFF) % partitions;

Для отрицательных значений hashCode результат, конечно, будет отличаться:
(-100 & 0x7FFFFFFF) % 7 // 0
Math.abs(-100 % 7) // 2

тем не менее, получим такое же распределение на [0; partitions).

Альтернативный взгляд на задачу от Одноклассников с JPoint 2018

Наверное, я некорректно выразился: нет гарантии совместимости Java 8 SE API и Java X SE API, т.е. описанное в javadoc поведение может поменяться в будущем. Или есть?

Альтернативный взгляд на задачу от Одноклассников с JPoint 2018

Верное замечание, спасибо.

Такой исходный код:
        switch(s) {
            case "s":
                System.out.println("S");
                break;
            case "b":
                System.out.println("B");
                break;
        }

компилируется в
        int var_ = -1;
        switch(s.hashCode()) {
        case 98:
            if(s.equals("b")) {
                var_ = 1;
            }
            break;
        case 115:
            if(s.equals("s")) {
                var_ = 0;
            }
        }

        switch(var_) {
        case 0:
            System.out.println("S");
            break;
        case 1:
            System.out.println("B");
        }

Альтернативный взгляд на задачу от Одноклассников с JPoint 2018

На assert явным образом есть отсылка в авторском разборе:
Вадим же человек аккуратный (вы посмотрите, сколько assertов!), значит, комментарий к методу он тоже написал аккуратно, а там указано, что метод вернет число в интервале от 0 до partitions исключительно.

У читателей может сложиться ложное впечатление, что это best practice, не так ли?

А вот тут
Другая, более серьезная проблема Вадима гораздо менее очевидна. Способ, который он выбрал, чтобы распределять данные по серверам, неконсистентен: при изменении количества партиций (например, при добавлении серверов) все треки перераспределяются по кластеру практически полностью.

ничего нет про поведение Object.hashCode(), а именно про его невоспроизводимость. Последнее, опять же на мой взгляд, куда большая проблема, чем изменение количество шардов, т.к. их количество может измениться либо вследствие сбоев, либо намеренного изменения (см. отсылки к Elasticsearch или MongoDB), в то время как hashCode на разных серверах для одних и тех же объектов уже будет давать разные результаты. Это важно.

Информация

В рейтинге
Не участвует
Откуда
Екатеринбург, Свердловская обл., Россия
Работает в
Зарегистрирован
Активность