Здравствуйте, Cyberax, Вы писали:
C>Не гарантируют. В случае падений SQS сообщения ещё как теряются, хотя они в последнее время исправились и падать почти перестали.
У меня первый проект с sqs стартовал года 4 назад. Уже более 2х лет в проде. Через sqs идут сотни тысяч(если не миллионы) сообщений в месяц. Ни единого нарекания на sqs за все это время. Что я не так делал?
C>Аж 25% скидки за последний месяц. Прямо как санкции против Северной Кореи по своей жестокости.
Еще раз повторюсь,. ты упорно демонстрируешь неумение читать. Просто дофига бизнесов с этим ок, его все устраивает и они прекрасно понимают что велосипеды будут стоить гораздо дороже.
C>Именно так. И никакие Tibco не дадут существенно лучший SLA, потому нечего на него кивать.
Я бы так не обобщал, ну да ладно.
C>У меня есть данные от нескольких очень крупных падений Oracle, с многомиллионными убытками. Во всех случаях Oracle не заплатил напрямую ничего. Про Tibco аналогично слышал из первых рук, но сам не присутствовал.
Даже опуская выделенное, это ОБС.
C>Что она даст, если критические компоненты не работают? Куда будет disaster recovery, если состояние системы неопределенное из-за того, что очередь сообщений скопытилась?
Очевидно, что развернет критические компоненты в другом регионе(клауде) и начнет процесить сообщения из резервной очереди, запись в которую идет синхронно с записью в основную (или с небольшим лагом, ок).
C>В моём примере очередь распухает н е из-за дубликатов, а из-за того, что уникальные обращения перестают обрабатываться.
Давай я процитирую
Отставание backend'а продолжает нарастать. Клиенты frontend'а паникуют, повторяя операции всё чаще. Отставание нарастает.
Ты уж сам определись, какие сценарии мы рассматриваем а потом озвучивай их консистентно, ок?
C>Как это будет выглядеть на уровне API для клиентов?
Я уверен ты и сам прекрасно сможешь спроектировать REST API endpoint. И может быть даже реализовать
I>>Еще как поможет, разгребет потихоньку если входной поток ограничить как я описал выше. C>А нафиг он тогда нужен? Не проще ли использовать синхронные вызовы?
Иногда проще, иногда — нет. Типичный сценарий — пиковые нагрузки. Погугли что это такое и чем они отличаются от stable. Еще один сценарий долгоиграющие операции, например транскодинг видео. Перегонять 2х часовую порнуху серию игры престолов в формат для айпада синхронно — наверное не самая лучшая идея. Если ты не сталкивался с подобными кейсами — то это совершенно не означает, что их не бывает.
C>А бэкэнд всё равно должен быть надёжен, так как иначе никакие 100500 девяток в SLA не помогут.
Кому должен, зачем должен и главное кто будет все это оплачивать?
I>>Любой асинхронный сетевой выхов(те не требующий ответа о завершении операции) — по сути распределенная модель, часть состояния которой хранится в виде сообщений(с). C>В случае с синхронным вызовом состояние системы не хранится в сетевом соединении, кроме как для статуса последнего запроса.
Еще раз повторюсь:
Ты сейчас говоришь, что асинхронная модель программирования в распределенной системе не пригодна ни на что. Это очень смелое заявление. Не, я понимаю у тебя оно с кнопкой 'checkout shopping bag' не взлетело по каким-то причинам, но нельзя же все задачи программирования натягивать на кнопку checkout?
Меня очень заинтересовала эта ветка обсуждения, жаль, что до конструктива не добрались.
Пока суммируя недостатки озвученные выше вижу следующее — если еще осталось желание поправьте меня:
* Системы на сообщениях будут иметь меньшую availability из-за потерь сообщений, это можно отмести для систем, где availability самой message queue system вполне достаточна для бизнеса.
* С точки зрения сопровождения восстановление состояния системы при ошибке будет более сложным -- насколько я вижу correlation id / request id частично решает вопрос, но в случае потерь сообщений это становится сложным.
* Сложная обработка случаев типа multicast storm. Необходимо в архитектуру закладывать способ работы со сценарием когда система позволяет накопить больше сообщений, чем может обработать.
* Непонятен общий рецепт cirquit breaker'a для сценариев когда компонент принимающий сообщение отваливается с ошибкой и накапливаются retries (частично решается для ряда бизнес кейсов установкой visibility timeouts в большое значение или retry==0 когда можно считать что клиент просто каким-то образом поймет инициирует retry) либо ограничением на максимальную глубину очереди (как тогда обрабатывать клиентские запросы? получается что-то некрасивое когда клик по кнопке сразу приводит к ошибке из-за невозможности инициировать обработку). Установка retry==0 позволяет гарантировать лишь best effort обработку, большой visibility timeout создает угрозу перенасыщения сообщениями (см пункт выше).
Да, и отвечая на вопрос выше про альтернативы асинхронным сообщениям для критических сервисов используют workflow / orchestration engines типа Amazon SWF или Uber Cadence — последний уберовцы построили уже имея внутреннюю "durable and scalable" message queue system — cherami.
Пока вроде бы очевидна неприменимость message queue-based систем для построения систем требующих максимальной надежности типа обработки заказов от пользователя, которые часто строят на подобии orchestration engines и мне кажется тут у вас консенсус —
Cyberax:
Пока я для себя нашёл два нормальных применения очередей:
1) Раскидывание вычислений или длинных асинхронных задач по вычислительному кластеру.
2) Простые best effort fire-and-forget пинги для внешних систем с уведомлениями об изменениях.
itslave:
в спецификациях вполне может быть написано: "потеря до Х% данных допустима". Пример — влегкую, допустим у тебя сайт flightradar24, который прямо в риал тайме слушает местоположжение самолетов(они могут бродкастить каждую секунду) и рисует это на веб странце.
Видимо, все же с точки зрения применимости речь идет об одних и тех же сценариях — плюс может быть таких, где в отличие от Амазона не требуется >99.99% availability и хватит даже 99% -- суммарная недоступность сайта <4 дня в год вполне может быть приемлема для задач многих небольших компаний, если не брать в расчет области типа medicine и digital commerce.
И кстати, было бы интересно узнать — какой бизнес сценарий был решен на очередях?
Здравствуйте, A13x, Вы писали:
A>Здравствуйте, itslave, Вы писали:
I>>...
A>Меня очень заинтересовала эта ветка обсуждения, жаль, что до конструктива не добрались.
A>* Системы на сообщениях будут иметь меньшую availability из-за потерь сообщений, это можно отмести для систем, где availability самой message queue system вполне достаточна для бизнеса.
Вот имха, выделенное очень сильно зависит от используемых компонентов, сценариев, квалификации команды, бюджета на разработку и многих других факторов. Из моего опыта, надежность и availability промышленных очередей в разы выше любых велосипедов(включая прямые вызовы), напедаленых среднестатистической командой в (обычно) сжатые сроки.
С другой стороны, при нагрузках в миллионы операций в секунду, как у сайберакса, естественно что 90% промышленных очередей тупо не справятся и велосипеды придется строить. Но тут наверняка и бюджеты другие, и квалификация команды и так далее.
С третьей стороны, подобные нагрузки — ну оочень редки, хотя и интересны.
A>* С точки зрения сопровождения восстановление состояния системы при ошибке будет более сложным -- насколько я вижу correlation id / request id частично решает вопрос, но в случае потерь сообщений это становится сложным.
Строя любую распределенную систему процессинга/сохранения даных, надо помнить о том что eventual consistency — это плата за распределенную систему. Это надо учитывать с самого начала и временами оно бьет очень больно. Поэтому я всячески не рекомендую распределенные системы в тех случаях, когда без них можно обойтись. Еще один способ борьбы с eventual consistency системы — event log/event sourcing. Что в свою очередь привносит новые сложности, которые надо героически решать.
A>* Сложная обработка случаев типа multicast storm. Необходимо в архитектуру закладывать способ работы со сценарием когда система позволяет накопить больше сообщений, чем может обработать.
Да, это надо учитывать с самого начала.
A>* Непонятен общий рецепт cirquit breaker'a для сценариев когда компонент принимающий сообщение отваливается с ошибкой и накапливаются retries (частично решается для ряда бизнес кейсов установкой visibility timeouts в большое значение или retry==0 когда можно считать что клиент просто каким-то образом поймет инициирует retry) либо ограничением на максимальную глубину очереди (как тогда обрабатывать клиентские запросы? получается что-то некрасивое когда клик по кнопке сразу приводит к ошибке из-за невозможности инициировать обработку). Установка retry==0 позволяет гарантировать лишь best effort обработку, большой visibility timeout создает угрозу перенасыщения сообщениями (см пункт выше).
Как то так, нет универсальных сценариев. Каждый раз надо смотреть на требования и работать с ними. еще можно разворачивать дополнительные мощности динамически, уменьшать пропускную способность фронтенда(по сути переносить очередь на веб сервера), в конце концов честно умереть.
Все зависит исключительно от бизнеса, бюджета и так далее.
A>Да, и отвечая на вопрос выше про альтернативы асинхронным сообщениям для критических сервисов используют workflow / orchestration engines типа Amazon SWF или Uber Cadence — последний уберовцы построили уже имея внутреннюю "durable and scalable" message queue system — cherami.
Да, по сути — actor model в разных ипостасях. Еще можно делать централизированно на ESB. A>Пока вроде бы очевидна неприменимость message queue-based систем для построения систем требующих максимальной надежности типа обработки заказов от пользователя, которые часто строят на подобии orchestration engines и мне кажется тут у вас консенсус -
Вот опять, все зависит от требований, нагрузки и так далее. ИМХА просто нельзя сравнивать решения для клепания сайта веб магазина аквариумных рыбок в мухосранске и для того же амазона. Соглашусь с сайбераксом, что в последнем случае любое лишнее звено привносит дополнительные риски и надо все упрощать настолько, насколько возможно.
A>Видимо, все же с точки зрения применимости речь идет об одних и тех же сценариях — плюс может быть таких, где в отличие от Амазона не требуется >99.99% availability и хватит даже 99% -- суммарная недоступность сайта <4 дня в год вполне может быть приемлема для задач многих небольших компаний, если не брать в расчет области типа medicine и digital commerce.
Из моего опыта, сейчас обычно бизнес требует 99.95% availability для client-oriented веб сайтов. И это число легко достигается очередями. Более того, очереди позволяют увеличить availability системы по сравнению с прямыми вызовами в целом ряде сценариев — можно делать даунтайм consumer-ам очередей (почти)незаметно для пользователя с гарантированной сохранностью данных.
A>И кстати, было бы интересно узнать — какой бизнес сценарий был решен на очередях?
Уже штук несколько, самый крупный пожалуй — аналог coursera для "реальных" американских университетов, вроде как лидер в своей отрасли.
Здравствуйте, A13x, Вы писали:
A>* Непонятен общий рецепт cirquit breaker'a для сценариев когда компонент принимающий сообщение отваливается с ошибкой и накапливаются retries (частично решается для ряда бизнес кейсов установкой visibility timeouts в большое значение или retry==0 когда можно считать что клиент просто каким-то образом поймет инициирует retry) либо ограничением на максимальную глубину очереди (как тогда обрабатывать клиентские запросы? получается что-то некрасивое когда клик по кнопке сразу приводит к ошибке из-за невозможности инициировать обработку). Установка retry==0 позволяет гарантировать лишь best effort обработку, большой visibility timeout создает угрозу перенасыщения сообщениями (см пункт выше).
Судя по статьям из интернета (читал на msdn), cb это просто умный retry. Я так понимаю, что по уму его всегда и надо использовать. Но в имплантации он сложнее.
A>И кстати, было бы интересно узнать — какой бизнес сценарий был решен на очередях?
Создание асинхронных сервисов. Можно почитать кто и зачем пользует те же rabbit mq
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, A13x, Вы писали:
A>>* Непонятен общий рецепт cirquit breaker'a для сценариев когда компонент принимающий сообщение отваливается с ошибкой и накапливаются retries (частично решается для ряда бизнес кейсов установкой visibility timeouts в большое значение или retry==0 когда можно считать что клиент просто каким-то образом поймет инициирует retry) либо ограничением на максимальную глубину очереди (как тогда обрабатывать клиентские запросы? получается что-то некрасивое когда клик по кнопке сразу приводит к ошибке из-за невозможности инициировать обработку). Установка retry==0 позволяет гарантировать лишь best effort обработку, большой visibility timeout создает угрозу перенасыщения сообщениями (см пункт выше).
S>Судя по статьям из интернета (читал на msdn), cb это просто умный retry. Я так понимаю, что по уму его всегда и надо использовать. Но в имплантации он сложнее.
Да. Тут очевидна необходимость использовать комбинированный подход и тут, видимо, можно придумать много решений — например если очередь используется для асинхронной обработки объектов описание которых хранится в некоторой БД, то можно добавить описание состояния асинхронной обработки и сделать retry возможным только по прошествию некторого дельта t от момента начала и ввести Janitor Job который бы рестартовал зависшие таски путем переотправки сообщений. Тогда клиенты не порушат систему ретраями и по достижению насыщения системы сообщениями часть будет отработана через janitor job.
A>>И кстати, было бы интересно узнать — какой бизнес сценарий был решен на очередях?
S>Создание асинхронных сервисов. Можно почитать кто и зачем пользует те же rabbit mq
Да это понятно, просто было бы интересно разобрать спор выше на примере конкретных бизнес требований, чтобы просто оценить применимы будут альтернативные решения.
Здравствуйте, itslave, Вы писали:
I>... I>Вот опять, все зависит от требований, нагрузки и так далее. ... A>>Видимо, все же с точки зрения применимости речь идет об одних и тех же сценариях — плюс может быть таких, где в отличие от Амазона не требуется >99.99% availability и хватит даже 99% -- суммарная недоступность сайта <4 дня в год вполне может быть приемлема для задач многих небольших компаний, если не брать в расчет области типа medicine и digital commerce. I>Из моего опыта, сейчас обычно бизнес требует 99.95% availability для client-oriented веб сайтов. И это число легко достигается очередями. Более того, очереди позволяют увеличить availability системы по сравнению с прямыми вызовами в целом ряде сценариев — можно делать даунтайм consumer-ам очередей (почти)незаметно для пользователя с гарантированной сохранностью данных.
Ну тут у нас консенсус, у меня нет явного неприятия очередей, по сказанному выше можно сделать вывод — очереди могут упростить ряд задач, но сами по себе не панацея и их использование в production системе требует учета факторов связанных с fault сценариями — обвязка специализированным логированием, хранение состояния обработки для предотвращения перенасыщения сообщениями и для введения если нужно janitor job позволяющего рано или поздно закончить асинхронную обработку.
A>>И кстати, было бы интересно узнать — какой бизнес сценарий был решен на очередях? I>Уже штук несколько, самый крупный пожалуй — аналог coursera для "реальных" американских университетов, вроде как лидер в своей отрасли.
Я хотел предложить разобрать конкретный кейс и альтернативные реализации для одних и тех же требований — было бы интересно сравнить решение предлагаемое cyberax'ом против решения на очередях.
Здравствуйте, A13x, Вы писали:
A>Я хотел предложить разобрать конкретный кейс и альтернативные реализации для одних и тех же требований — было бы интересно сравнить решение предлагаемое cyberax'ом против решения на очередях.
Ну давай попробуем, все равно проект заканчивается, скучаю.
Сценарий 1(несколько упрощенней чем в реальности)
Преподаватель загружает лекцию на сервер(S3 де факто) для того чтобы студенты могли ее просмотреть.
После загрузки надо
— проанализировать формат видео
— запустить транскодинг в необходимые форматы(mp4, aac)
— сгененировать thumbnails
— по окончанию всего что выше — отметить лекцию как новую и готовую к просмотру
— послать нотификацию студентам которые включены в соответсвующий курс
Все операции (транскодирование, thumbnails, нотификация) организована на сообщениях в очереди. Агрегация — в бд.
Сценарий 2
Преподававтель заходит на веб сайт и меняет description к видео.
Изначально планировалось делать асинхронно через очереди, с обновлением кеша. Это было связано с тем что проектировался multiregional deployment и соотвсетвенно репликая БД во все регионы. По результатам тестов, это занимало до 10 минут, в среднем 2-3.
Но потом решили деплоиться в один регион и сделали синхронный вызов.
Сценарий 3
Студент заходит на страницу лекции. Надо послать соотвествующее сообщение для сбора статистики — какие видео популярны и так далее.
Сделано опять таки на очередях.
Сценарий 4(другой проект)
Имеется несколько сервисов, которые общаются друг с другом. Разрабатываются разными командами, деплоятся независимо друг от друга и достаточно внезапно, с даунтаймами. Коммуникация между командами плохая(разные компании, разные континенты). Тут Внедрение сервис баса сильно все упростило. Появилось полное tracebility коммуникации, формат сообщений валидируется сервис басом, retry полечил проблемы независимого деплоймента, dlq, помогло при траблшутинге, минорные изменения формата сообщений полечилось трансформацией на сервис басе и закончился пинг-понг между командами что "у нас все работает".
Первые три сценария — очереди используются там и только там, где обработка запроса может занимать неприличное (больше 1 минуты) время.
Четвертый сценарий — проблемы менеджмента и технологического стека. Микросервисы без единой системы логгирования и трассировки просто не взлетят, умение писать и поддерживать стабильное сетевое API тоже обязательно.
Я так понял, у вас малонагруженные системы, где хранилища никогда не переполняются, а ресурсов всегда хватит, чтобы обработать запрос вовремя. В высоконагруженных системах всё не так — при отказе консумера очередь может переполниться за несколько минут, периодически кончается место на диске, одна из машин в кластере может "заболеть" непредсказуемым образом — от выключения до длительного раздумия над каждым запросом, ресурсов периодически не хватает для обработки всех запросов от клиентов.
И все перечисленные ситуации не являются авралом или критическими ошибками — система должна либо не допускать их вообще, либо восстанавливаться автоматически.
В таких системах очереди нужно использовать очень осторожно, т.к. они передают данные в одном направлении, не позволяя консумеру предупредить паблишера о потенциальных проблемах в системе.
Здравствуйте, scf, Вы писали:
scf>Здравствуйте, itslave, Вы писали:
scf>Первые три сценария — очереди используются там и только там, где обработка запроса может занимать неприличное (больше 1 минуты) время.
выносить в бекенд операции, которые выполняются милисекунды... наверное бывают такие кейсы, но в общем случае
это не нужно имха, даже с микросервисами.
scf>Четвертый сценарий — проблемы менеджмента и технологического стека.
Но esb порешал же с минимальными усилиями. Налаживать процессы. было бы больно, дорого и не факт что получилось бы. scf> Микросервисы без единой системы логгирования и трассировки просто не взлетят, умение писать и поддерживать стабильное сетевое API тоже обязательно.
И полностью автоматизированный деплоймент. IaaC. scf>Я так понял, у вас малонагруженные системы, где хранилища никогда не переполняются, а ресурсов всегда хватит, чтобы обработать запрос вовремя.
Все в мире относительно — десчтки(в пике сотни) тысяч конкурентных сессий система держит и все хорошо.
cf> В высоконагруженных системах всё не так — при отказе консумера очередь может переполниться за несколько минут, периодически кончается место на диске, одна из машин в кластере может "заболеть" непредсказуемым образом — от выключения до длительного раздумия над каждым запросом, ресурсов периодически не хватает для обработки всех запросов от клиентов.
Опять таки, все относительно. Я с трудом представляю что надо сделать, чтобы забить амазоновский sqs. Мониторинг, автоматическое масштабирование групп серверов, деплоймент всей стстемы в другой регион(и даже к другому клаудному провайдеру при первых признаках жопы решают огромное кол-во сценариев.
scf>В таких системах очереди нужно использовать очень осторожно, т.к. они передают данные в одном направлении, не позволяя консумеру предупредить паблишера о потенциальных проблемах в системе.
Опять таки, почему нотификация паблишера о проблемах — это задача консьюмера, а не мониторинга?
Здравствуйте, itslave, Вы писали:
I>Но esb порешал же с минимальными усилиями. Налаживать процессы. было бы больно, дорого и не факт что получилось бы.
Ну да, в данном случае ESB — тот самый вариант, когда взяв технологию вместо технической культуры, получаешь быстрый результат со сложными последствиями.
I>Опять таки, все относительно. Я с трудом представляю что надо сделать, чтобы забить амазоновский sqs. Мониторинг, автоматическое масштабирование групп серверов, деплоймент всей стстемы в другой регион(и даже к другому клаудному провайдеру при первых признаках жопы решают огромное кол-во сценариев.
SQS оплачивать под высокой нагрузкой — никаких денег не хватит. Значительно дешевле все-таки разобраться с кафкой.
I>Опять таки, почему нотификация паблишера о проблемах — это задача консьюмера, а не мониторинга?
Т.е. когда мониторинг собирает статистику с консьюмера и при превышении некоторых метрик говорит паблишеру снизить скорость? Имхо, слишком сложно и не взлетит. Встроить такого рода логику в сетевой клиент (разные коды ошибок, таймауты, реконнекты) значительно проще.
Здравствуйте, scf, Вы писали:
scf>Ну да, в данном случае ESB — тот самый вариант, когда взяв технологию вместо технической культуры, получаешь быстрый результат со сложными последствиями.
"Сложные последствия" существуют исключительно в твоих фантазиях
scf>SQS оплачивать под высокой нагрузкой — никаких денег не хватит. Значительно дешевле все-таки разобраться с кафкой.
Это будут доли процента от оплаты EC2, других сервисов и бизнеса вообще. У SQS не "забивается" очередь(кроме масштабов сайберакса наверное), не заканчивается место на диске, его не надо деплоить, он с гораздо меньшей вероятностью упадет и так далее.
scf>Т.е. когда мониторинг собирает статистику с консьюмера и при превышении некоторых метрик говорит паблишеру снизить скорость? Имхо, слишком сложно и не взлетит. Встроить такого рода логику в сетевой клиент (разные коды ошибок, таймауты, реконнекты) значительно проще.
Почему? Мониторить загрузку все равно надо. Реагировать на то что жопа наступает все равно надо. Почему бы еще одним шагом в этой цепочке не поставить нотификацию паблишеру? Гораздо проще вынести это в отдельное место, чем тулить в бизнес логику.
Здравствуйте, scf, Вы писали:
scf>В таких системах очереди нужно использовать очень осторожно, т.к. они передают данные в одном направлении, не позволяя консумеру предупредить паблишера о потенциальных проблемах в системе.
В чем проблема 2 очереди использовать -- одну для задач косумерам, другую для репорта от них же паблишера?
Здравствуйте, Sharov, Вы писали:
S>В чем проблема 2 очереди использовать -- одну для задач косумерам, другую для репорта от них же паблишера?
Если паблишеров несколько? Если проблема с конкретным запросом? Если реакция нужна сразу, а не когда паблишер получит сообщение от консумера? Если получит вообще — консумер может быть перегружен или поломан.
Две очереди в разные стороны — это популярная схема "нас заставляют сидеть на тибке, а нам нужно RPC".
Здравствуйте, scf, Вы писали:
scf>Если паблишеров несколько?
У каждого своя очередь. Хотя этот вариант не очень масштабируется.
scf>Если проблема с конкретным запросом?
Тут уже пляски намечаются -- попытаться изобразить тайм-аут в асинхронной системе.
scf>Если реакция нужна сразу, а не когда паблишер получит сообщение от консумера? Если получит вообще — консумер может быть перегружен или поломан.
В этом случае очередь не подходит.
scf>Две очереди в разные стороны — это популярная схема "нас заставляют сидеть на тибке, а нам нужно RPC".
Здравствуйте, scf, Вы писали:
scf>Если паблишеров несколько? Если проблема с конкретным запросом? Если реакция нужна сразу, а не когда паблишер получит сообщение от консумера? Если получит вообще — консумер может быть перегружен или поломан.
Вот тут начинают рулить сервис басы, которые в отличии от простых очередей поддерживают разные интеграционные паттерны.
scf>Две очереди в разные стороны — это популярная схема "нас заставляют сидеть на тибке, а нам нужно RPC".
ЕМНИП тибко поддерживает request-reply, и даже умеет делать ретраи в обе стороны.
Здравствуйте, Cyberax, Вы писали:
C>Если по каким-то причинам шаг Б начинает тормозить, то мы можем получить ряд интересных вариантов развития событий. Очередь начнёт расти неограниченно, при этом в зависимости от политики очереди новые сообщения могут вообще не обработаться (если FIFO и есть таймаут).
Это не проблема конкретно очередей. Это проблема асинхронной обработки в принципе. Как обычно тут трейдофф — либо у нас нет reliability, либо мы должны быть готовы к неожиданному распуханию очередей. Второе не так уж и сложно, если в системе нет серьезных ошибок — резерв по размеру и хорошо настроенный скейлинг вполне успешно с таким борются.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
