Вобщем написал сам на коленке. Получилось довольно удобно, теперь только им и пользуюсь. Есть возможность либо слать на FTP, либо на picasaweb. github.com/Tema/screenshot
В конфигурировании приложений нередко встает задача в различном наборе значений свойств для разных окружений (PROD, TEST, UAT, DEV, ...). Так же бывыает удобно когда есть возможность поменять какое-либо свойство для конкретного пользователя или комьпютера\приложения в кластере. К сожалению, я пока еще не встретил ни одного более-менее удобного открытого конфигурационного туда для этой цели (но видел уже как минимум два тула, которые были написаны внутри разных компаний для этой цели). Тот же Commons Configuration как-то уж мало что может предложить. Если будете о нем писать, упомяните и этот аспект.
Ой тут эта фича тоже платная. Впрочем, считаю, это вполне обоснованным, так как нужна она обычно для коммерческого использования. Жалко, правда, что её опробовать даже нельзя. Я правильно понимаю что в Base URL можно прописать базовый url, к которому будет просто имя файла загруженного на фтипишкник добавляться?
Может кто-нибудь знает, есть ли похожий сервис, но чтобы можно было настроить так, чтобы он скриншоты автоматически отправлял на заданный FTP, и в буфер обмена клал ссылку на него? Нужда в том, чтобы скриншоты за пределы интранета не выходили. Я видел в www.jetscreenshot.com/ есть опция сохранения на FTP, но она платная и непонятно можно ли настроить, чтобы ссылка в буфер на загруженный файл помещалась.
С точки зрения программиста это называется согласованным чтением, которое достигается путем уровня изоляции REPEATABLE_READ. Но Вы правы я забыл упомянуть одну очень важную деталь, что другие БД (в которых нет внутренней поддержки версионности на уровне операторов по умолчанию) получат кривые суммы только в случае уровня изоляции READ_COMMITTED, который и выбирается в большинстве случаев.
В других БД, чтобы получать всегда согласованный результат придется выставлять уровень REPEATABLE_READ, который они обычно достигают путем выставления строчных разделяемых блокировок чтения, которые, могут легко приводить к дедлокам. Например, если в описанном случае во время чтения большой таблицы одной транзакцией, другая транзакция попытается перевести деньги с последней строчки в первую и выставлен уровень REPEATABLE_READ, то и получиться дедлок.
Мнения о других БД я взял из книжки Тома Кайта 2005 года, так что возможно «многие другие БД» к сегодняшнему моменту уже перешли на поддержку версионности данных и построчными блокировками на чтение больше не балуются. Если кто знает, напишите в комментарии плиз.
Я забыл упомянуть, что, к сожалению, все мои знания ограничиваются девяткой. Прописал это явно во вступлении.
Про NO_LOGGING я конечно дал маху, по правде говоря никогда не использовал на практике, но всегда хотел. Вообще удалил абзац про него.
Про потерю данных и nologging — не нашел, честно говоря, где я писал про это. Да с Вами абсолютно согласен, что при обычно крэше ничего не потерять. Разве что во время крэша сломался еще и диск на который журнальный файл писался (если только он не писался параллельно на несколько дисков), в этом случае можно потерять немного последних изменений, но совсем немного, разумеется.
Спасибо за критику, поставил вам плюсик за коммент.
Во многом согласен с Вашими комментариями, правда, не понятно, зачем Вы полезли под кат, если уже читали книгу Кайта. В хабре не хватает возможности указать уровень аудитории на которую рассчитана статья: begginer, intermediate, expert… Хотя, конечно, в большинстве случаев можно указывать это явно в начале текста.
Да, что и говорить до Тома мне далеко, не поспоришь.
Все обороты — это в большинстве случаев отсебятина, а не подхваченные словечки из кривых переводов. Уж простите, но я на великого литератора я не претендую.
У Кайта по всему этому написана целая книга, а у меня только короткий топик, поэтому написать обо всем конкретно в таком формате попросту невозможно, о чем я и упомянул в заключении, если Вы дочитали до него.
По поводу категоричных утверждений тоже с Вами согласен, где-то я пытался вставлять слова «в большинстве случаев» и «скорее всего», но в большинстве случаев, неверное, опустил. Связано это с тем, что я описывал основной случай, а на исключения места уже не хватало, и так обо всем очень кратко писал.
Буду очень признателен, если укажете конкретно на смысловые ляпы.
Если бы вы запускали тесты на HotSpot JVM для java 6 update 23 или выше, то результаты StringBuilder и StringBuffer скорее всего дали бы идентичные результаты, так как начиная с этой версии по умолчанию включен EscapeAnalysis, который увидел бы что StringBuffer исползуется только одним потоком и не синхронизировал бы код вообще, тем самым превратив его по сути в StringBuilder
Интересно, правда, не понятно почему вы перезапускаете всю систему, а не только плохой поток. Или вы просто не можете его корректно остановить? Кстати, кто-нибудь знает можно ли жестко убить в java поток или это невозможно теоретически сделать не только в java?
Спасибо, но в этом месте я больше упор делал на бесконечные циклы в системах, которые обрабатывают сообщения последовательно, т.е. пока не обработан предыдущий, следующий не обрабатывается. И тут таймеры точно не могут. Твой случай скорее отностится к тротлингу (Degradate gracefully. Throttling).
нет, для других платформ справедливы тоже, за исключением разве что RMI. Но опять на других платформах тоже могут быть протоколы использующие произвольные порты. Например, CORBA, на сколько я слышал тоже грешит этим. Хотя, наверное, в некоторых случаях это даже удобнее, чем явное конфигурирование всего и всея. Правда, пока у вас не появляется firewall.
Формально вы конечно же правы. Хотя никто не будет спорить, что доминирующая реализация — это HotSpot, так что, если ничего об этом не написано, то стоит предполагать что имеется ввиду именно она.
Я же давал ссылку в на свой блок в этой статье в пункте про PermGen, где подробно описывается почему это может происходить и что с этим делать.
Конечно каждый конкретный случай надо разбирать отдельно. Если же не хочется разбираться, профайлить и искать причину, чтобы её фиксить, то если у вас CMS, попробуйте -XX:+CMSPermGenSweepingEnabled
-XX:+CMSClassUnloadingEnabled
Или еще вариант — возьмите JRocket (попробовать можно бесплатно), там говорят вообще проблем нет.
Или дождитесь пока oracle JRocket смержит в HotSpot.
Я тогда абзац про флаг в windows из своей статьи удаляю? pyatigil, можете дать ссылку про то что вы говорите? Или есть еще эксперты в этой области подтвердить сказанное pyatigil?
Ну у меня вебсервер был. Тогда еще Servlet API 3.0 не было. Так что пул добавить для асинхронной обработки каких-то действий пользователя я не мог.
Хотя на самом деле томкат-то использует внути пул, чтобы обрабатывать запросы клиентов. Просто если он маленький, а клиентов много, то они начинают отваливаться по HTTP с таймаутом, поэтому размер этого пула и пришлось увеличивать все больше и больше.
github.com/Tema/screenshot
Интересно у них есть корпоративные лицензии?
С точки зрения программиста это называется согласованным чтением, которое достигается путем уровня изоляции REPEATABLE_READ. Но Вы правы я забыл упомянуть одну очень важную деталь, что другие БД (в которых нет внутренней поддержки версионности на уровне операторов по умолчанию) получат кривые суммы только в случае уровня изоляции READ_COMMITTED, который и выбирается в большинстве случаев.
В других БД, чтобы получать всегда согласованный результат придется выставлять уровень REPEATABLE_READ, который они обычно достигают путем выставления строчных разделяемых блокировок чтения, которые, могут легко приводить к дедлокам. Например, если в описанном случае во время чтения большой таблицы одной транзакцией, другая транзакция попытается перевести деньги с последней строчки в первую и выставлен уровень REPEATABLE_READ, то и получиться дедлок.
Мнения о других БД я взял из книжки Тома Кайта 2005 года, так что возможно «многие другие БД» к сегодняшнему моменту уже перешли на поддержку версионности данных и построчными блокировками на чтение больше не балуются. Если кто знает, напишите в комментарии плиз.
Я забыл упомянуть, что, к сожалению, все мои знания ограничиваются девяткой. Прописал это явно во вступлении.
Про NO_LOGGING я конечно дал маху, по правде говоря никогда не использовал на практике, но всегда хотел. Вообще удалил абзац про него.
Про потерю данных и nologging — не нашел, честно говоря, где я писал про это. Да с Вами абсолютно согласен, что при обычно крэше ничего не потерять. Разве что во время крэша сломался еще и диск на который журнальный файл писался (если только он не писался параллельно на несколько дисков), в этом случае можно потерять немного последних изменений, но совсем немного, разумеется.
Во многом согласен с Вашими комментариями, правда, не понятно, зачем Вы полезли под кат, если уже читали книгу Кайта. В хабре не хватает возможности указать уровень аудитории на которую рассчитана статья: begginer, intermediate, expert… Хотя, конечно, в большинстве случаев можно указывать это явно в начале текста.
Да, что и говорить до Тома мне далеко, не поспоришь.
Все обороты — это в большинстве случаев отсебятина, а не подхваченные словечки из кривых переводов. Уж простите, но я на великого литератора я не претендую.
У Кайта по всему этому написана целая книга, а у меня только короткий топик, поэтому написать обо всем конкретно в таком формате попросту невозможно, о чем я и упомянул в заключении, если Вы дочитали до него.
По поводу категоричных утверждений тоже с Вами согласен, где-то я пытался вставлять слова «в большинстве случаев» и «скорее всего», но в большинстве случаев, неверное, опустил. Связано это с тем, что я описывал основной случай, а на исключения места уже не хватало, и так обо всем очень кратко писал.
Буду очень признателен, если укажете конкретно на смысловые ляпы.
Правильно, надо или нет добавлять CMSPermGenSweepingEnabled зависит от версии Java. Тем кто еще сидит на пятерке вполне может понадобиться.
В JRockit я не силен. Просто об этом сказали на javaone. За что купил, за то и продаю.
Конечно каждый конкретный случай надо разбирать отдельно. Если же не хочется разбираться, профайлить и искать причину, чтобы её фиксить, то если у вас CMS, попробуйте
-XX:+CMSPermGenSweepingEnabled-XX:+CMSClassUnloadingEnabled
Или еще вариант — возьмите JRocket (попробовать можно бесплатно), там говорят вообще проблем нет.
Или дождитесь пока oracle JRocket смержит в HotSpot.
Хотя на самом деле томкат-то использует внути пул, чтобы обрабатывать запросы клиентов. Просто если он маленький, а клиентов много, то они начинают отваливаться по HTTP с таймаутом, поэтому размер этого пула и пришлось увеличивать все больше и больше.