axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Amila Suriarachchi" <amilasuriarach...@gmail.com>
Subject Re: Axis2 Architecture problems. ... not any more ;)
Date Fri, 01 Jun 2007 16:55:15 GMT
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 <rajith77@gmail.com> 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.

Mime
View raw message