We have to have a proper close method in the balancer. This construct:

Close chan chan bool

Currently, we post new job to balancer and wait on the request CompletedChannel from the user side, like this:

balancer.PostJob(request)
<-request.CompletedChannel

We should merge this together and have one method, which will either:

• Fail immediately if the request validation fails
• Block for the whole duration of the job, meaning the method should do the wait on the CompletedChannel. The reason for doing it, if any user of the api forgets to wait on the channel, the worker for that request will block indefinitely and there will be less workers in balancer. Balancer unknowingly will queue new work for that worker and when the buffer fills up, it will block also.

If

• timeout is unset
• Context is not cancelled
• Network call is not responding
  The worker should abandon the request and continue, closing the request CompletedChannel with the error, request abandoned

func BuildRequests(context context.Context, task *FutureTask, size int) *Request {

	tasks := make([]*FutureTask, 0, size)
	tasks = append(tasks, task)
	return &Request{Ctx: context, Tasks: tasks, TaskCount: size, CompletedChannel: make(chan bool)}
}

compared to

func BuildSingleRequest(context context.Context, task *FutureTask) *Request {
	tasks := make([]*FutureTask, 1)
	tasks = append(tasks, task)
	return &Request{Ctx: context, Tasks: tasks}
}

We have to write godoc

There should be a method in balancer to know how many jobs are queued and how the workers are responding

The workers should also be closed with the balancer.

We need to write test cases for calculating the resource utilization and if there are any unaccounted goroutines leaks. Use the following package to count the number of goroutines.

runtime.NumGoroutine()

Currently, the workers are unbuffered. Any new task comes in, it will be started in a separate goroutine, so we are not really using the priority queue properly and there are stray goroutines in the background. If the system crashes, there will be many goroutines that will fail per worker. It the worker requests channel is buffered, we will have fewer failed tasks.

w := &Worker{ requests: make(chan *Request), pending: 0, index: i, Name: fmt.Sprintf("Worker-%d", i), done: b.done}

Currently, the BridgeConnection type is like this:

type BridgeConnection chan interface{}

It would have to be
type BridgeConnection struct{ Data chan interface{} Error error }

It will help in managing the errors well between chained tasks

It would be cool to have a fanout of dependent calls based on one parent call response. Like this:

Call 1 -->Bridge data ==> Call 2 & Call 3 in parallel

We have to write proper test case for the pool.go file. It's a priority queue based on the heap interface. The existing pool_test.go file does not have enough test case to test it on load.

Think about a backend having 3 data centers, and all these data centers are no responding uniformly, some is slow and some are fast.

or

There are multiple datacenters having sync issues. Some data center is updated first and some are later.

Now during this time, if a backend call is made to the slow responding dc or the dc having stale data, the obtained response will be of higher response time or be faulty respectively.

Replica calls can help in this context. If the backend is allowing, Rio should be able to select the one response based on some condition, maybe response time based or some data quality based.