это уточнение было на то, что можно повесить читателей сколько хочешь, пока они в пределах группы.
я уточнял что даже в пределах группы не более чем количество партиций.
простейший пример:
1) имеем топик на 10 партиций
2) 20 читателей с одной consumer group
вопрос:
сколько читателей будет одновременно работать?
10 будут читать, другие 10 будут висеть в воздухе ожидая пока кто-то из тех 10 отвалится.
до тех пор пока вы продолжаете использовать «то я всегда использую схему M*N <= P» все действительно можно разрулить, вот только я и начал разговор с того что
>> в общем представление партиции как упорядоченный лог накладывает свои ограничения, а держать 100500 партиций в пределах топика тоже не хочется, так как это дополнительные накладные расходы.
варианты решений есть, правда не всегда удобные и не избавляют от накапливания данных если некоторые консьюмеры начинают подтормаживать.
то есть используя схему M*N <= P мы можем получить что все вычитали, сидят курят, а один читатель продолжает пыхтеть из-за неравномерности распределения сообщений по партициям. и никто из его группы ему помочь не может. (хотя признаю что на такое только раз или два нарывался)
для вашего случая как уже сразу писалось нужно держать достаточно большое количество партиций, чтобы при необходимости масштабирования всем хватило работы. а устанавливать 100+ партиций не всегда оправдано из-за накладных расходов.
вот только я не пойму схему работы на версиях до 0.9 включительно:
1) когда вы делаете poll вам вернулся map с различных партиций или пачка сообщений даже из одной,
2) если обрабатывать последовательно даже одним потоком и в самом конце делать commit, то все равно остается вопрос что делать если обработали несколько, а потом упали, оффсет незакомиченный, а данные обработаны
согласен что на 0.10 данной проблемы нету так как можно прочитать ровно 1 сообщение, до 0.9 включительно нужно городить костыли и по мере обработки сообщения вызывать не просто commitSync()/commitAsync() (которые закомитят максимальный офсет из того что вам вернули по poll), а вариант с указанием где и что комитим
в данном случае можно обработать 1 сообщение, закомитить его,
обработать следующее и тд.
Даже если нам poll вернул достаточно большой блок мы сдвигаемся по очереди по каждому и по мере работы комитим
тут именно вопрос чтобы исключить двойную обработку отдельных сообщений
комитить в конце обработки блока не проблема и на 0.9, но иногда это не вариант =\
>> Сделать n читателей (по размеру пула, например) в рамках одной группы
нельзя сделать читателей больше чем количество партиций, 1 партиция — 1 читатель.
архитектурное ограничение для ускорения работы, так как broker делает sendfile между файловым дескриптором и дескриптором на сокет. вернее создать можно, но читать реально будет только по количеству партиций, остальные будут стоять в очереди пока какая-либо партиция не освободится
>> Каждый из них будет читать 1 сообщение, обрабатывать, коммитить, потом читать следующее.
указывать количество сообщений для вычитывания появилось начиная с 0.10 версии, до этого можно только управлять размером буфера, а там уж сколько попадет сообщений в этот буфер.
>> При такой схеме не обязательно строго привязывать читателя к партишону в кафке.
нельзя не привязывать читателя, подключение нового читателя обычно проходит по схеме:
1) подключился новый читатель в группу
2) бросилось всем читателям в группе сообщение что сейчас будет ребалансинг, притормозите работу
3) разослалась инфа о том кто какую партицию теперь будет обрабатывать
то есть вычитать не из той которая к тебе привязана нельзя, а процесс перепривязки достаточно долгий.
поэтому обычно читатель работает с 1+ партициями,
при вашей схеме держа:
M серверов по N потоков, P — количество партиций
каждый поток имеет своего читателя,
M*N > P — мы хоть и имеем несколько потоков которые курят, но зато каждый поток получает упорядоченные данные и нормально может комитить офсет.
M*N < P — тут в один поток влетает перемешенные данные из 2х партиций, при желании можно организовать доп логику и тоже работать, просто нужно будет проверять с какой партиции пришло сообщение и отправлять commit offset не общий, а именно в эту партицию
если же за 1 читателем находится пул потоков, то тут уже мешанина и async обработка неупорядоченная. проблему выше описал
p.s. чтобы было понятно: кафка отправляет подтверждение не на отдельное сообщение, а offset в пределах очереди, как бы говоря «все что было до этого оффсета я обработала»
>> В Kafka данные делятся по разделам (partition) и чтобы соблюдать порядок доставки каждый получатель сообщений читает данные ровно из одного раздела
неправильно, из одной партиции может читать только один читатель, чтобы соблюдать очередность в пределах партиции, но читатель может подписаться на несколько партиций и тогда дефолтный клиент при подписке не 2+ партициях уже выдает немного перемешанные данные.
>> Это может приводить к блокировке очереди в случае, когда получатель по каким-либо причинам обрабатывает сообщения медленнее обычного.
каждая партиция независима, о какой блокировке всей очереди идет речь? так как каждая партиция полностью независима, то у вас просто будет затык в определенной партиции, как поступать в этом случае отдельный вопрос, но остальные партиции продолжат работать без проблем.
а теперь реальные проблемы кафки если использовать как очередь запросов:
если у вас одну партицию разгребает за читателем пул потоков, то непонятно как комитить оффсет, то есть пришли сообщения mes1, mes2, mes3, раскинулись по 3 потокам, потоки выполнили их в порядке mes3, mes2, mes1.
Не дождавшись mes1 нельзя комитить mes3, иначе если мы сразу закомитим mes3, не дожидаясь mes1 и упадем, то mes1 повторно уже не вычитается.
Но и если ждем mes1 и произошло падение, то потом все этих три сообщения обработаются повторно, даже уже выполнившийся mes3.
в общем представление партиции как упорядоченный лог накладывает свои ограничения, а держать 100500 партиций в пределах топика тоже не хочется, так как это дополнительные накладные расходы.
Не знаю каким боком автор мерил производительность, но у меня в похожей ситуации и размере сообщений получалось из кафки 400k+ messages / second, а дальше упиралось в мой код.
Поэтому пока это смотрится: а смотрите что мы на Go сумели написать, Go сейчас модный, так что вы должны выбрать нас.
проблема в том, что очень часто сталкиваюсь с позицией «есть возможность — давайте использовать»
другая ситуация что 51% это возможно и надо, поэтому оставшиеся 49% тоже будут страдать, так как врубается на всех сразу
уверен многие последний абзац даже не будут читать, так как по всей статье идет внушение что server push это отличнейшая технология которую просто обязан внедрить каждый, кто хочет уменьшить скорость загрузки страницы
во всех этих server push меня смущает только пару вопросов:
1) клиенту может это все и не нужно (мобильный интернет)
2) у клиента уже есть эти данные закешированные, все что ему хочется знать это 304 NOT MODIFIED
не могу понять почему многие текущие разработки идут по принципу:
1) у пользователя простаивает cpu, надо его загрузить хоть чем-то
2) у пользователя простаивает канал в интернет, давайте мы по push закешируем весь сайт и пару поддоменов в нагрузку, может понадобится
ну дублирование не совсем корректное название, особенно что она очень легковесная, но хорошо.
по поводу друида: вы данные в него предполагали напрямую заливать?
просто везде где сталкивался с метриками мы гнали их через очередь, мало ли как индексатор себя поведет
независимо это cassandra/hbase/druid
1) HBase — Есть мастер нода – SPOF. мастеров в кластере несколько, выбираются кворумом, выпадение даже текущего не влияет на работу кластера (сам делал rolling restart всего кластера под нагрузкой, вышестоящие приложения лишь замечали небольшой скачек latency, драйвер сам детектил поведение и повторял запрос в новую ноду)
2) Druid — Долгове́чность — немного не понял, так как:
а) данные поступают в систему из kafka, пока блок не окажется в deepstorage то offset в kafka не комитится, данные всегда в очереди доступны
б) так как данные по большему immutable (сегменты полностью immutable, метаданные в реляционке лежат), то гарантии сохранности лежат или на deepstorage (это s3/hdfs зачастую) или как у вас резервирования sql базы сделано.
можете добавить сюда еще:
одно на нашем собственном Java-фреймворке, который основан на Spring и другое на kraken.js, с использованием express, dust.js и другого открытого кода.
никто не знает, кто что и как комитил в этот собственный фреймворк.
Отдельно смущает количество страниц в секунду, неужели там настолько тяжелые вызовы api?
причем стоит добавить, что aggregate с последующим «count: {$sum: 1}» работает на порядки медленнее, чем делать find(...).count() из-за особенностей реализации, разница в некоторых случаях у меня была миллисекунды-секунды vs минуты.
index используется в обоих случаях, но по разному
count может пробежаться по индексу и просто посчитать количество входов
агрегаты всегда производят материализацию объектов найденых, а уже потом только прибавляют 1, в итоге получаем fetch и disk io.
1. мы говорим о следующих пунктах:
а) интеллектуальная собственность (я тут полностью согласен с решением суда, вопрос по API возник бы рано или поздно, зато сейчас прецедент есть)
б) авторские права на код (не на сам язык, сам язык для разработки чего-либо никто не запрещал, копировать со сменой лицензии и вырезанием авторских прав есть запрет). Это если бы вы попытались использовать рантайм для Python/Lua от http://www.activestate.com/ и перетянули в свой «my-super-python-lua» дистрибутив стандартные библиотеки от них, а потом жаловались что вас за Python/Lua судят.
2. сам код openjdk под GPLv2, как и ядро linux, разрабатывай-открывай, либо не открывай, но тогда используй внутри не распространяя никому (хватает закрытых кастомных сборок jdk со специфическими патчами и никто никого не судит). GPL не означает «что хочу, то и делаю».
Вот поэтому за судом и следила вся индустрия, так как если бы судья сказал что «api действительно является ИС», то тогда бы попали все, нельзя было бы сделать ни одну стороннюю реализацию любого api, даже моки уже попадали бы под нарушение. Но судья попался грамотным и сказал обратное, поэтому все спят спокойно. Можно и реализовывать и применять.
А за копипасту со сменой лицензии доказали, что любой умный человек реализует почти таким же методом, вплоть до именования переменных.
Назовите пример открытых технологий, а то куда не посмотришь, то везде оказываются ограничения:
— ms за патенты в linux судиться,
— MPEG-LA за кодеки с гуглом (хотя тот считает что vp8-vp9 свободные кодеки),
— Yahoo! показывал что у него есть патенты на идею адблоков,
— про .net не говорю даже, там вообще все на «мы код открыли и обещаем за патенты не судить, честное слово» (почему тогда не открыли под нормальной лицензией, а то верить на слово ещё то удовольствие)
Поэтому и хотелось бы получить:
1) пример ОТКРЫТОЙ технологии
2) критерии открытости (свободно копировать, использовать, продавать изменения не показывая их)
ещё раз:
1) интеллектуальная собственность на API (тут все следили так как это касается не только google vs oracle, но и все в индустрии, так как процесс был знаковый)
2) авторское право на исходники (вопросы к копипасту с удалением headers об авторах и лицензии)
по второму подробней:
взять код под GPL лицензией и сказать, что теперь это apache лицензия и дальше вы если хотите, то сорцы закрывайте (а апач это позволяет) нельзя по условиям gpl, так как это нарушение, именно за это по второму пункту и были претензии.
Причем gpl => apache не относится конкретно к java, за это можно на любой gpl продукт попасть в суд, но никто же не говорит что gpl несвободная лицензия. Вернее говорят apache и bsd, что gpl недостаточно свободная, но каждый понимает свободу по своему.
то есть если есть сторонний продукт, который занимается раскидыванием jdk по машинкам в домене, но он платный хоть и можно скачать бесплатно, то это делает сразу же java несвободное технологией?
так под эту тему любое можно подвести:
1) .net несвободная технология, так как для нормальной работы если я скачаю нелицензионный windows мне ms счета выставит
2) js несвободная технология, так как за использование пиратского IE с windows для запуска ms опять счета выставит
3) sql несвободная технология, так как за его использование на oracle/db2/mssql некоторые компании счета выставляют
4) etc. можно продолжать аналогии до бесконечности
отличайте технологию и экосистему с продуктами
то что можно бесплатно скачать, не значит что данный продукт бесплатен
и уж тем более сторонние продукты не определяют свободность-открытость технологии
основные вопросы к Google были по 2 пунктам:
1) интеллектуальная собственность на API (тут все следили так как это касается не только google vs oracle, но и все индустрии)
2) авторское право на исходники (вопросы к копипасту с удалением headers об авторах)
видел =) за самим граалем уже давно посматриваю, хотя сейчас они планы чуть урезали, чтобы выйти сразу хоть с чем-то в прод, а уже потом добивать фичами
последнее время в этой части движение активное началось, помимо грааля зашевелились ibm http://www.eclipse.org/omr/
по осени дополнительно и свою версию jit открыли, в перспективе рассчитывают целиком свою версию jvm выложить и дальше двигаться по принципу Oracle «есть открытая версия, а есть наша сертифицированная с поддержкой, разница минимальная». http://openj9.mybluemix.net/
давно существуют алгоритмы и сборщики на подсчете ссылок, но у них есть свои проблемы:
1) атомарное увеличение-уменьшение количества ссылок не самая быстрая операция, а там нужна именно атомарная, так как часто мы не знаем куда убежала ссылка на объект и какие потоки еще держат данный объект
2) полностью вопроса с паузами он не снимает, хотя и делает на порядки более предсказуемым поведение.
Про второй пункт более подробно:
представьте что у Вас имеется структура в виде дерева и в программе держится только корень,
в какой-то момент корень выходит из зоны видимости и следовательно может быть собран,
после того как собран корень уменьшаются счетчики на объекты которые держались корнем и они тоже отправляются на удаление
и так проходит по всем элементам
в итоге у Вас возникает проблема, что выход из блока и инвалидация всего одной ссылки вызывает каскадную нагрузку на работу с памятью и очень часто предсказать Вы не можете в каком месте это выстрелит.
в классических языках с поколениями пройдет фаза mark и потом copy в новую область все кто выжил, а не будет вызываться пачка мелких удалений, просто пометим всю область как мусор и занулим.
p.s. известный факт: иногда из программы проще выйти по exit сразу в операционную систему, чем аккуратно освободить все участки памяти по очереди =) это касается любого managed языка
и верификация с математикой нам тут ничем не помогут, так как они не спасают от аппаратных сбоев, они не спасают от направленной атаки (Rowhammer уже приводил), они не спасают от направленного внедрения (когда человек сам запускает тот же вирус или он оказывается установленным еще на заводе изготовителе).
Shubinpavel уже вам ответил за космос: проблема зачастую в ресурсах (время, деньги, человеки) когда сознательно идут на срезание улов и уход от поставленных требований к проверке надежности, но чтобы было хоть что-то, а не воздушные замки в мечтах.
NASA имеет бюджет, любой спутник или ракета имеет бюджет, поэтому иногда возможно рискнуть и попытаться запустить сейчас с вероятностью неудачи в 0.001% чем пропустить запуск и ждать следующих 4-5 лет для появления окна запуска. В случае неудачи у вас есть риск строить такой же аппарат еще 8 лет, но это сознательный риск.
Не задумывались почему даже на Curiosity обновление прошивки заливали уже после достижения Марса: в момент отправки оно просто не было готово, не хватает ресурсов.
я уточнял что даже в пределах группы не более чем количество партиций.
простейший пример:
1) имеем топик на 10 партиций
2) 20 читателей с одной consumer group
вопрос:
сколько читателей будет одновременно работать?
10 будут читать, другие 10 будут висеть в воздухе ожидая пока кто-то из тех 10 отвалится.
до тех пор пока вы продолжаете использовать «то я всегда использую схему M*N <= P» все действительно можно разрулить, вот только я и начал разговор с того что
>> в общем представление партиции как упорядоченный лог накладывает свои ограничения, а держать 100500 партиций в пределах топика тоже не хочется, так как это дополнительные накладные расходы.
варианты решений есть, правда не всегда удобные и не избавляют от накапливания данных если некоторые консьюмеры начинают подтормаживать.
то есть используя схему M*N <= P мы можем получить что все вычитали, сидят курят, а один читатель продолжает пыхтеть из-за неравномерности распределения сообщений по партициям. и никто из его группы ему помочь не может. (хотя признаю что на такое только раз или два нарывался)
просто очень часто встречаю именно комит как есть, без указания доп параметров. в общем можно считать что понял вашу идею, у самих сделано похоже.
вот только я не пойму схему работы на версиях до 0.9 включительно:
1) когда вы делаете poll вам вернулся map с различных партиций или пачка сообщений даже из одной,
2) если обрабатывать последовательно даже одним потоком и в самом конце делать commit, то все равно остается вопрос что делать если обработали несколько, а потом упали, оффсет незакомиченный, а данные обработаны
согласен что на 0.10 данной проблемы нету так как можно прочитать ровно 1 сообщение, до 0.9 включительно нужно городить костыли и по мере обработки сообщения вызывать не просто commitSync()/commitAsync() (которые закомитят максимальный офсет из того что вам вернули по poll), а вариант с указанием где и что комитим
void commitSync(Map<TopicPartition, OffsetAndMetadata> offsets);
в данном случае можно обработать 1 сообщение, закомитить его,
обработать следующее и тд.
Даже если нам poll вернул достаточно большой блок мы сдвигаемся по очереди по каждому и по мере работы комитим
тут именно вопрос чтобы исключить двойную обработку отдельных сообщений
комитить в конце обработки блока не проблема и на 0.9, но иногда это не вариант =\
нельзя сделать читателей больше чем количество партиций, 1 партиция — 1 читатель.
архитектурное ограничение для ускорения работы, так как broker делает sendfile между файловым дескриптором и дескриптором на сокет. вернее создать можно, но читать реально будет только по количеству партиций, остальные будут стоять в очереди пока какая-либо партиция не освободится
>> Каждый из них будет читать 1 сообщение, обрабатывать, коммитить, потом читать следующее.
указывать количество сообщений для вычитывания появилось начиная с 0.10 версии, до этого можно только управлять размером буфера, а там уж сколько попадет сообщений в этот буфер.
>> При такой схеме не обязательно строго привязывать читателя к партишону в кафке.
нельзя не привязывать читателя, подключение нового читателя обычно проходит по схеме:
1) подключился новый читатель в группу
2) бросилось всем читателям в группе сообщение что сейчас будет ребалансинг, притормозите работу
3) разослалась инфа о том кто какую партицию теперь будет обрабатывать
то есть вычитать не из той которая к тебе привязана нельзя, а процесс перепривязки достаточно долгий.
поэтому обычно читатель работает с 1+ партициями,
при вашей схеме держа:
M серверов по N потоков, P — количество партиций
каждый поток имеет своего читателя,
M*N > P — мы хоть и имеем несколько потоков которые курят, но зато каждый поток получает упорядоченные данные и нормально может комитить офсет.
M*N < P — тут в один поток влетает перемешенные данные из 2х партиций, при желании можно организовать доп логику и тоже работать, просто нужно будет проверять с какой партиции пришло сообщение и отправлять commit offset не общий, а именно в эту партицию
если же за 1 читателем находится пул потоков, то тут уже мешанина и async обработка неупорядоченная. проблему выше описал
p.s. чтобы было понятно: кафка отправляет подтверждение не на отдельное сообщение, а offset в пределах очереди, как бы говоря «все что было до этого оффсета я обработала»
неправильно, из одной партиции может читать только один читатель, чтобы соблюдать очередность в пределах партиции, но читатель может подписаться на несколько партиций и тогда дефолтный клиент при подписке не 2+ партициях уже выдает немного перемешанные данные.
>> Это может приводить к блокировке очереди в случае, когда получатель по каким-либо причинам обрабатывает сообщения медленнее обычного.
каждая партиция независима, о какой блокировке всей очереди идет речь? так как каждая партиция полностью независима, то у вас просто будет затык в определенной партиции, как поступать в этом случае отдельный вопрос, но остальные партиции продолжат работать без проблем.
а теперь реальные проблемы кафки если использовать как очередь запросов:
если у вас одну партицию разгребает за читателем пул потоков, то непонятно как комитить оффсет, то есть пришли сообщения mes1, mes2, mes3, раскинулись по 3 потокам, потоки выполнили их в порядке mes3, mes2, mes1.
Не дождавшись mes1 нельзя комитить mes3, иначе если мы сразу закомитим mes3, не дожидаясь mes1 и упадем, то mes1 повторно уже не вычитается.
Но и если ждем mes1 и произошло падение, то потом все этих три сообщения обработаются повторно, даже уже выполнившийся mes3.
в общем представление партиции как упорядоченный лог накладывает свои ограничения, а держать 100500 партиций в пределах топика тоже не хочется, так как это дополнительные накладные расходы.
Не знаю каким боком автор мерил производительность, но у меня в похожей ситуации и размере сообщений получалось из кафки 400k+ messages / second, а дальше упиралось в мой код.
Поэтому пока это смотрится: а смотрите что мы на Go сумели написать, Go сейчас модный, так что вы должны выбрать нас.
другая ситуация что 51% это возможно и надо, поэтому оставшиеся 49% тоже будут страдать, так как врубается на всех сразу
уверен многие последний абзац даже не будут читать, так как по всей статье идет внушение что server push это отличнейшая технология которую просто обязан внедрить каждый, кто хочет уменьшить скорость загрузки страницы
1) клиенту может это все и не нужно (мобильный интернет)
2) у клиента уже есть эти данные закешированные, все что ему хочется знать это 304 NOT MODIFIED
не могу понять почему многие текущие разработки идут по принципу:
1) у пользователя простаивает cpu, надо его загрузить хоть чем-то
2) у пользователя простаивает канал в интернет, давайте мы по push закешируем весь сайт и пару поддоменов в нагрузку, может понадобится
по поводу друида: вы данные в него предполагали напрямую заливать?
просто везде где сталкивался с метриками мы гнали их через очередь, мало ли как индексатор себя поведет
независимо это cassandra/hbase/druid
1) HBase — Есть мастер нода – SPOF. мастеров в кластере несколько, выбираются кворумом, выпадение даже текущего не влияет на работу кластера (сам делал rolling restart всего кластера под нагрузкой, вышестоящие приложения лишь замечали небольшой скачек latency, драйвер сам детектил поведение и повторял запрос в новую ноду)
2) Druid — Долгове́чность — немного не понял, так как:
а) данные поступают в систему из kafka, пока блок не окажется в deepstorage то offset в kafka не комитится, данные всегда в очереди доступны
б) так как данные по большему immutable (сегменты полностью immutable, метаданные в реляционке лежат), то гарантии сохранности лежат или на deepstorage (это s3/hdfs зачастую) или как у вас резервирования sql базы сделано.
если я что-то неправильно понял, то уточните
одно на нашем собственном Java-фреймворке, который основан на Spring и другое на kraken.js, с использованием express, dust.js и другого открытого кода.
никто не знает, кто что и как комитил в этот собственный фреймворк.
Отдельно смущает количество страниц в секунду, неужели там настолько тяжелые вызовы api?
index используется в обоих случаях, но по разному
count может пробежаться по индексу и просто посчитать количество входов
агрегаты всегда производят материализацию объектов найденых, а уже потом только прибавляют 1, в итоге получаем fetch и disk io.
поэтому сравнения вообще ни о чём =)
а) интеллектуальная собственность (я тут полностью согласен с решением суда, вопрос по API возник бы рано или поздно, зато сейчас прецедент есть)
б) авторские права на код (не на сам язык, сам язык для разработки чего-либо никто не запрещал, копировать со сменой лицензии и вырезанием авторских прав есть запрет). Это если бы вы попытались использовать рантайм для Python/Lua от http://www.activestate.com/ и перетянули в свой «my-super-python-lua» дистрибутив стандартные библиотеки от них, а потом жаловались что вас за Python/Lua судят.
2. сам код openjdk под GPLv2, как и ядро linux, разрабатывай-открывай, либо не открывай, но тогда используй внутри не распространяя никому (хватает закрытых кастомных сборок jdk со специфическими патчами и никто никого не судит). GPL не означает «что хочу, то и делаю».
А за копипасту со сменой лицензии доказали, что любой умный человек реализует почти таким же методом, вплоть до именования переменных.
Назовите пример открытых технологий, а то куда не посмотришь, то везде оказываются ограничения:
— ms за патенты в linux судиться,
— MPEG-LA за кодеки с гуглом (хотя тот считает что vp8-vp9 свободные кодеки),
— Yahoo! показывал что у него есть патенты на идею адблоков,
— про .net не говорю даже, там вообще все на «мы код открыли и обещаем за патенты не судить, честное слово» (почему тогда не открыли под нормальной лицензией, а то верить на слово ещё то удовольствие)
Поэтому и хотелось бы получить:
1) пример ОТКРЫТОЙ технологии
2) критерии открытости (свободно копировать, использовать, продавать изменения не показывая их)
1) интеллектуальная собственность на API (тут все следили так как это касается не только google vs oracle, но и все в индустрии, так как процесс был знаковый)
2) авторское право на исходники (вопросы к копипасту с удалением headers об авторах и лицензии)
по второму подробней:
взять код под GPL лицензией и сказать, что теперь это apache лицензия и дальше вы если хотите, то сорцы закрывайте (а апач это позволяет) нельзя по условиям gpl, так как это нарушение, именно за это по второму пункту и были претензии.
Причем gpl => apache не относится конкретно к java, за это можно на любой gpl продукт попасть в суд, но никто же не говорит что gpl несвободная лицензия. Вернее говорят apache и bsd, что gpl недостаточно свободная, но каждый понимает свободу по своему.
так под эту тему любое можно подвести:
1) .net несвободная технология, так как для нормальной работы если я скачаю нелицензионный windows мне ms счета выставит
2) js несвободная технология, так как за использование пиратского IE с windows для запуска ms опять счета выставит
3) sql несвободная технология, так как за его использование на oracle/db2/mssql некоторые компании счета выставляют
4) etc. можно продолжать аналогии до бесконечности
отличайте технологию и экосистему с продуктами
то что можно бесплатно скачать, не значит что данный продукт бесплатен
и уж тем более сторонние продукты не определяют свободность-открытость технологии
основные вопросы к Google были по 2 пунктам:
1) интеллектуальная собственность на API (тут все следили так как это касается не только google vs oracle, но и все индустрии)
2) авторское право на исходники (вопросы к копипасту с удалением headers об авторах)
последнее время в этой части движение активное началось, помимо грааля зашевелились ibm
http://www.eclipse.org/omr/
по осени дополнительно и свою версию jit открыли, в перспективе рассчитывают целиком свою версию jvm выложить и дальше двигаться по принципу Oracle «есть открытая версия, а есть наша сертифицированная с поддержкой, разница минимальная». http://openj9.mybluemix.net/
в
>> Начиная с Java 9, Graal можно использовать как JVM плагин.
первичная идея была предоставить интерфейс JIT для поддержки сторонних реализаций
http://openjdk.java.net/jeps/243
Но есть сборки jvmci и для java 8, так что при желании можно гонять уже сейчас
>> А следующие части не относятся к OpenSource
>> Поддержка AOT
но тут пошли поезда от Марка Райнхольда и случился http://openjdk.java.net/jeps/295
в итоге core часть от graal уже войдет и в кодовую базу java 9
1) атомарное увеличение-уменьшение количества ссылок не самая быстрая операция, а там нужна именно атомарная, так как часто мы не знаем куда убежала ссылка на объект и какие потоки еще держат данный объект
2) полностью вопроса с паузами он не снимает, хотя и делает на порядки более предсказуемым поведение.
Про второй пункт более подробно:
представьте что у Вас имеется структура в виде дерева и в программе держится только корень,
в какой-то момент корень выходит из зоны видимости и следовательно может быть собран,
после того как собран корень уменьшаются счетчики на объекты которые держались корнем и они тоже отправляются на удаление
и так проходит по всем элементам
в итоге у Вас возникает проблема, что выход из блока и инвалидация всего одной ссылки вызывает каскадную нагрузку на работу с памятью и очень часто предсказать Вы не можете в каком месте это выстрелит.
в классических языках с поколениями пройдет фаза mark и потом copy в новую область все кто выжил, а не будет вызываться пачка мелких удалений, просто пометим всю область как мусор и занулим.
p.s. известный факт: иногда из программы проще выйти по exit сразу в операционную систему, чем аккуратно освободить все участки памяти по очереди =) это касается любого managed языка
Верифицировать и гарантировать работу ВСЕХ составляющих дорого, долго и не имеет смысла.
Shubinpavel уже вам ответил за космос: проблема зачастую в ресурсах (время, деньги, человеки) когда сознательно идут на срезание улов и уход от поставленных требований к проверке надежности, но чтобы было хоть что-то, а не воздушные замки в мечтах.
NASA имеет бюджет, любой спутник или ракета имеет бюджет, поэтому иногда возможно рискнуть и попытаться запустить сейчас с вероятностью неудачи в 0.001% чем пропустить запуск и ждать следующих 4-5 лет для появления окна запуска. В случае неудачи у вас есть риск строить такой же аппарат еще 8 лет, но это сознательный риск.
Не задумывались почему даже на Curiosity обновление прошивки заливали уже после достижения Марса: в момент отправки оно просто не было готово, не хватает ресурсов.