Java ™ Генератор реактивного потоку

Реактивне програмування-це мейнстрім. Навіть Java9 скоро включить інтерфейси, що підтримують систему публікації / підписки реактивних Потоків ( СЕП 266 .) Реактивний Програмування - з програмування це асинхронними потоками Даних . Це введення не вирішує фундаментальну проблему, як створити потік подій. Якщо у вас є потік, є всюдисущі програми, що мають справу з потоком. Створення потоку є предметом даної статті. (1100 слів).

Едвард Харнд ( а на coopsoft точка ком , @ed_harned )
Старший розробник, кооперативні Software Systems, Inc.

Жовтень 2015

Передмова

1. Проста задача вимагає простого рішення.

Для одного передплатника з пуш-вимогою, один видавець може впоратися з цим одним передплатником. Один видавець також може працювати з декількома Передплатниками все з тим же пуш-вимогою.

окремий абонент / видавецьокремий абонент / видавець ... окремий абонент / видавець

2. Складна проблема потребує складних ідей.

Коли декільком передплатникам з різними вимогами (скажімо, різні вимоги фільтрації) потрібен асинхронний потік, то один Видавець з декількома потоками може обробляти цих передплатників.

Проте, коли є багато (десятки і сотні) передплатників, то є необхідність в іншому рішенні.

3. Тимчасова, складна проблема вимагає ще більш складного рішення.

Коли передплатники знаходяться в різних місцях і видавець проживає окремо від інших, то починається абсолютно нова гра.

Кожен передплатник і видавець знаходяться в їх власній віртуальної машини Java. Чим більше видавців, тим більше віртуальної машини Java. Коли є багато (десятки, сотні) Видавців, то необхідно краще рішення.

4. Проблема з'єднання вимагає складного рішення.

У разі комбінації одного передплатника, мульти-передплатника, складних і віддалених передплатників і є багато (десятки, сотні) цих передплатників і видавців, то є необхідність в унікальному рішенні.

окремий абонент / видавецьокремий абонент / видавець ... окремий абонент / видавець

проблема

Багато видавців означає багато віртуальної машини Java. Маючи один-до-одного, коли існують сотні видавців, може привести до помилки 503.

Багато видавців, які проживають в тій же віртуальної машини Java, вимагають метод для відстежування цих видавців. Коли кожен Видавець потребує декількох потоках, може привести до помилки 503.

Як би ви на це не дивилися, все змінює обсяг.

Використання інтерфейсу виконавця походить на рішення, але інтерфейси засновані на потоках.

