You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Afkham Azeez <af...@gmail.com> on 2007/05/21 07:28:29 UTC
[Axis2] Clustering: Removing the ConfigurationManagerListener & ContextManagerListener
IMHO, there is no need to have multiple listeners for context/configuration
changes. If at all, practically there will be only one listener each for
context & configuration management. So I feel we should either allow the
user to specify only one listener, or scrap the listener interfaces
altogether and handle functionality the listeners were supposed to do in the
managers.
As I see it, nodes N1 & N2 will both have Managers running on them. The
managers will communicate with each other, just like the TCP/IP stack
N1 N2
--------------------------
---------------------------
| ContextManager | <------------------> | ContextManager |
--------------------------
---------------------------
The Managers send messages & communicate with each other. So for each
function there will be a pair of methods.
e.g. Node N1 ==> updateContext()
Node N2 ==> contextUpdated()
Thoughts?
--
Thanks
Afkham Azeez
http://www.wso2.org
GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760
Re: [Axis2] Clustering: Removing the ConfigurationManagerListener
& ContextManagerListener
Posted by Deepal Jayasinghe <de...@opensource.lk>.
+1
Thanks
Deepal
> So let's retain the listener interfaces, but allow the registration of
> only one listener instance each for the configuration management &
> context management.
>
> Azeez
>
> On 5/21/07, *Chamikara Jayalath* <chamikaramj@gmail.com
> <ma...@gmail.com>> wrote:
>
> Hi Azeez,
>
> By having listeners users will be able to write their own event
> handlers using the same ClusterMananager and will be able to
> control the way a Nodes should behave when they get notified of a
> changes in the Cluster.
>
> But I think u are right in saying that we may not need more than
> one listener. So I think it's OK to restrict it to a single
> listener (at least till the requirement arises). Also this may not
> be a requirement in the context replication scenarios. Here we
> almost know what we will have to do when an event get fired. So it
> may be OK to get rid of the Context listeners completely.
>
> Chamikara
>
>
>
> On 5/21/07, *Afkham Azeez* < afkham@gmail.com
> <ma...@gmail.com>> wrote:
>
> IMHO, there is no need to have multiple listeners for
> context/configuration changes. If at all, practically there
> will be only one listener each for context & configuration
> management. So I feel we should either allow the user to
> specify only one listener, or scrap the listener interfaces
> altogether and handle functionality the listeners were
> supposed to do in the managers.
>
> As I see it, nodes N1 & N2 will both have Managers running on
> them. The managers will communicate with each other, just like
> the TCP/IP stack
>
>
> N1
> N2
> --------------------------
> ---------------------------
> | ContextManager | <------------------> | ContextManager |
> --------------------------
> ---------------------------
>
> The Managers send messages & communicate with each other. So
> for each function there will be a pair of methods.
>
> e.g. Node N1 ==> updateContext()
> Node N2 ==> contextUpdated()
>
> Thoughts?
>
>
> --
> Thanks
> Afkham Azeez
>
> http://www.wso2.org
> GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E
> 0760
>
>
>
>
> --
> Chamikara Jayalath
> WSO2 Inc.
> http://wso2.com/
> http://wso2.org/ - For your Oxygen needs
>
>
>
>
> --
> Thanks
> Afkham Azeez
>
> http://www.wso2.org
> GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760
--
Thanks,
Deepal
................................................................
"The highest tower is built one brick at a time"
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Axis2] Clustering: Removing the ConfigurationManagerListener & ContextManagerListener
Posted by Afkham Azeez <af...@gmail.com>.
So let's retain the listener interfaces, but allow the registration of only
one listener instance each for the configuration management & context
management.
Azeez
On 5/21/07, Chamikara Jayalath <ch...@gmail.com> wrote:
>
> Hi Azeez,
>
> By having listeners users will be able to write their own event handlers
> using the same ClusterMananager and will be able to control the way a Nodes
> should behave when they get notified of a changes in the Cluster.
>
> But I think u are right in saying that we may not need more than one
> listener. So I think it's OK to restrict it to a single listener (at least
> till the requirement arises). Also this may not be a requirement in the
> context replication scenarios. Here we almost know what we will have to do
> when an event get fired. So it may be OK to get rid of the Context listeners
> completely.
>
> Chamikara
>
>
> On 5/21/07, Afkham Azeez <af...@gmail.com> wrote:
> >
> > IMHO, there is no need to have multiple listeners for
> > context/configuration changes. If at all, practically there will be only one
> > listener each for context & configuration management. So I feel we should
> > either allow the user to specify only one listener, or scrap the listener
> > interfaces altogether and handle functionality the listeners were supposed
> > to do in the managers.
> >
> > As I see it, nodes N1 & N2 will both have Managers running on them. The
> > managers will communicate with each other, just like the TCP/IP stack
> >
> >
> > N1 N2
> > --------------------------
> > ---------------------------
> > | ContextManager | <------------------> | ContextManager |
> > --------------------------
> > ---------------------------
> >
> > The Managers send messages & communicate with each other. So for each
> > function there will be a pair of methods.
> >
> > e.g. Node N1 ==> updateContext()
> > Node N2 ==> contextUpdated()
> >
> > Thoughts?
> >
> >
> > --
> > Thanks
> > Afkham Azeez
> >
> > http://www.wso2.org
> > GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760
>
>
>
>
> --
> Chamikara Jayalath
> WSO2 Inc.
> http://wso2.com/
> http://wso2.org/ - For your Oxygen needs
--
Thanks
Afkham Azeez
http://www.wso2.org
GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760
Re: [Axis2] Clustering: Removing the ConfigurationManagerListener & ContextManagerListener
Posted by Chamikara Jayalath <ch...@gmail.com>.
Hi Azeez,
By having listeners users will be able to write their own event handlers
using the same ClusterMananager and will be able to control the way a Nodes
should behave when they get notified of a changes in the Cluster.
But I think u are right in saying that we may not need more than one
listener. So I think it's OK to restrict it to a single listener (at least
till the requirement arises). Also this may not be a requirement in the
context replication scenarios. Here we almost know what we will have to do
when an event get fired. So it may be OK to get rid of the Context listeners
completely.
Chamikara
On 5/21/07, Afkham Azeez <af...@gmail.com> wrote:
>
> IMHO, there is no need to have multiple listeners for
> context/configuration changes. If at all, practically there will be only one
> listener each for context & configuration management. So I feel we should
> either allow the user to specify only one listener, or scrap the listener
> interfaces altogether and handle functionality the listeners were supposed
> to do in the managers.
>
> As I see it, nodes N1 & N2 will both have Managers running on them. The
> managers will communicate with each other, just like the TCP/IP stack
>
>
> N1 N2
> --------------------------
> ---------------------------
> | ContextManager | <------------------> | ContextManager |
> --------------------------
> ---------------------------
>
> The Managers send messages & communicate with each other. So for each
> function there will be a pair of methods.
>
> e.g. Node N1 ==> updateContext()
> Node N2 ==> contextUpdated()
>
> Thoughts?
>
>
> --
> Thanks
> Afkham Azeez
>
> http://www.wso2.org
> GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760
--
Chamikara Jayalath
WSO2 Inc.
http://wso2.com/
http://wso2.org/ - For your Oxygen needs