axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rajith Attapattu" <>
Subject Re: Axis2 Architecture problems. ... not any more ;)
Date Tue, 29 May 2007 16:11:44 GMT

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.

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

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.

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

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.

     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?

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.


Rajith Attapattu.
Red Hat.

View raw message