я вовсе не собирался ничего разрабатывать для этого, с позволения сказать, «сервиса». На это у меня нет не времени / желания / умения. Весь этот крохотный проектик только потому и существует, что почти ничего не надо было делать.
Ваши сексуальные ассоциации с словосочетанием «пассивная роль» — это ваше сугбо личное дело и его не стоит переносить на меня. Как и то, что в вашм понимании это имеет некий отрицательный и унизительный поддтекст.
а от того, что текст переместился вниз и покрасился — он стал лучше/красивее/доступней? И если проблема решилась и без копирайтера (кто бы это ни был), то зачем его находить?
этот адрес и есть сеть блогов под названием blogger.com. Как вам совершенно правильно пишут в комментариях тут — по сути вы заблокировали 1/4 часть доступа к миллионам ни в чем не повинных блогов, но при этом сам «плохой» сайт остался доступным в 3/4 случаев. Я могу понять неграмонтность того, кто принимал судебное решение, но вы ведь техническая компания, неужели вы не смогли придумать ничего более умного и заблокировать только экстремистсткий сайт? И что вы сделаете когда в ответ на очередную жалобу суда о экстрмистсок твите, сам твитер не примет мер? Заблокируете весь твитер? Ох, ох
Мне не очень понятно, при чем тут кивок в строну гугл, который не подчинился решению суда Кабардино-Балкарской Республики. Было бы странно если бы он подчинился.
Иными словами вы говорите «да, мы действительно в лоб реализовали блокировку самой поулярной блог-платфромы в мире на основе вопиюще-неграмотного решения суда». А что значит «Как только сайт будет полностью заблокирован...»? Кем заблокирован? Кто должен пойти и его заблокировать (Гугл это видимо делать не будет) чтоб пользователи вашей сети могли доступаться к миллионнам блогов?
Я не уверен, что вы до конца понимаете масштаб и суть явления. Это совершенно аналогично блокировке всего, видимо более знакомого вам, ЖЖ из за одного плохого блога, или блокировка всего твитера из за одного вредного экаунта.
Это одна из 4х A-записей блогера. Накопал это дело Dmitry (спасибо), и вылядит это как вопиющая некомпетентность принимающих решения в минюсте :( Видимо Билайну действительно это положенно блокировать, что совсем не радует.
а ничего, что у меня есть гораздо более прямой канал рассказать о своих проектах 100к человек каждую неделю? Да и ссылки вовсе не покрывают все проекты, но только те, на которые были жалобы,
Если это глюк, например их прокси не смогло взять у блогера, то тогда у Билайна не все в порядке с русским языком. Т.е. если бы было «сайт временно недоступен» то особо никто бы и не волновался, но «заблокирован» звучит как целенаправленное и осмысленное действие, вызывающее резонный вопрос — «За что?»
Ну я и билайну писать что-то конкретное не могу, я не их клиент и проблему вижу только через пользователей/слушателей. Но призвал всех заблокированых писать/звонить. Вот один из них и сказал, что ответ был — «заблокировано по решению суда»
У вас совершенно не покрыта проблема возможной блокировки многих клиентов одновременно при ожидании одного из них на sessionQueue.add. Не уверен, что за очередь у вас, но при заполнении подозреваю блокировку. Т.е. я про те ситуации, когда очередь заполняется, например слишком активным/агрессивным клиентом полностью и ваш пул не успевает обрабатывать. Видимо стоит в таких случаях «успокаивать» слишком активных клиентов переводом канала в нечитаемый режим. Кроме того, у вас игнорируется ситуация saturated outbound. Я вполне допускаю, что все это у вас делается за кадром, но из статьи возникает ложное впечатление, что в Netty эти проблемы решаются сами, волшебным образом. Увы, это не так.
примеры у них действительно не самые сложные. Однако, чтение исходников сильно помогает понять как оно должно работать. Вопросы можно и нужно задавть на stack overflow. Их форум туда переехал.
Что касается сложных протоколов, то это да, без поллитры не поднять. Я делал это частично конечным автоматом, частично форсированием начальнай части коммуникации в синхроный вид. Что касается серцебиений и всяких прочих PING/PONG в процессе — то я это сажал на idle события (у них есть IdleStateAwareChannelHandler для этого).
Вообще, сложные протоколы в Netty стоит реализовывать только если очень надо. Т.е. если у вас разумное количество паралельных соеденений то не стоит себе морочить голову, OIO реализция будет сильно проще
ну это я в порядке придрок и общего брюзжания. А вообще, полезная статья может оказаться, особенно для начинающих. Я бы добавил пару пунктов, не очевидных для тех, кто пришел из мира блокирующих коммуникаций и у кого не очень ясная картина как там потоки и что там может заблокироваться. Во первых, важно помнить главное — никогда и ни при каких обстоятельствах в обработчики нельзя ставить нечто блокирующее (например put в BlockingQueue) и, в общем случае, избегать любых долгих операций в этих обработчиках. А, во вторых, полезно помнить, что обработчики потоко-безопасные, и никакой дополнительной синхронизации в них не надо, конечно если нет доступа к общим данным.
тут у вас есть определенное количество неточностей, прыгающих в глаза. Например, останавливать сервер вызовом close — это не самая лучшая идея особенно в комплекте с awaitUninterruptibly(). Правильно это делать в в три этапа, с предварительным закрытием ChannelGroup (куда все активные коннекты добавлять/убивать из channelOpen/channelClosed. И не забыть bootstrap.releaseExternalResources(). Все это описано в оф.документации.
По поводу «Executors.newCachedThreadPool(), он создаёт неоправданно много потоков и ни какого выигрыша от Netty почти нет» это вы что-то путаете. В Netty можно сделать поток на коннект, но вовсе не выбором CachedThreadPool, а OioServerSocketChannelFactory.
И в качестве последней придирки «ChannelBuffer очень похож на DataInputStream и DataOutputStream в одном лице» — он скорее похож на ByteBuffer с 2мя указателями.
Иными словами вы говорите «да, мы действительно в лоб реализовали блокировку самой поулярной блог-платфромы в мире на основе вопиюще-неграмотного решения суда». А что значит «Как только сайт будет полностью заблокирован...»? Кем заблокирован? Кто должен пойти и его заблокировать (Гугл это видимо делать не будет) чтоб пользователи вашей сети могли доступаться к миллионнам блогов?
Я не уверен, что вы до конца понимаете масштаб и суть явления. Это совершенно аналогично блокировке всего, видимо более знакомого вам, ЖЖ из за одного плохого блога, или блокировка всего твитера из за одного вредного экаунта.
www.google.com/search?q=site%3Aminjust.ru+216.239.32.21
Это одна из 4х A-записей блогера. Накопал это дело Dmitry (спасибо), и вылядит это как вопиющая некомпетентность принимающих решения в минюсте :( Видимо Билайну действительно это положенно блокировать, что совсем не радует.
Что касается сложных протоколов, то это да, без поллитры не поднять. Я делал это частично конечным автоматом, частично форсированием начальнай части коммуникации в синхроный вид. Что касается серцебиений и всяких прочих PING/PONG в процессе — то я это сажал на idle события (у них есть IdleStateAwareChannelHandler для этого).
Вообще, сложные протоколы в Netty стоит реализовывать только если очень надо. Т.е. если у вас разумное количество паралельных соеденений то не стоит себе морочить голову, OIO реализция будет сильно проще
По поводу «Executors.newCachedThreadPool(), он создаёт неоправданно много потоков и ни какого выигрыша от Netty почти нет» это вы что-то путаете. В Netty можно сделать поток на коннект, но вовсе не выбором CachedThreadPool, а OioServerSocketChannelFactory.
И в качестве последней придирки «ChannelBuffer очень похож на DataInputStream и DataOutputStream в одном лице» — он скорее похож на ByteBuffer с 2мя указателями.