По-моему, уже в начале 2000-х был доказан тезис о том, что никакой контент защитить впринципе невозможно, пока пользователь контролирует воспроизводящее устройство. Как крайний случай: контент перехватывается при воспроизведении, и заново оцифровывается уже без защиты.
Полностью с вами согласен, коллега. Причем налицо парадокс — сложность разработки с каждым годом растет гораздо быстрее, чем сложность самих приложений. Интересно, когда же наступит технологическая сингулярность?
Видите ли, я вообще родом из 90-х. И на протяжении всей своей жизни видел и разрабатывал достаточно сложные десктопные приложения, используя разные технологии, начиная от MFC, VCL, QT, Java Swing и заканчивая Android-ом. Для меня достаточно сложным приложением является например Microsoft Word. И могу заявить, что даже он не тянет за собой все эти тонны нестабильного и постоянно меняющегося говна, и прочего псевдокода. Возможно в Microsoft все делают как-то неправильно и не концептуально, но люди как-то до сих пор обходились и обходятся. Уж не знаю что представляют из себя эти мифические "полноценные SPA приложения", но в реале дело не уходит дальше банального дешбоарда или десяти формочек с кнопочками, привязанных к страничной навигации. И мне очень смешит и одновременно нервирует, когда люди, имеющие в кармане язык с динамической типизацией, говорят о концептуальности использования Redux. Более того, я из области бекенда. Долгое время у нас был JavaEE, на смену которому постепенно пришел Spring. И нам как бы хватает — там есть все, что нужно для типового проекта. Почему же во фронтэнде нет такого инструмента, включающего в себя все необходимое? Уж извините за излишнюю резкость.
Навскидку. Микросервисы A, B, C, D, E. Две изменяющие транзакции: A->B->C, D->B->E. Последовательность выполнения изменений во времени: A, B, D, B, E, и первая транзакция на C отвалилась с валидацией, вторая транзакция закоммичена. В системе B обе изменили один и тот же регистр. Нет возможности откатить первую транзакцию, так как регистр уже был изменен второй (и мы не знаем как). Чтобы было совсем конкретно, в B лежит счет одного клиента. Две транзакции от разных источников A и D (оплата по карте, и ипотечный сбор). Любое решение, которое вы предложите будет сводиться к одному из трех вышеперечисленных мной сценариев:
Заблокировать счет на время проведения любой транзакции, чтобы любое другое изменение на нем сразу отваливалось (типа ручной двухфазный коммит).
Проводить все транзакции в B последовательно через одну и ту же очередь.
Увеличение и уменьшение счета — коммутируемые операции и их очередность применительно к счету не имеет значения.
Все решения плохие в том или ином случае и уступают ACID. Поэтому если есть сделать систему монолитной, лучше делать так и не утруждать себя лишним геморроем.
P.S. Я знаю как работают некоторые банковские системы: у них есть дорогая и монолитная ACID-система, которая обслуживает счета и базу данных. И куча всяких микросервисных и любых других спутников вокруг, целостность которых уже никого сильно не волнует.
А мне вот что интересно. Со временем количество используемых технологий, а соответственно и сложность входа во фронтенд разработку, растет гораздо быстрее, чем сложность публикуемых веб-приложений. В итоге встает вопрос, что проще: сделать веб приложение на более простых, но понятных технологиях бородатого года, либо обучиться всему стеку 2018 года и потом "долететь за 5 минут".
Я не претендую на объективность, но заметил, что в работе нашей фронтэнд команды, работающей на реакте, постоянно что-то отваливается и местами глючит. На устранение причины тратятся месяцы, а чаще всего они отмазываются, что это глючит что-то в стеке: фреймворк, библиотека, etc… Любое изменение или добавка начинается с нытья, что это рушит им всю архитектуру, или что это очень сложно сделать, ссылаясь на ограничения фреймворка. И самое главное — за прошедшие 10 лет сложность приложений сильно не возросла, но у меня твердо сложилось ощущение, что сейчас разработка стала более дорогой и менее качественной, чем 10 лет назад, когда все писали на JQuery. Посговорчивей чтоли тогда люди были...
Под катом я рассказываю, как обеспечить целостность данных в микросервисной архитектуре без распределенных транзакций и жесткой связности. (
Да никак. Забудьте. И не вводите людей в заблуждение.
Изоляция в среде нескольких независимых асинхронных сервисов — это техническое требование. Современные исследования показали, что реальные бизнес-процессы можно реализовывать без изоляции.
На самом деле это не так. Изоляция как раз гарантирует, что другая транзакция не увидит изменения до тех пор, пока они не будут закоммичены. Если вашими измененными данными уже воспользовалась другая транзакция, вы данную транзакцию уже не сможете корректно откатить (или скомпенсировать).
Помимо технической стороны вопроса, такой как отказоустойчивость или гарантированная доставка, так или иначе все ваши бизнес-процессы должны удовлетворять условию линеаризуемости. Обеспечить линеаризуемость вне ACID возможно, но на порядки сложнее. И есть всего три способа:
Либо мы вручную реализуем распределенный ACID в том или ином виде: это потребует введение аналога двухфазного коммита для ресурсов и дополнительных состояний ("заблокирован" или "в обработке"), а также для каждого действия процессов-"компенсаций", которые делают откат в изначальное состояние. И соответственно еще тонны геморроя.
Либо все ваши бизнес-процессы можно представить ввиде линейной (или в общем случае древовидной) "потоковой" архитектуры взаимодействия, в которой каждая система может принимать сообщения только от единственной другой. Но далеко не все процессы можно уложить в данную архитектуру.
Либо мы анализируем каждый кейс отдельно, все возможные конфликты и способы компенсации, и доказываем, что в каждом случае линеаризуемость не нарушается. С увеличением бизнес процессов сложность процедуры возрастает экспоненциально.
Однако, большинство использует четвертый вариант:
Микросервисы — модно, стильно, молодежно. Ставим Монгу, Кафку, соединяем, пробуем — заработало. Ставим в продакшн. Линеаризуемость? Не, не слышали. Все и так норм.
Итого от 50 до 75$ минимальная стоимость часа ремонта машины в легальном автосервисе, который платит налоги.
Только у меня в европейской столице на любой официальной СТО Форда почему-то обычный ТО никогда не выходит меньше 250€, а когда надо что-то менять то и выше. При всем этом у другой сети автомастерских всегда в два раза дешевле при том же объеме работ. На Форде 75€ стоит только заехать в гараж и произвести первичную диагностику — подключить компьютер. Так что СТО для автопроизводителя — это бизнес не хуже самого производства.
С «недолговечностью» тоже все не так просто. С «недолговечностью» современных автомобилей обычно сталкиваетя третий, а то и четвертный, владелец
Там недолговечность "хитрая". Основные агрегаты обычно ходят исправно. Через пять лет пластик начинает превращаться в труху. Кроме того, есть перечень расходников, которые строго меняются на СТО в соответствии с километражом: тормозные накладки, амортизаторы, колеса, ремень/цепь ГРМ, водяная помпа, а сейчас еще добавился геморройный и дорогущий фильтр сажи/катализатор, etc… Причем на официальном СТО не смотрят на состояние этих агрегатов и меняют исключительно по километражу. И чем больше пробег, тем дороже становится СТО. И это не включая поломок. Кроме того, узлы тоже не ремонтнопригодны. Раньше когда сломался генератор — это в 95% случаев либо щетки, либо "мостик" — чинилось за копейки и 10 минут. Сейчас новый генератор 350€ + работа. Износ некоторых компонентов зашит прямо в компьютер, например фильтр сажи. В этом я убедился на 100%. В итоге тупо дешевле становится купить новый автомобиль.
Вы хоть раз видели, как карбюратор регулируется? Что еще там было такого надежного, что сейчас не используется?
Даже регулировал. Два винта всего — и хрен настроишь. И опережение смотрел. И подвеску на Волге шприцевал. Ломалось все по причине совка — хреновое качество и дизайн. Возьмите иномарку 80-х — до сих пор при должном уходе ездит.
… и похороны водителя с пассажирами, сейчас приходится менять кучу дорогущих подушек безопасности и преднатяжителей ремней.
Вы посмотрите какое на старых автомобилях расстояние от решетки до двигателя. Сейчас же так все упаковано, что даже лампочку в фаре поменять нельзя без ее демонтажа. Еще раньше бамперы пластиковыми не делали, также как и детали кузова. И дело не в безопасности, а в том, что любой удар идет сразу по двигателю без буфера, что делает автомобиль неремонтнопригодным.
Тем не менее то, что наблюдается на рынке сейчас — это массовая истерия по поводу экологичности. В Европе правительства "зажимают" дизеля, поднимают налоги, в города уже запрещают въезд "неэкологичного" транспорта, таким образом вынуждая людей досрочно обновлять автомобили. У нас этим летом перед вступлением нового закона цены на дизели сильно упали, они не сбываются в срок, подержанные дизельные авто вообще не уходят ни за какие деньги — люди просто боятся их покупать. Тем не менее, общая продажа автомобилей этим летом резко выросла на 20%. Фабрики уже не справляются с заказами — все требуют либо бензин, либо гибриды.
А с Фольксвагеном история имеет больше политический подтекст — обманывают все, просто VW стал козлом отпущения. И тем не менее, в этом году у нас в стране оборудовали все станции техосмотра новыми стендами, которые уже измеряют параметры двигателя в режиме, приближенном к реальному, и, соответственно, ужесточили нормы.
Задачи современного автопрома — сделать автомобиль недолговечным и дорогим в эксплуатации. В итоге на смену проверенным и надежным решениям 80-х годов приходят сложные, дорогие и малоэффективные системы, контролируемые электроникой, и с обязательным обслуживанием. Там где раньше при небольшом ДТП достаточно было произвести лишь кузовной ремонт, сейчас приходится менять кучу неремонтируемых агрегатов.
Если раньше все "инновации" в сфере преподносились под соусом экономии потребления топлива и соответственно денег, то сейчас люди смекнули, что никакой экономии денег не получается. Автопром в свою очередь поменял стратегию — сформировал лобби на уровне правительств, пропаганлирующих экологичность и мнимую заботу об окружающей среде. Все инновации теперь рекламируются исключительно как "экологичные", об экономии ресурсов и денег уже речи не идет.
Во-первых, как-то вы оптимистично обрабатываете нештатные ситуации. Если у вас оборвался InputStream от клиента, вы все-равно должны отослать в очередь пакет JMS_IBM_Last_Msg_In_Group и как-то пометить его как "Exception". В свою очередь reader, прочитав такой пакет, должен будет вместо нормального завершения сгенерить IOException и дать понять консьюмеру на другой стороне, что стрим оборвался.
Во-вторых, ваш reader будет работать только, если весь файл полностью уже лежит в очереди, потому как вы делаете receiveNoWait(). В качестве бонуса такая логика на ура будет выдавать недочитанные файлы, если writer не успел записать блок. Здесь нужно поставить обычный блокирующий read() с каким-нибудь таймаутом, чтобы исключить бесконечную блокировку, если нужный пакет так и не пришел.
В-третьих, приложение-консьюмер каким-то мистическим образом узнает groupId, который ему надо читать. В реале вам нужно сделать бесконечный reader, который постоянно слушает очередь, и сначала запрашивает первый пакет из любой цепочки, узнает из него groupId и уже потом дочитывает остальное из данной цепочки, а затем возвращается на начало. И чтобы расширить пропускную способность, надо бы сделать целый пул из таких reader-ов.
В-четвертых, очередь будет потихоньку забиваться пакетами из оборванных цепочек. Необходима периодическая очистка от старых пакетов.
Ну и наконец, если уж вы используете IBM MQ, то вроде там как бы уже реализован сервис файлтрансфера. А вы тут предлагаете решения для бедных...
Судя по отзывам кажется, что модули java.xml, которые являются частью поддержки веб-сервисов JAX-WS, SOAP, — это те, которые вызовут наибольшее количество проблем.
Они хотя бы будут выложены как сторонние библиотеки? Я до сих пор JAXB юзаю в качестве сериализатора, конфиги им читаю. JAX-WS до сих пор очень нужен в кровавом энтерпрайзе. Особенно нравилось, что пока остальные для своего вебсервиса подтягивают тяжелый энтерпрайзный стек, мы пользуем три строчки: https://dzone.com/articles/simple-java-soap-web-service-using-jdk-tools
По идее c JAX-WS должны были удалить еще и com.sun.net.httpserver.HttpServer, ибо больше не нужен.
Кстати, с выходом Java 11 впервые в истории уменьшился размер бандла :)
Новый публичный API
У меня у одного такое впечатление, что есть список фич преднамеренно хотят растянуть на кучу релизов вперед, нежели добавить все скопом?
Чтобы стать героем, нужно помимо ресурсов и времени уметь вещать со сцены, уметь рассказать о себе и своем проекте, заинтересовать народ, крутиться в правильных тусовках, катать по презентациям, etc. А это совершенно другие скиллзы, более близкие к маркетингу, нежели девелоперские. Есть люди, которым повезло, и которые гармонично совмещают оба эти скиллза. Но есть другие, не менее упоротые и строчащие не менее прекрасные вещи, но незаслуженно обойденные вниманием, которые в лучшем случае могут довольствоваться лишь своим именем в бесчисленных коммитах в корпоративный репозиторий. Они сидят в залах на конференциях, смотрят доклады по интернету, читают Хабр, изучают новые технологии. И таких людей подавляющее большинство! Практически весь существующий вокруг вас софт написан именно ими. Эти люди, плюясь от очередной модной "инновации", которая красиво работает только на презентации спикеров, вынуждены победить ее и успеть закодить и отладить скучный кусок корпоративного функционала к очередному дедлайну. Это маньяки своего дела. И им нужны герои.
Немного в сторону: если кому надо SOAP дергать, вместо тяжелых Apache CXF и JAX-WS пригодится очень лайтовая библиотечка: https://github.com/reficio/soap-ws
Очень странно, что не сделали java.time.Instant, который есть натуральная замена java.sql.Timestamp. И вот еще очень интересно во что же мепится java.time.OffsetDateTime? Ведь очень немногие базы данных предоставляют временнЫе типы с зоной/смещением. Обычно когда нужно сохранять зону, делается дополнительное поле. Полагаю что OffsetDateTime конвертится в LocalDateTime, а затем сохраняется как обычное локальное время. При чтении, однако, оригинальная зона/смещение теряется.
Да, в коде это выглядит на порядок понятнее, чем простыня из SQL. Кроме того, позволяет моментально отрефакторить или найти в проекте весь код, где есть обращения к конкретному полю. Поэтому я даже редко делаю кодогенерацию, а в замен использую aliases.
Есть еще офигенная библиотека JINQ, но она сейчас находится в standby. Хоть и рабочая, но с грядущими изменениями в JDK что-то боязно ее использовать в серьезном проекте.
Так уж повелось, что в мире Java все, что имеет официальную спецификацию JSR, неудобно и эстетически неприятно. Зато сторонние библиотеки типа QueryDSL исправляют ситуацию. В большом проекте подобные type-safe врапперы сильно спасают ситуацию, например, когда нужно найти все места, где используется какое-то поле или таблица.
Ну, в Испании, солнечно далеко не всегда и не везде, да и тепло тоже :)
Почитать можно ну, например, тут. GMT+2 в свое время ввел еще Франко, чтобы быть в одном часовом поясе с Германией времен Гитлера. В итоге дневная жизнь сильно сместилась: испанцы в отличие от европейцев поздно начинают работать, поздно обедают и поздно ужинают. Сейчас в правительстве обсуждают вернуться в зону GMT+1 без перевода на летнее время. Кстати, уже вроде бы доказано, что ущерб от перевода на летнее/зимнее время превышает выгоду.
Ну да, есть такое. И впринципе поддерживаю. Астрономически постоянный GMT+1 будет для Испании оптимальным. Другое дело, после такого перехода как всегда начнется всеобщий месячник хаоса. Кое-что сломается сразу (как с Канарскими), кое-что будет глючить втечение месяца (ОС апдейтнула tzdata, а БД еще в старой зоне), а что-то затаится, выжидая следующего перехода на летнее/зимнее время.
Ну вот я постоянно получаю такое молчание, поэтому делаю как считаю нужным. Люди вообще плохо понимают время, причем все — начиная с бизнес-аналистов и кончая финальными пользователями.
И история не выдуманная: был проект онлайн системы продажи билетов в кинотеатры, в которой люди с островов не могли купить билет за час до сеанса, потому что там внезапно на час меньше, чем на континенте. Еще эпичнее выглядел фикс: вместо введения таймзоны во всем коде понатыкали что-то вроде: if (Canarias) hour = hour — 1;
По-моему, уже в начале 2000-х был доказан тезис о том, что никакой контент защитить впринципе невозможно, пока пользователь контролирует воспроизводящее устройство. Как крайний случай: контент перехватывается при воспроизведении, и заново оцифровывается уже без защиты.
Полностью с вами согласен, коллега. Причем налицо парадокс — сложность разработки с каждым годом растет гораздо быстрее, чем сложность самих приложений. Интересно, когда же наступит технологическая сингулярность?
Видите ли, я вообще родом из 90-х. И на протяжении всей своей жизни видел и разрабатывал достаточно сложные десктопные приложения, используя разные технологии, начиная от MFC, VCL, QT, Java Swing и заканчивая Android-ом. Для меня достаточно сложным приложением является например Microsoft Word. И могу заявить, что даже он не тянет за собой все эти тонны нестабильного и постоянно меняющегося говна, и прочего псевдокода. Возможно в Microsoft все делают как-то неправильно и не концептуально, но люди как-то до сих пор обходились и обходятся. Уж не знаю что представляют из себя эти мифические "полноценные SPA приложения", но в реале дело не уходит дальше банального дешбоарда или десяти формочек с кнопочками, привязанных к страничной навигации. И мне очень смешит и одновременно нервирует, когда люди, имеющие в кармане язык с динамической типизацией, говорят о концептуальности использования Redux. Более того, я из области бекенда. Долгое время у нас был JavaEE, на смену которому постепенно пришел Spring. И нам как бы хватает — там есть все, что нужно для типового проекта. Почему же во фронтэнде нет такого инструмента, включающего в себя все необходимое? Уж извините за излишнюю резкость.
Навскидку. Микросервисы A, B, C, D, E. Две изменяющие транзакции: A->B->C, D->B->E. Последовательность выполнения изменений во времени: A, B, D, B, E, и первая транзакция на C отвалилась с валидацией, вторая транзакция закоммичена. В системе B обе изменили один и тот же регистр. Нет возможности откатить первую транзакцию, так как регистр уже был изменен второй (и мы не знаем как). Чтобы было совсем конкретно, в B лежит счет одного клиента. Две транзакции от разных источников A и D (оплата по карте, и ипотечный сбор). Любое решение, которое вы предложите будет сводиться к одному из трех вышеперечисленных мной сценариев:
Все решения плохие в том или ином случае и уступают ACID. Поэтому если есть сделать систему монолитной, лучше делать так и не утруждать себя лишним геморроем.
P.S. Я знаю как работают некоторые банковские системы: у них есть дорогая и монолитная ACID-система, которая обслуживает счета и базу данных. И куча всяких микросервисных и любых других спутников вокруг, целостность которых уже никого сильно не волнует.
А мне вот что интересно. Со временем количество используемых технологий, а соответственно и сложность входа во фронтенд разработку, растет гораздо быстрее, чем сложность публикуемых веб-приложений. В итоге встает вопрос, что проще: сделать веб приложение на более простых, но понятных технологиях бородатого года, либо обучиться всему стеку 2018 года и потом "долететь за 5 минут".
Я не претендую на объективность, но заметил, что в работе нашей фронтэнд команды, работающей на реакте, постоянно что-то отваливается и местами глючит. На устранение причины тратятся месяцы, а чаще всего они отмазываются, что это глючит что-то в стеке: фреймворк, библиотека, etc… Любое изменение или добавка начинается с нытья, что это рушит им всю архитектуру, или что это очень сложно сделать, ссылаясь на ограничения фреймворка. И самое главное — за прошедшие 10 лет сложность приложений сильно не возросла, но у меня твердо сложилось ощущение, что сейчас разработка стала более дорогой и менее качественной, чем 10 лет назад, когда все писали на JQuery. Посговорчивей чтоли тогда люди были...
Да никак. Забудьте. И не вводите людей в заблуждение.
На самом деле это не так. Изоляция как раз гарантирует, что другая транзакция не увидит изменения до тех пор, пока они не будут закоммичены. Если вашими измененными данными уже воспользовалась другая транзакция, вы данную транзакцию уже не сможете корректно откатить (или скомпенсировать).
Помимо технической стороны вопроса, такой как отказоустойчивость или гарантированная доставка, так или иначе все ваши бизнес-процессы должны удовлетворять условию линеаризуемости. Обеспечить линеаризуемость вне ACID возможно, но на порядки сложнее. И есть всего три способа:
Однако, большинство использует четвертый вариант:
Только у меня в европейской столице на любой официальной СТО Форда почему-то обычный ТО никогда не выходит меньше 250€, а когда надо что-то менять то и выше. При всем этом у другой сети автомастерских всегда в два раза дешевле при том же объеме работ. На Форде 75€ стоит только заехать в гараж и произвести первичную диагностику — подключить компьютер. Так что СТО для автопроизводителя — это бизнес не хуже самого производства.
Там недолговечность "хитрая". Основные агрегаты обычно ходят исправно. Через пять лет пластик начинает превращаться в труху. Кроме того, есть перечень расходников, которые строго меняются на СТО в соответствии с километражом: тормозные накладки, амортизаторы, колеса, ремень/цепь ГРМ, водяная помпа, а сейчас еще добавился геморройный и дорогущий фильтр сажи/катализатор, etc… Причем на официальном СТО не смотрят на состояние этих агрегатов и меняют исключительно по километражу. И чем больше пробег, тем дороже становится СТО. И это не включая поломок. Кроме того, узлы тоже не ремонтнопригодны. Раньше когда сломался генератор — это в 95% случаев либо щетки, либо "мостик" — чинилось за копейки и 10 минут. Сейчас новый генератор 350€ + работа. Износ некоторых компонентов зашит прямо в компьютер, например фильтр сажи. В этом я убедился на 100%. В итоге тупо дешевле становится купить новый автомобиль.
Даже регулировал. Два винта всего — и хрен настроишь. И опережение смотрел. И подвеску на Волге шприцевал. Ломалось все по причине совка — хреновое качество и дизайн. Возьмите иномарку 80-х — до сих пор при должном уходе ездит.
Вы посмотрите какое на старых автомобилях расстояние от решетки до двигателя. Сейчас же так все упаковано, что даже лампочку в фаре поменять нельзя без ее демонтажа. Еще раньше бамперы пластиковыми не делали, также как и детали кузова. И дело не в безопасности, а в том, что любой удар идет сразу по двигателю без буфера, что делает автомобиль неремонтнопригодным.
Тем не менее то, что наблюдается на рынке сейчас — это массовая истерия по поводу экологичности. В Европе правительства "зажимают" дизеля, поднимают налоги, в города уже запрещают въезд "неэкологичного" транспорта, таким образом вынуждая людей досрочно обновлять автомобили. У нас этим летом перед вступлением нового закона цены на дизели сильно упали, они не сбываются в срок, подержанные дизельные авто вообще не уходят ни за какие деньги — люди просто боятся их покупать. Тем не менее, общая продажа автомобилей этим летом резко выросла на 20%. Фабрики уже не справляются с заказами — все требуют либо бензин, либо гибриды.
А с Фольксвагеном история имеет больше политический подтекст — обманывают все, просто VW стал козлом отпущения. И тем не менее, в этом году у нас в стране оборудовали все станции техосмотра новыми стендами, которые уже измеряют параметры двигателя в режиме, приближенном к реальному, и, соответственно, ужесточили нормы.
Задачи современного автопрома — сделать автомобиль недолговечным и дорогим в эксплуатации. В итоге на смену проверенным и надежным решениям 80-х годов приходят сложные, дорогие и малоэффективные системы, контролируемые электроникой, и с обязательным обслуживанием. Там где раньше при небольшом ДТП достаточно было произвести лишь кузовной ремонт, сейчас приходится менять кучу неремонтируемых агрегатов.
Если раньше все "инновации" в сфере преподносились под соусом экономии потребления топлива и соответственно денег, то сейчас люди смекнули, что никакой экономии денег не получается. Автопром в свою очередь поменял стратегию — сформировал лобби на уровне правительств, пропаганлирующих экологичность и мнимую заботу об окружающей среде. Все инновации теперь рекламируются исключительно как "экологичные", об экономии ресурсов и денег уже речи не идет.
Ой как все фиговенько!
Во-первых, как-то вы оптимистично обрабатываете нештатные ситуации. Если у вас оборвался InputStream от клиента, вы все-равно должны отослать в очередь пакет JMS_IBM_Last_Msg_In_Group и как-то пометить его как "Exception". В свою очередь reader, прочитав такой пакет, должен будет вместо нормального завершения сгенерить IOException и дать понять консьюмеру на другой стороне, что стрим оборвался.
Во-вторых, ваш reader будет работать только, если весь файл полностью уже лежит в очереди, потому как вы делаете receiveNoWait(). В качестве бонуса такая логика на ура будет выдавать недочитанные файлы, если writer не успел записать блок. Здесь нужно поставить обычный блокирующий read() с каким-нибудь таймаутом, чтобы исключить бесконечную блокировку, если нужный пакет так и не пришел.
В-третьих, приложение-консьюмер каким-то мистическим образом узнает groupId, который ему надо читать. В реале вам нужно сделать бесконечный reader, который постоянно слушает очередь, и сначала запрашивает первый пакет из любой цепочки, узнает из него groupId и уже потом дочитывает остальное из данной цепочки, а затем возвращается на начало. И чтобы расширить пропускную способность, надо бы сделать целый пул из таких reader-ов.
В-четвертых, очередь будет потихоньку забиваться пакетами из оборванных цепочек. Необходима периодическая очистка от старых пакетов.
Ну и наконец, если уж вы используете IBM MQ, то вроде там как бы уже реализован сервис файлтрансфера. А вы тут предлагаете решения для бедных...
Они хотя бы будут выложены как сторонние библиотеки? Я до сих пор JAXB юзаю в качестве сериализатора, конфиги им читаю. JAX-WS до сих пор очень нужен в кровавом энтерпрайзе. Особенно нравилось, что пока остальные для своего вебсервиса подтягивают тяжелый энтерпрайзный стек, мы пользуем три строчки: https://dzone.com/articles/simple-java-soap-web-service-using-jdk-tools
По идее c JAX-WS должны были удалить еще и com.sun.net.httpserver.HttpServer, ибо больше не нужен.
Кстати, с выходом Java 11 впервые в истории уменьшился размер бандла :)
У меня у одного такое впечатление, что есть список фич преднамеренно хотят растянуть на кучу релизов вперед, нежели добавить все скопом?
О боже! В этом мире еще остались люди, которые не пишут на Spring Boot и не ассоциируют его со словом Java?
Чтобы стать героем, нужно помимо ресурсов и времени уметь вещать со сцены, уметь рассказать о себе и своем проекте, заинтересовать народ, крутиться в правильных тусовках, катать по презентациям, etc. А это совершенно другие скиллзы, более близкие к маркетингу, нежели девелоперские. Есть люди, которым повезло, и которые гармонично совмещают оба эти скиллза. Но есть другие, не менее упоротые и строчащие не менее прекрасные вещи, но незаслуженно обойденные вниманием, которые в лучшем случае могут довольствоваться лишь своим именем в бесчисленных коммитах в корпоративный репозиторий. Они сидят в залах на конференциях, смотрят доклады по интернету, читают Хабр, изучают новые технологии. И таких людей подавляющее большинство! Практически весь существующий вокруг вас софт написан именно ими. Эти люди, плюясь от очередной модной "инновации", которая красиво работает только на презентации спикеров, вынуждены победить ее и успеть закодить и отладить скучный кусок корпоративного функционала к очередному дедлайну. Это маньяки своего дела. И им нужны герои.
Немного в сторону: если кому надо SOAP дергать, вместо тяжелых Apache CXF и JAX-WS пригодится очень лайтовая библиотечка: https://github.com/reficio/soap-ws
Очень странно, что не сделали java.time.Instant, который есть натуральная замена java.sql.Timestamp. И вот еще очень интересно во что же мепится java.time.OffsetDateTime? Ведь очень немногие базы данных предоставляют временнЫе типы с зоной/смещением. Обычно когда нужно сохранять зону, делается дополнительное поле. Полагаю что OffsetDateTime конвертится в LocalDateTime, а затем сохраняется как обычное локальное время. При чтении, однако, оригинальная зона/смещение теряется.
Да, в коде это выглядит на порядок понятнее, чем простыня из SQL. Кроме того, позволяет моментально отрефакторить или найти в проекте весь код, где есть обращения к конкретному полю. Поэтому я даже редко делаю кодогенерацию, а в замен использую aliases.
Есть еще офигенная библиотека JINQ, но она сейчас находится в standby. Хоть и рабочая, но с грядущими изменениями в JDK что-то боязно ее использовать в серьезном проекте.
Так уж повелось, что в мире Java все, что имеет официальную спецификацию JSR, неудобно и эстетически неприятно. Зато сторонние библиотеки типа QueryDSL исправляют ситуацию. В большом проекте подобные type-safe врапперы сильно спасают ситуацию, например, когда нужно найти все места, где используется какое-то поле или таблица.
Ну, в Испании, солнечно далеко не всегда и не везде, да и тепло тоже :)
Почитать можно ну, например, тут. GMT+2 в свое время ввел еще Франко, чтобы быть в одном часовом поясе с Германией времен Гитлера. В итоге дневная жизнь сильно сместилась: испанцы в отличие от европейцев поздно начинают работать, поздно обедают и поздно ужинают. Сейчас в правительстве обсуждают вернуться в зону GMT+1 без перевода на летнее время. Кстати, уже вроде бы доказано, что ущерб от перевода на летнее/зимнее время превышает выгоду.
Ну да, есть такое. И впринципе поддерживаю. Астрономически постоянный GMT+1 будет для Испании оптимальным. Другое дело, после такого перехода как всегда начнется всеобщий месячник хаоса. Кое-что сломается сразу (как с Канарскими), кое-что будет глючить втечение месяца (ОС апдейтнула tzdata, а БД еще в старой зоне), а что-то затаится, выжидая следующего перехода на летнее/зимнее время.
Ну вот я постоянно получаю такое молчание, поэтому делаю как считаю нужным. Люди вообще плохо понимают время, причем все — начиная с бизнес-аналистов и кончая финальными пользователями.
И история не выдуманная: был проект онлайн системы продажи билетов в кинотеатры, в которой люди с островов не могли купить билет за час до сеанса, потому что там внезапно на час меньше, чем на континенте. Еще эпичнее выглядел фикс: вместо введения таймзоны во всем коде понатыкали что-то вроде: if (Canarias) hour = hour — 1;