I suffered some back injuries in a minor automobile accident on Monday morning, and my concentration has been lacking due to pain.
hope you get well again soon, dude! Don't type too much and be sure to eat many apples :D
<snip type="common ground"/>
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!
My point was that it works well to implement your event-based programming as part of the handler and keep the socket server real simple. This because using a Queue for accepted connections and a single thread to do accept() seems to work a lot better than using a big server socket backlog:
,-----.
,' `.
( Web ) +-------+ +-------+
`. ---->|Request| |Request|
`-----' +-------+ +-------+
| |
+---|-------|--+ +-----------------+
| +----------+ | |Handler +-------+|
| | Backlog | | +------+ +-----+ | EBP ||
| +----------+ |-|Socket|--->|Queue|-->| ||
| ServerSocket | +------+ +-----+ +-------+|
+--------------+ +-----------------+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.
<snip type="description of EBP/NIO evolution"/>
EBP is gathering steam! Its nice to look at Tomcat5 connector ("coyote", I think) and the experimental version of Jetty (JettyExperimental) as well as the Rimfaxe Webserver as examples of how these concepts are (will be) rocking the servlet engine world.
<snip type="more general remarks"/>
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.
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
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.
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.
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
cheers,
- LSD
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
