Отдельно хочется отметить, что OnlyOffice как СПО также не попадет ни под какие антисанкции: )

а вам спасибо за вопрос. рады, что всё завелось: )

Если вы разворачивали Enterprise на виртуалке, то у вас, скорее всего, упал супервизор. Поднять его можно. Попробуйте поднять на Docker'e, а не на, например, VmWare. Также похожие проблемы обсуждаются на форуме разработчиков. Можно там посмотреть/написать.

Проблема существует, и мы её решаем. По большей части торомоза вызваны портированием .net приложения под mono. Сейчас ждем выхода asp.net vnext, который должен избавить нас от большей части подобных трудностей.

Описанная вами ситуация вызвана вот чем: при первом старте приложения мы, динамически, в несколько потоков, проходим по всем страницам приложения, отображая пользователю страницу прогрева. Во время прогрева создаются asp.net temporary files, и это занимает значительное время. При рестарте прогрев осуществляется в фоновом режиме.

Однако всё это временно — это всего лишь первая версия, над улучшением которой мы работаем каждый день.

последний раз когда пытался запустить ваши образы на centos 7, именно он у меня почему-то так и не запустился

Давайте разберемся! Какое сообщение об ошибке вы получили? Развертывали по инструкции?

Для упрощения развертывания ONLYOFFICE, в состав Enterprise-версии мы включили контрольную панель, которая позволяет в один клик обновить/проинсталлировать CommunityServer, DocumentServer, Mailserver, ControlPanel.

почему вы свой mailserver в DockerHub не переведете на Automated Build?

На самом деле, мы могли бы. Но на данный момент нам удобнее делать сборку и присваивать ей имя. Для отслеживания версий/поддержки обновлений мы помечаем отдельным тэгом каждый выпуск CommunityServer, DocumentServer, Mailserver, ControlPanel. Control Panel в новой коммерческой сборке ориентируется на выставленные тэги в DockerHub, и, в зависимости от полученной информации, отображает, доступно обновление или нет.

Ни одного программиста не пострадало.

Без WS сейчас трудно представить приложение, которому нужен быстрый отклик.
Ещё не хватает переключения на другой протокол, если вдруг не получилось соединиться по WS.

Речь о concurrent connections. Вот, например, статья на эту тему
Я и не говорил, что Rabbit нельзя использовать с ASP.NET.

Я уже писал, что у нас изначально было два сервера:
— совместного редактирования, изначально написанный на Node.JS
— вторая часть, которая конвертировала, собирала, раздавала документы (он был на ASP.NET)
Так вот, мы не просто так транслировали на другой язык, но и добавляли необходимый функционал.

Что-то держали в памяти, что-то в базе. Но самое главное, что мы держали большое число соединений (изначально использовали Node.JS на сервере совместного редактирования) и не могли перекидывать сообщения для пользователей одного документа между серверами. Теперь можем, благодаря Rabbit.
И да, сколько одновременных соединений может держать Asp.Net?

Например, в предыдущей реализации серверов мы не могли просто взять и поднять ещё один сервер совместного редактирования по необходимости.
Теоретически можно было только распределять по нескольким серверам по определенному правилу, но с существенным ограничением: все пользователи одного документа должны быть на одном сервере.
Ниже в комментарии я приводил схему текущей реализации.

Не просто портировали, а переписывали руками. И это было достаточно волевым решением, несмотря на то, что наша команда и на C#, и на C++, и на JS умеет писать.

Самый главный аргумент — это кроссплатформенность. Да, согласен, портирование простого проекта и Mono потянет. На что-то сложное его не хватает.
Наш C# код открытый, можно посмотреть вот тут — github.com/ONLYOFFICE/DocumentServer

В ближайшее время не планируем.

Я понимаю, что Вы уже давно это переписывали, но Вы смотрели в сторону ASP.NET 5 (Vnext)?
Там должно быть меньше багов, ведь реализация идет от Microsoft?

Пробовали. На начало перехода все было достаточно сыро.
Мы же не просто так переделывали, но и добавляли необходимый функционал. Например, заложили возможность масштабирования.

Точно так же, как с request и express, все это есть в npm. Почему дописывать руками?

Собственно мы и используем пакеты из npm (mkdirp, например).
Про «дописывать руками» имелось ввиду, что «в коробке» c Node.JS не идет.

В случае Node.JS вы не запускаете свой код в чёрном ящике? А учитывая уход от статической типизации.

Любой framework можно отчасти считать «чёрным ящиком». Но тут ситуация такая: изначально код писался под ASP.Net («черный ящик»), его портировали с помощью Mono («черный ящик»). В итоге получаем произведение «черных ящиков».
Да, можно было править баги в самом Mono. Но когда выходит его новая версия и появляются новые?
По поводу статической типизации — хотелось бы, но с другой стороны у нас основная часть редакторов была на JS (клиентская), поэтому привыкли.

Как мне видится, на всех платформах, на которых вы планируете разрабатывать полностью присутствует Mono.
Я так понимаю в угоду моды ваши приложения теперь начнут работать с бОльшим откликом для пользователя. Спасибо.

Мы переделывали не в угоду моде. У нас было два разных сервера:
— совместного редактирования, изначально написанный на Node.JS
— вторая часть, которая конвертировала, собирала, раздавала документы
И одним из желаний было их объединить.

открытие/сохранение документов, сборка изменений — все это написано на c/c++. так что с докх на c# не работаем.

очень большие там тормоза. работать на мой взгляд невозможно.

передал дизайнерам)