Всё классно, если вы работаете с проверенным знакомым прибором и можете доверять его данным.
На практике китай-трекеры(а равно и отечественные говнотахографы) могут не то, что HDOP не передавать(это вообще редкость), но и врать насчёт кол-ва спутников/курса/скорости, передавать данные в чёрт-пойми каком порядке и т.п.
Всё как написано выше.
Руками собрать свою jar-ку в которой будет свой кастомный ZoneInfoProvider и скомпилированная tzdata в ресурсах, положить куда-нибудь рядом с приложением, добавить её в classpath и добавить ключик JVM -Dorg.joda.time.DateTimeZone.Provider
Никто за вас вашу jarку автоматически не обновит.
Оно сейчас работает(с кастомным write-behind), есть-пить не просит вот и не торопимся.
Код его, честно говоря, мне тоже не слишком нравится. А какие альтернативы? Вы что-нибудь присматривали?
Надо бы переползти чтоли с 3.1, т.к. в 3.2+ сделали нормальный write-behind в MapStore, но также и сломали протокол и чтобы обновить 3.1 до 3.3 надо все ноды остановить, обновить и запустить снова.
Требования к паролю: от 6 до 20 цифр, не менее 3-х различных цифр,
не допускается введение подряд одной и той же цифры, не должен совпадать с УНК/логином.
О как я вас понимаю! Это реально был ад, особенно на заре(2010-2011 гг). Я пилил тогда одну вещь под Samsung TV, удалось даже App Certification пройти. Как вспомню так вздрогну.
lordbss.narod.ru/pmk29.html
Цель игры: пролететь по заданному маршруту, т.е. подняться над горой, поднырнуть под тучку, ещё раз подняться над горой, зайти на посадку и приземлиться.
Вот в такую, помню, играли на калькуляторе у друга.
Это был просто шик :)
OrderedMemoryAware — нужен не для эффективности, а для того чтобы соблюдался порядок выполнения событий в канале + защита от ООМ.
Для boss, нафиг не нужен, да и для worker тоже. Лучше создать отдельный executionHandler и запихать его в конец pipeline, если вас заботит очередность обработки событий в канале и есть какая-то блокирующая работа + можно выкинуть ваш QueueHandler.
connectTimeoutMillis — не имеет смысла для серверных каналов.
На практике китай-трекеры(а равно и отечественные говнотахографы) могут не то, что HDOP не передавать(это вообще редкость), но и врать насчёт кол-ва спутников/курса/скорости, передавать данные в чёрт-пойми каком порядке и т.п.
Тьху, неруси :-D
Руками собрать свою jar-ку в которой будет свой кастомный ZoneInfoProvider и скомпилированная tzdata в ресурсах, положить куда-нибудь рядом с приложением, добавить её в classpath и добавить ключик JVM -Dorg.joda.time.DateTimeZone.Provider
Никто за вас вашу jarку автоматически не обновит.
see github.com/JodaOrg/joda-time/blob/master/src/main/java/org/joda/time/tz/ZoneInfoCompiler.java и кастомным ZoneInfoProvider
и подсунуть руками через system property -Dorg.joda.time.DateTimeZone.Provider=my.foo.CustomZoneInfoProvider
Код его, честно говоря, мне тоже не слишком нравится. А какие альтернативы? Вы что-нибудь присматривали?
Но только одни цифры всё равно доставляют.
О как я вас понимаю! Это реально был ад, особенно на заре(2010-2011 гг). Я пилил тогда одну вещь под Samsung TV, удалось даже App Certification пройти. Как вспомню так вздрогну.
www.wondeproud.com/product_5_1_2.html
Цель игры: пролететь по заданному маршруту, т.е. подняться над горой, поднырнуть под тучку, ещё раз подняться над горой, зайти на посадку и приземлиться.Вот в такую, помню, играли на калькуляторе у друга.
Это был просто шик :)
OrderedMemoryAware — нужен не для эффективности, а для того чтобы соблюдался порядок выполнения событий в канале + защита от ООМ.
Для boss, нафиг не нужен, да и для worker тоже. Лучше создать отдельный executionHandler и запихать его в конец pipeline, если вас заботит очередность обработки событий в канале и есть какая-то блокирующая работа + можно выкинуть ваш QueueHandler.
connectTimeoutMillis — не имеет смысла для серверных каналов.
Channel.getId() — готовый уникальный идентификатор.
>>synchronized(channel)
зачем ??
Нафига для bossExecutor использовать OrderedMemoryAwareThreadPoolExecutor?