Multithreaded Message from the Devil ;P

[Berin Loritsch <bl...@apache.org>]

<disclaimer>
Playing Devil's advocate here, so the opinions and views expressed in this
message are not necessarily my own, and may in fact be totally made up.
</disclaimer>

<disclaimer>
I may or may not make sense here.  I suffered some back injuries in a minor
automobile accident on Monday morning, and my concentration has been lacking
due to pain.  Hopefully this is one of my lucid moments... ;P
</disclaimer>

The talks of what a container is supposed to do and the component is supposed
to do got me thinking a bit.  (could be good or bad).  So before we make the
component model different, or impose more requirements on the container, let's
do the big picture thing.  Why do we use components?  Because they make it
easier to manage change in an application (among other reasons).  Why do we
have containers?  Because they make it easier to manage components and apply
cross-cutting concerns consistently to all the components.  A large repository
of reusable components is a pipe dream.  There will be some that can be
reused to be sure, but not the cornicopia early adopters of COP wanted us to
believe.

So what types of problems are we solving with CBD?  Each problem domain has its
own set of challenges.  The question is how formal do we want our components
to be?  If we make everything completely hard, then new features such as thread
monitoring and such would be difficult to mix in to a containment architecture.
If we make everything completely soft (like JavaBeans), then we can run into
stability and security issues rather quickly.  So we need a balance.

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.

The traditional view of a connection listening system consumed one thread to
monitor the incoming socket, and then kick off events to a handler using a
thread pool, or just a new thread per request.  This is an N+1 resource
consumption, and usually the thread pool has to become unnecessarily large
to handle the load.  Threads are precious resources, so the solution can only
scale so far.

In a more modern view, what happens is that we have one or more threads
monitoring the *same* socket, and call the handler code in-line.  I.e. no
additional threads are called.  This is an N resource consumption for threads,
but it also has the advantage of being able to use the monitoring thread to
run the handling code.  In theory, this scales up very well, even to the point
of handling 10,000+ users simultaneously in one JVM!

There are some caveats though.  The read messages will come in piece-meal, so
the information has to be cached in some sort of message context until the whole
is received.  The response can be sent as soon as the processing is complete for
the read cycle, but it can't be committed until the socket is ready to accept
a "write".

It can be worked around if all the components in the processing chain can handle
events, and process things a little at a time.  However, most people are used
to handling things traditionally, or all at once.  It's a high impedence to
learn enough to experiment.

The thing is you will never be able to have a one size fits all solution.  Ever.
It can be a holy grail, and an inspiration to help us take great strides toward
that goal, but each problem domain has its challenges and not all of them will
translate to new problem domains.

The best thing we can do is to make simple things really easy, and hard things
possible.  It would be incredible to open up the world to new inventive ideas
that would change the way they think about the development world.  But that is
not our job.  I think the reason we are all here together is because we have in
common that Avalon components work for our kinds of problems.  We are all
working to make them easier to use and open to all developers, but some folks
are resistant to change for the sake of being resistant to change.  Don't worry
about them.

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?

There are ideas that maybe possibly, we would want to monitor threads created
by the component.  What if the container made it a security policy that your
sandboxed Startable component was not able to create threads?  Does that mean
that there is no way for the component to *use* them?  There are ways, such
as using the CommandQueue from the Event package.  Another component is
responsible for running the asynchronous code, not the sandboxed one.  That
works in many situations.  However, most of the components I write are passive
in nature.  There is no reason to actively monitor it, or to burn up precious
threads to monitor them.

The question is where is the balance?  Where should the container leave off
and the component start?

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.  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?  Maybe not.  But then again, we also need a way to implement
sandboxes in the future.  That way we would need to allow certain privileges
to some components, and deny them to others.  Perhaps we might even need a
way to identify security constraints at the service level.  For instance, the
socket handling code referred to above would need to be able to listen to and
manage sockets--all implementations.

Anyhoo, I am probably rambling by now, so I will allow for comments.

-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

Re: Multithreaded Message from the Devil ;P

[Berin Loritsch <bl...@apache.org>]

Leo Simons wrote:

> Berin Loritsch wrote:
> 
>>> 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?
> 
> 
> I wouldn't dare say anything as controversial as that! :P
> 
> Thing is, if you build a container out of components, then you can put 
> those components inside a container. Layered complexity, if you will. I 
> can't see why you couldn't layer merlin's features on top of fortress. I 
> also can't see why you can't do it the other way around.
> 
> I'm also not sure whether any of that is a good idea.

A diplomatic response.  I wasn't suggesting that we abandond Merlin and
only work with Fortress.  I think we all are willing to work with Merlin
for the future.  The componentized container is the way to go, and the
future as I see it.  We can evolve Merlin in that direction as long as
we make the components not rely directly on any one container.  That would
mean that no container component should rely on any class in the **.merlin.**
or **.fortress.** or **.phoenix.** namespaces--as a goal at least.


> Keep in mind that the last time I tried and completely grok merlins 
> internals was roughly three refactorings ago. It looks rather alien to 
> me at the moment :D

