HTTP-сессия в мире Java.
В любом веб-приложении одним из краеугольных вопросов является поддержка клиентских сессий. Платформа JavaEE не исключение и для этих целей в ней существует специализированный HttpSession API, доступ к которому есть у любого веб-приложения, развернутого в некотором сервлет-контейнере. Что же из себя представляют эти самые сессии? Возможно, Вам известно, что протокол HTTP и веб-серверы по природе своей являются stateless, и каждый новый запрос от клиента расценивается сервером, как абсолютно новый, ничего не знающий об истории предшествующих обращений. Вы скажете, а, как же тогда реализуются интернет-магазины, знающие о списке добавленных в корзину товаров своих покупателей?
Сессия — это диалоговое состояние между клиентом и сервером, включающее информацию о предыдущих запросах клиента и ответах сервера. В силу того, что протокол и сами веб-сервера не обеспечивают сохранение состояние, то единственной возможностью для этого является передача всей необходимой информации о запросе в нем самом. Чтобы этого не делать, каждый запрос от данного клиента сервер ассоциирует с некоторой уникальной информацией об установленной сессии (идентификатор сессии), пробрасывая ее в каждом запросе и ответе. Для передачи данного UID наиболее популярными являются, такие способы, как использование пользовательских cookies, скрытые поля формы и передача непосредственно в адресе запроса. При разработке веб-приложения, конечно, функцию генерации UID и последующей его передачи от клиента к серверу может взять на себя само приложение, но тогда разработчик будет ответственен за все возможные обращения, каждый раз проверяя, а не забыл ли он передать это значение, при этом генерируя огромное количество boilerplate-кода. К великому счастью, разработчики JavaEE освобождены от такой рутины и выполнение данной задачи взвалено на плечи контейнера, в пределах которого развернуто Ваше приложение. Осталось понять — каким же образом он это делает. Работа с пользовательскими сессиями веб-приложений в JavaEE вынесена в раздел Servlet API и осуществляется средствами интерфейса javax.servlet.http.HttpSession, который предоставляет высокоуровневые методы работы с ними. Непосредственная реализация уже располагается в библиотеке servlet-api.jar используемого контейнера сервлетов и напрямую зависит от него. Существует два способа получения ссылки на объект пользовательского сеанса из объекта клиентского запроса, используя методы Servlet API:
1. HttpSession getSession(boolean flag) — для ложного значения параметра flag, данный метод возвращает объект сессии, если он был создан у данного запроса, и null в противном случае; в случае истинного значения flag, данный метод равносилен другому методу 2. HttpSession getSession() — если сеанс не установлен, то контейнер его создает, иначе возвращает уже созданный объект сессии. В момент, когда сеанс установлен, сервлет-контейнер создает пользовательский cookie с именем JSESSIONID, значение которого содержит уникальный идентификатор сессии (это же значение можно получить методом String getId() объекта HttpSession). Наряду с этим, в рамках контейнера определяется дефолтное значение таймаута сессии — время неактивного состояния пользователя, приводящее к устареванию его сеанса связи с сервером. Данное значение конфигурируется на уровне контейнера сервлетов, либо непосредственно в веб-приложении на уровне дескриптора развертывания web.xml или непосредственным вызовом метода void setMaxInactiveInterval(int interval) у объекта сессии. Начиная с версии Servlet API 3.0, также можно задать и время жизни куки JSESSIONID в конфиге web.xml, уничтожение которой также приведет к запросу на повторное установление сеанса между клиентом и сервером. Кусок дескриптора развертывания web.xml:

«<session-config>»
«<!— Timeout in minutes —>»
«<session-timeout>15</session-timeout>»
«<cookie-config>»
«<http-only>true</http-only>»
«<path>/</path>»
«<!— Cookie lifetime in seconds —>»
«<max-age>900</max-age>»
»</cookie-config>»
«</session-config>»

А что же будет, если пользовательские «печенки» запрещены на клиентской маш

ине? Данный факт будет выявлен сервером автоматически и для поддержания сеанса будет использован механизм URL Rewriting, который позволяет передавать UID сессии непосредственно в адресной строке, например, так:
http://amp.gs/BDav;jsessionid=1E6FEC0D14D044541DD84D2..

