• Опасности метода finalize
    0
    Ага, спасибо, Руслан. Очень разумно звучит. Особенно понравились твои рассуждения про old-gen, про это я вообще ничего не писал и не задумывался даже об этом.
  • Опасности метода finalize
    0
    В комментариях к коду Cleaner написано, что в отличие от finalize он не делает jni up call. Так что получается, что действительно быстрее.
  • Опасности метода finalize
    –2
    Ну что он реально делает? Говорит GC, что теперь объект можно собирать? И получается, если его не вызвать, то объект никогда и не собереться?
  • Опасности метода finalize
    –1
    Кто-нибудь знает, зачем в конце обязательно вызывать super.finalize() и почему в конце, а не в начале?
  • Опасности метода finalize
    –1
    Если у вашего логера есть метод finalize, то нужно исопльзовать защитную технику: в логгере должен быть волатайл флаг, который выставляется при его финализации, а все метод логирования сначала проверяют этот флаг.

    И про второе дополнение тоже спасибо.
  • Как мы избавились от пауз GC с помощью собственного java off-heap storage решения
    0
    ответил в предыдущем комменте
  • Как мы избавились от пауз GC с помощью собственного java off-heap storage решения
    0
    Проект большой, в том числе есть задачи которые можно решать локальным off-heap кэшом. Выборочные апдейты, выборочное чтение и фильтрация действительно много используются. К тому же если есть логика тесно связанная с данными, почему бы ей не находиться в том же процессе на удаленных распределенных кэшах.
  • Как мы избавились от пауз GC с помощью собственного java off-heap storage решения
    0
    Ключом может быть любой java объект. У нас это обычно лонги, они все же в хипе лежат, большие объекты в виде ключей, могут свести на нет все усилия освобождения heap. Как на картинке нарисовано, ключи лежат по сути в обычной хешмапе, а значение — адрес в памяти процесса вне хипа.

    Для сериализации используем отдельно описанную логику. Эта логика так же позволяет делать выборку и апдейты отдельных полей по сдвигам от изначального адреса.
  • Как мы избавились от пауз GC с помощью собственного java off-heap storage решения
    0
    А какое у вас железо и сколько секунд паузы на минорных сборках и stop-the-world фазах CMS?
    У нас все таки в памяти хранятся десятки гигабайт, используется commodity железо и CPU отдыхает.
  • Как мы избавились от пауз GC с помощью собственного java off-heap storage решения
    0
    Это было так давно, что вряд ли уже сможем поднять какую-то статистику. Сейчас при разработке любого функционала, мы сразу понимаем, в каком случае у нас могут возникнуть проблемы с GC и сразу делаем компонент с off-heap хранилищем, так что сейчас сложно сказать.
  • Как мы избавились от пауз GC с помощью собственного java off-heap storage решения
    0
    Oracle Coherence опять же совсем не дешевый и не open-source, что затрудняет с ним работу. К тому же, на сколько я знаю, off-heap конфигурация в Oracle Coherence появилась 2,5 года назад, нам же потребовалось решать проблемы с GC немного раньше.
  • Как мы избавились от пауз GC с помощью собственного java off-heap storage решения
    0
    Ну у нас все же в основном операции чтения и реже апдейта поля, при котором с большой долей вероятности не надо будет malloc-free делать.
  • Как мы избавились от пауз GC с помощью собственного java off-heap storage решения
    0
    C JRocket, к сожалению, опыта нет, но на JavaOne в прошлом году говорили, что на больших Heap он от пауз все равно не избавит.
  • Как мы избавились от пауз GC с помощью собственного java off-heap storage решения
    0
    Когда писался описанный фреймворк, azul еще не предлагал своего решения в этом плане. К тому же он платный и требует другую jvm. Текущее решение вполне удовлетворяет, поэтому в данный момент не рассматриваем.
  • Как мы избавились от пауз GC с помощью собственного java off-heap storage решения
    0
    Если поймем, что это будет много кому интересно, то почему бы и нет.
  • Недопонимание CAP-теоремы
    0
    Да, совершенно с вами согласен.
  • LRU, метод вытеснения из кэша
    0
    О том какие готовые решения предоставляет Java можно почитать в статье Java LRU Cache
  • Недопонимание CAP-теоремы
    +1
    Я смотрю данный топик побудил уже третью публикацию о CAP-теореме, что меня конечно же не может не радовать. Я сначала сомневался, писать или нет об этом всём. Думал закидают же тухлыми помидорами. Ан нет, действительно нашлось о чем поговорить!
  • Разъяснение по CAP-теореме
    0
    Дмитрий, спасибо большое за подробное разъяснение. К сожалению, статью увидел только сегодня, поэтому и коммент пишу только сейчас.

    В целом, я с Вами абсолютно согласен, действительно, теорема построена и доказана для модели. Я в своем топике, в комментариях, к сожалению ушел от темы теоремы и стал рассуждать о возможности построения CA системы в «реальном мире». Хотя, впрочем, теоретическая часть теоремы мне не очень интересна, мне важно ее применение на практике.

    Но все же напишу пару слов о некоторых ваших высказываниях, которые меня немного покоробили:

    1. Чисто формально в теореме Avalability — это способность давать ответ не упавших компонент. Т.е. пример о невозможности построения системы со 100% avalability в терминах теоремы не совсем корректен. Мне все таки кажется создать систему полностью согласованной или полностью доступной в терминах теоремы все же можно, в отличие от системы без 100% потерь связи. Но Вы совершенно правы, в теореме мы имеем дело с моделью, поэтому об этом говорить можно.

    2. Ваш пример CA системы, где придется что-то чинить руками в случае маловероятного сплита, мне кажется не совсем хорошим, так как во время починки, ваша система уже не будет A, соответственно, и не будет CA.

    3. Вы привели очень хороший пример с домом. И я как практик с вами очень даже соглашусь. Но как теоретик, я призадумаюсь. Ведь, если уж мы говорим о теореме с моделью, то как-то называть систему сначала CA, а потом, когда что-то произошло называть CP или AP, не кажется мне очень логичным. Все таки в теореме мы говорим о постоянном свойстве системы, с обозначенными свойствами модели.

    Еще раз повторю, что с мыслью проходящей сквозь весь Ваш топик я абсолютно согласен. Теорема — эта модель и, что ее нельзя получить в реальном мире, ее это мало волнует. Однако переходя все же из теоремы в реальный мир, я вижу очень полезное утверждение, которое напрямую следует из этой теоремы. Так как в реальном мире устойчивость к сплиту достичь на 100% невозможно (но вы совершенно верно, невозможно пока), то и построить систему на 100% удовлетворяющую CA невозможно. Ну или можно еще сформулировать как это Вы сделали, т.е. можно, но до первой потери сообщения.

    Нда, немного противоречивый комментарий получился. Ну уж какой есть :)
  • Недопонимание CAP-теоремы
    0
    Спасибо за ссылки. Ознакомился с понятием fencing, но как на основе его сделать CA систему там, к сожалению не написано. Посмотрите, я апдейт в конце топика написал. Вобщем попытки построить CA систему, в который возможны потери между компонентами системы, значит опровергнуть CAP-теорему, думаю не стоит больше этим заниматься.
  • Недопонимание CAP-теоремы
    0
    Наверное, надо закрывать топик. Написал вконец поста апдейт.
  • Недопонимание CAP-теоремы
    0
    Я больше чем уверен, что любой дизайн в общем виде можно очень просто объяснить на пальцах. Но раз вы просто кидаете ссылки, то я что-нибудь одно постараюсь сегодня посмотреть и завтра отпишусь.
  • Недопонимание CAP-теоремы
    0
    Я весь внимания как Вы это будете делать.
  • Недопонимание CAP-теоремы
    0
    эээ… Ну в этом случае изменения применяться на {A,B} и будут не консистенты с нодой С.
  • Недопонимание CAP-теоремы
    0
    Ну я специально сузил область рассуждений до распределенных хранилищ данных, возможно в этом дело.
  • Недопонимание CAP-теоремы
    0
    Ну с этим вроде никто не спорит уже. Скорее четко объяснили, зачем P введена в CAP-теореме.
  • Недопонимание CAP-теоремы
    0
    Сорри, неправильно прочитал ваш предыдущий коммент.

    Ну что-то вроде этого. Надеялся, что кто-то меня переубедит, но как-то не переубедили пока:)
  • Недопонимание CAP-теоремы
    0
    Ну есть и PA. В комментариях даже было несколько примеров. А вот CA ни одной не было.
  • Недопонимание CAP-теоремы
    0
    Раз сессия клиента обрывается, то записи он не может осуществлять, значит 100% доступности нет.

    «Неработающий мастер=неработающая система. Это к CAP-теореме не относится.» Ну как не относиться. Здесь получается single point of failure, от которого распределенные системы позволяют опять же избавиться. Разве это не получается, что 100% доступности опять нет?

    При такой логике мы сваливаемся к централизованной системе в итоге, а не распределенной. А топик именно об распределенных системах.
  • Недопонимание CAP-теоремы
    0
    Расскажите как в описанной системе происходит запись. Давайте для упрощения пусть у нас будет один мастер и одна read-only нода. Как данные, записанные на мастер, попадают в read-only копию, и что произойдет в момент когда связь между мастером и read-only копией потеряется, а между клиентом и read-only останется?
    Так же что значит мастер отказоустойчивый внутри? Т.е. они никогда не падает? Такого не бывает.
  • Недопонимание CAP-теоремы
    0
    Я тут так понимаю тут зависит от того, что в этом случае показывает Twitter. Если он показывает, ой извините у нас поломка, я вам не могу показать данные, которые на самом деле у меня есть, то это отказ в обслуживании, т.е. потеря avalability.
    Если же он просто тупо их отрезает, делая вид, что их никогда не было, это наверное уже можно посмотреть как потерю consistency.

    Кто как думает?
  • Недопонимание CAP-теоремы
    0
    Я тоже, об этом и хотел написать :)
  • Недопонимание CAP-теоремы
    0
    Я абсолютно согласен, что построить нераспределнную систему CA, в терминах обсуждаемой теоремы можно. Я просто говорю, что она формулировалась именно для распределенных систем, что и хотел обсудить в этом топике.
  • Недопонимание CAP-теоремы
    0
    Zorkus, извините, не совсем понимаю к чему Вы апеллируете. Вы приводите два дизайна систем: CP и AP, где жертвуется доступностью или согласованностью, соответственно. Я себе очень хорошо, как можно построить такие системы. Я не могу себе представить CA систему, где есть и доступность и согласованность на 100%.
  • Недопонимание CAP-теоремы
    0
    Мне нечего Вам возразить, я, действительно, плаваю во всех этих формулировках.
  • Недопонимание CAP-теоремы
    0
    Вы сейчас о чем? Раз вы пишете в этой ветке обсуждений, то Вы все еще говорите о том применима ли CAP теорема для не распределенных систем. Так в той же википедии и написано: «эвристическое утверждение о том, что в любой реализации распределённых (sic!) вычислений возможно обеспечить не более двух из трёх следующих свойств»

    Если же Вы это приводите в качестве контраргумента, что распределенные системы существуют, то приведите общее описание такой системы, которая может этого достичь. Цитируемая строчка из википедии, мне не дает понять как такую систему построить.
  • Недопонимание CAP-теоремы
    0
    Вот тут как раз и недопонимание формулировки («Partition Tolerance не выполнено»). Я не говорю, что Вы его недопонимаете. Я думаю, что я его недопонимаю. Но на сколько я понял, в вашем примере как раз Partition Tolerance присутствует, т.е. система работает при разрыве межконтинентальной связи. Так как Partition Tolerance присутствует, то возможно обеспечить только что-нибудь одно. В вашем примере — это согласованность. Отличный пример, подтверждающий мой топик :) Разве нет?
  • Недопонимание CAP-теоремы
    0
    Нет, я как раз настаиваю на том, что в распределенной системе в реальном мире нельзя выбрать CA, только либо CP, либо AP.
  • Недопонимание CAP-теоремы
    0
    Вот и я так подумал, что это антонимы, поэтому и спросил в таком ключе :)

    А вот с тем что область применения CAP теоремы шире, я на согласен. Ведь, везде говориться что CAP теорема сформулирована именно для распределенных систем.
  • Недопонимание CAP-теоремы
    0
    Как это «всегда доступно», если Вы сами в своем первом комментарии пишете пишите, что «нет доступа к части данных — работа невозможна, все идут на обед.»