Кто вам сказал что оно течет? Все же вероятнее Jetty подойдет вам лучше. Компактнее, быстрее, код проще и с ним удобнее и приятнее работать в разных use кейсах

Авторы Jetty - perfomance дрочеры, что не может не радовать

А как вы с USB будете читать? Если натив, то лучше там посмотрите чтобы не текло, вместо того чтобы утечки в pure-java продакшн серверах искать

Довольно продвинутые люди, юзавшие жаву с ее рождения.

А так, гуглинг по «tomcat memory leak» и «jetty memory leak» выдает кучу еды :)

Сейчас кто-то предложит Common Lisp.

Ну меньше чем на джаве утечек памяти все равное нигде нет, а так напишите независимый от движка код и потестируйте конкретные версии разных контейнеров. Заранее волнуетесь

Весь код на железке, включая USB, предположительно, будет из трех с половиной строчек. Мотивация простая, нету кода - нечему ломаться. И нечего сертифицировать, потому что подобные устройства проходят жесткую сертификацию.

Эта штука должна годами работать без перезагрузок. А все что может (и будет) ломаться - будет происходить уже на наших серверах, а не в железяке.

Самая опасная часть будет как раз в используемой технологии (виртуалка, сервер, фреймворк. либы).

о том, как правильно юзать USB я потом еще поспрашиваю в /development :)

Python, для web-интерфейса - любой фреймворк с WSGI.

А потом кто-нибудь предложит Haskell.

Если боитесь либ, то напишите нативный код и возможно вам улыбнется удача, но Java действительно уже имеет имунитет. Любые утечки в ней являются следствием феерического явного ССЗБ, который мне кажется врядли будет иметь место на продакшн серверах. Но если у вас простая задача, то возможно крутить там jetty будет слишком.

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

Еще вариант - предусмотреть простой рестарт, который сможет делать тот кто на месте, даже не обладая квалификацией. Или вы сами удаленно

> Еще вариант - предусмотреть простой рестарт, который сможет делать тот кто на месте, даже не обладая квалификацией. Или вы сами удаленно

1) железяка будет стоять в труднодоступных местах
2) лучше всего вообще запретить какое-то влияние на железяку. Внутри ценные данные, которые клиент, возможно, хотел бы подделать. Лучше всего было бы вообще взрывать все содержимое ящика к чертям собачьим при попытке отключить его от электричества, или там намертво заваривать расплавленным металлом, но это фантастика...

Если кто-нибудь бы еще привел шокирующие данные о невероятной стабильности Хаскеля, было бы вообще апупенно!

Чем не подходит длительное стресс тестирование? Простая система диагностики? (o, shit, утечка памяти, насрать в логи перезагрузиться)

JVM врядли потечет, если кровь из носу не нужен HTTP, то забейте на него и напишите все на сокетах. Такое на Java течь не будет.

Откуда она возьмется? Мульйоны бабла надо

lua

Erlang+yaws+C дрова на железку?

стресс-тестирование мы организуем. Но тупое стресс-тестирование - это очевидно, универсально и потому неинтересно для обсуждения :)

Интересно было бы поговорить о преимуществах и косяках технологий, которыми пользуются лоровцы :)

Хотя, если ты можешь рассказать какие-нибудь серебряные пули из мира стресс-тестирования, поделиться историями успеха и неуспеха, это была бы вкуснотища!

Если Play - то зачем сервлет-контейнер? У Play же основной режим работы - сам-себе-контейнер. Поддержка сервлет-контейнеров там вроде чисто для совместимости.

Присоединяюсь. Зачем такой студенто-фреймворк на железку с такими требованиями?

You receive a bug report that in one of your instant messaging (IM) servers, the euro symbol is reaching its final destination in a garbled form. You find the error in the library module that maps special characters, correct the bug, recompile the code, and test it. When it’s validated, you transfer the patch to the live servers and load it in the Erlang runtime system. The next time a euro symbol is received, the patched module will be used and the euro symbol will be mapped correctly.

Это к вопросу нужна ли тебе мифическая супер-стабильность или лучше возможность на лету исправлять возникшие ошибки.

Как один из вариантов. Прототип есть с его участием, как и положено прототипу - будет выкинут :) А что будет вместо - размышляем.

1) Веб-интерфейс 2) Чтение raw data с USB 3) Потоковая предобработка и засылание куда-то в интернеты этого потока raw data

в 80% случаев, покупаете железку которая УЖЕ это умеет, подпиливаете/заказываете п1. (веб-интерфейс) под свои термины и пару форм, в итоге имеете готовое изделие на опробированной и отлаженной вдоль и поперёк до вас платформе. На вскидку функционал п2,3 реализован в куевой туче cctv и скуд контроллеров, в лабараторных контроллерах, просто в универсальных контроллерах а-ля Lego, в USB over IP железяках, и так далее.. Тут не то чтобы Tomcat, тут Linux-то не особо нужен :)

> Потом нас начали пугать страшилками, что Томкат - решето и отчаяно течет. И Jetty тоже.

Разрешать сборку мусора в PermGen пробовали?

Идея хорошая, но есть неприятное но: таким образом клиент может попытаться загрузить какую-нибудь самописную бяку, чтобы подделать данные в железяке. Какой-нибудь гений напишет бяку, выложит на рапидшаре, и каждая домохозяйка сможет поломать все к чертям собачьим. Пока заюзан самый простой способ - железяка может только отдавать инфу, а тому что в нее прилетает (типа запросов к веб-интерфейсу) она старательно не доверяет.

