Управление пулом буферов с помощью C#
Как сказано в документации Apache Tomcat :
Сравнение строк используется для определения порядка версий.
blockquote>Это просто не то же самое, что сравнение версий артефактов Maven. Версия 2.0.2 всегда больше при сравнении строк, чем 2.0.10 или даже 2.0.15000 и т. Д.
Я полагаю, у вас есть что-то подобное в вашем
pom.xml:${maven.build.timestamp} yyyyMMddHHmm ${project.artifactId}##${project.version}_${maven.build.timestamp} Вы можете изменить это на:
${project.artifactId}##${maven.build.timestamp}_${project.version} , что дает имя файла, например
WebappName##201901010000_0.2.10-SNAPSHOT.war.Таким образом, самая текущая сборка по метке времени будет развернута как текущая активная версия приложения.
В качестве альтернативы вы можете сохранить схему версий имени файла .war и вместо этого развернуть свое приложение, используя версионное имя файла для вашего context.xml:
[ 112]
apache-tomcat/conf/Catalina/localhost/WebappName##201901010000.xmlс содержимым:В Apache Tomcat Manager это будет отображаться как версия 201901010000 в столбце версии приложения. Снова самая последняя сборка по метке времени будет развернута как текущая активная версия приложения, независимая от версии артефакта Maven, так как версия развертывания String берется из имени файла .xml вместо имени файла .war.
4 ответа
Управление памятью C# sharps на самом деле довольно хорошо, таким образом, вместо того, чтобы иметь пул буферов, Вы могли просто выделить точно, что Вы нуждаетесь и засовываете его в очередь. После того как Вы сделаны с буфером, просто позволяет сборщику "мусора" обработать его.
Еще одна опция (знающий только очень мало о Вашем приложении), состоит в том, чтобы обработать сообщения минимально, поскольку Вы получаете их и превращаете их в абсолютные объекты (с приоритетами и всеми), затем Ваша очередь могла расположить по приоритетам их только путем исследования корректного набора атрибутов или методов.
Если Ваши сообщения наталкиваются слишком быстро даже на минимальную обработку, у Вас могло бы быть две системы очереди. Каждый - просто очередь необработанных буферов, и следующая очередь является очередью объектов сообщения, созданных из буферов.
Я надеюсь, что это помогает.
Почему Вы только не получили бы сообщения, создать DeviceMessage (из-за отсутствия лучшего имени) объект и поместить тот объект в Очередь? Если установление приоритетов важно, реализуйте класс PriorityQueue, который обрабатывает это автоматически (путем размещения объектов DeviceMessage в первоочередной заказ, поскольку они вставляются в очередь). Походит на большее количество подхода OO и упрощал бы обслуживание со временем относительно установления приоритетов.
Я делаю что-то подобное. У меня есть сообщения, входящие на потоках MTA, которые должны быть обслужены на потоках STA.
Я использовал BlockingCollection (часть параллели fx расширения), который контролируется несколькими потоками STA (настраивающийся, но значения по умолчанию к xr * количество ядер). Каждый поток пытается вытолкать сообщение от очереди. Они или приводят к таймауту и попробовали еще раз или успешно выталкивают сообщение прочь и обслуживают его.
У меня есть соединенный проводом со счетчиками perfmon для отслеживания время простоя, длины задания, входящие сообщения, и т.д., который может использоваться для тонкой настройки настроек очереди.
Необходимо было бы реализовать пользовательский набор или возможно расшириться до н.э, для реализации приоритетов объекта очереди.
Одна из причин, почему я реализовал его этот путь, - то, что насколько я понимаю теория массового обслуживания обычно способствует одной строке, несколько-серверов (почему я чувствую, что собираюсь поймать дерьмо об этом?).
@grieve: Сеть является родной, это означает, что при использовании буферов для приема / отправки данных в сети они закрепляются в памяти. см. мои комментарии ниже для уточнения.