?

Log in

Вчера разбирался целый день с сабжем, думаю стоит записать для себя, а может кому ещё поможет (или кто подскажет что может я не так понимаю).
В принципе осенью коллеги без проблем подняли мини-кластер (из 2 хостов), поэтому было несколько неожиданно нарваться на то, что софт просто тупо не устанавливается: пакеты не находятся, пустая страница http://ppa.launchpad.net/ubuntu-ha/lucid-cluster/ubuntu/pool/ намекает, что кто-то что-то поломал. Судя по данным в ppa пакет redhat-cluster тупо сломан, а стабильный кластерный стэк теперь в ubuntu-ha-maintainers. Плюс ещё pacemaker-dlm переименовали в dlm-pcmk  да выделили отдельный ocfs2-tools-pacemaker.
Вроде всё установилось, только вот кластер ocfs2 не поднялся со словами Wrong stack o2cb. В интернетах нашлось только упоминание про отключение автостарта o2cb (т.к. pacemaker должен в итоге его стартом управлять), ну и естественно я это сделал (подглядывая в официальную подсказку).
Всё свелось к тому, что в /sys/fs/ocfs2/loaded_cluster_plugins числился именно o2cb (плюс ещё какие-то левые 4 нулевых байта).
Никаких оф. доков по переключению стеков не откопалось, поэтому после ковыряния скриптов pacemaker родился следующий вариант:

$ sudo modprobe ocfs2_stack_user
$ sudo modprobe -r ocfs2_stack_o2cb

В loaded_cluster_plugins появилось нужное "user" и ресурс o2cb ожил в pacemaker.

P.S. Если файловая система была создана с некорректным стеком, то это можно исправить следующим образом:
tunefs.ocfs2 --update-cluster-stack /dev/<ваш девайс>

Толь лыжи не едут...

Какая-то вот очень подозрительная ситуация:
Erlang, который типа fail fast, куча девяток и всё такое, и система буквально "зависает" раз в пару недель. И никаких намёков на то, что может быть причиной, так и не удалось обнаружить.
Из найденного только то, что работающим при вырубании по SIGUSR1 является процесс user_drv и "зависание" происходит посредине вывода в stdout. Поэтому единственная мысль, что какие-то вилы с системой вывода.

Толь лыжи не едут..

Сижу, думаю над вопросом - "это я тупой, или Spring Security действительно требует пары дней для сведения всех концов в рабочее приложение?"

Суммируя

Наверное в последнюю неделю года неплохо бы подвести некоторый итог и обернуться назад.
Что касается проф. деятельности, то в унисон предыдущему посту стоит сказать, что в данной области всё чаще приходит в голову мысль, что чем дальше, тем больше я понимаю, сколько же я ещё не знаю...
С другой стороны, текущее место работы, при всех его ньюансах, внушает некоторую надежду хотяб потому, что, спустя полгода после начала работы там, не возникает настойчивая мысль "а куда бы отсюда свалить".
Мысли о ФП в этом году так и остались мыслями, но, возможно, в следующем году найдётся место Scala.
В житейско-бытовом плане год был довольно насыщенным - сначала свадьба, потом покупка квартиры и, самое главное, рождение Даши. Так что поводы для оптимизма имеются :)
Посмотрим, что год следующий приготовит, и что произойдёт с идеями и ожиданиями...
Всем же желаю побольше позитива, удачи и приятных сюрпризов!

Tags:

Самокритичное

Последние полгода (или может побольше) назревает какое-то повышенное недовольство собой как профессиональным разработчиком. С одной стороны имеется уже не такой уж и малый опыт работы с разными технологиями и приёмами, но, в основном, на некотором "микроуровне" (ограниченном какой-то небольшой задачей), с другой же стороны создание чего-то более серьёзного и сложного и рассчитанного на долгий срок службы и развитие получается, честно скажем, плохо.
В качестве объяснения (а также, видимо, в вину себе) стоит назвать довольно частую смену работы (с десяток мест с довольно разнообразным набором задач/технологий), а "специалист подобен флюсу", как говорил Прутков не без доли правды.
Остаётся надеяться, что настойчивость и более чёткое понимание проблемы и внимание к ней, изменят ситуацию в нужную мне сторону.

