Сергей Горностаев, Ну где, где у меня негарантированное поведение или тем более недокументированая функция?! В любом, любом учебнике, начиная с Java 1.2 это стандартный и легитимный способ сортировки, любой коллекции.
А если у вас из многих потоков все делается, то будьте добры, позаботьтесь о иммутабельности и/или синхронизации.
Ну и что делать, если мне хеш свалился из какого нибудь API левого, как данность, мне на него теперь и дышать нельзя?
Сергей Горностаев, Т.е. вы подразумеваете, что при сортировке будет запись данных в коллекцию? Ну кто же так делает, без синхронизации?
Да и смотрю вот в класс TreeMap, а там болдом выделено Note that this implementation is not synchronized.
Т.е. по вашему он безопаснее?!
Александр Семененко, Ну, тогда я вам не помощник. Но я знаю, для работы 32бит системы нужны и библиотеки 32бит, также и для компиляции. Это я по аналогии с коросскомпилированием, нужно установить себе все окружение, потом работаешь.
Александр Семененко, Ну я не пробовал multiarch, но говорят, что работает.
А какие там зависимости могут поломаться?! Просто добавится пол системы в :i386
По моему, ломаться там нечему.
Ну и протестировать не помешает, сделайте себе тестовую виртуалку с x64 и установите multiarch i386, сразу все станет ясно, сломалось или нет. Заодно и нем расскажете.
Валентин, Ну и в догонку, а что вам запрещает сразу заливать файлы куда нужно? Через свой собственный json/rest/WEB-API? Я в своих приложениях так и делаю.
Валентин а чем sshfs/ftpfs принципиально отличается от nfs? Это же все равно Файловая Система (!), пусть и через FUSE, которая при монтировании и доступу к файлу/каталогу прорастет в ядро через VFS, будет сидеть ссылками и точками доступа в кешах ядра.
Любое отключение хоть локальной, хоть удаленной файловой системы без размонтирования равносильно вытаскиванию жесткого диска из сервера на горячую!
Да и сетевые файловые системы придуманы немного не для того, они нужны для прозрачной работы программ с удаленным хранилищем, как будто оно здесь и сейчас, включая, по возможности всякие POSIX вызовы.
Ну и по поводу:
Мне не сильно критично временная приостановка непосредственно аплода
У вас может остановиться не только аплоад, у вас встанет все, что хоть откроет файл/каталог через удаленную файловую систему, собственно весь IO пойдет на смарку.
Как раз ради этого и придумали "облака", облачные и объектные хранилиша - не зависеть от файловой системы, ее монтирования и размонтирования. Да, удобства работы конечно же гораздо меньше, нужно пользовать всякие библиотеки, интерфейс писали "чужие для хищников", но это то как раз и заточено под ваши задачи - кинуть файл в атрибутами и забрать его максимально быстро!
Но это будет работать только (!) при монтировании, и не спасет вас от ситуации обрыва связи при уже подмонтированной NFS. А здесь еще вступит в свои права ядро, которое до последнего будет пытаться достучаться до файлов, ядро то ведь не знает, что у него повис NFS, ему в рамках VFS все равно, через чего идет обращение, через сеть или через SATA/SAS.
Валентин, Честно говоря не помню, но не ошибусь, если скажу что в рамках NFS3/NFS4 такого функционала нет. Возможно есть в PNFS, но это отдельно разворачивать нужно, да и в стандартном кернельном сервере его нет, нужно ставить ganesha.
Поэтому и не рекомендую использовать файловые системы под это дело. У них другие задачи, вам же не критично показать код ошибки, при доступе к медиафайлу.
Что касается NFS, то это самый быстрый механизм дял доступа к удаленной файловой системе в линуксе. Мы, например используем NFS на кластере в пару десятков серверов, но это все локально в датацентре. Если же распрелеленно и для web, то я не советую таким образом отдавать данные.
А если у вас из многих потоков все делается, то будьте добры, позаботьтесь о иммутабельности и/или синхронизации.
Ну и что делать, если мне хеш свалился из какого нибудь API левого, как данность, мне на него теперь и дышать нельзя?