А зачем они вообще нужны эти http-сессии и, какие в принципе возможности предоставляют? Это уже тема следующей заметки. До новых встреч!

Мы знали, что курс «DevOps: практики и инструменты» востребован компаниями для повышения квалификации своих сотрудников. В первой группе много счастливчиков, которые учатся за счет работодателей. Но в этом наборе тех, кто получит новые знания и умения за счет работодателей, оказалось больше, чем мы ожидали!
Обучение за счет работодателя — радость для студента и, к сожалению, нагрузка на администрацию компаний. Чтобы успеть принять на курс всех, кто хочет стать серьезным DevOps специалистом, мы приняли решение о переносе начала обучения второй группы. Торжественно клянемся, что 28 ноября вторая группа DevOps начнет свое обучение!
Хотите попасть во второй набор нашего звездного курса? Самое время сделать это! Для физических лиц еще есть места. А вот если вы хотите обучаться за счет работодателя — стоит поторопиться с заявкой на help@otus.ru

Пожалуй, самое большое количество вопросов возникает при кластеризации запросов. Точность ручной кластеризации опытного оптимизатора не превышает 40%. Это значит, что если вы не эксперт в нише для которой собираете ядро — лучше прокачать свои знания в ней или воспользоваться автоматом. Вся сложность в том, что каждый запрос имеет интент (задача, которую подразумевает пользователь при поиске). Поисковая система интент прекрасно определяет и знает. А вот человек — отнюдь не всегда. Кроме того, одни интенты могут продвигаться на одной странице, другие — нет. Поэтому, выполняя ручную кластеризацию следует смотреть на выдачу — как разделено именно там. Если в выдаче по одинаковым запросам присутствуют одинаковые страницы в ТОП — значит их можно продвигать на одной странице.

Выдача непостоянна, она постоянно меняется. Особенно, когда меняется алгоритмы работы поисковых систем. Иногда два запроса имеют абсолютно одинаковый смысл и интент, но выдача по ним разная. В данном случае необходимо разместить такие запросы на одну страницу, иначе возникнет каннибализм — две страницы будут ранжироваться по схожим запросам, отжирая релевантность друг у друга.

Поэтому, кластеризуя семантические ядра для начала проходимся автоматом. Например, можно встроенным в Key Collector кластеризатором по ТОП. Полученное ядро обрабатывайте руками, исправляя огрехи алгоритмов поисковых систем. Только таким способом на выходе можно получить полное и качественное семантическое ядро.

Когда в кино показывают компьютерных злодеев — это часто выглядит печально. Взлом системы, к примеру, обычно изображают, как быстро бегущие строки, которые сменяет большая зеленая надпись «Доступ получен». Режиссеров очень редко волнуют всякие мелочи, которые на их взгляд понятны только специалистам. А мы подходим в вопросу образования крайне серьезно. Программы обучения в образовательном проекте OTUS —
это всегда белые методы, с современным и легким подходом, порой, увлекает, так, что теряешься во времени. Чтобы не пропустить следующий День Открытых Дверей курса «Python», который состоится 17 ноября, поставьте себе напоминалку на 20:00 и подключайтесь к трансляции из любого города, страны, континента. И наконец, чтобы завладеть желанной целью получить бесплатное образование в OTUS нужно пройти тестирование https://goo.gl/jiaW8e

О чем говорят логи Garbage Collector?

