BlazkowiczИ память, как я понимаю, там тоже не регулируется.
- негодяям использующим глючные фреймворки жрущие кучу памяти настоятельно предлагают отправиться на тариф "Большой" где созданы все условия для такого гадства :)

- а тариф "Стандартный" для простых ребят, использующих Java для создания гостевых книг, небольших каталогов и т. п., т. е. мечтающих вытеснить PHP из занимаемой им ниши :)

Blazkowicz Kachalov- а тариф "Стандартный" для простых ребят, использующих Java для создания гостевых книг, небольших каталогов и т. п., т. е. мечтающих вытеснить PHP из занимаемой им ниши :)
Можно мемори лик и в гостевой книге написать, без проблем.
- в таком случае либо гуманитарно-интеллектуальная подмога со стороны суппорта (хотя некоторые чудики обижаются и говорят что у них ошибок быть не может, это мол сервер криво настроен), либо тариф "Большой" - перезапускай свой Tomcat хоть по пять раз на день :)

BlazkowiczМожно мемори лик и в гостевой книге написать, без проблем.
- кстати более популярная ошибка - ДБ-connection leak

Софтверный проктолог Kachalov- кстати более популярная ошибка - ДБ-connection leak
К сожалению, Tomcat не умеет их отлавливать самостоятельно. А фреймворки типа Spring умеют?
- эта ошибка связана с неправильными настройками JDBC-пула в приложении в сочетании с отсутствием метода close() при использовании соединений (или close() находящийся в блоке который при некоторых случаях не выполняется), а так Spring использует те же JDBC-пулы, то ошибку такого рода можно получить и в Spring :)

Blazkowicz Kachalov- в таком случае либо гуманитарно-интеллектуальная подмога со стороны суппорта (хотя некоторые чудики обижаются и говорят что у них ошибок быть не может, это мол сервер криво настроен), либо тариф "Большой" - перезапускай свой Tomcat хоть по пять раз на день :)
То есть хостер оставляет щза собой правот отказать в услуге в случае нестабильной работы приложения?
- хостер оставляет за собой право приостановить действие услуги, в случаях, когда пользователь своими действиями создает затруднения для других клиентов (а если он кривым кодом выел всю память в разделяемом Tomcat, можно считать что он создал затруднения). Это нормальная практика и все хостеры так поступают независимо от того о чем идет речь: CPU, ОП, трафик, файловая система, почта и т. д. и т. п. (все случаи предусмотреть сложно). Т. е. если приложение падает - это проблемы клиента, а когда оно грузит ЦПУ или выедает память на разделяемых серверах создавая проблемы другим клиентам, то да, услугу приостановят.

- в договоре обычно есть пункт типа:
авторИсполнитель вправе приостановить доступ Заказчика к Услугам без предупреждения в случае нарушения Заказчиком обязанностей, предусмотренным настоящим Договором, либо когда Заказчик вовлечен в действия, которые Исполнитель, считает нарушающими настоящие Договор и Приложения к нему, а также на основании получения обоснованных претензий от иных Заказчиков и третьих лиц

Alexey TurnПо теме: на джаве скушно писать без фреймворков, а фреймворки мугут себя чувствовать отлично только на выделенном сервере(машине) в этом и есть отличие джавы от пхп.
- на PHP написано много могучих CMS, которые в какой то степени являются аналогами фреймворков используемых в Java web-программировании, и, также как и Java фреймворки, часто требуют снижения безопасности для работы и увеличения ОП, также частенько для их работы требуется подкомпилировать к PHP-парсеру экзотические модули. Так что и PHP сайты, бывают не так уж "просты" в плане развертывания на сервере и иногда также требуют VPS для нормальной работы.

- я бы сказал, что криво написаные Java-фреймворки/PHP-CMS (имеющие избыточное количество функций разной степени глючности, которые нельзя легко отключать/подключать) сближают обе технологии в вопросах требований к хостингу :)