RU2679546C2 - Устройство и способ прогона множества потоков - Google Patents

Устройство и способ прогона множества потоков Download PDF

Info

Publication number
RU2679546C2
RU2679546C2 RU2017124982A RU2017124982A RU2679546C2 RU 2679546 C2 RU2679546 C2 RU 2679546C2 RU 2017124982 A RU2017124982 A RU 2017124982A RU 2017124982 A RU2017124982 A RU 2017124982A RU 2679546 C2 RU2679546 C2 RU 2679546C2
Authority
RU
Russia
Prior art keywords
rpc
requests
request
ordered
stored
Prior art date
Application number
RU2017124982A
Other languages
English (en)
Other versions
RU2017124982A (ru
RU2017124982A3 (ru
Inventor
Дэвид ДОМИНГЕС
Александр НОЗДРИН
Original Assignee
Хуавей Текнолоджиз Ко., Лтд.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Хуавей Текнолоджиз Ко., Лтд. filed Critical Хуавей Текнолоджиз Ко., Лтд.
Publication of RU2017124982A publication Critical patent/RU2017124982A/ru
Publication of RU2017124982A3 publication Critical patent/RU2017124982A3/ru
Application granted granted Critical
Publication of RU2679546C2 publication Critical patent/RU2679546C2/ru

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F7/00—Methods or arrangements for processing data by operating upon the order or content of the data handled
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/547—Remote procedure calls [RPC]; Web services
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/28—Databases characterised by their database models, e.g. relational or object models
    • G06F16/289—Object oriented databases
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/485—Task life-cycle, e.g. stopping, restarting, resuming execution
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/133—Protocols for remote procedure calls [RPC]

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Computer And Data Communications (AREA)

Abstract

Изобретение относится к технологиям сетевой связи. Технический результат заключается в повышении скорости обработки данных. Устройство прогона множества потоков, причем упомянутое устройство содержит: память; клиента, выполненного с возможностью формирования для каждого из множества потоков запроса удаленного вызова процедуры (RPC) для выполнения операции и сохранения сформированного запроса RPC в памяти; и менеджера RPC, выполненного с возможностью упорядочивания сохраненных запросов RPC; в котором клиент дополнительно выполнен с возможностью посылки упорядоченных запросов RPC в пакете RPC посредством прогона потока в устройстве. 3 н. и 18 з.п. ф-лы, 6 ил.

Description

Область техники, к которой относится изобретение
Настоящее изобретение относится к устройству и способу прогона множества потоков. В частности, устройство и способ настоящего изобретения позволяют посылать в определенном порядке запросы удаленного вызова процедуры (RPC) в пакете RPC для повышения эффективности процедуры RPC.
Уровень техники
RPC является механизмом, позволяющим выполнение функции в адресном пространстве другого процесса, который может быть другим компьютером. В типичной процедуре RPC запрос RPC формируется клиентом и затем посылается на сервер. Ответ RPC, который является ответом на запрос RPC, принимается клиентом от сервера.
На предшествующем уровне техники обычный подход состоит в том, что клиент посылает запрос RPC и обрабатывает соответствующий ответ RPC в одном и том же потоке. В ситуации, когда запрос RPC формируется и посылается первым потоком, первый поток занимает процессор клиента до тех пор, пока не будет получен и обработан соответствующий ответ RPC. Во временном интервале между запросом RPC и соответствующим ответом RPC первый поток непрерывно опрашивает сетевую карту. Дополнительно, временной интервал может увеличиваться за счет задержки, вводимой сетевой связью. Поэтому процессор не может быть освобожден или использоваться другими потоками в течение относительно длительного периода времени.
Если клиент имеет множество потоков и каждый поток формирует запрос RPC с местом назначения, посылаемый одному или более удаленным компьютерам, эффективность процедуры RPC, выполняемой клиентом, является низкой из-за непрерывной занятости одним потоком.
Раскрытие изобретения
С точки зрения описанных выше проблем, особенно проблемы низкой эффективности выполнения процедуры RPC на стороне клиента, настоящее изобретение направлено на совершенствование состояния уровня техники. Поэтому настоящее изобретение имеет своей задачей обеспечение устройства и способа прогона множества потоков для повышения эффективности процедуры RPC.
Упомянутая выше задача настоящего изобретения достигается решением, предусмотренным в содержащихся здесь независимых пунктах формулы изобретения. Предпочтительные реализации настоящего изобретения дополнительно определяются в соответствующих зависимых пунктах формулы изобретения.
Первый вариант настоящего изобретения обеспечивает устройство прогона множества потоков. Устройство содержит память, клиента и менеджера RPC. Клиент выполнен с возможностью формирования для каждого из множества потоков запроса RPC на выполнение операции и сохранения сформированных запросов RPC (в базе данных) в памяти. Менеджер RPC выполнен с возможностью упорядочивания сохраненных запросов RPC. Клиент дополнительно выполнен с возможностью посылки упорядоченных запросов RPC в пакете RPC.
Таким образом, устройство или клиент внутри устройства посылает пакет RPC, содержащий многочисленные запросы RPC, и не посылает запросы RPC индивидуально. Таким образом, многочисленные запросы RPC фактически посылаются в одном пакете и поэтому служебная сигнализация при связи значительно снижается. Другими словами, посылка запросов RPC в пакете означает, что многочисленные запросы RPC посылаются клиентом одновременно. Таким образом, клиент может эффективно выполнять процедуру RPC, не занимая соответствующий процессор излишне долгое время.
Кроме того, многочисленные запросы RPC упорядочиваются менеджером RPC. Пакет RPC, посланный клиентом, содержит упорядоченные запросы RPC. Следовательно, в пакете RPC существует порядок (последовательность) запросов RPC. Этот порядок указывает порядок выполнения RPC в приемнике пакета RPC, например, на сервере. Другими словами, пакет RPC определяет порядок выполнения RPC. Этот порядок определяет порядок выполнения каждого запроса RPC, содержащегося в пакете.
Как вариант, ответы, соответствующие запросам RPC, также пакетируются и посылаются в пределах единого ответа на пакет RPC, содержащий запросы RPC. Таким образом, объем служебной сигнализации связи снижается и эффективность устройства повышается.
В первой форме реализации устройства, соответствующего первому варианту, менеджер RPC выполнен с возможностью упорядочивания хранящихся запросов RPC, основываясь на времени, когда были сформированы хранящиеся запросы RPC.
Поэтому порядок запросов RPC создается, основываясь на порядке формирования запросов RPC. Чем раньше формируется запрос RPC, тем выше вероятность, что запрос RPC будет послан раньше по порядку. Например, первый запрос RPC формируется раньше, чем второй запрос RPC. В одном пакете RPC первый запрос RPC устанавливается по порядку с более высоким приоритетом, чем второй запрос RPC. Таким образом, ответ на первый запрос RPC, как ожидается, должен прибыть к клиенту раньше, чем ответ на второй запрос RPC. В соответствии с другим примером, третий запрос RPC имеет более высокий шанс быть посланным в более позднем пакете RPC, если третий запрос RPC сформирован позже, чем второй запрос RPC.
Во второй форме реализации устройства, соответствующего первой форме реализации первого варианта, менеджер RPC выполнен с возможностью определения для каждого из хранящихся запросов RPC по меньшей мере одного объекта и порядок хранения запросов RPC основывается на времени и определенном объекте.
Таким образом, при определении порядка запросов RPC менеджер RPC учитывает два параметра. Первый параметр - время, когда был сформирован запрос RPC. Второй параметр - объект, связанный с RPC. При рассмотрении различных параметров определение порядка запросов RPC становится более гибким. Объект может быть данными, содержащими запрос RPC, или ссылкой на некоторый тип ключа в запросе RPC. Такой объект может быть, например, объектом базы данных или данными, на основе которых выполняется операция. Операция может быть одной из следующих: добавление объекта, удаление объекта, модификация полей объекта, применение математических действий к полю объекта, восстановление некоторых частей объекта, преобразование объекта в другую схему.
В третьей форме реализации устройства, соответствующего второй форме реализации первого варианта, все упорядоченные запросы RPC соответствуют одному и тому же объекту.
В этой ситуации множество запросов RPC, соответствующих объекту, упорядочиваются и посылаются, основываясь на самом раннем из упомянутого множества запросов RPC. Таким образом, самый ранний сформированный запрос RPC определяет приоритет множества запросов RPC, соответствующих одному и тому же объекту при передаче. Следовательно, выполнение процедуры RPC, связанной с этим объектом, облегчается.
В четвертой форме реализации устройства, соответствующего второй форме реализации первого варианта, менеджер RPC выполнен с возможностью упорядочивания всех хранящихся запросы RPC, соответствующих первому объекту, раньше упорядочивания хранящегося запроса RPC, соответствующего второму объекту, где по меньшей мере один упорядоченный запрос RPC, соответствующий первому объекту, был сформирован клиентом раньше, чем любой упорядоченный запрос RPC, соответствующий второму объекту.
Это облегчает передачу многочисленных запросов RPC, соответствующих одному объекту, через один пакет RPC. Например, второй запрос RPC формируется после первого запроса RPC и перед третьим запросом RPC. Полагая, что первый запрос RPC и третий запрос RPC соответствуют первому объекту, а второй запрос RPC соответствует второму объекту, третьему запросу RPC будет упорядочиваться так, чтобы иметь приоритет выше, чем второй запрос RPC.
В пятой форме реализации устройства, соответствующего четвертой форме реализации первого аспекта, состояние каждого сформированного запроса RPC устанавливается во время сохранения структуры данных и в дальнейшем обновляется на основе состояния ранее упорядоченных запросов RPC.
Вводя состояние запроса RPC, которое может устанавливаться и обновляться в определенных условиях, своевременное и удобное управление запросами RPC в устройстве облегчается. Клиент или менеджер RPC могут устанавливать или обновлять состояние запроса RPC в соответствии с определенной стратегией, которая облегчает регулирование нагрузки выполнения на различные части устройства.
В шестой форме реализации устройства, соответствующего пятой форме реализации первого варианта, состояние каждого сформированного запроса RPC является одним из следующих: PENDING (ожидание), SENDABLE (пригодное для посылки), SENT (послано) и COMPLETED (выполнено). Состояние устанавливается как PENDING в момент, когда сформированный запрос RPC сохранен в структуре данных. Состояние устанавливается как SENDABLE, если упорядоченный запрос RPC, соответствующий объекту, не послан и состояния всех предшествующих посланных запросов RPC, соответствующих упомянутому объекту, установлены как COMPLETED. Состояние устанавливается как SENT, если упорядоченный запрос RPC послан и ответ на упомянутый упорядоченный запрос RPC не получен клиентом. Состояние устанавливается как COMPLETED, если ответ на упорядоченный запрос RPC получен.
Четыре состояния запросов RPC связываются друг с другом определенными условиями, с тем, чтобы обеспечивать своевременное управление процедурой RPC в устройстве. Основываясь на этих четырех состояниях, устройство может точно управлять всей процедурой RPC, связанной с каждым запросом RPC.
В седьмой форме реализации устройства, соответствующей любой из предыдущих форм реализации первого варианта, упорядоченные запросы RPC посылаются в пакете посредством потока, проходящего в устройстве.
Другими словами, любой поток, проходящий в устройстве, может быть использован для посылки пакета, содержащего упорядоченные запросы RPC. Поток может быть одним и тем же или отличающимся от любого из множества потоков, формирующих запросы RPC. Следовательно, устройство не должно иметь специального потока, выделенного для посылки пакетов, что приводит к более эффективному использованию процессора (например, центрального процессора, CPU).
В восьмой форме реализации устройства, соответствующего седьмой форме реализации первого варианта, упорядоченные запросы RPC посылаются серверу, находящемуся вне устройства, например, в другом компьютерном устройстве.
Следовательно, эффективность передачи запросов RPC между двумя устройствами, которые могут быть расположены на удалении друг от друга (два компьютера), повышается.
В девятой форме реализации устройства, соответствующего любой из предыдущих форм реализации первого варианта, клиент выполнен с возможностью хранения сформированных запросов RPC в совместно используемой структуре данных, доступной менеджеру RPC.
Другими словами, к структуре данных, совместно используемой в среде множества потоков у клиента, можно получать доступ через менеджера RPC. Следовательно, любое выполнение запросов RPC, хранящихся в совместно используемой структуре данных, может выполняться клиентом или менеджером RPC или посредством обмена между клиентом и менеджером. На практике эффективность устройства при внутренней обработке и управлении может быть гибко улучшена.
В десятой форме реализации устройства, соответствующего любому из второй-девятой форм реализации первого варианта, операция, которая должна выполняться, основываясь на запросе RPC, является операцией базы данных и объект является объектом базы данных.
База данных может рассматриваться как техническое поле, в котором операция делает ссылку на операцию базы данных и объект ссылается на объект базы данных. Например, набор операций базы данных может выполняться в базе данных. Операцией базы данных является преобразование базы данных из одного состояния в другое. При таких преобразованиях нет необходимости сохранять совместимость. В последующем примере объектом базы данных является любой определенный объект в базе данных, который используется для хранения ссылочных данных. Например, объектом базы данных является блок данных в базе данных, такой как одно или более полей записи, одна или более записей или одна или более таблиц.
Второй вариант настоящего изобретения обеспечивает систему, содержащую устройство, соответствующее первому варианту настоящего изобретения, и сервер, выполненный с возможностью приема пакета RPC от устройства.
Третий вариант настоящего изобретения обеспечивает способ прогона множества потоков, содержащий этапы, на которых: формируют посредством устройства для каждого из множества потоков запрос RPC на выполнение операции; сохраняют посредством устройства сформированные запросы RPC (в базе данных) в памяти устройства; упорядочивают посредством устройства сохраненные запросы RPC и передают посредством устройства упорядоченные запросы RPC в пакете RPC.
В первой форме реализации способа, соответствующего третьему варианту, хранящиеся запросы RPC упорядочиваются, основываясь на времени, когда были сформированы хранящиеся запросы RPC.
Во второй форме реализации способа, соответствующего первой форме реализации третьего варианта, способ дополнительно содержит этап, на котором: определяют посредством устройства для каждого хранящегося запроса RPC по меньшей мере один объект, в котором хранящиеся запросы RPC упорядочиваются, основываясь на времени и определенном объекте.
В третьей форме реализации способа, соответствующего второй форме реализации третьего варианта, все упорядоченные запросы RPC соответствуют одному и тому же объекту.
В четвертой форме реализации способа, соответствующего второй форме реализации третьего варианта, способ дополнительно содержит этапы, на которых: упорядочивают все хранящиеся запросы RPC, соответствующие первому объекту, прежде чем упорядочивать хранящийся запрос RPC, соответствующий второму объекту, где по меньшей мере один упорядоченный запрос RPC, соответствующий первому объекту, был сформирован устройством раньше, чем любой упорядоченный запрос RPC, соответствующий второму объекту.
В пятой форме реализации способа, соответствующего четвертой форме реализации третьего аспекта, состояние каждого сформированного запроса RPC устанавливается, когда он сохраняется в структуре данных, и в дальнейшем обновляется, основываясь на состоянии ранее упорядоченных запросов RPC.
В шестой форме реализации способа, соответствующего пятой форме реализации третьего варианта, состояние каждого сформированного запроса RPC является одним из следующих: PENDING (ожидание), SENDABLE (пригодное для посылки), SENT (послано) и COMPLETED (выполнено). Состояние устанавливается как PENDING в момент, когда сформированный запрос RPC сохраняется в структуре данных. Состояние устанавливается как SENDABLE, если упорядоченный запрос RPC, соответствующий объекту, не послан и состояния всех предшествующих посланных запросов RPC, соответствующих упомянутому объекту, устанавливаются как COMPLETED. Состояние устанавливается как SENT, если упорядоченный запрос RPC послан и ответ на упомянутый упорядоченный запрос RPC не получен устройством. Состояние устанавливается как COMPLETED, если ответ на упорядоченный запрос RPC получен.
В седьмой форме реализации способа, соответствующего любой из предшествующих форм реализации третьего варианта, упорядоченные запросы RPC посылаются в пакете посредством потока, проходящего в устройстве.
В восьмой форме реализации способа, соответствующего седьмой форме реализации третьего варианта, упорядоченные запросы RPC отправляются серверу, находящемуся вне устройства.
В девятой форме реализации способа, соответствующего любой из предшествующих форм реализации третьего варианта, способ может дополнительно сохранять сформированные запросы RPC в совместно используемой структуре данных в устройстве, где совместно используемая структура данных доступна в устройстве как клиенту, так и менеджеру RPC.
В десятой форме реализации способа, соответствующего любой из второй-девятой форм реализации третьего варианта, операция, которая должна выполняться, основываясь на запросе RPC, является операцией базы данных и объект является объектом базы данных.
Способ настоящего изобретения достигает тех же самых преимуществ, которые описаны выше для устройства. Способ может выполняться с дополнительными этапами способа, соответствующими функциям, выполняемым различными формами реализации, описанными выше для устройства.
Краткое описание чертежей
Упомянутые выше варианты и формы реализации настоящего изобретения объясняются в последующем описании конкретных вариантов осуществления совместно с приложенными чертежами, на которых:
фиг. 1 - блок-схема устройства, соответствующего варианту осуществления настоящего изобретения;
фиг. 2 - блок-схема системы, соответствующей варианту осуществления настоящего изобретения;
фиг. 3 - способ прогона множества потоков, соответствующий варианту осуществления настоящего изобретения;
фиг. 4 - процесс управления запросами RPC, соответствующий варианту осуществления настоящего изобретения;
фиг. 5 - способ упорядочивания запросов RPC, соответствующий варианту осуществления настоящего изобретения;
фиг. 6 - процесс управления запросами RPC, соответствующий дополнительному варианту осуществления настоящего изобретения.
Подробное описание вариантов осуществления
На фиг. 1 представлена блок-схема, схематично показывающая устройство, соответствующее варианту осуществления настоящего изобретения. Устройство 100 способно к выполнению прогона множества потоков. Устройство 100 может быть любым устройством, поддерживающим процедуру RPC, например, компьютером.
Устройство 100 на фиг. 1 содержит память 101, процессор RPC, который может быть, например, клиентом 103, и менеджера 105 RPC. Клиент 103 и менеджер 105 RPC, соответственно, соединяются с памятью 101. Соединение может поддерживать управление клиентом 103 и менеджером 105 RPC данными, хранящимися в памяти 101, такое как считывание, запись и т. д. Клиент 103 может быть блоком программного обеспечения или аппаратными средствами внутри компьютера и быть выполненным с возможностью осуществления определенных функций. Примеры функций, осуществляемых клиентом 103, приводятся далее.
На фиг. 2 представлена блок-схема, схематично показывающая систему, соответствующую варианту осуществления настоящего изобретения. Система может быть компьютерной системой. Компьютерная система содержит устройство 100 и сервер 200. Сервер 200 может быть устройством, расположенным вне устройства 100, например, удаленным устройством, способным к осуществлению связи с устройством 100. Альтернативно, сервер 200 может быть частью устройства 100, например, блоком, расположенным внутри устройства 100. Другими словами, устройство 100 рассматривается как система и связь между сервером 200 и клиентом 103 осуществляется внутри устройства 100.
Как показано на фиг. 1 и фиг. 2, клиент 103 выполнен с возможностью формирования для каждого из множества потоков запроса RPC на выполнение операции и хранения сформированного запроса RPC в памяти 101. Менеджер 105 RPC выполнен с возможностью упорядочивания хранящихся запросов RPC. Клиент 103 дополнительно выполнен с возможностью посылки упорядоченных запросов RPC в пакете RPC.
В примере, операция, которая должна выполняться, основываясь на запросе RPC, является операцией базы данных и объект является объектом базы данных. Операции базы данных могут выполняться в базе данных и могут определяться как преобразование из одного состояния базы данных в другое. Для таких преобразований нет необходимости сохранять совместимость данных. Объект базы данных может быть любым определенным объектом в базе данных, которая используется для хранения данных или справочных данных. Например, объект базы данных является блоком информации в базе данных, таким как одно или более полей записи, одной или более записями или одной или более таблицами.
На фиг. 3 представлен соответствующий варианту осуществления настоящего изобретения способ прогона множества потоков, который может выполняться устройством 100, как показано на фиг. 1 и фиг. 2. Для каждого из множества потоков клиент 103 формирует запрос RPC на выполнение операции (этап 301) и дополнительно сохраняет сформированный RPC в памяти 101 (этап 303). Менеджер 105 RPC упорядочивает хранящиеся запросы RPC, с тем, чтобы клиент посылал упорядоченные запросы RPC в пакете RPC (этап 305, этап 307).
Устройство 100 может использоваться в многозадачной среде. Наиболее простым таким использованием является многопоточность. Поэтому на этапе 301 один поток у клиента 103 может моделировать множество потоков, чтобы сформировать множество запросов RPC.
В настоящем изобретении нет ограничения, какой поток используется для посылки упорядоченных запросов RPC. Другими словами, упорядоченные запросы RPC могут посылаться в пакете любым потоком, проходящим в устройстве 100. По сравнению с предшествующим уровнем техники, где поток, формирующий запрос RPC, должен посылать запрос RPC и ожидать соответствующего ответа RPC, клиент 103 может послать пакет, содержащий упорядоченные запросы RPC, посредством потока, отличного от того, который использовался при формировании упорядоченных запросов RPC. Потоки, занятые процедурами RPC, могут своевременно освобождаться и использоваться для формирования других запросов RPC. Поэтому эффективность обработки запросов RPC в устройстве 100 увеличивается.
Дополнительно, потоки, проходящие через устройство 100, могут отличаться по своей функциональности. В решении о выделении потока могут быть выделены один или более потоков для осуществления сетевой связи, такой как посылка пакета. Например, для формирования запросов RPC может быть выделено несколько потоков, тогда как для посылки пакета RPC могут быть выделены несколько потоков. Поэтому клиент 103 может быть дополнительно выполнен с возможностью определения конкретного потока или конкретной группы потоков для посылки пакета RPC. Таким образом, может быть обеспечена эффективность обработки запросов RPC в устройстве 100.
Клиент 103 может быть выполнен с возможностью сохранения сформированных запросов RPC в совместно используемой структуре 400 данных, доступной менеджеру 105 RPC. Совместно используемая структура 400 данных может быть базой данных, например, памятью 101.
Устройство 100 может, по мере необходимости, переупорядочить запросы RPC, используя механизм приоритезации, могут быть рассмотрены другой механизм приоритезации и различные параметры. Например, параметр ''время формирования" может придавать более высокое значение приоритета более ранним сформированным запросам RPC. Параметр "качество обслуживания", который связывается с RPC, может придавать более высокое значение приоритета запросам RPC, связываемым с определенным качеством обслуживания. Параметр "размер RPC" может придавать более высокое значение приоритета запросам RPC с определенным размером. Параметр "адрес получателя" может придавать более высокое значение приоритета запросам RPC с определенным адресом получателя.
В последующем варианте осуществления параметром механизма приоритезации является время формирования, то есть, время, когда сформирован запрос RPC.
На фиг. 4 представлен процесс управления запросами RPC, соответствующий варианту осуществления настоящего изобретения. Позиция "Time" (время) на фиг. 4 может, например, указывать часы прогона в системе. Каждый из запросов 1, 2, 3 и 4 RPC соответственно формируются клиентом 103 в моменты времени t1, t2, t3 и t4. Совместно используемая структура 400 данных сохраняет запросы 1, 2, 3 и 4 RPC, сформированные одним из потоков 1, 2 или 3. Менеджер 105 RPC, который может получать доступ к совместно используемой структуре 400 данных, упорядочивает запросы 1, 2, 3 и 4 RPC, основываясь на времени, когда хранящиеся запросы 1, 2, 3 и 4 RPC были сформированы клиентом 103. Клиент 103 посылает пакет Х RPC, содержащий упорядоченные запросы 1, 2, 3 и 4 RPC потоком 4 к серверу в момент время tn, например, в заданное время, когда поток 4 считывает совместно используемую структуру 400 данных, и посылает пакет Х RPC. Клиент непрерывно ведет накопление, чтобы получать ответы RPC, соответствующие запросам RPC, содержащимся в пакете Х RPC.
Если менеджер 105 RPC при ранжировании сохраненного запроса RPC учитывает один параметр, например, время, когда сформирован сохраненный запрос RPC, запросы RPC, содержащиеся в пакете Х RPC, могут иметь показанный на фиг. 4 следующий порядок "запрос 1 RPC 1, сформированный потоком 1 → запрос 2 RPC, сформированный потоком 2, → запрос 3 RPC, сформированный потоком 3 → запрос 4 RPC, сформированный потоком 2". Эта последовательность указывает, как менеджер 105 RPC последовательно упорядочивает запросы 1, 2, 3 и 4 RPC. Например, запрос 1 RPC упорядочивается раньше менеджером 105 RPC. Это означает, что ранг запроса 1 RPC выше, чем ранги запросов 1, 3 и 4 RPC. Поэтому при группировании пакета Х RPC запрос 1 RPC имеет более высокий приоритет по сравнению с запросами 2, 3 и 4 RPC.
Дополнительно, менеджер 105 RPC может быть выполнен с возможностью определения для каждого из хранящихся запросов RPC одного объекта и упорядочивания хранящихся запросов RPC, основываясь на двух параметрах: время, когда был сформирован хранящийся запрос RPC, и определенный объект. Другими словами, ранжирование каждого запроса RPC определяется, основываясь на времени, когда был сформирован сохраненный запрос RPC, и определенном объекте. Порядок запросов RPC в совместно используемой структуре 400 данных определяется, основываясь на ранжировании всех запросов RPC. В частности, менеджер 105 RPC выполнен с возможностью назначения ранга для каждого из запросов RPC, основываясь на времени и объекте. Ранжирование указывает, как запросы RPC упорядочиваются менеджером 105 RPC.
Для заданного объекта запросы RPC, соответствующие объекту, упорядочиваются в соответствии со временем, когда сформированы запросы RPC, как объясняется выше.
Полагая, что запросы 1, 2, 3 и 4 RPC соответствуют одному и тому же объекту, запросы RPC, содержащиеся в пакете Х RPC, могут иметь следующий порядок: "запрос 1 RPC→ запрос 2 RPC → запрос 3 RPC → запрос 4 RPC".
Альтернативно, запросы 1, 2, 3 и 4 RPC могут соответствовать различным объектам. Например, запросы 1 и 3 RPC соответствуют объекту 1, запрос 2 RPC соответствует объекту 2 и запрос 4 RPC соответствует объекту 3. Менеджер 105 RPC может определить, как упорядочивать запросы 1, 2, 3 и 4 RPC, что показано на фиг. 5.
В качестве примера этапа 305, показанного на фиг. 3, на фиг. 5 показан способ упорядочивания запросов RPC в соответствии с вариантом осуществления настоящего изобретения. Таблица 500 содержит информацию о запросах RPC, сформированных клиентом 103. Другими словами, запросы RPC, хранящиеся в совместно используемой структуре 400 данных, могут быть записаны в таблице 500.
Таблица 500 может храниться в памяти 101 и доступна как клиенту 103, так и менеджеру 105 RPC. Таблица 500 может обновляться всякий раз, когда изменяется любой из параметров, связанных с запросом RPC. Другими словами, как клиент 103, так и менеджер 105 RPC могут осуществлять выполнение, связанное с одним или более запросами RPC, в качестве средства запуска обновления таблицы 500. В одном из примеров, таблица 500 обновляется менеджером 105 RPC всякий раз, когда упорядочиваются один или более запросов RPC. В другом примере таблица 500 обновляется клиентом 103 всякий раз, когда сформированы один или более запросов RPC.
Как показано на фиг. 5, менеджер 105 RPC определяет, какой запрос RPC из числа запросов RPC, которые не упорядочены, является самым ранним, сформированным клиентом 103 (этап 501). Менеджер 105 RPC упорядочивает этот самый ранний запрос RPC прежде, чем упорядочивать другие сформированные запросы RPC. Другими словами, менеджер 105 RPC присваивает ранг этому самому раннему запросу RPC, чтобы придать ему самый высокий приоритет среди неупорядоченных запросов RPC, с тем, чтобы упорядочить этот самый ранний запрос RPC. Менеджер 105 RPC 05 может дополнительно соответственно обновить таблицу 500. Например, менеджер 105 RPC присваивает этому самому раннему запросу RPC (например, запросу 1 RPC) ранг "1" в таблице 500.
На этапе 503 менеджер 105 RPC определяет, к какому объекту принадлежит этот самый ранний запрос RPC. Например, определяется и записывается в таблицу 500 объект 1 (не показано на фиг. 5).
На этапе 505, менеджер 105 RPC проверяет, имеются ли другие запросы RPC, соответствующие тому же самому определенному объекту. Если "да", эти запросы RPC упорядочиваются менеджером 105 RPC, основываясь на времени, когда был сформирован каждый запрос RPC. Например, менеджер 105 RPC устанавливает порядок запроса 3 RPC раньше, чем порядок запроса 2 RPC, потому что запрос 3 RPC и запрос 1 RPC принадлежат одному и тому же объекту. Дополнительно, менеджер 105 RPC может соответственно обновить таблицу 500. Например, менеджер 105 RPC назначает в таблице 500 запросу 3 RPC ранг "2".
Если все запросы RPC, соответствующие одному и тому же определенному объекту, упорядочены, менеджер 105 RPC среди всех сформированных, но не упорядоченных запросов RPC, определяет, какой запрос RPC является самым ранним, сформированным клиентом 103. Например, менеджер 105 RPC выполняет процедуру этапов 501, 502 и 503 как итерационный алгоритм. То есть, беря всякий раз, как показано на фиг. 5, различное (обновленное) множество запросов RPC в качестве ввода в процедуру, менеджер 105 RPC непрерывно упорядочивает запросы RPC, хранящиеся в памяти 101, основываясь на таких параметрах, как время и объект.
На фиг. 6 представлен процесс управления запросов RPC, соответствующий дополнительному варианту осуществления настоящего изобретения.
Как показано на фиг. 6, таблица 600 содержит несколько параметров, используемых для управления запросами RPC, хранящимися в совместно используемой структуре 400 данных. Параметрами являются: "время формирования", когда запросы RPC сформированы клиентом 103, "объект", к которому принадлежат запросы RPC, "ранжирование", которое менеджер 105 RPC назначает запросам RPC.
Параметры дополнительно содержат состояние каждого запроса RPC. Состояние может устанавливаться и обновляться клиентом 103 или менеджером 105 RPC. В одном из примеров, клиент 103 устанавливает состояние запроса RPC при сохранении запроса RPC в совместно используемой структуре 400 данных. В другом примере менеджер 105 RPC может обновлять (сбрасывать) состояние запроса RPC, основываясь на состоянии ранее упорядоченных запросов RPC.
Состояние каждого запроса RPC может быть одним из следующих: PENDING (ожидание), SENDABLE (пригодное для посылки), SENT (послано) и COMPLETED (выполнено).
Как показано на фиг. 6, клиент 103 устанавливает каждое состояние PENDING запросов 1-8 RPC в момент, когда каждый из запросов 1-8 RPC сохраняется в совместно используемой структуре 400 данных. Устройство 100 не готово посылать запросы RPC с состоянием PENDING.
Менеджер 105 RPC упорядочивает запросы RPC, например, с помощью способа, показанного выше на фиг. 5, и записывает результаты этапа упорядочивания в позицию "порядок" таблицы 600.
Предположим, что в момент TA, как показано на фиг. 6, устройством 100 была получена только часть ответов RPC, соответствующих запросам RPC, сформированным раньше, чем запрос 1 RPC. Например, все ответы RPC, соответствующие запросам RPC, принадлежащим объекту 1 и объекту 2, были получены. Ответы RPC, соответствующие запросам RPC, принадлежащим объекту 3, не были получены.
В момент TA клиент 103 устанавливает состояние всех запросов RPC, принадлежащих объекту 1 (то есть, запросов 1 и 3 RPC), как SENDABLE.
Предположим, что пакет RPC определяется устройством 100 как содержащий больше запросов RPC, например, 6 запросов RPC. В момент TВ клиент 103 дополнительно устанавливает состояние всех запросов RPC, принадлежащих объекту 2 (то есть, запросов 2, 5 и 7 RPC) как SENDABLE.
Все другие упорядоченные запросы RPC, принадлежащие объекту 3 (то есть, запросы 4, 6 и 8 RPC), являются неупорядоченными менеджером 105 RPC в момент TB. Поскольку ответы RPC, соответствующие ранее сформированным запросам RPC (с состоянием SENT), которые принадлежат объекту 3, не были получены, ни один из запросов 4, 6 и 8 RPC не будет обновляться, то есть, их состояния устанавливаются как SENDABLE, даже когда пакет RPC имеет возможность получить еще один запрос RPC.
Клиент 103 группирует запросы 1, 2, 3, 5 и 7 RPC в пакет RPC, основываясь на их порядке. Дополнительно, клиент 103 посылает пакет RPC на сервер и в момент TC обновляет состояние запросов 1, 2, 3, 5 и 7 RPC на состояние SENT.
Предположим, что после момента TC ответы RPC, соответствующие запросам 1, 2, 3 и 5 RPC, были получены устройством 100. В момент Td клиент 103 устанавливает состояние запросов 1, 2, 3 и 5 RPC как COMPLETED. Состояние запроса 7 RPC сохраняется как SENT, поскольку до момента Td никакой ответ RPC, соответствующий запросу 7 RPC получен не был.
Дополнительно предположим, что ответы RPC, соответствующие ранее сформированным запросам RPC, принадлежащим объекту 3, также были получены устройством 100 перед TD. Состояние ранее сформированных запросов RPC, принадлежащих объекту 3, может быть установлено как COMPLETED (не показано на фиг. 6). В момент TD клиент 103 может установить состояние запросов RPC, принадлежащих объекту 3, то есть, запросов 4, 6 и 8 RPC, как SENDABLE.
Состояние запросов 4, 6 и 8 RPC будет обновлено клиентом 103, когда будет послан пакет RPC, содержащий запросы 4, 6 и 8 RPC.
Параметры, связанные с запросами RPC, являются необязательными и не ограничиваются тем, чтобы одновременно содержаться в одной таблице. Любой механизм, поддерживающий клиента 103 и менеджера 105 RPC при реализации управления запросами RPC, содержится в настоящем изобретении.
В итоге, устройство 100 и способ прогона множества потоков способны повысить эффективность процедуры RPC.
Настоящее изобретение здесь было описано в сочетании с различными вариантами осуществления. Однако, и другие вариации раскрытых вариантов осуществления могут стать понятны и осуществлены специалистами в данной области техники, практически реализующими заявленное настоящее изобретение, исходя из изучения чертежей, раскрытия и приложенной формулы изобретения. В формуле изобретения слово "содержащий" не исключает другие элементы или этапы и единственное число не исключает множественное число. Единый процессор или другой блок могут выполнять функции нескольких элементов, описанных в формуле изобретения. Простой факт, что определенные меры описываются во взаимно различных зависимых пунктах формулы изобретения, не указывает, что сочетание этих мер не может использоваться для достижения преимуществ. Компьютерная программа может храниться/распространяться на соответствующем носителе, таком как оптический носитель или твердотельный носитель, поставляемых вместе или как часть других аппаратных средств, но может также распространяться в других формах, таких как через Интернет или другие проводные или беспроводные системы связи.

Claims (21)

1. Устройство прогона множества потоков, причем упомянутое устройство содержит: память; клиента, выполненного с возможностью формирования для каждого из множества потоков запроса удаленного вызова процедуры (RPC) для выполнения операции и сохранения сформированного запроса RPC в памяти; и менеджера RPC, выполненного с возможностью упорядочивания сохраненных запросов RPC; в котором клиент дополнительно выполнен с возможностью посылки упорядоченных запросов RPC в пакете RPC посредством прогона потока в устройстве.
2. Устройство (100) по п. 1, в котором менеджер RPC выполнен с возможностью упорядочивания хранящихся запросов RPC, основываясь на времени, когда были сформированы сохраненные запросы RPC.
3. Устройство (100) по п. 2, в котором менеджер RPC выполнен с возможностью определения для каждого из сохраненных запросов RPC по меньшей мере одного объекта и упорядочивания сохраненных запросов RPC, основываясь на времени и определенном объекте.
4. Устройство по п. 3, в котором менеджер RPC выполнен с возможностью упорядочивания всех сохраненных запросов RPC, соответствующих первому объекту, прежде чем упорядочивать сохраненный запрос RPC, соответствующий второму объекту, и котором по меньшей мере один упорядоченный запрос RPC, соответствующий первому объекту, был сформирован клиентом раньше любого упорядоченного запроса RPC, соответствующего второму объекту.
5. Устройство по п. 4, в котором состояние каждого сформированного запроса RPC устанавливается при сохранении в структуре данных и после этого обновляется, основываясь на состоянии ранее упорядоченных запросов RPC.
6. Устройство по п. 5, в котором состояние каждого сформированного запроса RPC является одним из следующих: PENDING (ожидание), устанавливаемое в момент, когда сформированный запрос RPC сохранен в структуре данных; SENDABLE (пригодное для посылки), когда упорядоченный запрос RPC, соответствующий объекту, не послан и состояния всех предшествующих посланных запросов RPC, соответствующих упомянутому объекту, устанавливаются как COMPLETED; SENT (послано), когда упорядоченный запрос RPC послан и ответ на упомянутый упорядоченный запрос RPC не получен клиентом; и COMPLETED (выполнено), когда ответ на упорядоченный запрос RPC получен.
7. Устройство по п. 3, в котором все упорядоченные запросы RPC соответствуют одному и тому же объекту.
8. Устройство по п. 1, в котором упорядоченные запросы RPC посылаются серверу, находящемуся вне устройства.
9. Устройство по любому из пп. 1-7, в котором клиент выполнен с возможностью сохранения сформированных запросов RPC в совместно используемой структуре данных, доступной менеджеру RPC.
10. Устройство по любому из пп. 1-7, в котором операция, которая должна быть выполнена, основываясь на запросе RPC, является операцией базы данных и объект является объектом базы данных.
11. Система прогона множества потоков, содержащая: устройство по любому из пп. 1-7; и сервер, выполненный с возможностью получения от устройства пакета RPC.
12. Способ прогона множества потоков, содержащий этапы, на которых: формируют посредством устройства для каждого из множества потоков запрос удаленного вызова процедуры (RPC) для выполнения операции; сохраняют посредством устройства сформированные запросы RPC в памяти устройства; упорядочивают посредством устройства сохраненные запросы RPC и посылают посредством устройства упорядоченные запросы RPC в пакете RPC посредством прогона потока в устройстве.
13. Способ по п. 12, в котором сохраненные запросы RPC упорядочиваются, основываясь на времени, когда были сформированы сохраненные запросы RPC.
14. Способ по п. 13, дополнительно содержащий этап, на котором: определяют посредством устройства для каждого сохраненного запроса RPC по меньшей мере один объект; в котором сохраненные запросы RPC упорядочиваются, основываясь на времени и на определенном объекте.
15. Способ по п. 14, причем упомянутый способ дополнительно содержит этап, на котором: упорядочивают все сохраненные запросы RPC, соответствующие первому объекту, прежде чем упорядочивать сохраненный запрос RPC, соответствующий второму объекту, где по меньшей мере один упорядоченный запрос RPC, соответствующий первому объекту, был сформирован устройством раньше, чем любой упорядоченный запрос RPC, соответствующий второму объекту.
16. Способ по п. 15, в котором состояние каждого сформированного запроса RPC устанавливается, когда запрос сохраняется в структуре данных, и после этого обновляется, основываясь на состоянии ранее упорядоченных запросов RPC.
17. Способ по п. 16, в котором состояние каждого из сформированных запросов RPC является одним из следующих: PENDING (ожидание), устанавливаемое в момент, когда сформированный запрос RPC сохранен в структуре данных; SENDABLE (пригодное для посылки), когда упорядоченный запрос RPC, соответствующий объекту, не послан, и состояния всех предшествующих посланных запросов RPC, соответствующих упомянутому объекту, устанавливаются как COMPLETED; SENT (послано), когда упорядоченный запрос RPC послан и ответ на упомянутый упорядоченный запрос RPC не получен устройством; и COMPLETED (выполнено), когда ответ на упорядоченный запрос RPC получен.
18. Способ по п. 14, в котором все упорядоченные запросы RPC соответствуют одному и тому же объекту.
19. Способ по п. 12, в котором упорядоченные запросы RPC посылаются серверу, находящемуся вне устройства.
20. Способ по любому из пп. 12-18, в котором способ дополнительно содержит этап, на котором: сохраняют сформированные запросы RPC в совместно используемой структуре данных в устройстве, где совместно используемая структура данных доступна как клиенту, так и менеджеру RPC в устройстве.
21. Способ по любому из пп. 12-18, в котором операция, которая должна выполняться, основываясь на запросе RPC, является операцией базы данных и объект является объектом базы данных.
RU2017124982A 2016-08-09 2017-04-19 Устройство и способ прогона множества потоков RU2679546C2 (ru)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
EP16183428.8 2016-08-09
EP16183428.8A EP3282357B1 (en) 2016-08-09 2016-08-09 Apparatus and method for running plurality of threads
PCT/EP2017/059237 WO2018028845A1 (en) 2016-08-09 2017-04-19 Apparatus and method for running plurality of threads

Publications (3)

Publication Number Publication Date
RU2017124982A RU2017124982A (ru) 2019-01-15
RU2017124982A3 RU2017124982A3 (ru) 2019-01-15
RU2679546C2 true RU2679546C2 (ru) 2019-02-11

Family

ID=56684481

Family Applications (1)

Application Number Title Priority Date Filing Date
RU2017124982A RU2679546C2 (ru) 2016-08-09 2017-04-19 Устройство и способ прогона множества потоков

Country Status (5)

Country Link
US (1) US10606673B2 (ru)
EP (1) EP3282357B1 (ru)
JP (1) JP6749329B2 (ru)
RU (1) RU2679546C2 (ru)
WO (1) WO2018028845A1 (ru)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10721335B2 (en) 2018-08-01 2020-07-21 Hewlett Packard Enterprise Development Lp Remote procedure call using quorum state store

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7809848B1 (en) * 2005-03-15 2010-10-05 Oracle America, Inc. System and method for aggregating NFS requests
US20110145545A1 (en) * 2009-12-10 2011-06-16 International Business Machines Corporation Computer-implemented method of processing resource management
US20140007114A1 (en) * 2012-06-29 2014-01-02 Ren Wang Monitoring accesses of a thread to multiple memory controllers and selecting a thread processor for the thread based on the monitoring

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5956509A (en) * 1995-08-18 1999-09-21 Microsoft Corporation System and method for performing remote requests with an on-line service network
US6901596B1 (en) 1998-05-07 2005-05-31 Hewlett-Packard Development Company, L.P. Method of communicating asynchronous events to remote procedure call clients
DE19929751A1 (de) 1999-06-30 2001-01-18 Siemens Ag System und Verfahren zur Übertragung von Daten, insbesondere zwischen einem Anwender- und einem Serverprogramm im Bereich der Automatisierungstechnik mit verteilten Objekten
US20050080930A1 (en) * 2003-10-14 2005-04-14 International Business Machines Corporation Method and apparatus for processing service requests in a service-oriented architecture
US7380248B1 (en) 2004-02-26 2008-05-27 Sun Microsystems, Inc. Queue alerts
WO2005125235A2 (en) 2004-06-10 2005-12-29 Netmotion Wireless, Inc. Method and apparatus for providing mobile and other intermittent connectivity in a computing environment
CN101719902B (zh) 2009-12-04 2014-07-30 深圳创维数字技术股份有限公司 一种远程过程调用方法和系统
JP2015210791A (ja) 2014-04-30 2015-11-24 富士通株式会社 分散処理装置、分散処理システム、および分散処理プログラム

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7809848B1 (en) * 2005-03-15 2010-10-05 Oracle America, Inc. System and method for aggregating NFS requests
US20110145545A1 (en) * 2009-12-10 2011-06-16 International Business Machines Corporation Computer-implemented method of processing resource management
US20140007114A1 (en) * 2012-06-29 2014-01-02 Ren Wang Monitoring accesses of a thread to multiple memory controllers and selecting a thread processor for the thread based on the monitoring

Also Published As

Publication number Publication date
RU2017124982A (ru) 2019-01-15
US10606673B2 (en) 2020-03-31
EP3282357B1 (en) 2023-10-11
RU2017124982A3 (ru) 2019-01-15
US20180210772A1 (en) 2018-07-26
JP2018530796A (ja) 2018-10-18
WO2018028845A1 (en) 2018-02-15
EP3282357A1 (en) 2018-02-14
JP6749329B2 (ja) 2020-09-02

Similar Documents

Publication Publication Date Title
CN108537543B (zh) 区块链数据的并行处理方法、装置、设备和存储介质
US9917913B2 (en) Large message support for a publish-subscribe messaging system
Tan et al. Coupling task progress for mapreduce resource-aware scheduling
EP3285187B1 (en) Optimized merge-sorting of data retrieved from parallel storage units
US20160275123A1 (en) Pipeline execution of multiple map-reduce jobs
US8843632B2 (en) Allocation of resources between web services in a composite service
US20190196875A1 (en) Method, system and computer program product for processing computing task
CN110383764A (zh) 无服务器系统中使用历史数据处理事件的系统和方法
WO2019024508A1 (zh) 资源分配方法、主装置、从装置和分布式计算系统
JP2018073412A (ja) マルチストリームが可能なソリッドステートドライブ並びにそのためのドライバー及びデータストリームの統合方法
CN105786603B (zh) 一种基于分布式的高并发业务处理系统及方法
CN107766343B (zh) 一种数据存储方法、装置及存储服务器
US11947534B2 (en) Connection pools for parallel processing applications accessing distributed databases
JP6951846B2 (ja) 計算機システム及びタスクの割当方法
CN104239508A (zh) 数据查询方法和装置
US9501485B2 (en) Methods for facilitating batch analytics on archived data and devices thereof
WO2024156239A1 (zh) 视频流传输方法、装置、电子设备及存储介质
JP6069503B2 (ja) 系列データ並列分析基盤およびその並列分散処理方法
RU2679546C2 (ru) Устройство и способ прогона множества потоков
CN110309229A (zh) 分布式系统的数据处理方法和分布式系统
CN108958933A (zh) 任务执行器的配置参数更新方法、装置及设备
US11106514B2 (en) Message stream processor microbatching
WO2017018978A1 (en) Scheduling jobs in a computing cluster
Jordan et al. Wrangler's user environment: A software framework for management of data-intensive computing system
US10819622B2 (en) Batch checkpointing for inter-stream messaging system