Наверняка вы слышали, что сборщик мусора в Java может оказывать значительное влияние на производительность приложения. Многое может зависеть от типа сборщика и его настройки. Есть много инструментов для того, чтобы мониторить различные параметры сборки, но иногда достаточно внимательно посмотреть на логи, которые пишет GC. В этой заметке я расскажу, как выглядят логи, которые пишет сборщик мусора и что с помощью них можно понять о работе вашего приложения. Для начала, нужно запустить JVM, указав специальные параметры:
«-XX:+PrintGCDetails» — печатать детали о событиях сборки мусора
«-XX:+PrintGCDateStamps» — также печатать timestamp этих событий
«-Xloggc:/home/otus/gc.log» — опционально можно указать, в какой файл будут писаться логи, чтобы отделить их от логов вашего приложения.
Сборщики мусора SerialGC, ParallelGC, ConcurrentMarkSweepGC (CMS) разбивают память (хип) java-приложения на несколько регионов. Это «Eden+Survivor1+Survivor2» — молодое поколение и Tenured — старое поколение. Сборщик GC1 устроен иначе и его стоит рассматривать отдельно.
Сборки мусора могут происходить только в молодом поколении — Minor GC или во всех регионах — FullGC. Давайте посмотрим на логи на примере «ParallelGC (-XX:+UseParallelGC)».
В этих логах отображено 3 сборки мусора, сначала 2 minor, затем full:
«2017-09-17T21:03:30.200+0300: 0,449: [GC (Allocation Failure) [PSYoungGen: 3662K→336K(4608K)] 3662K→3408K(15872K), 0,0020199 secs] [Times: user=0,01 sys=0,00, real=0,01 secs]
2017-09-17T21:03:30.506+0300: 0,755: [GC (Allocation Failure) [PSYoungGen: 3652K→400K(4608K)] 6724K→6544K(15872K), 0,0021768 secs] [Times: user=0,01 sys=0,00, real=0,00 secs]
017-09-17T21:03:30.815+0300: 1,064: [Full GC (Ergonomics) [PSYoungGen: 400K→0K(4608K)] [ParOldGen: 9216K→9581K(18944K)] 9616K→9581K(23552K), [Metaspace: 3570K→3570K(1056768K)], 0,0047284 secs] [Times: user=0,00 sys=0,00, real=0,01 secs]»

«2017-09-17T21:03:30.200+0300» — сперва идет timestamp — абсолютное время, когда сборка была начата, затем время относительно старта приложения (0,449).

GC (AllocationFailure) — указывает, что это минорная сборка, при полной сборке будет указано Full GC. Причина начала сборки: не удалось выделить (allocate) место под новый объект.

PSYoungGen — тип сборщика. PSYoungGen — это сборка молодого поколения в ParallelGC. Также вы можете встретить DefNew — сборка молодого поколения в SerialGC, ParNew — сборка молодого поколения CMS.
Дальше идет самая интересная с практической точки зрения часть — занятая память до и после сборки по регионам:
«[PSYoungGen: 3662K→336K(4608K)]» — В молодом поколении до сборки было 3662K, после — 336K. Всего в регионе доступно памяти — 4608K.
«3662K→3408K(15872K)» — Статистика по всему хипу, доступно 15872K. И здесь мы видим интересный момент, что в молодом поколении освободилось 3326K, а общее место в хипе уменьшилось только на 3662 — 3408 = 254К. Это означает, что часть объектов были перемещены из молодого поколения в старое (promoted).
Сборка заняла 0,0020199 secs.
Для FullGC в логах видно статистику по всем регионам памяти, так как сборка запускается и в молодом и в старом поколении.
«[PSYoungGen: 400K→0K(4608K)] [ParOldGen: 9216K→9581K(18944K)] 9616K→9581K(23552K), [Metaspace: 3570K→3570K(1056768K)], 0,0047284 secs]»
«[Times: user=0,01 sys=0,00, real=0,01 secs]»
User — user-space время (операции вне ядра ОС), затраченное на GC. Sys — kernel-space — время, затраченное на системные вызовы ОС. Real — реальное время от начала и до конца сборки мусора. В нем учитывается, то время, пока процесс был прерван ОС или заблокирован (например, на IO).
При использовании параллельной сборки User-space время может быть больше чем real-time, потому что user-space будет суммироваться по всем CPU, на которых исполнялась сборка.
Вооружившись этими знаниями, вы сможете в рантайме смотреть за поведением GC и определить, не выросли ли паузы или количество FullGC. Как используется память вашего приложения и как объекты перемещаются между регионами памяти. Понимание этих процессов дает возможность более вдумчиво подойт

и к настройке вашего приложения.

#deeppostjava

