The Java microservice lib. QBit is a reactive programming lib for building microservices - JSON, HTTP, WebSocket, and REST. QBit uses reactive programming to build elastic REST, and WebSockets based cloud friendly, web services. SOA evolved for mobile and cloud. ServiceDiscovery, Health, reactive StatService, events, Java idiomatic reactive programming for Microservices.
Queues should start with a size of 1, i.e., the QueueBuilder should create a queue with a queue size of one by default. This will help new projects get off the ground and help new people get started w/o getting bitten. If you want speed and throughput, increase the batch size.
We have reworked ServiceQueue so it can run in a bundle, it can run alone and it can run in a bundle which is backing an endpoint server. But the design has not kept up with the features. In fact we have more than one way to do the dispatch. The new improve way which the Vertx EventBusBridge uses and the old way, which was sort of put together under duress, but has some possible important perf stuff in it (sometimes ugly code is ugly because it is ugly and sometimes it is ugly for performance). The dispatch has to be documented and understood and possible refactored, but in such a way that does not break working fairly performant code. I am thinking of doing EndpointServer2 and doing the refactor there w/o breaking EndpoitnServerImpl and then slowly move over to ES2 once we can perf test ES1 vs. ES2. The process must start with looking at the current design, (documenting it and understanding it), and then see if there is any improvements to be made.
Thread model of Queue
The Thread model of Queue is ok. It is not flexible. It is tuned for a certain common work load. It would be nice if we could revisit this. I am thinking about moving out the Queue out of core into a new lib called Kueue. Then refactoring the threading model there. You could use the current Queue in any thread model you like, but you would have to write the code yourself. I think we can do better than this.
ServiceBundle
ServiceBundle was originally the dispatcher and it had many service queues to manage. ServiceBundle is the way you manage service pools and round robin and service shards and all sorts of goodies. We need to document the design and then do a refactor after the Thread model Queue refactor. Again, I want to start with a ServiceBundle2, and refactor it and then eventually cross over to using ServiceBundle2.
Not broken
None of this is to say that things are broken, but it is time to look at them again now that we are more feature complete.
Queue batch size of 1 as the new default
Queues should start with a size of 1, i.e., the QueueBuilder should create a queue with a queue size of one by default. This will help new projects get off the ground and help new people get started w/o getting bitten. If you want speed and throughput, increase the batch size.
ServiceQueue, ServiceBundle, Vertx EventBus Bridge, EndpointServer method dispatch
We have reworked ServiceQueue so it can run in a bundle, it can run alone and it can run in a bundle which is backing an endpoint server. But the design has not kept up with the features. In fact we have more than one way to do the dispatch. The new improve way which the Vertx EventBusBridge uses and the old way, which was sort of put together under duress, but has some possible important perf stuff in it (sometimes ugly code is ugly because it is ugly and sometimes it is ugly for performance). The dispatch has to be documented and understood and possible refactored, but in such a way that does not break working fairly performant code. I am thinking of doing EndpointServer2 and doing the refactor there w/o breaking EndpoitnServerImpl and then slowly move over to ES2 once we can perf test ES1 vs. ES2. The process must start with looking at the current design, (documenting it and understanding it), and then see if there is any improvements to be made.
Thread model of Queue
The Thread model of Queue is ok. It is not flexible. It is tuned for a certain common work load. It would be nice if we could revisit this. I am thinking about moving out the Queue out of core into a new lib called Kueue. Then refactoring the threading model there. You could use the current Queue in any thread model you like, but you would have to write the code yourself. I think we can do better than this.
ServiceBundle
ServiceBundle was originally the dispatcher and it had many service queues to manage. ServiceBundle is the way you manage service pools and round robin and service shards and all sorts of goodies. We need to document the design and then do a refactor after the
Thread model Queuerefactor. Again, I want to start with aServiceBundle2, and refactor it and then eventually cross over to usingServiceBundle2.Not broken
None of this is to say that things are broken, but it is time to look at them again now that we are more feature complete.