Heh, heh.  At least it still works.  That is a testament to the degree that
the component/container code is separated.  We should be able to rip appart
and reimplement a container from scratch if possible without breaking anything.
Due to the number of refactorings that Merlin has gone through, I think this
is one of the paramount requirements for it.  Stephen has been doing a decent
job in this area.

-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

Re: Multithreaded Message from the Devil ;P

[Leo Simons <le...@apache.org>]

Berin Loritsch wrote:
>> 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?

I wouldn't dare say anything as controversial as that! :P

Thing is, if you build a container out of components, then you can put 
those components inside a container. Layered complexity, if you will. I 
can't see why you couldn't layer merlin's features on top of fortress. I 
also can't see why you can't do it the other way around.

I'm also not sure whether any of that is a good idea.

Keep in mind that the last time I tried and completely grok merlins 
internals was roughly three refactorings ago. It looks rather alien to 
me at the moment :D

cheers!

- LSD



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

Re: Multithreaded Message from the Devil ;P

[Berin Loritsch <bl...@apache.org>]

Leo Simons wrote:

> 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: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

Re: Multithreaded Message from the Devil ;P

[Leo Simons <le...@apache.org>]

Berin Loritsch wrote:
> 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: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

Re: Multithreaded Message from the Devil ;P

[Berin Loritsch <bl...@apache.org>]

Stephen McConnell wrote:

> 
> 
> Berin Loritsch wrote:
> 
>> <disclaimer>
>> I may or may not make sense here.  I suffered some back injuries in a 
>> minor
>> automobile accident on Monday morning, and my concentration has been 
>> lacking
>> due to pain.  Hopefully this is one of my lucid moments... ;P
>> </disclaimer>
> 
> 
> 
> I'm guessing the above is an understatement - I have this mental image 
> of you in a hospital bed covered with plaster head to foot with a laptop 
> strapped to the right arm and fingers tapping out messages to Avalon dev 
> - you look up though dilated pupils to see a young nurses coming in and 
> cheerfully saying "Good Morning Berin! - Its time for your medication".  
> Get well soon and tell the family we'll be looking out for you (lucid or 
> otherwise)!

Man, what a grim vision...  Esp. since those young nurses turn into old men
when the medication wears off....

It was a *minor* accident, and no medication (which probably explains why
I'm in so much pain...)

I will.  I am on the mend now--the work just isn't finished yet.


-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

Re: Multithreaded Message from the Devil ;P

[Stephen McConnell <mc...@apache.org>]

Berin Loritsch wrote:

> <disclaimer>
> I may or may not make sense here.  I suffered some back injuries in a 
> minor
> automobile accident on Monday morning, and my concentration has been 
> lacking
> due to pain.  Hopefully this is one of my lucid moments... ;P
> </disclaimer>


I'm guessing the above is an understatement - I have this mental image 
of you in a hospital bed covered with plaster head to foot with a laptop 
strapped to the right arm and fingers tapping out messages to Avalon dev 
- you look up though dilated pupils to see a young nurses coming in and 
cheerfully saying "Good Morning Berin! - Its time for your medication".  
Get well soon and tell the family we'll be looking out for you (lucid or 
otherwise)!


Cheers, Steve.

-- 

Stephen J. McConnell
mailto:mcconnell@apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

Re: Multithreaded Message from the Devil ;P

[Berin Loritsch <bl...@apache.org>]

Leo Sutic wrote:

> 
>>From: Berin Loritsch [mailto:bloritsch@apache.org] 
>>
>>the opinions and views 
>>expressed in this message are not necessarily my own
> 
> 
> IP theft has reached Avalon. Great.


Nothing of the sort.  Playing Devil's Advocate entails thinking
outside your opinions.

> 
>><disclaimer>
>>I may or may not make sense here.  I suffered some back 
>>injuries in a minor automobile accident on Monday morning, 
>>and my concentration has been lacking due to pain.  Hopefully 
>>this is one of my lucid moments... ;P </disclaimer>
> 
> 
> That's a bit bad. Wishing you a speedy recovery with no
> permanent damage. Get well soon.

There is no permanent damage, but I am looking forward to several
months of chiropractic therapy, including two types of traction.
To tell the truth, even after my first visit I can tell a difference.
I am much more lucid today than I was yesterday.  Still hurts though.

Anyway, I included that info merely so you can understand if something
didn't quite make sense--not so much to elicit sympathy.  Thank you
for your well wishes, though.  They are very much appreciated.

-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

RE: Multithreaded Message from the Devil ;P

[Leo Sutic <le...@inspireinfrastructure.com>]

> From: Berin Loritsch [mailto:bloritsch@apache.org] 
>
> the opinions and views 
> expressed in this message are not necessarily my own

IP theft has reached Avalon. Great.
 
> <disclaimer>
> I may or may not make sense here.  I suffered some back 
> injuries in a minor automobile accident on Monday morning, 
> and my concentration has been lacking due to pain.  Hopefully 
> this is one of my lucid moments... ;P </disclaimer>

That's a bit bad. Wishing you a speedy recovery with no
permanent damage. Get well soon.

/LS


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org