Open Source Load Balancers

Build powerful reactive, concurrent, and distributed applications more easily. Akka is a toolkit for building highly concurrent, distributed, and resilient message-driven applications for Java and Scala. Actors and Streams let you build systems that scale up, using the resources of a server more efficiently, and out, using multiple servers. Building on the principles of The Reactive Manifesto Akka allows you to write systems that self-heal and stay responsive in the face of failures. Up to 50 million msg/sec on a single machine. Small memory footprint; ~2.5 million actors per GB of heap. Distributed systems without single points of failure. Load balancing and adaptive routing across nodes. Event Sourcing and CQRS with Cluster Sharding. Distributed Data for eventual consistency using CRDTs. Asynchronous non-blocking stream processing with backpressure.

This networked(LAN) software is made as an IT solution for a blood bank to support the day-to-day actions. The software is coded using Java language and the UI is implemented with JavaFX. Please concern that this software is developed mainly for educational purpose.

AWS Load Balancer Controller is a controller to help manage Elastic Load Balancers for a Kubernetes cluster. It satisfies Kubernetes Ingress resources by provisioning Application Load Balancers. It satisfies Kubernetes Service resources by provisioning Network Load Balancers. This project was formerly known as "AWS ALB Ingress Controller", we rebranded it to be "AWS Load Balancer Controller". AWS ALB Ingress Controller was originated by Ticketmaster and CoreOS as part of Ticketmaster's move to AWS and CoreOS Tectonic. Learn more about Ticketmaster's Kubernetes initiative from Justin Dean's video at Tectonic Summit. AWS ALB Ingress Controller was donated to Kubernetes SIG-AWS to allow AWS, CoreOS, Ticketmaster and other SIG-AWS contributors to officially maintain the project. The controller watches for ingress events from the API server. When it finds ingress resources that satisfy its requirements, it begins the creation of AWS resources.

The toolkit glpk supports methods for mixed integer linear programming (MILP). These methods solve Capital Budgeting Problems (CBP). Unfortunately, glpk does not support any multithreading and there is no feature to distribute problems via network connections. Today, this is a pitiable sight, because modern computer systems are coupled by networks and support multi threading. We create a distributed system with Apache thrift and the C-API of glpk. Now, it is possible to use as many cores in a network as you want. With a focus on the MILP methods we implement a load balancing and speed up the solving process in a multiplicative way. Sometimes we have super-linear speedup with a small set of hardware. With a splitting of problems, parallel computing and distributing the actual best solution to all running processes we solve CBP much faster than a sequential processing can do.

OpenJCS (Job Control System) is a batch scheduling and control system for use on Unix systems which uses load balancing, dependency control, scheduling, runbooks, queueing and resource allocation subsystems for unmatched scalability and flexibility.

Quartz.NET is a full-featured, open-source job scheduling system that can be used from smallest apps to large-scale enterprise systems. Can run embedded within an application or even instantiated as a cluster of stand-alone programs (with load-balance and fail-over capabilities). Jobs are scheduled to run when a given trigger occurs, triggers support wide variety of scheduling options. Jobs can be any .NET class that implements the simple IJob interface, leaving infinite possibilities for the work jobs can perform. Job stores can be implemented to provide various mechanisms for the storage of jobs, in-memory and multiple relational databases come supported out of the box. Built-in support for load balancing your work and graceful fail-over. Applications can catch scheduling events to monitor or control job/trigger behavior by implementing one or more listener interfaces.

The Shepherd project is an effort to create an open-source enterprise class software platform for managing a "farm" of processing resources (servers with pre-installed software). Within the Shepherd architecture, pre-configured processes can be executed on a farm of "worker" nodes by calling them via their "resource ID". The Shepherd architecture includes the following primary software modules... - farmRcMgr: a process that manages load-balancing of "resource" processes across "worker" nodes, and requests that a "resource" process be executed on a selected "worker" node - nodeRcMgr: a process that runs on a "worker" node, and manages execution of "resource" processes on that node - farmStatus: a process accumulates log messages from other processes - webUI: a web server process that provides the UI for Shepherd

wZD is a server written in Go language that uses a modified version of the BoltDB database as a backend for saving and distributing any number of small and large files, NoSQL keys/values, in a compact form inside micro Bolt databases (archives), with distribution of files and values in BoltDB databases depending on the number of directories or subdirectories and the general structure of the directories. Using wZD can permanently solve the problem of a large number of files on any POSIX compatible file system, including a clustered one. Outwardly it works like a regular WebDAV server.