International Business Machines Corporation

Timothy J Mitchell

Adam J Pilkington

Graham Castree Charters

Gordon Douglas Hutchison

Lewis Evans

In a service mesh, back-pressure is applied and relieved as needed by a control mechanism which is applied between pairs of services to control the rate at which service requests are made from one of service to the other via monitoring hardware and/or software metrics. A proxy of one service is monitored to observe the rate at which it receives service requests from the other service. If it is observed that the monitored metrics have breached allowable limits, back-pressure is applied to reduce the rate at which the other proxy transmits these service requests. Through continued monitoring of the proxy, the back-pressure can be later relieved when appropriate by increasing the permitted request rate.

Managing workload in a service mesh

A computer system hosting (micro)services that uses a service mesh to govern communication between the services. The services include consumer services and an event stream service, the latter directing an event stream from a producer service to the individual consumer services. The control plane of the service mesh has the role of creating and removing service instances. Based on a specified event capacity that is to be provided by the consumer services collectively, the control plane manages service provisioning by estimating the current event capacity of the system. This is done by measuring the event capacities of each consumer service instance and summing them, from which any shortfall or excess of the current event capacity in relation to the specified event capacity can be determined. Consumer service instances are then added in case of a shortfall or removed in case of an excess as needed to avoid over or under-provisioning.

Dynamic load balancing in reactive systems

A computer-implemented method, apparatus, system and computer program product for optimizing parameter data passing between services in a service mesh, the method including receiving, at a first service, a request for the first service, the request including parameter data; storing the parameter data in a request parameter store, retrieving the parameter data from the request parameter store; the first service initiating a request for a second service, the parameter data in the request being replaced by a unique token identifying the parameter data in the request parameter store; and responsive to the second service using the parameter data, retrieving the parameter data from the request parameter store.

Optimizing large parameter passing in a service mesh

Method and system are provided for identifying a source file for use in debugging compiled code. The method includes referencing a compiled file for debugging and searching for potential source files of the compiled file from configured repositories. The method obtains the potential source files from the configured repositories and iterates over the obtained potential source files to compile and compare each potential source file to the compiled file. One or more matching source files are identified for use in debugging the compiled file.

Identifying a source file for use in debugging compiled code

A method, computer system, and computer program product for generating an optimized managed runtime application is provided. Method invocation statistics for a managed runtime application are received. The managed runtime application comprises code defining a plurality of classes, each class including bytecode for one or more methods associated with the class. The method invocation statistics identify the methods invoked during at least one previous execution of the managed runtime application. An optimized version of the managed runtime application is generated based on the method invocation statistics. The managed runtime application is retrieved, and bytecode for at least one method of a class of the managed runtime application is selectively replaced with proxy code based on the method invocation statistics. The proxy code is configured for retrieving the replaced code.

Optimizing managed runtime applications for serverless environments

In a cluster of microservice nodes, each microservice node comprises a microservice and microservices form a service mesh. Data communications across the service mesh are controlled to prioritize sequence in which various data parameters are sent to destination nodes, so that data needs of a destination microservice are met as quickly as possible. An originator program receives, from a destination, data usage information relating to access of the data parameters received by a destination program from the originator program. The originator program determines, for the destination microservice, a priority order of the data parameters based on the historic data usage information, and transmits input data in the priority order to the destination program.

Controlling data communication between microservices

Diagnostic information for a program execution is provided, where the program is executable in a machine having a program stack for individual program elements. At least one program element is saved from the program stack into an event buffer as the at least one program element is executed. A historical event buffer associated with at least one runtime error is loaded, and a similarity between the event buffer and the historical event buffer is determined. It is requested that at least one type of diagnostic information be provided with the execution of the program in the event buffer when the determined similarity exceeds a threshold similarity.

Diagnostic stackframe buffer

Optimizing deployment of a modular application in a runtime environment is provided. The optimizing includes: deploying application modules of the modular application, each application module having a module manifest and at least one application module having parts for execution, one or more module manifests include one or more references to parts of another application module, and parts required for execution of the application, the deploying is according to the module manifest; executing the modular application; determining that at least one deployed application module has no parts executing in the runtime environment; and adapting the module manifest so that the determined at least one deployed application module will not be deployed as part of the modular application in future deployments.

System module deployment optimization

This invention relates to a system, method, and computer program product for providing diagnostic data for execution of a program, the program executable in a virtual machine having a program stack for individual program elements, the system comprising: a historical event buffer comprising historical execution data associated with at least one runtime error; an event buffer for saving each program element from the program stack as each program element is executed and updated with a new program element in the program stack; a buffer similarity engine for determining a similarity of the event buffer with any one of the loaded historical event buffers; and a diagnostic engine for requesting diagnostic information with the execution of the program in the event buffer when the similarity of the event buffer and a loaded historical event buffer is more than a threshold similarity.

Growing community of inventors

Chandlers Ford, United Kingdom

Timothy J Mitchell