-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Now I can feel the real barriers of communication when we are far away :).
Since this is a revisit of the architecture, and all the replies are very long, can we have an audio chat. We used to have weekly IRC chats, but not anymore. So how about having an audio conference? Chinthaka Rajith Attapattu 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. > > 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 > situation? > > 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. > > Regards, > > Rajith Attapattu. > Red Hat. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGXPBdjON2uBzUhh8RAiafAJ9a53WxSay1IPjTZs2yPrJeCvNlnACgqULM lfz1iCLMDrtbq7FKRaFe1Hc= =H+gG -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
