Berin Loritsch wrote:
It was mentioned in the "Monitored Components" thread that multi-threading is really the option of the handler. That *can* be
the case, but is not necessarily the case. With the arrival of event
based architectures like SEDA and NIO/NBIO, multithreading can be
completely orthagonal to the whole handler/ monitor picture.
Indeed, and that was, in fact, the point I was trying to make!
Kool!
with a smaller backlog seems to work better. Maybe the synchronization and contention around the server socket is expensive. Anyway, I haven't run my tests on the NIO version of all this; maybe that code fares better with multiple threads connecting to the server socket.
Yep, sockets are slower than just about any other resource on a computer, even the screen. Your blocking time includes both the connect, and the time it takes to read in the request. With NIO type of environments, you can have multiple threads monitoring the same ServerSocket, and processing information one bit at a time. The bits get sent to a queue which sends the events to another component. That component takes care of its processing and forwards the results to another queue, etc.
Anyway, I'm not going to describe the whole process, there are enough long documents that do that already.
As far as component health monitoring, exactly what would we monitor? Additionally, what would we do with the information once we have it? Lastly, how much of an inconvenience would it be for the component writer to use the monitoring?
the key is that what exactly we monitor and what we do with that is kept domain-specific, while the tools we provide enable making that domain-specific implementation easy. IMO.
Ok. I guess my main question which hasn't been addressed is how much of an inconvenience would this put on the component writer?
There are many different views on this. For instance, many people still hold to the monolithic approach, and want to combine all management and application logic into one large executable. Then, there is where Fortress and to some extent Merlin is, which we have a complex kernel that runs all the aspects for the application components. Lastly, we have the nano-kernel type approach that I have bantered about in the past, which looks like what Leo is inferring.
which Leo? Me? :D
I dunno.... Slipping out of consciousness... ;P
Probably you.
Anyway, fortress is /very/ close to being very usable as a nanokernel. To make that happen, all that we need to do is transfer more of the responsibilities to the component factories. Pico is a nice example of how well this works: more and more responsibility transferred into the component adapters / component adapter factories until only 50 lines or so remain in the actual container code.
Ok. So are you saying Fortress would be scalable enough to include Merlin's features as needed?
That approach means that we have some components which act to help the container do its job. In a sense, they are privileged/container components. In another sense, they can probably also be used in application logic. So should we make a distinction?
I think the key here is that it is okay to make the distinction, but that making the component author /not/ make the distinction results in cleaner and more reusable components.
Ok.
I'm not sure what point you were trying to make here, and it seems I didn't really make any points either. Ah, the joy of random thoughts :D
I didn't realize we had to have a point... My bad. :D
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
