Hi Paul and Peter,
thank you very much for you answer. Question 1 was quite easy and I should
have found the answer myself. But the answers for 2/3 didn't help me much so
far.
> Take a look the the new lifecycle-demo.sar files in avalon-apps/demo.
> It should show you how it works. Rule of thumb : don;t block the
> initialise of start methods. Phoenix needs control back.
The lifecycle-demo just shows the usual contextualize/service/configure
stuff. ECM did the lifecycle handling (for non threadsafe components) at
lookup time. But Phoenix does it all at startup time. This seems to be my
problem.
> Best thing would be to have service that is a factory to that
> comonent...
>
> // this one is not a block.
> interface MyComp {
> void somePotentiallyThreadUnsafeMethod();
> }
>
> // this one is the block.
> interface MyCompFactory {
> MyComp getOrMakeMyComp();
> }
But then I would have to do all the lifecycle handling myself in the
factory. What do I need Phoenix for then? I would have to know about the
implementation myself and this seems to me the opposit of component oriented
programming.
The main problem seem to be that you don't know the nature of my blocks:
You seem to think:
My blocks get initialized and started and are then ready to handle
incoming requests.
But my reality is:
My blocks get initialized and start doing their work when the
start method is called. The start method NEVER RETURNS (except
when stop is called) and except of stop no method will ever be
called.
Why is this?
I basically got 3 blocks in my server Input, Converter, Output and
additionally a Main block that wires it all together.
I could theoretically build them according to your way of thinking and just
call the three services of Input, Converter and Output in a loop of the Main
block.
But the performance of the server would be very bad because these three
blocks all do tiny little things but many billions of them!
Thus I did a design where I can configure how many threads do Input, run a
Converter or do Output. So I need to be able to create multiple instances of
the same block. All these instances are of course looked up with the same
string in a for-loop. The number of threads/block-instances should be able
to change without any change to the assembly.xml but by just changing a
number in the config.xml.
So I would like to know how Phoenix advocats would design a server that has
to be optimized for throughput and that should be able to parallelize the
work so that multiple processors can be used by multiple threads.
An additional constraint is:
The Input and Output blocks do a lot of I/O but don't use the
processors much. But the Converter block doesn't do much I/O
but uses the processor very much.
So the usual Input-Converter-Output loop would lead to many
thread switches. I would rather have threads that do only
Input Output or the conversion.
I hope you now understand the problem I have got.
Regards,
Ole
--
To unsubscribe, e-mail: <mailto:avalon-users-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-users-help@;jakarta.apache.org>