Бедный-бедный лис...

Оказалось, что проблема в предыдущем случае была далеко не столько в генерации DOM, а просто Firefox очень хреново добавляет большие куски HTML (а у меня там треть мегабайта набегала) в отображаемую часть дерева. Причём скрытие элемента делает ситуацию ещё более загадочной, т.к. перерисовка, судя по всему, выполняется не менее тяжело, только выполняется асинхронно выполнению js.
В общем, не стоит отображать большие HTML с нетривиальной структурой в FF или пользуйтесь хромом, на текущем примере разница между ним и FF составляет аж 2 порядка (1,5с против 15мс).
Надеюсь, что в FF4 HTML-движок тоже был оптимитизирован, а не только js-часть.

Мир DOMу твоему

Ковыряясь с гапертоновским include.js на реальных примерах упёрся-таки на то, что манипуляция DOMом - вещь довольно тормознутая. Буквально, при выводе дочернего списка в 2 сотни формочек бедная лисичка начала скулить - один только рендеринг этого списка идёт больше 2 секунд. К тому же там идёт манипуляция через jQuery, а, судя по моим шутёвым тестам прямые операции быстрее где-то раза в 4 (при чём это соотношение есть и в хроме и в фоксе). Кстати, тут я почти впервые явно увидел насколько лучше v8 по сравнению с SpiderMonkey.
Прихожу к выводу, что на предложенном гапертоном подходе можно строить лишь проложения, оперирующие одновременно лишь ограниченным набором данных.
Кстати, в Knockout с точки зрения производительности, судя по всему, всё ещё грустнее, т.к. движок шаблонов там не быстрее, плюс добавляются ещё затраты на биндинг. Хотя с т.зр. построения гуя подход Knockout кажется несколько более логичным и прозрачным (правда он, судя по всему, "плоский", я не нашёл намёка на то, что там можно создавать что-то похожее на "виджеты, использующие виджеты")
Из других вариантов Sproutcore выглядит похожим на то, что им можно пользоваться, но какой-то он сложный, а документация не так чтоб полная и тестовый hello world грузящийся 5 секунд как-то "символизирует". А на ExtJS я пока так и не могу отважиться...
Видимо буду решать задачу на include.js вводя искусственные ограничения (всё равно смысла в списке больше 25 форм особо нет, и пагинацию никто не запрещал), возможно надо будет подумать как можно его подоптимизировать и совсем было бы круто воткнуть биндинги из KO.

So enterprisy...

Пробую тут нарисовать простенький интерфейс на js к REST-серверу на Spring MVC. Складывается впечатление, что им почти никто не пользуется, например, он не понимает POST в "application/x-www-form-urlencoded" (а чинить собираются только в 3.1), хотя есть вполне штатный FormHttpMessageConverter. Пришлось в итоге на стороне jQuery заворачивать объект в JSON.stringify().
P.S. Надо бы, конечно, с ExtJS разобраться, а не делать велосипедики на jQuery, но, видимо, не в рамках этой задачки.

В очередной раз вспомнилась эта песня после 2 часов войны с IE.
Понадобилось тут добавить jqGrid на сайт, всё вроде нормально, но вот пользователи с IE начинают роптать... Оказывается таблица тупо не показывает данные в этом гениальном браузере. Долгое тыкание туда-сюда ни к чему не привело, и я уже почти совсем отчаялся найти "где же собака порылась", как вдруг заметил, что на демо-сайте jqGrid JSON отдаётся с "Content-type: text/html", а на сайте с "Content-type: text/html; charset=cp1251" (да вот такой вот легаси в cp151). Выставление чуть более корректного "Content-type: application/json" всё поставило на свои места.