While there are many challenges in this medium, the biggest advantage is
that the history is recorded. This is a good conversation to either
(re-)rationalize the current architecture or improve it. Given the
globally distributed nature of this community, its virtually impossible to
find a single happy slot for a telecon anyway!
So, despite all the pain I think we need to continue on this path :(.
Sanjiva.
Eran Chinthaka wrote:
-----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]
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Director; Open Source Initiative; http://www.opensource.org/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
