Иными словами, переписывать ничего не стали, просто заменили секции synchronized (что стало бессмысленным с появлением Java 24) на примитивы, и на том и успокоились.
А что они могли ещё сделать, помимо этого? Ещё и с учётом того, что JEP 491 сделал такую доработку бессмысленной. Для поддержки виртуальных тредов в принципе ничего особенного делать не нужно.
Все примеры крутятся на основе PoolingHttpClientConnectionManager. Само название как бы намекает на пул соединений. Это резко противоречит идеям JEP 425, секции под говорящим названием Do not pool virtual threads
Вы путаете две кардинально различающиеся концепции - пул потоков и пул соединений. Это не одно и то же. Пул соединений - это просто контейнер для TCP сокетов. Он жизненно необходим для корректной поддержки HTTP фичи keep-alive и с потоками никак не связан.
Между прочим, java.net.http.HttpClient тоже содержит пул коннектов. Но при этом вашего праведного гнева он почему-то не вызывает.
Под капотом у RestClient используются сторонние http библиотеки типа java.net.http.HttpClient, apache http components и другие. RestClient просто обёртка. Соответственно, надо задавать вопрос нижележащей библиотеке. Могу сказать, что стандартный java.net.http.HttpClient полностью поддерживает виртуальные треды.
А как он ограничивается в таком случае - открывает соединения для каждого запроса со своим виртуальным потоком?
Сколько лично Вы запустите одновременных запросов - столько соединений и будет. Этот момент зависит только от вас, а не от фреймворка. От виртуальности зависит только количество нативных потоков, привлекаемых для обработки ваших запросов.
Вряд ли моих познаний в радиотехнике хватит чтобы поставить чёткое тз с конкретными параметрами каким должен быть радиоэфир внутри моей квартиры. Мне как обывателю хочется не беспокоиться о том, что каждый год увеличивающееся количество iot устройств с умными домами и прочие беспроводные девайсы у соседей как-то повлияют на мою wifi сеть. Идеал - радиогерметичное помещение, но, как вы верно подметили, это нерационально.
Экранируя соседский вайфай, заодно экранируете сотовую связь
Это верное замечание. Как я уже писал в комментариях выше, есть предложение не экранировать стены, граничащие с улицей. Это не будет блокировать gsm, а залётный с улицы wifi сигнал будет скорее всего слишком слаб, чтобы о нём как-то беспокоиться. Вот только я не уверен, что такая незамкнутая клетка фарадея будет нормально работать.
ethernet везде с запасом, чтобы если у вас появятся новые устройства или вы захотите перенести старые, вам не нужны были многометровые пачкорды
Это всё понятно. Уж спроектировать удобную кабельную систему для дома я могу и самостоятельно. Есть опыт. Но вопрос-то про беспроводную сеть.
Все что можно посадить на провода я сажаю и так. Но за соседей я ручаться не могу. А с тенденцией строить человейники по 15 квартир на этаже, я начинаю задумываться о вопросе, который и поднял в данной ветке комментариев.
Идея тут в том, чтобы улучшить качество моей собственной wifi сети путём физической очистки радиоэфира от ненужных мне wifi сетей соседей. А если моя сеть при этом станет навидимой для соседей - это будет просто приятный бонус.
То, что прилетает с улицы, беспокоит меня меньше, чем то, что прилетает от соседей. Особенно если каждый из них воспользуется советом @Genix и жахнет по ap в каждую комнату.
Меня всегда интересовал вопрос. Можно ли на этапе ремонта заэкранировать квартиру от соседского wifi излучения и оградить соседей от своего? Ну там сетку медную в стены, потолки и стяжку пола встроить или ещё что-то сделать.
Какая-нибудь малозначимая и простая система может и остановиться. Но для отказоустойчивых систем, работающих 24/7, это недостаточная причина для полной остановки.
Так это касается не только 1С, а вообще любого консьюмера.
Вопрос был в контексте 1С, и я подумал, что ответ в этом же контексте будет смотреться органичнее. Но вы верно подметили - ответ применим не только к 1С.
Если в архитектуре используется кафка - то изначально предполагается, что сервисы умеют сами разбираться со своими проблемами.
Сервис не может предусмотреть все возможные проблемы. И не важно, кафка там у него или нет. Поэтому ошибки делятся на два типа - которые мы знаем как обработать и все остальные. С первым типом всё понятно, а вот со вторым уже не очень.
Допустим, встретилась ошибка сети. Очевидно, что коммитить оффсет нет смысла, так как все последующие сообщения так же упадут с этой же ошибкой и лучше ретраить текущее сообщение до победного, либо до изменения ошибки на какую-то другую.
А если возникла ошибка, которую никто никогда не видел? Можем ли мы блокировать чтение топика, отправив сообщение в "ретрай до победного"?
Типичным вариантом обработки всех подобных неизвестных ошибок является изъятие проблемного сообщения из топика и отправка его в отдельную независимую ретрай схему с увеличивающимся интервалом между попытками. И в системах на кафке такая схема делается либо очень сложно, либо с привлечением сторонних инструментов.
Потому что один застрявший документ остановит весь поток. Это нормально сработает только если 1С не принимает документ из-за каких-либо временных проблем: перегружена база, сеть барахлит и т.п. А если проблема перманентная, например, невалидный с точки зрения 1С документ, то на этом документе весь поток и встанет. А ретрай механизмов у кафки нет, что вынуждает городить костыли.
ASN.1 был придуман очень давно учёными для учёных. Очень сложная спецификация с большим количеством тонкостей и нюансов. Исчезающе малое количество актуальных компиляторов и рантайм библиотек. Это тем более удивительно, что очень широко используемые во всем мире структуры - SSL сертификаты для сайтов, кодируются именно в ASN.1.
С другой стороны, protobuf создан инженерами для инженеров. Простая спецификация, хорошая поддержка на всех языках программирования.
Обнаружил способ сделать значение опции более читабельным и поддерживаемым. В документации указана возможность задавать значения в одинарных кавычках и тогда оно автоматически преобразуется в двоичный формат. Если указано число или IP адрес, то они сразу же целиком переводятся в двоичный формат. При этом написано "Now it is also possible to combine data types into one", что даёт возможность писать серию десятичных чисел и IP адресов подряд друг за другом без мутотени с ручным преобразованием. Не очень понятно к какой конкретно версии ROS относится слово "now", но оно появилось в документации в районе ноября 2021 года, так что думаю речь идёт про ROS 6.49 и выше.
Пример 1 из статьи можно записать как '24''10''0''0''192.168.0.2'
Чтобы не запутаться в кавычках, напишу как оно делится: '24' + '10' + '0' + '0' + '192.168.0.2'. То есть отдельно в кавычках маска, отдельно каждый октет адреса назначения и адрес роутера целиком. Но записывать нужно без промежутков (без пробелов и т.п.).
Пример 2 - '8''10''192.168.0.2'
Пример 3 - '29''172.16.4.0''192.168.0.2'
В 3 примере автор накосячил. Либо ошибся когда копипастил, либо просто запутался в преобразованиях. Кстати, если маска адреса назначения 25 и больше, то адрес назначения можно написать не раздельно, а сразу целиком.
И как вы можете гарантировать что пароль в лог файл не утечет?
Проводить обучение разработчиков, админов и прочих причастных основам информационной безопасности, где объясняется, что логгирование пароля - плохо и чревато.
Особенно если учесть что nginx у вас может использоваться как tls terminator, а после него все на чистом http взаимодействовать …
Значит необходимо объяснить разработчику, что не стоит передавать пароль в query string, так как nginx по умолчанию записывает его в лог. Либо объяснить админу, что в nginx есть возможность логгировать урл без query string.
При передаче пароля в открытом виде есть одна проблема:
TLS достаточно надёжно защищает передаваемые данные между клиентом и сервером. Это подтверждено большим количеством исследований и проверено временем. Так что пароль передаётся в зашифрованном виде, а не в открытом.
Если приложение пишет пароль (или хеш пароля) в логи, то это почти наверняка не единственная и не самая большая проблема с таким-то подходом к безопасности.
Верно. Именно по этой причине пароль предварительно солят перед тем как прогнать его через хеш функцию. Бывает ещё и перчат.
Согласен. Но теперь вам нужно как-то защититься от слива базы, что происходит несравнимо чаще, чем перехват пароля/хеша в полёте. Будете хранить в базе хеш от хеша?
Запрещено пропускать, если есть персональная льгота на проезд. Например, инвалидность, статус почётного донора, студенческая/школьная скидка и т.п. За полный тариф и за своё счёт пропускай кого хочешь. Никто слова не скажет.
Прочитал статью.
А что они могли ещё сделать, помимо этого? Ещё и с учётом того, что JEP 491 сделал такую доработку бессмысленной. Для поддержки виртуальных тредов в принципе ничего особенного делать не нужно.
Вы путаете две кардинально различающиеся концепции - пул потоков и пул соединений. Это не одно и то же. Пул соединений - это просто контейнер для TCP сокетов. Он жизненно необходим для корректной поддержки HTTP фичи keep-alive и с потоками никак не связан.
Между прочим, java.net.http.HttpClient тоже содержит пул коннектов. Но при этом вашего праведного гнева он почему-то не вызывает.
Под капотом у RestClient используются сторонние http библиотеки типа java.net.http.HttpClient, apache http components и другие. RestClient просто обёртка. Соответственно, надо задавать вопрос нижележащей библиотеке. Могу сказать, что стандартный java.net.http.HttpClient полностью поддерживает виртуальные треды.
Сколько лично Вы запустите одновременных запросов - столько соединений и будет. Этот момент зависит только от вас, а не от фреймворка. От виртуальности зависит только количество нативных потоков, привлекаемых для обработки ваших запросов.
Вряд ли моих познаний в радиотехнике хватит чтобы поставить чёткое тз с конкретными параметрами каким должен быть радиоэфир внутри моей квартиры. Мне как обывателю хочется не беспокоиться о том, что каждый год увеличивающееся количество iot устройств с умными домами и прочие беспроводные девайсы у соседей как-то повлияют на мою wifi сеть. Идеал - радиогерметичное помещение, но, как вы верно подметили, это нерационально.
Это верное замечание. Как я уже писал в комментариях выше, есть предложение не экранировать стены, граничащие с улицей. Это не будет блокировать gsm, а залётный с улицы wifi сигнал будет скорее всего слишком слаб, чтобы о нём как-то беспокоиться. Вот только я не уверен, что такая незамкнутая клетка фарадея будет нормально работать.
Это всё понятно. Уж спроектировать удобную кабельную систему для дома я могу и самостоятельно. Есть опыт. Но вопрос-то про беспроводную сеть.
Все что можно посадить на провода я сажаю и так. Но за соседей я ручаться не могу. А с тенденцией строить человейники по 15 квартир на этаже, я начинаю задумываться о вопросе, который и поднял в данной ветке комментариев.
Идея тут в том, чтобы улучшить качество моей собственной wifi сети путём физической очистки радиоэфира от ненужных мне wifi сетей соседей. А если моя сеть при этом станет навидимой для соседей - это будет просто приятный бонус.
Это уже детали. Меня интересует практичен ли вообще такой подход к очищению эфира и не принесёт ли он больше проблем, чем решит.
То, что прилетает с улицы, беспокоит меня меньше, чем то, что прилетает от соседей. Особенно если каждый из них воспользуется советом @Genix и жахнет по ap в каждую комнату.
Можно ж не закрывать сеткой стены, граничащие с улицей. Или такая незамкнутая клетка фарадея работать не будет?
Меня всегда интересовал вопрос. Можно ли на этапе ремонта заэкранировать квартиру от соседского wifi излучения и оградить соседей от своего? Ну там сетку медную в стены, потолки и стяжку пола встроить или ещё что-то сделать.
Какая-нибудь малозначимая и простая система может и остановиться. Но для отказоустойчивых систем, работающих 24/7, это недостаточная причина для полной остановки.
Собственно, сложность как раз в том, что задержки и ttl любого рода на кафке делаются неудобно.
Вопрос был в контексте 1С, и я подумал, что ответ в этом же контексте будет смотреться органичнее. Но вы верно подметили - ответ применим не только к 1С.
Сервис не может предусмотреть все возможные проблемы. И не важно, кафка там у него или нет. Поэтому ошибки делятся на два типа - которые мы знаем как обработать и все остальные. С первым типом всё понятно, а вот со вторым уже не очень.
Допустим, встретилась ошибка сети. Очевидно, что коммитить оффсет нет смысла, так как все последующие сообщения так же упадут с этой же ошибкой и лучше ретраить текущее сообщение до победного, либо до изменения ошибки на какую-то другую.
А если возникла ошибка, которую никто никогда не видел? Можем ли мы блокировать чтение топика, отправив сообщение в "ретрай до победного"?
Типичным вариантом обработки всех подобных неизвестных ошибок является изъятие проблемного сообщения из топика и отправка его в отдельную независимую ретрай схему с увеличивающимся интервалом между попытками. И в системах на кафке такая схема делается либо очень сложно, либо с привлечением сторонних инструментов.
Потому что один застрявший документ остановит весь поток. Это нормально сработает только если 1С не принимает документ из-за каких-либо временных проблем: перегружена база, сеть барахлит и т.п. А если проблема перманентная, например, невалидный с точки зрения 1С документ, то на этом документе весь поток и встанет. А ретрай механизмов у кафки нет, что вынуждает городить костыли.
На мой взгляд - ничем не лучше.
ASN.1 был придуман очень давно учёными для учёных. Очень сложная спецификация с большим количеством тонкостей и нюансов. Исчезающе малое количество актуальных компиляторов и рантайм библиотек. Это тем более удивительно, что очень широко используемые во всем мире структуры - SSL сертификаты для сайтов, кодируются именно в ASN.1.
С другой стороны, protobuf создан инженерами для инженеров. Простая спецификация, хорошая поддержка на всех языках программирования.
Белый ip на устройстве не означает, что фаервол и фильтрация трафика на роутере автоматически выключаются.
Обнаружил способ сделать значение опции более читабельным и поддерживаемым. В документации указана возможность задавать значения в одинарных кавычках и тогда оно автоматически преобразуется в двоичный формат. Если указано число или IP адрес, то они сразу же целиком переводятся в двоичный формат. При этом написано "Now it is also possible to combine data types into one", что даёт возможность писать серию десятичных чисел и IP адресов подряд друг за другом без мутотени с ручным преобразованием. Не очень понятно к какой конкретно версии ROS относится слово "now", но оно появилось в документации в районе ноября 2021 года, так что думаю речь идёт про ROS 6.49 и выше.
Пример 1 из статьи можно записать как
'24''10''0''0''192.168.0.2'Чтобы не запутаться в кавычках, напишу как оно делится:
'24'+'10'+'0'+'0'+'192.168.0.2'. То есть отдельно в кавычках маска, отдельно каждый октет адреса назначения и адрес роутера целиком. Но записывать нужно без промежутков (без пробелов и т.п.).Пример 2 -
'8''10''192.168.0.2'Пример 3 -
'29''172.16.4.0''192.168.0.2'В 3 примере автор накосячил. Либо ошибся когда копипастил, либо просто запутался в преобразованиях. Кстати, если маска адреса назначения 25 и больше, то адрес назначения можно написать не раздельно, а сразу целиком.
SQQQ скорее уж...
Проводить обучение разработчиков, админов и прочих причастных основам информационной безопасности, где объясняется, что логгирование пароля - плохо и чревато.
Значит необходимо объяснить разработчику, что не стоит передавать пароль в query string, так как nginx по умолчанию записывает его в лог. Либо объяснить админу, что в nginx есть возможность логгировать урл без query string.
TLS достаточно надёжно защищает передаваемые данные между клиентом и сервером. Это подтверждено большим количеством исследований и проверено временем. Так что пароль передаётся в зашифрованном виде, а не в открытом.
Если приложение пишет пароль (или хеш пароля) в логи, то это почти наверняка не единственная и не самая большая проблема с таким-то подходом к безопасности.
Верно. Именно по этой причине пароль предварительно солят перед тем как прогнать его через хеш функцию. Бывает ещё и перчат.
Согласен. Но теперь вам нужно как-то защититься от слива базы, что происходит несравнимо чаще, чем перехват пароля/хеша в полёте. Будете хранить в базе хеш от хеша?
Запрещено пропускать, если есть персональная льгота на проезд. Например, инвалидность, статус почётного донора, студенческая/школьная скидка и т.п. За полный тариф и за своё счёт пропускай кого хочешь. Никто слова не скажет.
Это в mysql так. В постгресе правая граница исключительная:
Постгрес не позволит создать партицию с пересекающимися ренджами. Будет ошибка.