Java EE в естественной среде обитания.
С каждым днем мы получаем все больше заявок на обучение от людей с начальным уровнем знаний и вынуждено отказываем в обучении, так, как проект OTUS направлен на стремительное увеличение профессионального опыта для тех, кто уже состоялся, как профессионал. Сегодня, как и вчера, мы не набираем группы Junior Java Enterprise. Курс «Разработчик Java Enterprise» — это бесценный обмен опытом с профессионалами высокого уровня для профессионалов высокого уровня в естественной среде обитания. Эти уникальные знания и опыт от преподавательского состава нашего проекта вы получаете «из первых рук». Вы полностью погружаетесь в атмосферу сильных профессионалов, вы развиваетесь в стремительном темпе в полностью адаптированной среде. Мы не просим вас тратить самый драгоценный ресурс «ваше время» на пустые разговоры или скучные лекции. Курс «Разработчик Java Enterprise» носит уникальный характер и достоин вашего внимания. Подробности программы обучения https://goo.gl/bqRo2T

Мы разделяем любовь Виталия Чибрикова (автора курса «Разработчик Java») к Java, поэтому грядущий набор на курс будет в OTUS уже 4-тым. Группа #1 уже закончила обучение и радует нас приятными отзывами о курсе и карьерными успехами на новых местах работы. Группа #2 недавно тоже закончила обучение и находится в активной фазе трудоустройства. Желаем ребятам успехов!
Опыт выпущенных групп позволил нам максимально доработать программу под потребности рынка, сместить акценты в сторону того, что действительно важно студентам и работодателям.
Ряды Java-преподавателей пополнили опытные разработчики и сертифицированные преподаватели Дмитрий Архангельский и Олег Климаков. При этом мы сохранили дружескую атмосферу на занятиях, где есть место серьезным вопросам и подробным ответам, монологам преподавателя и интерактивам для студентов. Мы продолжаем давать студентам не всегда простые домашние задания (но ведь тяжело в учении, легко в бою, да?), чтобы максимально эффективно закреплять практикой полученные знания. Несмотря на то, что преподаватели серьезно погружены в процесс проверки домашних заданий (ведь каждому студенту нужно дать развернутый фитбек в течение двух суток), у них остается время на дискуссии со студентами — ведь мы создали живое комьюнити по Java, где студенты делятся своим опытом, обсуждают домашние задания и лекции. Случается так, что кто-то из студентов пропустил вебинар (или несколько по причине, например, отпуска). В этом случае комьюнити и видеозаписи вебинаров (они всегда будут доступны студенту), помогут наверстать упущенное.
Хотите посмотреть, как проходит вебинар, чтобы оценить, подходит ли вам такой формат? Посмотрите небольшое видео с одного из вебинаров — говорим про SOLID.
Если вам интересна серьезная разработка на Java, хочется новых кейсов, опыта, знаний и карьерных возможностей, хочется учиться с удовольствием и вы не боитесь трудностей — приходите к нам на курс. Мы начнем погружаться в тонкости Java уже завтра! Смотреть видео https://goo.gl/aE6hpH

Дорогие друзья, в связи с тем, что deeppost Java, который мы подготовили для вас, имеет сложную структуру подачи, мы не можем отправить его в канал Telegram и приглашаем вас к прочтению статьи на официальной странице facebook OTUS https://goo.gl/vjkNTM

Ура! Наступил долгожданный день! Сегодня стартует первый день занятий у четвертой группы программы обучения «Разработчик Java»!
Поздравляем слушателей курса и наших преподавателей с этим событием. Популярность курса Java растет каждый день и увеличивается в геометрической прогрессии, а это говорит о том, что специалистов с каждым днем будет становиться больше и больше. Сегодня последний день, когда можно записаться на обучение в группу #2 по курсу «Разработчик Java» https://goo.gl/KLKw6P

Друзья, сегодня День Открытых Дверей по курсу «Разработчик Python»! Начало трансляции в 20:00 по московскому времени. Именно сегодня состоится розыгрыш бесплатных мест обучения для тех, кто прошел тестирование.
Пройти тестирование можно тут https://goo.gl/EsNEmj
Присоединиться к трансляции https://goo.gl/XX9xXn
Станислав Ступников программист компании Mail.ru, преподаватель образовательного проекта OTUS сегодня в 20:00 по московскому времени в прямом эфир для вас. Можно и нужно задавать все волнующие вопросы об обучении, формате занятий и т.п. Все самые популярные вопросы: а как? а почему? а можно ли …? Будут рассмотрены именно сегодня. Присоединяйтесь!