Використання динамічно розпадається системи (вилка / з'єднання), коли немає нічого для розпаду - ірраціонально.

Коли мова орієнтований на об'єкт, не можливий, розробник стикається з дилемою - використовувати потік чи ні.

рішення

Ключ до успіху - це поділ кожної окремої пуш-операції (завдання) від її видавця. Кожна Завдання може виконуватися в ефективному многозадачном мікросервісе. Tymeac для генерації реактивного потоку є рішенням для відстеження декількох пуш-операцій з будь-якої кількості видавців з найменшою кількістю потоків.

Tymeac - це

1. Ефективний багатозадачність сервіс, який дозволяє багатьом ресурсоємним додатків співіснувати в одному мікросервісе.

2. Ефективний пуш-механізм, що дозволяє Видавцям ( Реактивний ПОТІК ) генерувати асинхронні потоки для маршрутизації передплатників. Tymeac не є "Видавцем" сам по собі. Однак, оскільки видавець експортує роботу підписки (фільтр і т.д.) в Завдання, Видавець може працювати сам як Tymeac завдання і не потребує потоці.

3. 100% Java Пуш чистий-МЕХАНІЗМ. Tymeac не покладається на зовнішні додатки для багатозадачного режиму. Ні препроцесорам, немає автономної роботи, НІЯКИХ обмежень по обладнанню. Якщо ваш додаток працює на Java SE, воно працює без будь-яких модифікацій або додаткових завантажень з Tymeac.

4. Гнучкий пуш-механізм, який підтримує неблокірующіх засунений. Ви можете скасувати (розумно), натиснути на паузу / відновлення, і змінити будь-який додаток в будь-який час.

5. Стійкий пуш-механізм, який підтримує декілька сценаріїв тайм-ауту, щоб впоратися з не відповідають додатками.

6. Масштабний пуш-механізм, так як Завдання відокремлені від потоків.

7. Повнофункціональний пуш-механізм. Tymeac поставляється з дев'ятнадцятьма доступами клієнтської програми JavaFX з графічним інтерфейсом і так чином можна контролювати / змінювати виконуваний запит і сервер. І ще п'ять JavaFX з графічним інтерфейсом для установки серверного додатка.

Опис: Tymeac меню

8. Перестроюваний пуш-механізм. Кожна чергу і потік має структуру управління, для полегшення налаштування.

9. Універсальний пуш-механізм з підтримкою локального (такий же віртуальної машини Java) і віддаленого доступу (RMI).

10. 10. добре документований пуш-механізм. У той час як JavaDoc хороший для API-х, професійний мікросервіс вимагає професійної документації.

10.

Tymeac підтримує загальну і окрему обробку.

Як працює спільне опрацювання:

Загальний означає спільноту. У співтоваристві, гравці грають добре один з одним. Ті, хто не грають добре, шкодять для всіх. Якщо гравець не грає добре, то належить до " окремої " майданчику.

Завдання - це серце процесингу. Завдання містить змінні / методи, які Tymeac повинен виконати в багатозадачному режимі запитів. Всі призначені для користувача класи повинні розширити цей клас. завдання може

• активно обчислювати потік або

• перебувати в очікуванні ресурсу (база даних / доступ до файлів, доступ до інтернету, або інший доступ для обслуговування) Тайм-аут - це спосіб впоратися з не відповідають доступами,

• чекати відправки для завершення (onNext і т.д.)

У той час поки Завдання очікує чогось, Tymeac може поставити задачу в очікування, звільняючи потік для іншої роботи. Це просте управління завдання, яке більшість операційних систем використовують для планування роботи на процесорах. Tymeac не може зробити контекстне перемикання. Tymeac спирається на співпрацю Завдань в постановці завдання до дії (потрібен посил, потрібен ресурсу) і повернення з методу виклику, ніж блокування.

Tymeac чудово реалізує дуже просту концепцію:

Поставте запити в черзі для обробки асинхронних потоків.

Tymeac використовує три черги: активна, відправка і в очікуванні. Кожна чергу має спеціальний пул потоків.


Черга на відправку потрібна для потоку, щоб викликати завдання, і використовувати Оглядач <T>, щоб відправити асинхронний потік (onNext / Помилка / Завершено.) Після того, як відправка завершена, Tymeac переміщує завдання до активної черги, або, якщо є ще затримка видатним, Tymeac переміщує завдання в чергу в очікуванні. Активна чергу потрібна для потоку, щоб викликати завдання, щоб завдання могли вирахувати те, що вони роблять. Коли Завдання потребує ресурсі, вона запускає асинхронний доступ, встановлює, за оцінками, час затримки, яке, як вона вважає, необхідно для доступу (відкладене дію тут - це затримка в очікуванні завершення) і повертається, якщо їй не потрібно посилати дані. Коли Задачі необхідно відправити потік (onNext і т.д.), вона встановлює відправки на розгляді (відкладене дію) і повертається. Якщо є відправити на розгляді, Tymeac переносить завдання в чергу на відправку. Якщо немає відправки на розгляді, але є затримка, то Tymeac переміщує завдання в чергу в очікуванні.

Черга в очікуванні потрібна для очікування завершення події (затримка, після закінчення або один з тих асинхронних доступів для завершення .) Після того, як подія завершено, Tymeac переміщує завдання до активної черги.

Таким чином, Завдання співпрацюють з іншими Завданнями, не зв'язуючи потік з блокуючими викликами. Обчислити - все, що вам потрібно. Скасуйте потік, коли ви повинні чекати. Система може підтримувати сотні / тисячі активних запитів за допомогою декількох потоків.

Як працює окрема обробка:

Tymeac використовує одну чергу: Окрему. Черга має спеціальний пул потоків.

Окрема Черга потрібна для завдань, щоб зробити все, що вони роблять; доступ до ресурсів, відправка onNext / Помилка / Завершено. Як тільки ви тут, вони залишаються тут, поки запит не завершиться. Різниця між загальним пулом потоків і окремої обробки ой в тому , що Tymeac управляє постійним з'єднанням, обміном повідомленнями, чергами, потоками, виявлення / відновлення збоїв, рекурсією, веденням журналу, статистикою, призначеним для користувача інтерфейсом і багатьом іншим.

висновок

Якщо вам потрібен безпечний, надійний, керований, і відмовостійкої асинхронний конструктор потоків для будь-яких цілей і не хочете самі починати проектування і тестування, то вам потрібен Tymeac.

посилання

Завантажуйте проект з SourceForge.net, проект: TymeacRSE

JEP 266
http://openjdk.java.net/jeps/266

Введення в реактивне програмування

https://gist.github.com/staltz/868e7e9bc2a7b8c1f754

Реактивні Streams орг
http://www.reactive-streams.org/

про автора

Харнд ед є розробником програмного Забезпечення з досвідом роботи понад тридцять років. Спочатку вів проекти в якості працівника в основних галузях промисловості, а потім працював в якості незалежного консультанта. Сьогодні, Ед є старшим розробником в Кооперативні Software Systems, Inc , де протягом останніх чотирнадцяти років, використовує Java ™, щоб впроваджувати паралельні рішення для широкого кола завдань.

© 2015 Е.П. Харнд Всі права захищені