hi Rajith.
Thanks for your reply.
Sorry for late replying. I tried to reply once but missed it and fogotten.
On 5/29/07, Rajith Attapattu <[EMAIL PROTECTED]> wrote:
Amila,
First of all I want to make sure I understand your idea properly. Based
on my understanding I have put down my comments.
Is this what u are proposing?I am putting them down in point form to make
it simple and easy to understand. Please shout if I have misunderstood you.
1. You want a single set of handlers that are determined at deployment
time.
yes.
2. You register operations against each handler. (So instead of each
operation O1 having (H1,H2..Hn) you are inverting the relationship and
proposing H1 (O1,O3,Om) and H2(O2,O3,On) ..etc
yes.
3. As u say "they know next handler and registered operations but they *do
not change* when processing the messages."
This means the handler chain is static
and is aware of the next handler in line.
Here are my comments.
1. Since u are having only one set of handlers, u will have to include all
the handlers in the chain. This is not efficient and will force the message
ctx to flow through all handlers irrespective of their interest and needs to
look up the operations map to figure out whether this operation is
registered with the particular handler.
This depends tipically how much handler can there be in a server and how
long would it be. I belive it is less than 40. of course if there are more
than 100 handlers this is a problem.
2. For different flows the order and composition of handlers can change. Ex
read Sanjiva and Dims email.
Ex - composition - We only want to log fault messages
order - for fault messages we may want to have a custom phase
before policy determination phase and for normal messages we want the custom
phase after the policy determination phase.
Considering your 3rd point above, how are u going to handle this
situation?
can you please discribe this bit more. What happens at the policy
determination phase?
3. If u have a single handler chain it will also be the bottle neck as all
your messages will now flow through a single instance of the handler chain
in serial order.
To increase performance now u will have to clone (create several
instances of) this handler chain to process messages parallel.
No. we can use the same handler chain. This is the idea behind keep its
state unchanged during the message process
How different is this from creating a custom handler chain for each
operation?
With your proposal u can reuse from a pool of handler chain instances and
will not be quite as expensive as creating every time., but if we cache
custom handler chains then we can achieve the same performance. So If we are
incurring the more or less the same cost then why not go for the added
flexibility?
The main difference between the handler chain currently have and what I am
proposing is the flow. In current case is invoked by the Axis2 Engine and
hence has no control to handlers. But on the new way each handler call to
next and have a more controll. So what type of handler chain you are talking
about?
if you proposing to keep a special handler chain (as I have told)for each
operation. (or in the Axis2Engine in a hash map indexed with the operation
Qname) that is also a possibility. this will reduce the chain length.
But the problem comes when receiving messages, without knowing the operation
before invoking and may be a problem.
If you are worried about memory and performance due to creating the
handler chain each time a message comes (for the current architecture), why
not we cache a particular handler chain? We can use a LRU algorithm to weed
out the cache. We can make this feature configurable, so people who don't
want caching can turn it off.
It clones the handler chain always simply becauce it can not use same
handler set. So caching is not a solution.
Actually It was disscussed to put a flag to use either cloning or not in
this thread.
thanks,
Amila.
Regards,
Rajith Attapattu.
Red Hat.
--
Amila Suriarachchi,
WSO2 Inc.