Говоря об оптимизациях, мы должны понимать сложность используемых алгоритмов, но, зачастую, имеем ввиду только вычислительную сложность. Конечно, скорость работы алгоритма - это очень важная метрика, но мы можем и не успеть полностью, утилизировать CPU, если у нас кончится память. В реальном мире есть много ресурсов, которые надо беречь. Не про деревья и воду, а дисковый и сетевой ввод/вывод, объем кэша и даже скорость памяти. Попробуем оценить аппетит поедания памяти в динамике. Насколько легко понять, сколько и какой памяти требуется для работы нашему чудо-сервису?
«#include <array>»
«#include <memory>»
«auto static_storage = std::array<char, 0x40000000>();»
«int main(int argc, char *argv[])»
«{« «static_storage.fill(0);»
«auto dynamic_storage = std::make_unique<std::array<char, 0x40000000>>();»
«dynamic_storage->fill(0);»
«auto automatic_storage = std::array<char, 0x400000>();»
«automatic_storage.fill(0);»
«return 0;»
«}»
В примере трижды вызывается конструктор «std::array» и трижды метод «fill». Как меняется потребление памяти после выполнения каждой из этих строк? Как влияет на потребление памяти то, что первый объект со статическим временем жизни, второй в куче (да, при этом сам указатель на стеке), а третий целиком на стеке? Зачем в примере используется метод «fill», память и так уже выделена, в чем подвох? Почему память выделяется не в том порядке, в котором можно было бы ожидать? Оптимизация ни при чём. И, кстати, сколько раз массивы будут заполнены значениями? Конструктор «+ fill» и, так три раза – неверный ответ. #deeppost c++

Спешим сообщить, что 17 ноября завершился День Открытых Дверей по курсу «Разработчик Python». По традиции в гонке тестирования «светлых умов программирования» есть два победителя, которых мы спешим поздравить с тем, что они заслуженно получают в награду бесплатное образование по курсу «Разработчик Python». Ура! А, те, кто хотел присоединиться к трансляции, но не смог, приглашаем к просмотру на официальном канале YouTube образовательного проекта OTUS https://goo.gl/tNKCEg Друзья, спасибо всем, кто присутствовал на встрече! И увидимся на первом занятии!

Друзья, сегодня особенный день! В образовательном проекте OTUS, сегодня, в 19.00 часов по московскому времени, будет проходить открытый урок по Java EE. В формате вебинара будут рассмотрены вопросы проектирования API на платформе Java. Слушатель научится разрабатывать приложения построенные на базе SOA с использованием технологий «JAX-WS» и «JAX-RS». Присоединиться к трансляции можно тут https://goo.gl/Zx57tu

А мы начали говорить, про Java EE :) https://www.youtube.com/channel/UCetgtvy93o3i3CvyGXKFU3g/live

Если вы еще думаете, чем заняться в декабре — эта информация для вас! 27 ноября нас ждет уникальный День Открытых Дверей посвященный курсу «Разработчик C++». Великолепный специалист и виртуозный преподаватель Дмитрий Шебордаев в прямом эфире! Профессионал высокого уровня, выпускник МГУ, персона youself, совершенствуется c каждым днем и с радостью делиться своим опытом с нами!
Обратите внимание, что разработчик C++ в OTUS — это не начальный курс для новичков или тех, кто еще ищет себя в профессии. Это сильный курс для сильных. Это не просто скучные лекции или учеба по принципу «Ну, что нового вы сможете мне рассказать?». Это глубокий курс с увлекательным погружением в мир C++. Только лучшее, только самое смелое, ловкое и увлекательное в процессе обучения. Совершенствоваться вместе с OTUS, в атмосфере абсолютных профессионалов и единомышленников — это быстрый рост профессиональных навыков, достижений и личных побед. 80% наших учеников меняют свои профессиональные предпочтения после обучения в лучшую сторону. Ведь мы не только учим, мы вдохновляем на достижение наивысших результатов и гордимся каждым из вас!
Работодатели по окончании курса: Yandех, Luxoft, Kaspersky, КРОК, 1C. Перед началом трансляции протестируй свои знания и, кто знает, может быть именно Вам выпадет уникальная возможность бесплатного обучения в OTUS https://goo.gl/5XVuSY