Как думаешь, стоит ли рискнуть безопасностью ради возможности автоматических обновлений?

Внутри ценные данные, которые клиент, возможно, хотел бы подделать. Лучше всего было бы вообще взрывать все содержимое ящика к чертям собачьим при попытке отключить его от электричества, или там намертво заваривать расплавленным металлом, но это фантастика...

Подобное применяется в карточных терминалах. Если че (любая попытка физического взлома), стираются ключи в SRAM, и терминал уходит в глухую оборону. Ну и цифровая подпись во все поля. Постороннее не загрузишь, не запустишь.

По существу:

1) Если так боитесь утечек памяти, используйте сервер вообще без динамического выделения памяти. В принципе, таковой можно сделать, если задачи ограничены. Может, уже есть что-то готовое.

2) У меня был весьма положительный опыт с языком Lua. Там есть расширение для работы с сокетами и какой-то HTTP-сервер с возможностью написания Web-приложений.

ЛОР глючит

Не получается ответить на комментарий. Придется отвечать цитируя руками :(

Угу, кто-то деплойнул не то

> покупаете железку которая УЖЕ это умеет

уже умеет что?

в 80% случаев, покупаете железку которая УЖЕ это умеет

конкуренты уже есть. Главная наша фишка - железяка будет для нищебродов, плюс реализована пара десятков ноу-хау. Можно купить готовую отлаженную платформу, но, к сожалению, она будет дорогой, совсем не нищебродской.

> сервер вообще без динамического выделения памяти

хмммм, а это идея!

теперь бы найти какой-нибудь параноидальный жавовский фреймворк, который умел бы это искаропки =)

> стираются ключи в SRAM ... Ну и цифровая подпись

блджад, это гениально. Пошел думать ;)

JVM, -Xmx )))

уже умеет что?

чтение raw-data с USB, поточная обработка и пересылка в интернетные *беня :) Тут Linux, Tomcat (и наверное ещё СУБД) нужны только для попила бабла и спонсирования студентам на еду.

У вас цель-то какая ? сделать и продать вещь, или заюзать Java ?

> чтение raw-data с USB, поточная обработка и пересылка в интернетные

Назови какое-нибудь конкретное устройство? Или фирму, чтобы позвонить им и задолбать вопросами

Нужна
1) сабжевая пересылка 2) сохранение всего на встроенный жесткий диск или SSD
Если есть специализированные железяки, и они дешевле маленькой китайской материнки на которую впихуется Линукс, то я был бы счастлив :)

Тут Linux, Tomcat (и наверное ещё СУБД) нужны только для попила бабла и спонсирования студентам на еду.

1) На линукс можно накатывать апдейты. На спаянную ручками ламповую фигню - нет.
2) Свою программу в случае сбоев - можно самостоятельно починить. Чужой контроллер - нельзя, даже если он программируемый, хотя бы потому, что мы нифига не поймем, как он работает.
3) Наш электронщик оценил разработку прототипа «цельно-железного» сервера в 3 месяца - черновой вариант и 6 - относительно продакшеновый. На жаве мы написали полнофункциональный прототип за чуть более чем неделю неспешных ковыряний.

как вариант использовать нечто вида: java/scala + akka-http / netty + akka-actors + libusb либо же: c++ + boost-asio (там простой http сервер в примерах идет) + libusb

Если есть специализированные железяки, и они дешевле маленькой китайской материнки на которую впихуется Линукс, то я был бы счастлив

если задача более контрольно-измерительная - по старой памяти owen, segnetics, может ещё кто появился на рынке, если multimedia (всякие звук/видео) - например tral. Любая компания которая делает свои железки будет только рада новому рынку, тем более партнёрам с собственными тематиками/программистами.

Но это вам не поможет :) Если уж начали делать без иследования рынка и поиска партнёров, и прицелились сделать и содержать свой велосипед, знать такова ваша судьбина.

$25k за сетевую лицензию LispWorks Enterprise, мне $5k за оказанные консалтинговые услуги.

Вот когда ВВС США перейдут с JOVIAL и Ada на Haskell, тогда я смогу назвать его стабильным.

P.S. не любитель хаскеля :)

>Если в железяке есть утечка, то в случае чего ее можно ребутнуть и перепрошить (накатить апдейты). НО целевая аудитория не будет этого делать. Придется высылать доктора, чтобы зачистить все проблемы.

А что мешает повесить демона-жЫвотное (watchdog) который, при приближении свободного ОЗУ к критическому значению, будет принудительно оправлять жестянку в ребут?

Да ладно, зачем там такое жывотное, когда есть простой скрипт:

#!/usr/bin/env sh if ! ps xa | grep -v grep | grep java; then rcjava restart; fi

Ну, а об остальном позаботится OOM-Killer. Так все программы и надо писать. Сустемд как раз и придуман, чтобы облегчить тяжелую судьбину мистера Кодера.

>Да ладно, зачем там такое жывотное, когда есть простой скрипт:

На чем писать жЫвотное — дело уже десятое)

чего он такой дорогой то?

Я бы конечно пропиарил здесь http://nodejs.org/ но меня сейчас наверно закидают чем-то дурно пахнущим.

чего он такой дорогой то?

На одного девелопера $4500 :)

Успокоили :)

Ну и почему ещё никто не посоветовал G-WAN?