Mail API. Среди распространенных требований, предъявляемых к приложениям уровня Enterprise, следует отметить необходимость отправки электронных писем на стороне сервера. Например, может потребоваться отправить сообщение пользователю после регистрации или смены пароля в системе, или же отправка сообщения с новостной рассылкой. Нет сомнений, что каждый найдет свой случай для применения этой полезной функциональности. Рассматривая стек технологий JavaEE, важно отметить, что все необходимое для отправки электронных писем доступно «из коробки» и можно использовать для любого JavaEE-приложения. Данная технология так же известна, как «Mail API», располагающаяся в пакете «javax.mail». Важно понимать, что JavaEE не решает вопросов создания почтового SMTP-сервера. Для этих целей Вы можете использовать готовые решения, к примеру, любой общедоступный сервер как Gmail, Yandex, Mail и т.д. Для целей отправки писем достаточно знать параметры используемого почтового сервера: имя и порт сервера, параметры соединения. Для безопасной отправки писем также допустимо использование «SSL» и «TLS-протоколов». С помощью «Mail API» можно отправлять не только простые письма, но и включать вложения, прикреплять изображения, документы, использовать HTML-форматирование и т.д. Наиболее значимые сущности для возможности отправки email — это класс Session, инициализирующий основные параметры для соединения с SMTP-сервером, MimeMessage, включающий информацию о получателе письма, теме, теле и вложениях сообщения, а также класс Transport, реализующий непосредственную отправку методом void send(MimeMessage message). Обратите внимание, что количество инициализируемых параметров соединения класса Session напрямую зависит от типа SMTP-сервера. Для серверов, в которых не требуется какой-либо аутентификации, достаточно указать лишь свойство «mail.smtp.host» и оставить без изменения 25й порт, используемый по умолчанию. Но для случаев использования почтовых серверов, поддерживающих SSL или TLS аутентификацию, важно детализировать оба параметра «mail.smtp.host» и «mail.smtp.port». Если рассматривать Gmail в качестве почтового сервера, то в нем используются 465й и 587й порты для SSL и TLS, соответственно (самая актуальная информация о деталях почтового сервера Gmail доступна по ссылке). Взгляните на код метода, обеспечивающего отправку письма, используя TLS-аутентификацию: «public static void sendEmail(final String username, final String password)»
«throws MessagingException {»
«Properties props = new Properties();»
«props.put(„mail.smtp.auth“, „true“);»
«props.put(„mail.smtp.starttls.enable“, „true“);»
«props.put(„mail.smtp.host“, „smtp.gmail.com“);»
«props.put(„mail.smtp.port“, „587“);»
«Session session = Session.getInstance(props,»
«new javax.mail.Authenticator() {»
«protected PasswordAuthentication getPasswordAuthentication() {»
«return new PasswordAuthentication(username, password);»
«}»
«});»
«Message message = new MimeMessage(session);»
«message.setFrom(new InternetAddress(„youremail@gmail.com“));»
«message.setRecipients(Message.RecipientType.TO,»
«InternetAddress.parse(„whomemail@gmail.com“));»
«message.setSubject(„Your Subject“);»
«message.setText(„This is test email! Don’t answer!“);»
«Transport.send(message);»
«}»
Данный код в особых комментариях особо не нуждается, поэтому для лучшего закрепления материала предлагается реализовать метод, который отправляет email через Gmail, но уже с использованием SSL-аутентификации.

Друзья, приглашаем Вас к прочтению свежей и полезной статьи "Применение DevOps практики Infrastructure as Code (IaC)" опубликованной на официальной странице OTUS в Facebook. Читать сейчас https://goo.gl/LB4VXA

Внимание, уже через час стартует сразу два Дня Открытых Дверей по курсам: «Разработчик Python» и «DevOps практики и инструменты». Старт встреч ровно в 20:00 по московскому времени. Трансляция встречи «Разработчик Python» https://goo.gl/C2Rwpp
Трансляция встречи «DevOps практики и инструменты» https://goo.gl/95nRGe

У вас есть еще час, чтобы пройти тестирование и принять участие в розыгрыше бесплатных мест обучения. До встречи в прямом эфире!