You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@synapse.apache.org by TrevorC <ma...@gmail.com> on 2011/06/29 15:28:31 UTC
Sample #57 Dynamic load balancing
Hey Guys
I got a problem wit sample 57 I cant run it.I have done everything
instructed by sample documentation but when it come 2 client side I get
error message "couldn't send the message to the server" and also apache
synapse interface has an error message "DynamicloadbalancingEndpoint no
application members available" .Any Suggestion
Contribution will appreciated
Kind Regards
Trevor
--
View this message in context: http://old.nabble.com/Sample--57-Dynamic-load-balancing-tp31954754p31954754.html
Sent from the Synapse - User mailing list archive at Nabble.com.
Re: Sample #57 Dynamic load balancing
Posted by TrevorC <ma...@gmail.com>.
Hi Afkham
Im checking if you have found the problem...or probably just send me your
xml
if sample 57 is working
TrevorC wrote:
>
> Here are logs
>
> Afkham Azeez wrote:
>>
>> Please enable info level logs for org.apache.axis2.clustering in both the
>> servers, and send the logs over.
>>
>>
>> On Tue, Jul 19, 2011 at 6:21 PM, TrevorC <ma...@gmail.com> wrote:
>>
>>>
>>> Hi Afkham
>>>
>>> i did the modification now the problem Im getting an error message that
>>> say
>>> "The input stream for an incoming message is null "
>>>
>>> Any Suggestion
>>>
>>>
>>>
>>> TrevorC wrote:
>>> >
>>> > Hi Afkham
>>> >
>>> > I cant see any attached files or is there way 2 retrieve them
>>> >
>>> > Afkham Azeez wrote:
>>> >>
>>> >> The clustering configurations in both files are identical. That won't
>>> >> work
>>> >> in a dynamic LB scenario.
>>> >>
>>> >> Please try replacing the clustering sections in the respective
>>> axis2.xml
>>> >> files with the attached ones.
>>> >>
>>> >> If you want to understand how to configure clustering, please see;
>>> >>
>>> >> 1.
>>> http://wso2.org/library/articles/introduction-wso2-carbon-clustering
>>> >> 2.
>>> >>
>>> http://wso2.org/library/articles/wso2-carbon-cluster-configuration-language
>>> >>
>>> >>
>>> >> On Wed, Jul 13, 2011 at 1:30 AM, TrevorC <ma...@gmail.com>
>>> wrote:
>>> >>
>>> >>>
>>> >>> Here are my xml files synapse,axis server respectively
>>> >>> contribution are highly appreciated
>>> >>>
>>> >>> Afkham Azeez wrote:
>>> >>> >
>>> >>> > No application members available suggests that the Axis2 nodes
>>> were
>>> >>> not
>>> >>> > able
>>> >>> > to join the load balancers (LB) cluster. This indicates that
>>> either;
>>> >>> >
>>> >>> > 1. GroupManagement has not been enabled in the LB's axis2.xml
>>> >>> > 2. A group management agent has not been defined in the axis2.xml
>>> file
>>> >>> > corresponding to the domain defined in the Axis2 nodes' axis2.xml
>>> >>> > 3. If you have enabled multicast based membership discovery,
>>> >>> multicasting
>>> >>> > is
>>> >>> > not working on your network, hence the membership discovery fails
>>> >>> > 4. In the LB you have enabled wka based membership discovery, and
>>> in
>>> >>> the
>>> >>> > Axis2 nodes, you have enabled WKA based discovery.
>>> >>> > 5. Members advertising invalid hosts/ports because of invalid
>>> >>> clustering
>>> >>> > config.
>>> >>> >
>>> >>> >
>>> >>> > Send me your axis2.xml files and synapse.xml file, and I will see
>>> what
>>> >>> is
>>> >>> > wrong.
>>> >>> >
>>> >>> >
>>> >>> http://old.nabble.com/file/p32048735/axis2.xml axis2.xml
>>> >>> http://old.nabble.com/file/p32048735/axis2.xml axis2.xml
>>> >>> --
>>> >>> View this message in context:
>>> >>>
>>> http://old.nabble.com/Sample--57-Dynamic-load-balancing-tp31954754p32048735.html
>>> >>> Sent from the Synapse - User mailing list archive at Nabble.com.
>>> >>>
>>> >>>
>>> >>
>>> >>
>>> >> --
>>> >> *Afkham Azeez*
>>> >> Director of Architecture; WSO2, Inc.; http://wso2.com,
>>> >> *Member; Apache Software Foundation;
>>> >> **http://www.apache.org/*<http://www.apache.org/>
>>> >> *
>>> >> *
>>> >> *email: **azeez@wso2.com* <az...@wso2.com>* cell: +94 77 3320919
>>> >> blog: **http://blog.afkham.org* <http://blog.afkham.org>*
>>> >> twitter:
>>> >> **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez>
>>> >> *
>>> >> linked-in: **http://lk.linkedin.com/in/afkhamazeez*
>>> >> *
>>> >> *
>>> >> *Lean . Enterprise . Middleware*
>>> >> *
>>> >> *
>>> >>
>>> >> <clustering
>>> >> class="org.apache.axis2.clustering.tribes.TribesClusteringAgent"
>>> >> enable="true">
>>> >>
>>> >> <!--
>>> >> This parameter indicates whether the cluster has to be
>>> >> automatically initalized
>>> >> when the AxisConfiguration is built. If set to "true" the
>>> >> initialization will not be
>>> >> done at that stage, and some other party will have to
>>> >> explictly initialize the cluster.
>>> >> -->
>>> >> <parameter name="AvoidInitiation">true</parameter>
>>> >>
>>> >> <!--
>>> >> The membership scheme used in this setup. The only values
>>> >> supported at the moment are
>>> >> "multicast" and "wka"
>>> >>
>>> >> 1. multicast - membership is automatically discovered
>>> using
>>> >> multicasting
>>> >> 2. wka - Well-Known Address based multicasting. Membership
>>> is
>>> >> discovered with the help
>>> >> of one or more nodes running at a Well-Known
>>> Address.
>>> >> New members joining a
>>> >> cluster will first connect to a well-known node,
>>> >> register with the well-known node
>>> >> and get the membership list from it. When new
>>> members
>>> >> join, one of the well-known
>>> >> nodes will notify the others in the group. When a
>>> >> member leaves the cluster or
>>> >> is deemed to have left the cluster, it will be
>>> >> detected by the Group Membership
>>> >> Service (GMS) using a TCP ping mechanism.
>>> >> -->
>>> >> <parameter name="membershipScheme">multicast</parameter>
>>> >>
>>> >> <!--
>>> >> The clustering domain/group. Nodes in the same group will
>>> belong
>>> >> to the same multicast
>>> >> domain. There will not be interference between nodes in
>>> >> different groups.
>>> >> -->
>>> >> <parameter
>>> >> name="domain">apache.axis2.application.domain</parameter>
>>> >>
>>> >> <!--
>>> >> When a Web service request is received, and processed,
>>> before
>>> >> the response is sent to the
>>> >> client, should we update the states of all members in the
>>> >> cluster? If the value of
>>> >> this parameter is set to "true", the response to the
>>> client
>>> >> will be sent only after
>>> >> all the members have been updated. Obviously, this can be
>>> time
>>> >> consuming. In some cases,
>>> >> such this overhead may not be acceptable, in which case
>>> the
>>> >> value of this parameter
>>> >> should be set to "false"
>>> >> -->
>>> >> <parameter name="synchronizeAll">false</parameter>
>>> >>
>>> >> <!--
>>> >> The maximum number of times we need to retry to send a
>>> message
>>> >> to a particular node
>>> >> before giving up and considering that node to be faulty
>>> >> -->
>>> >> <parameter name="maxRetries">10</parameter>
>>> >>
>>> >> <!-- The multicast address to be used -->
>>> >> <parameter name="mcastAddress">228.0.0.4</parameter>
>>> >>
>>> >> <!-- The multicast port to be used -->
>>> >> <parameter name="mcastPort">45564</parameter>
>>> >>
>>> >> <!-- The frequency of sending membership multicast messages
>>> (in
>>> >> ms) -->
>>> >> <parameter name="mcastFrequency">500</parameter>
>>> >>
>>> >> <!-- The time interval within which if a member does not
>>> respond,
>>> >> the member will be
>>> >> deemed to have left the group (in ms)
>>> >> -->
>>> >> <parameter name="memberDropTime">3000</parameter>
>>> >>
>>> >> <!--
>>> >> The IP address of the network interface to which the
>>> >> multicasting has to be bound to.
>>> >> Multicasting would be done using this interface.
>>> >> -->
>>> >> <parameter name="mcastBindAddress">127.0.0.1</parameter>
>>> >>
>>> >> <!-- The host name or IP address of this member -->
>>> >>
>>> >> <parameter name="localMemberHost">127.0.0.1</parameter>
>>> >>
>>> >>
>>> >> <!--
>>> >> The TCP port used by this member. This is the port through
>>> which
>>> >> other nodes will
>>> >> contact this member
>>> >> -->
>>> >> <parameter name="localMemberPort">4010</parameter>
>>> >>
>>> >> <!--
>>> >> Preserve message ordering. This will be done according to
>>> sender
>>> >> order.
>>> >> -->
>>> >> <parameter name="preserveMessageOrder">true</parameter>
>>> >>
>>> >> <!--
>>> >> Maintain atmost-once message processing semantics
>>> >> -->
>>> >> <parameter name="atmostOnceMessageSemantics">true</parameter>
>>> >>
>>> >> <!--
>>> >> This interface is responsible for handling state
>>> replication.
>>> >> The property changes in
>>> >> the Axis2 context hierarchy in this node, are propagated
>>> to
>>> >> all other nodes in the cluster.
>>> >>
>>> >> The "excludes" patterns can be used to specify the
>>> prefixes
>>> >> (e.g. local_*) or
>>> >> suffixes (e.g. *_local) of the properties to be excluded
>>> from
>>> >> replication. The pattern
>>> >> "*" indicates that all properties in a particular context
>>> >> should not be replicated.
>>> >>
>>> >> The "enable" attribute indicates whether context
>>> replication
>>> >> has been enabled
>>> >> -->
>>> >> <stateManager
>>> >> class="org.apache.axis2.clustering.state.DefaultStateManager"
>>> >> enable="false">
>>> >> <replication>
>>> >> <defaults>
>>> >> <exclude name="local_*"/>
>>> >> <exclude name="LOCAL_*"/>
>>> >> </defaults>
>>> >> <context
>>> >> class="org.apache.axis2.context.ConfigurationContext">
>>> >> <exclude name="local_*"/>
>>> >> <exclude name="UseAsyncOperations"/>
>>> >> <exclude name="SequencePropertyBeanMap"/>
>>> >> </context>
>>> >> <context
>>> >> class="org.apache.axis2.context.ServiceGroupContext">
>>> >> <exclude name="local_*"/>
>>> >> <exclude name="my.sandesha.*"/>
>>> >> </context>
>>> >> <context
>>> class="org.apache.axis2.context.ServiceContext">
>>> >> <exclude name="local_*"/>
>>> >> <exclude name="my.sandesha.*"/>
>>> >> </context>
>>> >> </replication>
>>> >> </stateManager>
>>> >> </clustering>
>>> >>
>>> >> <clustering
>>> >> class="org.apache.axis2.clustering.tribes.TribesClusteringAgent"
>>> >> enable="true">
>>> >>
>>> >> <!--
>>> >> This parameter indicates whether the cluster has to be
>>> >> automatically initalized
>>> >> when the AxisConfiguration is built. If set to "true" the
>>> >> initialization will not be
>>> >> done at that stage, and some other party will have to
>>> >> explictly initialize the cluster.
>>> >> -->
>>> >> <parameter name="AvoidInitiation">true</parameter>
>>> >>
>>> >> <!--
>>> >> The membership scheme used in this setup. The only values
>>> >> supported at the moment are
>>> >> "multicast" and "wka"
>>> >>
>>> >> 1. multicast - membership is automatically discovered
>>> using
>>> >> multicasting
>>> >> 2. wka - Well-Known Address based multicasting. Membership
>>> is
>>> >> discovered with the help
>>> >> of one or more nodes running at a Well-Known
>>> Address.
>>> >> New members joining a
>>> >> cluster will first connect to a well-known node,
>>> >> register with the well-known node
>>> >> and get the membership list from it. When new
>>> members
>>> >> join, one of the well-known
>>> >> nodes will notify the others in the group. When a
>>> >> member leaves the cluster or
>>> >> is deemed to have left the cluster, it will be
>>> >> detected by the Group Membership
>>> >> Service (GMS) using a TCP ping mechanism.
>>> >> -->
>>> >> <parameter name="membershipScheme">multicast</parameter>
>>> >>
>>> >> <!--
>>> >> The clustering domain/group. Nodes in the same group will
>>> belong
>>> >> to the same multicast
>>> >> domain. There will not be interference between nodes in
>>> >> different groups.
>>> >> -->
>>> >> <parameter name="domain">wso2.carbon.lb.domain</parameter>
>>> >>
>>> >> <!--
>>> >> When a Web service request is received, and processed,
>>> before
>>> >> the response is sent to the
>>> >> client, should we update the states of all members in the
>>> >> cluster? If the value of
>>> >> this parameter is set to "true", the response to the
>>> client
>>> >> will be sent only after
>>> >> all the members have been updated. Obviously, this can be
>>> time
>>> >> consuming. In some cases,
>>> >> such this overhead may not be acceptable, in which case
>>> the
>>> >> value of this parameter
>>> >> should be set to "false"
>>> >> -->
>>> >> <parameter name="synchronizeAll">false</parameter>
>>> >>
>>> >> <!--
>>> >> The maximum number of times we need to retry to send a
>>> message
>>> >> to a particular node
>>> >> before giving up and considering that node to be faulty
>>> >> -->
>>> >> <parameter name="maxRetries">10</parameter>
>>> >>
>>> >> <!-- The multicast address to be used -->
>>> >> <parameter name="mcastAddress">228.0.0.4</parameter>
>>> >>
>>> >> <!-- The multicast port to be used -->
>>> >> <parameter name="mcastPort">45564</parameter>
>>> >>
>>> >> <!-- The frequency of sending membership multicast messages
>>> (in
>>> >> ms) -->
>>> >> <parameter name="mcastFrequency">500</parameter>
>>> >>
>>> >> <!-- The time interval within which if a member does not
>>> respond,
>>> >> the member will be
>>> >> deemed to have left the group (in ms)
>>> >> -->
>>> >> <parameter name="memberDropTime">3000</parameter>
>>> >>
>>> >> <!--
>>> >> The IP address of the network interface to which the
>>> >> multicasting has to be bound to.
>>> >> Multicasting would be done using this interface.
>>> >> -->
>>> >> <parameter name="mcastBindAddress">127.0.0.1</parameter>
>>> >>
>>> >> <!-- The host name or IP address of this member -->
>>> >>
>>> >> <parameter name="localMemberHost">127.0.0.1</parameter>
>>> >>
>>> >>
>>> >> <!--
>>> >> The TCP port used by this member. This is the port through
>>> which
>>> >> other nodes will
>>> >> contact this member
>>> >> -->
>>> >> <parameter name="localMemberPort">4000</parameter>
>>> >>
>>> >> <!--
>>> >> Preserve message ordering. This will be done according to
>>> sender
>>> >> order.
>>> >> -->
>>> >> <parameter name="preserveMessageOrder">true</parameter>
>>> >>
>>> >> <!--
>>> >> Maintain atmost-once message processing semantics
>>> >> -->
>>> >> <parameter name="atmostOnceMessageSemantics">true</parameter>
>>> >>
>>> >> <!--
>>> >> Enable the groupManagement entry if you need to run this node
>>> as
>>> >> a cluster manager.
>>> >> Multiple application domains with different
>>> GroupManagementAgent
>>> >> implementations
>>> >> can be defined in this section.
>>> >> -->
>>> >> <groupManagement enable="true">
>>> >> <applicationDomain name="apache.axis2.application.domain"
>>> >> description="Axis2 group"
>>> >>
>>> >>
>>> agent="org.apache.axis2.clustering.management.DefaultGroupManagementAgent"/>
>>> >> </groupManagement>
>>> >>
>>> >> <!--
>>> >> This interface is responsible for handling state
>>> replication.
>>> >> The property changes in
>>> >> the Axis2 context hierarchy in this node, are propagated
>>> to
>>> >> all other nodes in the cluster.
>>> >>
>>> >> The "excludes" patterns can be used to specify the
>>> prefixes
>>> >> (e.g. local_*) or
>>> >> suffixes (e.g. *_local) of the properties to be excluded
>>> from
>>> >> replication. The pattern
>>> >> "*" indicates that all properties in a particular context
>>> >> should not be replicated.
>>> >>
>>> >> The "enable" attribute indicates whether context
>>> replication
>>> >> has been enabled
>>> >> -->
>>> >> <stateManager
>>> >> class="org.apache.axis2.clustering.state.DefaultStateManager"
>>> >> enable="false">
>>> >> <replication>
>>> >> <defaults>
>>> >> <exclude name="local_*"/>
>>> >> <exclude name="LOCAL_*"/>
>>> >> </defaults>
>>> >> <context
>>> >> class="org.apache.axis2.context.ConfigurationContext">
>>> >> <exclude name="local_*"/>
>>> >> <exclude name="UseAsyncOperations"/>
>>> >> <exclude name="SequencePropertyBeanMap"/>
>>> >> </context>
>>> >> <context
>>> >> class="org.apache.axis2.context.ServiceGroupContext">
>>> >> <exclude name="local_*"/>
>>> >> <exclude name="my.sandesha.*"/>
>>> >> </context>
>>> >> <context
>>> class="org.apache.axis2.context.ServiceContext">
>>> >> <exclude name="local_*"/>
>>> >> <exclude name="my.sandesha.*"/>
>>> >> </context>
>>> >> </replication>
>>> >> </stateManager>
>>> >> </clustering>
>>> >>
>>> >>
>>> >
>>> >
>>>
>>> --
>>> View this message in context:
>>> http://old.nabble.com/Sample--57-Dynamic-load-balancing-tp31954754p32090823.html
>>> Sent from the Synapse - User mailing list archive at Nabble.com.
>>>
>>>
>>
>>
>> --
>> *Afkham Azeez*
>> Director of Architecture; WSO2, Inc.; http://wso2.com,
>> *Member; Apache Software Foundation;
>> **http://www.apache.org/*<http://www.apache.org/>
>> *
>> *
>> *email: **azeez@wso2.com* <az...@wso2.com>* cell: +94 77 3320919
>> blog: **http://blog.afkham.org* <http://blog.afkham.org>*
>> twitter:
>> **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez>
>> *
>> linked-in: **http://lk.linkedin.com/in/afkhamazeez*
>> *
>> *
>> *Lean . Enterprise . Middleware*
>> *
>> *
>>
>>
> http://old.nabble.com/file/p32094166/synapse.log synapse.log
> http://old.nabble.com/file/p32094166/service.log service.log
> http://old.nabble.com/file/p32094166/wrapper.log wrapper.log
>
--
View this message in context: http://old.nabble.com/Sample--57-Dynamic-load-balancing-tp31954754p32240627.html
Sent from the Synapse - User mailing list archive at Nabble.com.
Re: Sample #57 Dynamic load balancing
Posted by TrevorC <ma...@gmail.com>.
Here are logs
Afkham Azeez wrote:
>
> Please enable info level logs for org.apache.axis2.clustering in both the
> servers, and send the logs over.
>
>
> On Tue, Jul 19, 2011 at 6:21 PM, TrevorC <ma...@gmail.com> wrote:
>
>>
>> Hi Afkham
>>
>> i did the modification now the problem Im getting an error message that
>> say
>> "The input stream for an incoming message is null "
>>
>> Any Suggestion
>>
>>
>>
>> TrevorC wrote:
>> >
>> > Hi Afkham
>> >
>> > I cant see any attached files or is there way 2 retrieve them
>> >
>> > Afkham Azeez wrote:
>> >>
>> >> The clustering configurations in both files are identical. That won't
>> >> work
>> >> in a dynamic LB scenario.
>> >>
>> >> Please try replacing the clustering sections in the respective
>> axis2.xml
>> >> files with the attached ones.
>> >>
>> >> If you want to understand how to configure clustering, please see;
>> >>
>> >> 1.
>> http://wso2.org/library/articles/introduction-wso2-carbon-clustering
>> >> 2.
>> >>
>> http://wso2.org/library/articles/wso2-carbon-cluster-configuration-language
>> >>
>> >>
>> >> On Wed, Jul 13, 2011 at 1:30 AM, TrevorC <ma...@gmail.com>
>> wrote:
>> >>
>> >>>
>> >>> Here are my xml files synapse,axis server respectively
>> >>> contribution are highly appreciated
>> >>>
>> >>> Afkham Azeez wrote:
>> >>> >
>> >>> > No application members available suggests that the Axis2 nodes were
>> >>> not
>> >>> > able
>> >>> > to join the load balancers (LB) cluster. This indicates that
>> either;
>> >>> >
>> >>> > 1. GroupManagement has not been enabled in the LB's axis2.xml
>> >>> > 2. A group management agent has not been defined in the axis2.xml
>> file
>> >>> > corresponding to the domain defined in the Axis2 nodes' axis2.xml
>> >>> > 3. If you have enabled multicast based membership discovery,
>> >>> multicasting
>> >>> > is
>> >>> > not working on your network, hence the membership discovery fails
>> >>> > 4. In the LB you have enabled wka based membership discovery, and
>> in
>> >>> the
>> >>> > Axis2 nodes, you have enabled WKA based discovery.
>> >>> > 5. Members advertising invalid hosts/ports because of invalid
>> >>> clustering
>> >>> > config.
>> >>> >
>> >>> >
>> >>> > Send me your axis2.xml files and synapse.xml file, and I will see
>> what
>> >>> is
>> >>> > wrong.
>> >>> >
>> >>> >
>> >>> http://old.nabble.com/file/p32048735/axis2.xml axis2.xml
>> >>> http://old.nabble.com/file/p32048735/axis2.xml axis2.xml
>> >>> --
>> >>> View this message in context:
>> >>>
>> http://old.nabble.com/Sample--57-Dynamic-load-balancing-tp31954754p32048735.html
>> >>> Sent from the Synapse - User mailing list archive at Nabble.com.
>> >>>
>> >>>
>> >>
>> >>
>> >> --
>> >> *Afkham Azeez*
>> >> Director of Architecture; WSO2, Inc.; http://wso2.com,
>> >> *Member; Apache Software Foundation;
>> >> **http://www.apache.org/*<http://www.apache.org/>
>> >> *
>> >> *
>> >> *email: **azeez@wso2.com* <az...@wso2.com>* cell: +94 77 3320919
>> >> blog: **http://blog.afkham.org* <http://blog.afkham.org>*
>> >> twitter:
>> >> **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez>
>> >> *
>> >> linked-in: **http://lk.linkedin.com/in/afkhamazeez*
>> >> *
>> >> *
>> >> *Lean . Enterprise . Middleware*
>> >> *
>> >> *
>> >>
>> >> <clustering
>> >> class="org.apache.axis2.clustering.tribes.TribesClusteringAgent"
>> >> enable="true">
>> >>
>> >> <!--
>> >> This parameter indicates whether the cluster has to be
>> >> automatically initalized
>> >> when the AxisConfiguration is built. If set to "true" the
>> >> initialization will not be
>> >> done at that stage, and some other party will have to
>> >> explictly initialize the cluster.
>> >> -->
>> >> <parameter name="AvoidInitiation">true</parameter>
>> >>
>> >> <!--
>> >> The membership scheme used in this setup. The only values
>> >> supported at the moment are
>> >> "multicast" and "wka"
>> >>
>> >> 1. multicast - membership is automatically discovered using
>> >> multicasting
>> >> 2. wka - Well-Known Address based multicasting. Membership
>> is
>> >> discovered with the help
>> >> of one or more nodes running at a Well-Known
>> Address.
>> >> New members joining a
>> >> cluster will first connect to a well-known node,
>> >> register with the well-known node
>> >> and get the membership list from it. When new
>> members
>> >> join, one of the well-known
>> >> nodes will notify the others in the group. When a
>> >> member leaves the cluster or
>> >> is deemed to have left the cluster, it will be
>> >> detected by the Group Membership
>> >> Service (GMS) using a TCP ping mechanism.
>> >> -->
>> >> <parameter name="membershipScheme">multicast</parameter>
>> >>
>> >> <!--
>> >> The clustering domain/group. Nodes in the same group will
>> belong
>> >> to the same multicast
>> >> domain. There will not be interference between nodes in
>> >> different groups.
>> >> -->
>> >> <parameter
>> >> name="domain">apache.axis2.application.domain</parameter>
>> >>
>> >> <!--
>> >> When a Web service request is received, and processed,
>> before
>> >> the response is sent to the
>> >> client, should we update the states of all members in the
>> >> cluster? If the value of
>> >> this parameter is set to "true", the response to the client
>> >> will be sent only after
>> >> all the members have been updated. Obviously, this can be
>> time
>> >> consuming. In some cases,
>> >> such this overhead may not be acceptable, in which case the
>> >> value of this parameter
>> >> should be set to "false"
>> >> -->
>> >> <parameter name="synchronizeAll">false</parameter>
>> >>
>> >> <!--
>> >> The maximum number of times we need to retry to send a
>> message
>> >> to a particular node
>> >> before giving up and considering that node to be faulty
>> >> -->
>> >> <parameter name="maxRetries">10</parameter>
>> >>
>> >> <!-- The multicast address to be used -->
>> >> <parameter name="mcastAddress">228.0.0.4</parameter>
>> >>
>> >> <!-- The multicast port to be used -->
>> >> <parameter name="mcastPort">45564</parameter>
>> >>
>> >> <!-- The frequency of sending membership multicast messages
>> (in
>> >> ms) -->
>> >> <parameter name="mcastFrequency">500</parameter>
>> >>
>> >> <!-- The time interval within which if a member does not
>> respond,
>> >> the member will be
>> >> deemed to have left the group (in ms)
>> >> -->
>> >> <parameter name="memberDropTime">3000</parameter>
>> >>
>> >> <!--
>> >> The IP address of the network interface to which the
>> >> multicasting has to be bound to.
>> >> Multicasting would be done using this interface.
>> >> -->
>> >> <parameter name="mcastBindAddress">127.0.0.1</parameter>
>> >>
>> >> <!-- The host name or IP address of this member -->
>> >>
>> >> <parameter name="localMemberHost">127.0.0.1</parameter>
>> >>
>> >>
>> >> <!--
>> >> The TCP port used by this member. This is the port through
>> which
>> >> other nodes will
>> >> contact this member
>> >> -->
>> >> <parameter name="localMemberPort">4010</parameter>
>> >>
>> >> <!--
>> >> Preserve message ordering. This will be done according to
>> sender
>> >> order.
>> >> -->
>> >> <parameter name="preserveMessageOrder">true</parameter>
>> >>
>> >> <!--
>> >> Maintain atmost-once message processing semantics
>> >> -->
>> >> <parameter name="atmostOnceMessageSemantics">true</parameter>
>> >>
>> >> <!--
>> >> This interface is responsible for handling state
>> replication.
>> >> The property changes in
>> >> the Axis2 context hierarchy in this node, are propagated to
>> >> all other nodes in the cluster.
>> >>
>> >> The "excludes" patterns can be used to specify the prefixes
>> >> (e.g. local_*) or
>> >> suffixes (e.g. *_local) of the properties to be excluded
>> from
>> >> replication. The pattern
>> >> "*" indicates that all properties in a particular context
>> >> should not be replicated.
>> >>
>> >> The "enable" attribute indicates whether context
>> replication
>> >> has been enabled
>> >> -->
>> >> <stateManager
>> >> class="org.apache.axis2.clustering.state.DefaultStateManager"
>> >> enable="false">
>> >> <replication>
>> >> <defaults>
>> >> <exclude name="local_*"/>
>> >> <exclude name="LOCAL_*"/>
>> >> </defaults>
>> >> <context
>> >> class="org.apache.axis2.context.ConfigurationContext">
>> >> <exclude name="local_*"/>
>> >> <exclude name="UseAsyncOperations"/>
>> >> <exclude name="SequencePropertyBeanMap"/>
>> >> </context>
>> >> <context
>> >> class="org.apache.axis2.context.ServiceGroupContext">
>> >> <exclude name="local_*"/>
>> >> <exclude name="my.sandesha.*"/>
>> >> </context>
>> >> <context
>> class="org.apache.axis2.context.ServiceContext">
>> >> <exclude name="local_*"/>
>> >> <exclude name="my.sandesha.*"/>
>> >> </context>
>> >> </replication>
>> >> </stateManager>
>> >> </clustering>
>> >>
>> >> <clustering
>> >> class="org.apache.axis2.clustering.tribes.TribesClusteringAgent"
>> >> enable="true">
>> >>
>> >> <!--
>> >> This parameter indicates whether the cluster has to be
>> >> automatically initalized
>> >> when the AxisConfiguration is built. If set to "true" the
>> >> initialization will not be
>> >> done at that stage, and some other party will have to
>> >> explictly initialize the cluster.
>> >> -->
>> >> <parameter name="AvoidInitiation">true</parameter>
>> >>
>> >> <!--
>> >> The membership scheme used in this setup. The only values
>> >> supported at the moment are
>> >> "multicast" and "wka"
>> >>
>> >> 1. multicast - membership is automatically discovered using
>> >> multicasting
>> >> 2. wka - Well-Known Address based multicasting. Membership
>> is
>> >> discovered with the help
>> >> of one or more nodes running at a Well-Known
>> Address.
>> >> New members joining a
>> >> cluster will first connect to a well-known node,
>> >> register with the well-known node
>> >> and get the membership list from it. When new
>> members
>> >> join, one of the well-known
>> >> nodes will notify the others in the group. When a
>> >> member leaves the cluster or
>> >> is deemed to have left the cluster, it will be
>> >> detected by the Group Membership
>> >> Service (GMS) using a TCP ping mechanism.
>> >> -->
>> >> <parameter name="membershipScheme">multicast</parameter>
>> >>
>> >> <!--
>> >> The clustering domain/group. Nodes in the same group will
>> belong
>> >> to the same multicast
>> >> domain. There will not be interference between nodes in
>> >> different groups.
>> >> -->
>> >> <parameter name="domain">wso2.carbon.lb.domain</parameter>
>> >>
>> >> <!--
>> >> When a Web service request is received, and processed,
>> before
>> >> the response is sent to the
>> >> client, should we update the states of all members in the
>> >> cluster? If the value of
>> >> this parameter is set to "true", the response to the client
>> >> will be sent only after
>> >> all the members have been updated. Obviously, this can be
>> time
>> >> consuming. In some cases,
>> >> such this overhead may not be acceptable, in which case the
>> >> value of this parameter
>> >> should be set to "false"
>> >> -->
>> >> <parameter name="synchronizeAll">false</parameter>
>> >>
>> >> <!--
>> >> The maximum number of times we need to retry to send a
>> message
>> >> to a particular node
>> >> before giving up and considering that node to be faulty
>> >> -->
>> >> <parameter name="maxRetries">10</parameter>
>> >>
>> >> <!-- The multicast address to be used -->
>> >> <parameter name="mcastAddress">228.0.0.4</parameter>
>> >>
>> >> <!-- The multicast port to be used -->
>> >> <parameter name="mcastPort">45564</parameter>
>> >>
>> >> <!-- The frequency of sending membership multicast messages
>> (in
>> >> ms) -->
>> >> <parameter name="mcastFrequency">500</parameter>
>> >>
>> >> <!-- The time interval within which if a member does not
>> respond,
>> >> the member will be
>> >> deemed to have left the group (in ms)
>> >> -->
>> >> <parameter name="memberDropTime">3000</parameter>
>> >>
>> >> <!--
>> >> The IP address of the network interface to which the
>> >> multicasting has to be bound to.
>> >> Multicasting would be done using this interface.
>> >> -->
>> >> <parameter name="mcastBindAddress">127.0.0.1</parameter>
>> >>
>> >> <!-- The host name or IP address of this member -->
>> >>
>> >> <parameter name="localMemberHost">127.0.0.1</parameter>
>> >>
>> >>
>> >> <!--
>> >> The TCP port used by this member. This is the port through
>> which
>> >> other nodes will
>> >> contact this member
>> >> -->
>> >> <parameter name="localMemberPort">4000</parameter>
>> >>
>> >> <!--
>> >> Preserve message ordering. This will be done according to
>> sender
>> >> order.
>> >> -->
>> >> <parameter name="preserveMessageOrder">true</parameter>
>> >>
>> >> <!--
>> >> Maintain atmost-once message processing semantics
>> >> -->
>> >> <parameter name="atmostOnceMessageSemantics">true</parameter>
>> >>
>> >> <!--
>> >> Enable the groupManagement entry if you need to run this node
>> as
>> >> a cluster manager.
>> >> Multiple application domains with different
>> GroupManagementAgent
>> >> implementations
>> >> can be defined in this section.
>> >> -->
>> >> <groupManagement enable="true">
>> >> <applicationDomain name="apache.axis2.application.domain"
>> >> description="Axis2 group"
>> >>
>> >>
>> agent="org.apache.axis2.clustering.management.DefaultGroupManagementAgent"/>
>> >> </groupManagement>
>> >>
>> >> <!--
>> >> This interface is responsible for handling state
>> replication.
>> >> The property changes in
>> >> the Axis2 context hierarchy in this node, are propagated to
>> >> all other nodes in the cluster.
>> >>
>> >> The "excludes" patterns can be used to specify the prefixes
>> >> (e.g. local_*) or
>> >> suffixes (e.g. *_local) of the properties to be excluded
>> from
>> >> replication. The pattern
>> >> "*" indicates that all properties in a particular context
>> >> should not be replicated.
>> >>
>> >> The "enable" attribute indicates whether context
>> replication
>> >> has been enabled
>> >> -->
>> >> <stateManager
>> >> class="org.apache.axis2.clustering.state.DefaultStateManager"
>> >> enable="false">
>> >> <replication>
>> >> <defaults>
>> >> <exclude name="local_*"/>
>> >> <exclude name="LOCAL_*"/>
>> >> </defaults>
>> >> <context
>> >> class="org.apache.axis2.context.ConfigurationContext">
>> >> <exclude name="local_*"/>
>> >> <exclude name="UseAsyncOperations"/>
>> >> <exclude name="SequencePropertyBeanMap"/>
>> >> </context>
>> >> <context
>> >> class="org.apache.axis2.context.ServiceGroupContext">
>> >> <exclude name="local_*"/>
>> >> <exclude name="my.sandesha.*"/>
>> >> </context>
>> >> <context
>> class="org.apache.axis2.context.ServiceContext">
>> >> <exclude name="local_*"/>
>> >> <exclude name="my.sandesha.*"/>
>> >> </context>
>> >> </replication>
>> >> </stateManager>
>> >> </clustering>
>> >>
>> >>
>> >
>> >
>>
>> --
>> View this message in context:
>> http://old.nabble.com/Sample--57-Dynamic-load-balancing-tp31954754p32090823.html
>> Sent from the Synapse - User mailing list archive at Nabble.com.
>>
>>
>
>
> --
> *Afkham Azeez*
> Director of Architecture; WSO2, Inc.; http://wso2.com,
> *Member; Apache Software Foundation;
> **http://www.apache.org/*<http://www.apache.org/>
> *
> *
> *email: **azeez@wso2.com* <az...@wso2.com>* cell: +94 77 3320919
> blog: **http://blog.afkham.org* <http://blog.afkham.org>*
> twitter:
> **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez>
> *
> linked-in: **http://lk.linkedin.com/in/afkhamazeez*
> *
> *
> *Lean . Enterprise . Middleware*
> *
> *
>
>
http://old.nabble.com/file/p32094166/synapse.log synapse.log
http://old.nabble.com/file/p32094166/service.log service.log
http://old.nabble.com/file/p32094166/wrapper.log wrapper.log
--
View this message in context: http://old.nabble.com/Sample--57-Dynamic-load-balancing-tp31954754p32094166.html
Sent from the Synapse - User mailing list archive at Nabble.com.
Re: Sample #57 Dynamic load balancing
Posted by Afkham Azeez <af...@gmail.com>.
Please enable info level logs for org.apache.axis2.clustering in both the
servers, and send the logs over.
On Tue, Jul 19, 2011 at 6:21 PM, TrevorC <ma...@gmail.com> wrote:
>
> Hi Afkham
>
> i did the modification now the problem Im getting an error message that say
> "The input stream for an incoming message is null "
>
> Any Suggestion
>
>
>
> TrevorC wrote:
> >
> > Hi Afkham
> >
> > I cant see any attached files or is there way 2 retrieve them
> >
> > Afkham Azeez wrote:
> >>
> >> The clustering configurations in both files are identical. That won't
> >> work
> >> in a dynamic LB scenario.
> >>
> >> Please try replacing the clustering sections in the respective axis2.xml
> >> files with the attached ones.
> >>
> >> If you want to understand how to configure clustering, please see;
> >>
> >> 1. http://wso2.org/library/articles/introduction-wso2-carbon-clustering
> >> 2.
> >>
> http://wso2.org/library/articles/wso2-carbon-cluster-configuration-language
> >>
> >>
> >> On Wed, Jul 13, 2011 at 1:30 AM, TrevorC <ma...@gmail.com> wrote:
> >>
> >>>
> >>> Here are my xml files synapse,axis server respectively
> >>> contribution are highly appreciated
> >>>
> >>> Afkham Azeez wrote:
> >>> >
> >>> > No application members available suggests that the Axis2 nodes were
> >>> not
> >>> > able
> >>> > to join the load balancers (LB) cluster. This indicates that either;
> >>> >
> >>> > 1. GroupManagement has not been enabled in the LB's axis2.xml
> >>> > 2. A group management agent has not been defined in the axis2.xml
> file
> >>> > corresponding to the domain defined in the Axis2 nodes' axis2.xml
> >>> > 3. If you have enabled multicast based membership discovery,
> >>> multicasting
> >>> > is
> >>> > not working on your network, hence the membership discovery fails
> >>> > 4. In the LB you have enabled wka based membership discovery, and in
> >>> the
> >>> > Axis2 nodes, you have enabled WKA based discovery.
> >>> > 5. Members advertising invalid hosts/ports because of invalid
> >>> clustering
> >>> > config.
> >>> >
> >>> >
> >>> > Send me your axis2.xml files and synapse.xml file, and I will see
> what
> >>> is
> >>> > wrong.
> >>> >
> >>> >
> >>> http://old.nabble.com/file/p32048735/axis2.xml axis2.xml
> >>> http://old.nabble.com/file/p32048735/axis2.xml axis2.xml
> >>> --
> >>> View this message in context:
> >>>
> http://old.nabble.com/Sample--57-Dynamic-load-balancing-tp31954754p32048735.html
> >>> Sent from the Synapse - User mailing list archive at Nabble.com.
> >>>
> >>>
> >>
> >>
> >> --
> >> *Afkham Azeez*
> >> Director of Architecture; WSO2, Inc.; http://wso2.com,
> >> *Member; Apache Software Foundation;
> >> **http://www.apache.org/*<http://www.apache.org/>
> >> *
> >> *
> >> *email: **azeez@wso2.com* <az...@wso2.com>* cell: +94 77 3320919
> >> blog: **http://blog.afkham.org* <http://blog.afkham.org>*
> >> twitter:
> >> **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez>
> >> *
> >> linked-in: **http://lk.linkedin.com/in/afkhamazeez*
> >> *
> >> *
> >> *Lean . Enterprise . Middleware*
> >> *
> >> *
> >>
> >> <clustering
> >> class="org.apache.axis2.clustering.tribes.TribesClusteringAgent"
> >> enable="true">
> >>
> >> <!--
> >> This parameter indicates whether the cluster has to be
> >> automatically initalized
> >> when the AxisConfiguration is built. If set to "true" the
> >> initialization will not be
> >> done at that stage, and some other party will have to
> >> explictly initialize the cluster.
> >> -->
> >> <parameter name="AvoidInitiation">true</parameter>
> >>
> >> <!--
> >> The membership scheme used in this setup. The only values
> >> supported at the moment are
> >> "multicast" and "wka"
> >>
> >> 1. multicast - membership is automatically discovered using
> >> multicasting
> >> 2. wka - Well-Known Address based multicasting. Membership is
> >> discovered with the help
> >> of one or more nodes running at a Well-Known
> Address.
> >> New members joining a
> >> cluster will first connect to a well-known node,
> >> register with the well-known node
> >> and get the membership list from it. When new
> members
> >> join, one of the well-known
> >> nodes will notify the others in the group. When a
> >> member leaves the cluster or
> >> is deemed to have left the cluster, it will be
> >> detected by the Group Membership
> >> Service (GMS) using a TCP ping mechanism.
> >> -->
> >> <parameter name="membershipScheme">multicast</parameter>
> >>
> >> <!--
> >> The clustering domain/group. Nodes in the same group will
> belong
> >> to the same multicast
> >> domain. There will not be interference between nodes in
> >> different groups.
> >> -->
> >> <parameter
> >> name="domain">apache.axis2.application.domain</parameter>
> >>
> >> <!--
> >> When a Web service request is received, and processed, before
> >> the response is sent to the
> >> client, should we update the states of all members in the
> >> cluster? If the value of
> >> this parameter is set to "true", the response to the client
> >> will be sent only after
> >> all the members have been updated. Obviously, this can be
> time
> >> consuming. In some cases,
> >> such this overhead may not be acceptable, in which case the
> >> value of this parameter
> >> should be set to "false"
> >> -->
> >> <parameter name="synchronizeAll">false</parameter>
> >>
> >> <!--
> >> The maximum number of times we need to retry to send a message
> >> to a particular node
> >> before giving up and considering that node to be faulty
> >> -->
> >> <parameter name="maxRetries">10</parameter>
> >>
> >> <!-- The multicast address to be used -->
> >> <parameter name="mcastAddress">228.0.0.4</parameter>
> >>
> >> <!-- The multicast port to be used -->
> >> <parameter name="mcastPort">45564</parameter>
> >>
> >> <!-- The frequency of sending membership multicast messages (in
> >> ms) -->
> >> <parameter name="mcastFrequency">500</parameter>
> >>
> >> <!-- The time interval within which if a member does not
> respond,
> >> the member will be
> >> deemed to have left the group (in ms)
> >> -->
> >> <parameter name="memberDropTime">3000</parameter>
> >>
> >> <!--
> >> The IP address of the network interface to which the
> >> multicasting has to be bound to.
> >> Multicasting would be done using this interface.
> >> -->
> >> <parameter name="mcastBindAddress">127.0.0.1</parameter>
> >>
> >> <!-- The host name or IP address of this member -->
> >>
> >> <parameter name="localMemberHost">127.0.0.1</parameter>
> >>
> >>
> >> <!--
> >> The TCP port used by this member. This is the port through which
> >> other nodes will
> >> contact this member
> >> -->
> >> <parameter name="localMemberPort">4010</parameter>
> >>
> >> <!--
> >> Preserve message ordering. This will be done according to sender
> >> order.
> >> -->
> >> <parameter name="preserveMessageOrder">true</parameter>
> >>
> >> <!--
> >> Maintain atmost-once message processing semantics
> >> -->
> >> <parameter name="atmostOnceMessageSemantics">true</parameter>
> >>
> >> <!--
> >> This interface is responsible for handling state replication.
> >> The property changes in
> >> the Axis2 context hierarchy in this node, are propagated to
> >> all other nodes in the cluster.
> >>
> >> The "excludes" patterns can be used to specify the prefixes
> >> (e.g. local_*) or
> >> suffixes (e.g. *_local) of the properties to be excluded from
> >> replication. The pattern
> >> "*" indicates that all properties in a particular context
> >> should not be replicated.
> >>
> >> The "enable" attribute indicates whether context replication
> >> has been enabled
> >> -->
> >> <stateManager
> >> class="org.apache.axis2.clustering.state.DefaultStateManager"
> >> enable="false">
> >> <replication>
> >> <defaults>
> >> <exclude name="local_*"/>
> >> <exclude name="LOCAL_*"/>
> >> </defaults>
> >> <context
> >> class="org.apache.axis2.context.ConfigurationContext">
> >> <exclude name="local_*"/>
> >> <exclude name="UseAsyncOperations"/>
> >> <exclude name="SequencePropertyBeanMap"/>
> >> </context>
> >> <context
> >> class="org.apache.axis2.context.ServiceGroupContext">
> >> <exclude name="local_*"/>
> >> <exclude name="my.sandesha.*"/>
> >> </context>
> >> <context
> class="org.apache.axis2.context.ServiceContext">
> >> <exclude name="local_*"/>
> >> <exclude name="my.sandesha.*"/>
> >> </context>
> >> </replication>
> >> </stateManager>
> >> </clustering>
> >>
> >> <clustering
> >> class="org.apache.axis2.clustering.tribes.TribesClusteringAgent"
> >> enable="true">
> >>
> >> <!--
> >> This parameter indicates whether the cluster has to be
> >> automatically initalized
> >> when the AxisConfiguration is built. If set to "true" the
> >> initialization will not be
> >> done at that stage, and some other party will have to
> >> explictly initialize the cluster.
> >> -->
> >> <parameter name="AvoidInitiation">true</parameter>
> >>
> >> <!--
> >> The membership scheme used in this setup. The only values
> >> supported at the moment are
> >> "multicast" and "wka"
> >>
> >> 1. multicast - membership is automatically discovered using
> >> multicasting
> >> 2. wka - Well-Known Address based multicasting. Membership is
> >> discovered with the help
> >> of one or more nodes running at a Well-Known
> Address.
> >> New members joining a
> >> cluster will first connect to a well-known node,
> >> register with the well-known node
> >> and get the membership list from it. When new
> members
> >> join, one of the well-known
> >> nodes will notify the others in the group. When a
> >> member leaves the cluster or
> >> is deemed to have left the cluster, it will be
> >> detected by the Group Membership
> >> Service (GMS) using a TCP ping mechanism.
> >> -->
> >> <parameter name="membershipScheme">multicast</parameter>
> >>
> >> <!--
> >> The clustering domain/group. Nodes in the same group will
> belong
> >> to the same multicast
> >> domain. There will not be interference between nodes in
> >> different groups.
> >> -->
> >> <parameter name="domain">wso2.carbon.lb.domain</parameter>
> >>
> >> <!--
> >> When a Web service request is received, and processed, before
> >> the response is sent to the
> >> client, should we update the states of all members in the
> >> cluster? If the value of
> >> this parameter is set to "true", the response to the client
> >> will be sent only after
> >> all the members have been updated. Obviously, this can be
> time
> >> consuming. In some cases,
> >> such this overhead may not be acceptable, in which case the
> >> value of this parameter
> >> should be set to "false"
> >> -->
> >> <parameter name="synchronizeAll">false</parameter>
> >>
> >> <!--
> >> The maximum number of times we need to retry to send a message
> >> to a particular node
> >> before giving up and considering that node to be faulty
> >> -->
> >> <parameter name="maxRetries">10</parameter>
> >>
> >> <!-- The multicast address to be used -->
> >> <parameter name="mcastAddress">228.0.0.4</parameter>
> >>
> >> <!-- The multicast port to be used -->
> >> <parameter name="mcastPort">45564</parameter>
> >>
> >> <!-- The frequency of sending membership multicast messages (in
> >> ms) -->
> >> <parameter name="mcastFrequency">500</parameter>
> >>
> >> <!-- The time interval within which if a member does not
> respond,
> >> the member will be
> >> deemed to have left the group (in ms)
> >> -->
> >> <parameter name="memberDropTime">3000</parameter>
> >>
> >> <!--
> >> The IP address of the network interface to which the
> >> multicasting has to be bound to.
> >> Multicasting would be done using this interface.
> >> -->
> >> <parameter name="mcastBindAddress">127.0.0.1</parameter>
> >>
> >> <!-- The host name or IP address of this member -->
> >>
> >> <parameter name="localMemberHost">127.0.0.1</parameter>
> >>
> >>
> >> <!--
> >> The TCP port used by this member. This is the port through which
> >> other nodes will
> >> contact this member
> >> -->
> >> <parameter name="localMemberPort">4000</parameter>
> >>
> >> <!--
> >> Preserve message ordering. This will be done according to sender
> >> order.
> >> -->
> >> <parameter name="preserveMessageOrder">true</parameter>
> >>
> >> <!--
> >> Maintain atmost-once message processing semantics
> >> -->
> >> <parameter name="atmostOnceMessageSemantics">true</parameter>
> >>
> >> <!--
> >> Enable the groupManagement entry if you need to run this node as
> >> a cluster manager.
> >> Multiple application domains with different GroupManagementAgent
> >> implementations
> >> can be defined in this section.
> >> -->
> >> <groupManagement enable="true">
> >> <applicationDomain name="apache.axis2.application.domain"
> >> description="Axis2 group"
> >>
> >>
> agent="org.apache.axis2.clustering.management.DefaultGroupManagementAgent"/>
> >> </groupManagement>
> >>
> >> <!--
> >> This interface is responsible for handling state replication.
> >> The property changes in
> >> the Axis2 context hierarchy in this node, are propagated to
> >> all other nodes in the cluster.
> >>
> >> The "excludes" patterns can be used to specify the prefixes
> >> (e.g. local_*) or
> >> suffixes (e.g. *_local) of the properties to be excluded from
> >> replication. The pattern
> >> "*" indicates that all properties in a particular context
> >> should not be replicated.
> >>
> >> The "enable" attribute indicates whether context replication
> >> has been enabled
> >> -->
> >> <stateManager
> >> class="org.apache.axis2.clustering.state.DefaultStateManager"
> >> enable="false">
> >> <replication>
> >> <defaults>
> >> <exclude name="local_*"/>
> >> <exclude name="LOCAL_*"/>
> >> </defaults>
> >> <context
> >> class="org.apache.axis2.context.ConfigurationContext">
> >> <exclude name="local_*"/>
> >> <exclude name="UseAsyncOperations"/>
> >> <exclude name="SequencePropertyBeanMap"/>
> >> </context>
> >> <context
> >> class="org.apache.axis2.context.ServiceGroupContext">
> >> <exclude name="local_*"/>
> >> <exclude name="my.sandesha.*"/>
> >> </context>
> >> <context
> class="org.apache.axis2.context.ServiceContext">
> >> <exclude name="local_*"/>
> >> <exclude name="my.sandesha.*"/>
> >> </context>
> >> </replication>
> >> </stateManager>
> >> </clustering>
> >>
> >>
> >
> >
>
> --
> View this message in context:
> http://old.nabble.com/Sample--57-Dynamic-load-balancing-tp31954754p32090823.html
> Sent from the Synapse - User mailing list archive at Nabble.com.
>
>
--
*Afkham Azeez*
Director of Architecture; WSO2, Inc.; http://wso2.com,
*Member; Apache Software Foundation;
**http://www.apache.org/*<http://www.apache.org/>
*
*
*email: **azeez@wso2.com* <az...@wso2.com>* cell: +94 77 3320919
blog: **http://blog.afkham.org* <http://blog.afkham.org>*
twitter: **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez>
*
linked-in: **http://lk.linkedin.com/in/afkhamazeez*
*
*
*Lean . Enterprise . Middleware*
*
*
Re: Sample #57 Dynamic load balancing
Posted by TrevorC <ma...@gmail.com>.
Hi Afkham
i did the modification now the problem Im getting an error message that say
"The input stream for an incoming message is null "
Any Suggestion
TrevorC wrote:
>
> Hi Afkham
>
> I cant see any attached files or is there way 2 retrieve them
>
> Afkham Azeez wrote:
>>
>> The clustering configurations in both files are identical. That won't
>> work
>> in a dynamic LB scenario.
>>
>> Please try replacing the clustering sections in the respective axis2.xml
>> files with the attached ones.
>>
>> If you want to understand how to configure clustering, please see;
>>
>> 1. http://wso2.org/library/articles/introduction-wso2-carbon-clustering
>> 2.
>> http://wso2.org/library/articles/wso2-carbon-cluster-configuration-language
>>
>>
>> On Wed, Jul 13, 2011 at 1:30 AM, TrevorC <ma...@gmail.com> wrote:
>>
>>>
>>> Here are my xml files synapse,axis server respectively
>>> contribution are highly appreciated
>>>
>>> Afkham Azeez wrote:
>>> >
>>> > No application members available suggests that the Axis2 nodes were
>>> not
>>> > able
>>> > to join the load balancers (LB) cluster. This indicates that either;
>>> >
>>> > 1. GroupManagement has not been enabled in the LB's axis2.xml
>>> > 2. A group management agent has not been defined in the axis2.xml file
>>> > corresponding to the domain defined in the Axis2 nodes' axis2.xml
>>> > 3. If you have enabled multicast based membership discovery,
>>> multicasting
>>> > is
>>> > not working on your network, hence the membership discovery fails
>>> > 4. In the LB you have enabled wka based membership discovery, and in
>>> the
>>> > Axis2 nodes, you have enabled WKA based discovery.
>>> > 5. Members advertising invalid hosts/ports because of invalid
>>> clustering
>>> > config.
>>> >
>>> >
>>> > Send me your axis2.xml files and synapse.xml file, and I will see what
>>> is
>>> > wrong.
>>> >
>>> >
>>> http://old.nabble.com/file/p32048735/axis2.xml axis2.xml
>>> http://old.nabble.com/file/p32048735/axis2.xml axis2.xml
>>> --
>>> View this message in context:
>>> http://old.nabble.com/Sample--57-Dynamic-load-balancing-tp31954754p32048735.html
>>> Sent from the Synapse - User mailing list archive at Nabble.com.
>>>
>>>
>>
>>
>> --
>> *Afkham Azeez*
>> Director of Architecture; WSO2, Inc.; http://wso2.com,
>> *Member; Apache Software Foundation;
>> **http://www.apache.org/*<http://www.apache.org/>
>> *
>> *
>> *email: **azeez@wso2.com* <az...@wso2.com>* cell: +94 77 3320919
>> blog: **http://blog.afkham.org* <http://blog.afkham.org>*
>> twitter:
>> **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez>
>> *
>> linked-in: **http://lk.linkedin.com/in/afkhamazeez*
>> *
>> *
>> *Lean . Enterprise . Middleware*
>> *
>> *
>>
>> <clustering
>> class="org.apache.axis2.clustering.tribes.TribesClusteringAgent"
>> enable="true">
>>
>> <!--
>> This parameter indicates whether the cluster has to be
>> automatically initalized
>> when the AxisConfiguration is built. If set to "true" the
>> initialization will not be
>> done at that stage, and some other party will have to
>> explictly initialize the cluster.
>> -->
>> <parameter name="AvoidInitiation">true</parameter>
>>
>> <!--
>> The membership scheme used in this setup. The only values
>> supported at the moment are
>> "multicast" and "wka"
>>
>> 1. multicast - membership is automatically discovered using
>> multicasting
>> 2. wka - Well-Known Address based multicasting. Membership is
>> discovered with the help
>> of one or more nodes running at a Well-Known Address.
>> New members joining a
>> cluster will first connect to a well-known node,
>> register with the well-known node
>> and get the membership list from it. When new members
>> join, one of the well-known
>> nodes will notify the others in the group. When a
>> member leaves the cluster or
>> is deemed to have left the cluster, it will be
>> detected by the Group Membership
>> Service (GMS) using a TCP ping mechanism.
>> -->
>> <parameter name="membershipScheme">multicast</parameter>
>>
>> <!--
>> The clustering domain/group. Nodes in the same group will belong
>> to the same multicast
>> domain. There will not be interference between nodes in
>> different groups.
>> -->
>> <parameter
>> name="domain">apache.axis2.application.domain</parameter>
>>
>> <!--
>> When a Web service request is received, and processed, before
>> the response is sent to the
>> client, should we update the states of all members in the
>> cluster? If the value of
>> this parameter is set to "true", the response to the client
>> will be sent only after
>> all the members have been updated. Obviously, this can be time
>> consuming. In some cases,
>> such this overhead may not be acceptable, in which case the
>> value of this parameter
>> should be set to "false"
>> -->
>> <parameter name="synchronizeAll">false</parameter>
>>
>> <!--
>> The maximum number of times we need to retry to send a message
>> to a particular node
>> before giving up and considering that node to be faulty
>> -->
>> <parameter name="maxRetries">10</parameter>
>>
>> <!-- The multicast address to be used -->
>> <parameter name="mcastAddress">228.0.0.4</parameter>
>>
>> <!-- The multicast port to be used -->
>> <parameter name="mcastPort">45564</parameter>
>>
>> <!-- The frequency of sending membership multicast messages (in
>> ms) -->
>> <parameter name="mcastFrequency">500</parameter>
>>
>> <!-- The time interval within which if a member does not respond,
>> the member will be
>> deemed to have left the group (in ms)
>> -->
>> <parameter name="memberDropTime">3000</parameter>
>>
>> <!--
>> The IP address of the network interface to which the
>> multicasting has to be bound to.
>> Multicasting would be done using this interface.
>> -->
>> <parameter name="mcastBindAddress">127.0.0.1</parameter>
>>
>> <!-- The host name or IP address of this member -->
>>
>> <parameter name="localMemberHost">127.0.0.1</parameter>
>>
>>
>> <!--
>> The TCP port used by this member. This is the port through which
>> other nodes will
>> contact this member
>> -->
>> <parameter name="localMemberPort">4010</parameter>
>>
>> <!--
>> Preserve message ordering. This will be done according to sender
>> order.
>> -->
>> <parameter name="preserveMessageOrder">true</parameter>
>>
>> <!--
>> Maintain atmost-once message processing semantics
>> -->
>> <parameter name="atmostOnceMessageSemantics">true</parameter>
>>
>> <!--
>> This interface is responsible for handling state replication.
>> The property changes in
>> the Axis2 context hierarchy in this node, are propagated to
>> all other nodes in the cluster.
>>
>> The "excludes" patterns can be used to specify the prefixes
>> (e.g. local_*) or
>> suffixes (e.g. *_local) of the properties to be excluded from
>> replication. The pattern
>> "*" indicates that all properties in a particular context
>> should not be replicated.
>>
>> The "enable" attribute indicates whether context replication
>> has been enabled
>> -->
>> <stateManager
>> class="org.apache.axis2.clustering.state.DefaultStateManager"
>> enable="false">
>> <replication>
>> <defaults>
>> <exclude name="local_*"/>
>> <exclude name="LOCAL_*"/>
>> </defaults>
>> <context
>> class="org.apache.axis2.context.ConfigurationContext">
>> <exclude name="local_*"/>
>> <exclude name="UseAsyncOperations"/>
>> <exclude name="SequencePropertyBeanMap"/>
>> </context>
>> <context
>> class="org.apache.axis2.context.ServiceGroupContext">
>> <exclude name="local_*"/>
>> <exclude name="my.sandesha.*"/>
>> </context>
>> <context class="org.apache.axis2.context.ServiceContext">
>> <exclude name="local_*"/>
>> <exclude name="my.sandesha.*"/>
>> </context>
>> </replication>
>> </stateManager>
>> </clustering>
>>
>> <clustering
>> class="org.apache.axis2.clustering.tribes.TribesClusteringAgent"
>> enable="true">
>>
>> <!--
>> This parameter indicates whether the cluster has to be
>> automatically initalized
>> when the AxisConfiguration is built. If set to "true" the
>> initialization will not be
>> done at that stage, and some other party will have to
>> explictly initialize the cluster.
>> -->
>> <parameter name="AvoidInitiation">true</parameter>
>>
>> <!--
>> The membership scheme used in this setup. The only values
>> supported at the moment are
>> "multicast" and "wka"
>>
>> 1. multicast - membership is automatically discovered using
>> multicasting
>> 2. wka - Well-Known Address based multicasting. Membership is
>> discovered with the help
>> of one or more nodes running at a Well-Known Address.
>> New members joining a
>> cluster will first connect to a well-known node,
>> register with the well-known node
>> and get the membership list from it. When new members
>> join, one of the well-known
>> nodes will notify the others in the group. When a
>> member leaves the cluster or
>> is deemed to have left the cluster, it will be
>> detected by the Group Membership
>> Service (GMS) using a TCP ping mechanism.
>> -->
>> <parameter name="membershipScheme">multicast</parameter>
>>
>> <!--
>> The clustering domain/group. Nodes in the same group will belong
>> to the same multicast
>> domain. There will not be interference between nodes in
>> different groups.
>> -->
>> <parameter name="domain">wso2.carbon.lb.domain</parameter>
>>
>> <!--
>> When a Web service request is received, and processed, before
>> the response is sent to the
>> client, should we update the states of all members in the
>> cluster? If the value of
>> this parameter is set to "true", the response to the client
>> will be sent only after
>> all the members have been updated. Obviously, this can be time
>> consuming. In some cases,
>> such this overhead may not be acceptable, in which case the
>> value of this parameter
>> should be set to "false"
>> -->
>> <parameter name="synchronizeAll">false</parameter>
>>
>> <!--
>> The maximum number of times we need to retry to send a message
>> to a particular node
>> before giving up and considering that node to be faulty
>> -->
>> <parameter name="maxRetries">10</parameter>
>>
>> <!-- The multicast address to be used -->
>> <parameter name="mcastAddress">228.0.0.4</parameter>
>>
>> <!-- The multicast port to be used -->
>> <parameter name="mcastPort">45564</parameter>
>>
>> <!-- The frequency of sending membership multicast messages (in
>> ms) -->
>> <parameter name="mcastFrequency">500</parameter>
>>
>> <!-- The time interval within which if a member does not respond,
>> the member will be
>> deemed to have left the group (in ms)
>> -->
>> <parameter name="memberDropTime">3000</parameter>
>>
>> <!--
>> The IP address of the network interface to which the
>> multicasting has to be bound to.
>> Multicasting would be done using this interface.
>> -->
>> <parameter name="mcastBindAddress">127.0.0.1</parameter>
>>
>> <!-- The host name or IP address of this member -->
>>
>> <parameter name="localMemberHost">127.0.0.1</parameter>
>>
>>
>> <!--
>> The TCP port used by this member. This is the port through which
>> other nodes will
>> contact this member
>> -->
>> <parameter name="localMemberPort">4000</parameter>
>>
>> <!--
>> Preserve message ordering. This will be done according to sender
>> order.
>> -->
>> <parameter name="preserveMessageOrder">true</parameter>
>>
>> <!--
>> Maintain atmost-once message processing semantics
>> -->
>> <parameter name="atmostOnceMessageSemantics">true</parameter>
>>
>> <!--
>> Enable the groupManagement entry if you need to run this node as
>> a cluster manager.
>> Multiple application domains with different GroupManagementAgent
>> implementations
>> can be defined in this section.
>> -->
>> <groupManagement enable="true">
>> <applicationDomain name="apache.axis2.application.domain"
>> description="Axis2 group"
>>
>> agent="org.apache.axis2.clustering.management.DefaultGroupManagementAgent"/>
>> </groupManagement>
>>
>> <!--
>> This interface is responsible for handling state replication.
>> The property changes in
>> the Axis2 context hierarchy in this node, are propagated to
>> all other nodes in the cluster.
>>
>> The "excludes" patterns can be used to specify the prefixes
>> (e.g. local_*) or
>> suffixes (e.g. *_local) of the properties to be excluded from
>> replication. The pattern
>> "*" indicates that all properties in a particular context
>> should not be replicated.
>>
>> The "enable" attribute indicates whether context replication
>> has been enabled
>> -->
>> <stateManager
>> class="org.apache.axis2.clustering.state.DefaultStateManager"
>> enable="false">
>> <replication>
>> <defaults>
>> <exclude name="local_*"/>
>> <exclude name="LOCAL_*"/>
>> </defaults>
>> <context
>> class="org.apache.axis2.context.ConfigurationContext">
>> <exclude name="local_*"/>
>> <exclude name="UseAsyncOperations"/>
>> <exclude name="SequencePropertyBeanMap"/>
>> </context>
>> <context
>> class="org.apache.axis2.context.ServiceGroupContext">
>> <exclude name="local_*"/>
>> <exclude name="my.sandesha.*"/>
>> </context>
>> <context class="org.apache.axis2.context.ServiceContext">
>> <exclude name="local_*"/>
>> <exclude name="my.sandesha.*"/>
>> </context>
>> </replication>
>> </stateManager>
>> </clustering>
>>
>>
>
>
--
View this message in context: http://old.nabble.com/Sample--57-Dynamic-load-balancing-tp31954754p32090823.html
Sent from the Synapse - User mailing list archive at Nabble.com.
Re: Sample #57 Dynamic load balancing
Posted by TrevorC <ma...@gmail.com>.
Hi Afkham
I cant see any attached files or is there way 2 retrieve them
Afkham Azeez wrote:
>
> The clustering configurations in both files are identical. That won't work
> in a dynamic LB scenario.
>
> Please try replacing the clustering sections in the respective axis2.xml
> files with the attached ones.
>
> If you want to understand how to configure clustering, please see;
>
> 1. http://wso2.org/library/articles/introduction-wso2-carbon-clustering
> 2.
> http://wso2.org/library/articles/wso2-carbon-cluster-configuration-language
>
>
> On Wed, Jul 13, 2011 at 1:30 AM, TrevorC <ma...@gmail.com> wrote:
>
>>
>> Here are my xml files synapse,axis server respectively
>> contribution are highly appreciated
>>
>> Afkham Azeez wrote:
>> >
>> > No application members available suggests that the Axis2 nodes were not
>> > able
>> > to join the load balancers (LB) cluster. This indicates that either;
>> >
>> > 1. GroupManagement has not been enabled in the LB's axis2.xml
>> > 2. A group management agent has not been defined in the axis2.xml file
>> > corresponding to the domain defined in the Axis2 nodes' axis2.xml
>> > 3. If you have enabled multicast based membership discovery,
>> multicasting
>> > is
>> > not working on your network, hence the membership discovery fails
>> > 4. In the LB you have enabled wka based membership discovery, and in
>> the
>> > Axis2 nodes, you have enabled WKA based discovery.
>> > 5. Members advertising invalid hosts/ports because of invalid
>> clustering
>> > config.
>> >
>> >
>> > Send me your axis2.xml files and synapse.xml file, and I will see what
>> is
>> > wrong.
>> >
>> >
>> http://old.nabble.com/file/p32048735/axis2.xml axis2.xml
>> http://old.nabble.com/file/p32048735/axis2.xml axis2.xml
>> --
>> View this message in context:
>> http://old.nabble.com/Sample--57-Dynamic-load-balancing-tp31954754p32048735.html
>> Sent from the Synapse - User mailing list archive at Nabble.com.
>>
>>
>
>
> --
> *Afkham Azeez*
> Director of Architecture; WSO2, Inc.; http://wso2.com,
> *Member; Apache Software Foundation;
> **http://www.apache.org/*<http://www.apache.org/>
> *
> *
> *email: **azeez@wso2.com* <az...@wso2.com>* cell: +94 77 3320919
> blog: **http://blog.afkham.org* <http://blog.afkham.org>*
> twitter:
> **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez>
> *
> linked-in: **http://lk.linkedin.com/in/afkhamazeez*
> *
> *
> *Lean . Enterprise . Middleware*
> *
> *
>
> <clustering
> class="org.apache.axis2.clustering.tribes.TribesClusteringAgent"
> enable="true">
>
> <!--
> This parameter indicates whether the cluster has to be
> automatically initalized
> when the AxisConfiguration is built. If set to "true" the
> initialization will not be
> done at that stage, and some other party will have to explictly
> initialize the cluster.
> -->
> <parameter name="AvoidInitiation">true</parameter>
>
> <!--
> The membership scheme used in this setup. The only values
> supported at the moment are
> "multicast" and "wka"
>
> 1. multicast - membership is automatically discovered using
> multicasting
> 2. wka - Well-Known Address based multicasting. Membership is
> discovered with the help
> of one or more nodes running at a Well-Known Address.
> New members joining a
> cluster will first connect to a well-known node,
> register with the well-known node
> and get the membership list from it. When new members
> join, one of the well-known
> nodes will notify the others in the group. When a
> member leaves the cluster or
> is deemed to have left the cluster, it will be
> detected by the Group Membership
> Service (GMS) using a TCP ping mechanism.
> -->
> <parameter name="membershipScheme">multicast</parameter>
>
> <!--
> The clustering domain/group. Nodes in the same group will belong
> to the same multicast
> domain. There will not be interference between nodes in different
> groups.
> -->
> <parameter
> name="domain">apache.axis2.application.domain</parameter>
>
> <!--
> When a Web service request is received, and processed, before
> the response is sent to the
> client, should we update the states of all members in the
> cluster? If the value of
> this parameter is set to "true", the response to the client
> will be sent only after
> all the members have been updated. Obviously, this can be time
> consuming. In some cases,
> such this overhead may not be acceptable, in which case the
> value of this parameter
> should be set to "false"
> -->
> <parameter name="synchronizeAll">false</parameter>
>
> <!--
> The maximum number of times we need to retry to send a message
> to a particular node
> before giving up and considering that node to be faulty
> -->
> <parameter name="maxRetries">10</parameter>
>
> <!-- The multicast address to be used -->
> <parameter name="mcastAddress">228.0.0.4</parameter>
>
> <!-- The multicast port to be used -->
> <parameter name="mcastPort">45564</parameter>
>
> <!-- The frequency of sending membership multicast messages (in
> ms) -->
> <parameter name="mcastFrequency">500</parameter>
>
> <!-- The time interval within which if a member does not respond,
> the member will be
> deemed to have left the group (in ms)
> -->
> <parameter name="memberDropTime">3000</parameter>
>
> <!--
> The IP address of the network interface to which the
> multicasting has to be bound to.
> Multicasting would be done using this interface.
> -->
> <parameter name="mcastBindAddress">127.0.0.1</parameter>
>
> <!-- The host name or IP address of this member -->
>
> <parameter name="localMemberHost">127.0.0.1</parameter>
>
>
> <!--
> The TCP port used by this member. This is the port through which
> other nodes will
> contact this member
> -->
> <parameter name="localMemberPort">4010</parameter>
>
> <!--
> Preserve message ordering. This will be done according to sender
> order.
> -->
> <parameter name="preserveMessageOrder">true</parameter>
>
> <!--
> Maintain atmost-once message processing semantics
> -->
> <parameter name="atmostOnceMessageSemantics">true</parameter>
>
> <!--
> This interface is responsible for handling state replication.
> The property changes in
> the Axis2 context hierarchy in this node, are propagated to all
> other nodes in the cluster.
>
> The "excludes" patterns can be used to specify the prefixes
> (e.g. local_*) or
> suffixes (e.g. *_local) of the properties to be excluded from
> replication. The pattern
> "*" indicates that all properties in a particular context
> should not be replicated.
>
> The "enable" attribute indicates whether context replication
> has been enabled
> -->
> <stateManager
> class="org.apache.axis2.clustering.state.DefaultStateManager"
> enable="false">
> <replication>
> <defaults>
> <exclude name="local_*"/>
> <exclude name="LOCAL_*"/>
> </defaults>
> <context
> class="org.apache.axis2.context.ConfigurationContext">
> <exclude name="local_*"/>
> <exclude name="UseAsyncOperations"/>
> <exclude name="SequencePropertyBeanMap"/>
> </context>
> <context
> class="org.apache.axis2.context.ServiceGroupContext">
> <exclude name="local_*"/>
> <exclude name="my.sandesha.*"/>
> </context>
> <context class="org.apache.axis2.context.ServiceContext">
> <exclude name="local_*"/>
> <exclude name="my.sandesha.*"/>
> </context>
> </replication>
> </stateManager>
> </clustering>
>
> <clustering
> class="org.apache.axis2.clustering.tribes.TribesClusteringAgent"
> enable="true">
>
> <!--
> This parameter indicates whether the cluster has to be
> automatically initalized
> when the AxisConfiguration is built. If set to "true" the
> initialization will not be
> done at that stage, and some other party will have to explictly
> initialize the cluster.
> -->
> <parameter name="AvoidInitiation">true</parameter>
>
> <!--
> The membership scheme used in this setup. The only values
> supported at the moment are
> "multicast" and "wka"
>
> 1. multicast - membership is automatically discovered using
> multicasting
> 2. wka - Well-Known Address based multicasting. Membership is
> discovered with the help
> of one or more nodes running at a Well-Known Address.
> New members joining a
> cluster will first connect to a well-known node,
> register with the well-known node
> and get the membership list from it. When new members
> join, one of the well-known
> nodes will notify the others in the group. When a
> member leaves the cluster or
> is deemed to have left the cluster, it will be
> detected by the Group Membership
> Service (GMS) using a TCP ping mechanism.
> -->
> <parameter name="membershipScheme">multicast</parameter>
>
> <!--
> The clustering domain/group. Nodes in the same group will belong
> to the same multicast
> domain. There will not be interference between nodes in different
> groups.
> -->
> <parameter name="domain">wso2.carbon.lb.domain</parameter>
>
> <!--
> When a Web service request is received, and processed, before
> the response is sent to the
> client, should we update the states of all members in the
> cluster? If the value of
> this parameter is set to "true", the response to the client
> will be sent only after
> all the members have been updated. Obviously, this can be time
> consuming. In some cases,
> such this overhead may not be acceptable, in which case the
> value of this parameter
> should be set to "false"
> -->
> <parameter name="synchronizeAll">false</parameter>
>
> <!--
> The maximum number of times we need to retry to send a message
> to a particular node
> before giving up and considering that node to be faulty
> -->
> <parameter name="maxRetries">10</parameter>
>
> <!-- The multicast address to be used -->
> <parameter name="mcastAddress">228.0.0.4</parameter>
>
> <!-- The multicast port to be used -->
> <parameter name="mcastPort">45564</parameter>
>
> <!-- The frequency of sending membership multicast messages (in
> ms) -->
> <parameter name="mcastFrequency">500</parameter>
>
> <!-- The time interval within which if a member does not respond,
> the member will be
> deemed to have left the group (in ms)
> -->
> <parameter name="memberDropTime">3000</parameter>
>
> <!--
> The IP address of the network interface to which the
> multicasting has to be bound to.
> Multicasting would be done using this interface.
> -->
> <parameter name="mcastBindAddress">127.0.0.1</parameter>
>
> <!-- The host name or IP address of this member -->
>
> <parameter name="localMemberHost">127.0.0.1</parameter>
>
>
> <!--
> The TCP port used by this member. This is the port through which
> other nodes will
> contact this member
> -->
> <parameter name="localMemberPort">4000</parameter>
>
> <!--
> Preserve message ordering. This will be done according to sender
> order.
> -->
> <parameter name="preserveMessageOrder">true</parameter>
>
> <!--
> Maintain atmost-once message processing semantics
> -->
> <parameter name="atmostOnceMessageSemantics">true</parameter>
>
> <!--
> Enable the groupManagement entry if you need to run this node as a
> cluster manager.
> Multiple application domains with different GroupManagementAgent
> implementations
> can be defined in this section.
> -->
> <groupManagement enable="true">
> <applicationDomain name="apache.axis2.application.domain"
> description="Axis2 group"
>
> agent="org.apache.axis2.clustering.management.DefaultGroupManagementAgent"/>
> </groupManagement>
>
> <!--
> This interface is responsible for handling state replication.
> The property changes in
> the Axis2 context hierarchy in this node, are propagated to all
> other nodes in the cluster.
>
> The "excludes" patterns can be used to specify the prefixes
> (e.g. local_*) or
> suffixes (e.g. *_local) of the properties to be excluded from
> replication. The pattern
> "*" indicates that all properties in a particular context
> should not be replicated.
>
> The "enable" attribute indicates whether context replication
> has been enabled
> -->
> <stateManager
> class="org.apache.axis2.clustering.state.DefaultStateManager"
> enable="false">
> <replication>
> <defaults>
> <exclude name="local_*"/>
> <exclude name="LOCAL_*"/>
> </defaults>
> <context
> class="org.apache.axis2.context.ConfigurationContext">
> <exclude name="local_*"/>
> <exclude name="UseAsyncOperations"/>
> <exclude name="SequencePropertyBeanMap"/>
> </context>
> <context
> class="org.apache.axis2.context.ServiceGroupContext">
> <exclude name="local_*"/>
> <exclude name="my.sandesha.*"/>
> </context>
> <context class="org.apache.axis2.context.ServiceContext">
> <exclude name="local_*"/>
> <exclude name="my.sandesha.*"/>
> </context>
> </replication>
> </stateManager>
> </clustering>
>
>
--
View this message in context: http://old.nabble.com/Sample--57-Dynamic-load-balancing-tp31954754p32083032.html
Sent from the Synapse - User mailing list archive at Nabble.com.
Re: Sample #57 Dynamic load balancing
Posted by Afkham Azeez <af...@gmail.com>.
The clustering configurations in both files are identical. That won't work
in a dynamic LB scenario.
Please try replacing the clustering sections in the respective axis2.xml
files with the attached ones.
If you want to understand how to configure clustering, please see;
1. http://wso2.org/library/articles/introduction-wso2-carbon-clustering
2.
http://wso2.org/library/articles/wso2-carbon-cluster-configuration-language
On Wed, Jul 13, 2011 at 1:30 AM, TrevorC <ma...@gmail.com> wrote:
>
> Here are my xml files synapse,axis server respectively
> contribution are highly appreciated
>
> Afkham Azeez wrote:
> >
> > No application members available suggests that the Axis2 nodes were not
> > able
> > to join the load balancers (LB) cluster. This indicates that either;
> >
> > 1. GroupManagement has not been enabled in the LB's axis2.xml
> > 2. A group management agent has not been defined in the axis2.xml file
> > corresponding to the domain defined in the Axis2 nodes' axis2.xml
> > 3. If you have enabled multicast based membership discovery, multicasting
> > is
> > not working on your network, hence the membership discovery fails
> > 4. In the LB you have enabled wka based membership discovery, and in the
> > Axis2 nodes, you have enabled WKA based discovery.
> > 5. Members advertising invalid hosts/ports because of invalid clustering
> > config.
> >
> >
> > Send me your axis2.xml files and synapse.xml file, and I will see what is
> > wrong.
> >
> >
> http://old.nabble.com/file/p32048735/axis2.xml axis2.xml
> http://old.nabble.com/file/p32048735/axis2.xml axis2.xml
> --
> View this message in context:
> http://old.nabble.com/Sample--57-Dynamic-load-balancing-tp31954754p32048735.html
> Sent from the Synapse - User mailing list archive at Nabble.com.
>
>
--
*Afkham Azeez*
Director of Architecture; WSO2, Inc.; http://wso2.com,
*Member; Apache Software Foundation;
**http://www.apache.org/*<http://www.apache.org/>
*
*
*email: **azeez@wso2.com* <az...@wso2.com>* cell: +94 77 3320919
blog: **http://blog.afkham.org* <http://blog.afkham.org>*
twitter: **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez>
*
linked-in: **http://lk.linkedin.com/in/afkhamazeez*
*
*
*Lean . Enterprise . Middleware*
*
*
Re: Sample #57 Dynamic load balancing
Posted by TrevorC <ma...@gmail.com>.
Here are my xml files synapse,axis server respectively
contribution are highly appreciated
Afkham Azeez wrote:
>
> No application members available suggests that the Axis2 nodes were not
> able
> to join the load balancers (LB) cluster. This indicates that either;
>
> 1. GroupManagement has not been enabled in the LB's axis2.xml
> 2. A group management agent has not been defined in the axis2.xml file
> corresponding to the domain defined in the Axis2 nodes' axis2.xml
> 3. If you have enabled multicast based membership discovery, multicasting
> is
> not working on your network, hence the membership discovery fails
> 4. In the LB you have enabled wka based membership discovery, and in the
> Axis2 nodes, you have enabled WKA based discovery.
> 5. Members advertising invalid hosts/ports because of invalid clustering
> config.
>
>
> Send me your axis2.xml files and synapse.xml file, and I will see what is
> wrong.
>
>
http://old.nabble.com/file/p32048735/axis2.xml axis2.xml
http://old.nabble.com/file/p32048735/axis2.xml axis2.xml
--
View this message in context: http://old.nabble.com/Sample--57-Dynamic-load-balancing-tp31954754p32048735.html
Sent from the Synapse - User mailing list archive at Nabble.com.
Re: Sample #57 Dynamic load balancing
Posted by Afkham Azeez <af...@gmail.com>.
No application members available suggests that the Axis2 nodes were not able
to join the load balancers (LB) cluster. This indicates that either;
1. GroupManagement has not been enabled in the LB's axis2.xml
2. A group management agent has not been defined in the axis2.xml file
corresponding to the domain defined in the Axis2 nodes' axis2.xml
3. If you have enabled multicast based membership discovery, multicasting is
not working on your network, hence the membership discovery fails
4. In the LB you have enabled wka based membership discovery, and in the
Axis2 nodes, you have enabled WKA based discovery.
5. Members advertising invalid hosts/ports because of invalid clustering
config.
Send me your axis2.xml files and synapse.xml file, and I will see what is
wrong.
Re: Sample #57 Dynamic load balancing
Posted by TrevorC <ma...@gmail.com>.
what is your suggestion about the cluster configuration because you said
"might be incorrect" or just send me your both XML(synapse,axis server)...
Kind Regards
Trevor
Afkham Azeez wrote:
>
> We have deployed and tested this in the same machine, as well as in a
> distributed setup.
>
> On Tue, Jul 12, 2011 at 12:48 PM, TrevorC <ma...@gmail.com> wrote:
>
>>
>> I wanna Know if you deploy everything in one node/workstation or you
>> distribute them
>>
>> Afkham Azeez wrote:
>> >
>> > This happens if the clustering configuration is incorrect.
>> > On Jun 29, 2011 6:58 PM, "TrevorC" <ma...@gmail.com> wrote:
>> >>
>> >> Hey Guys
>> >>
>> >> I got a problem wit sample 57 I cant run it.I have done everything
>> >> instructed by sample documentation but when it come 2 client side I
>> get
>> >> error message "couldn't send the message to the server" and also
>> apache
>> >> synapse interface has an error message "DynamicloadbalancingEndpoint
>> no
>> >> application members available" .Any Suggestion
>> >>
>> >> Contribution will appreciated
>> >>
>> >> Kind Regards
>> >> Trevor
>> >> --
>> >> View this message in context:
>> >
>> http://old.nabble.com/Sample--57-Dynamic-load-balancing-tp31954754p31954754.html
>> >> Sent from the Synapse - User mailing list archive at Nabble.com.
>> >>
>> >
>> >
>>
>> --
>> View this message in context:
>> http://old.nabble.com/Sample--57-Dynamic-load-balancing-tp31954754p32043784.html
>> Sent from the Synapse - User mailing list archive at Nabble.com.
>>
>> *
> *
>
>
--
View this message in context: http://old.nabble.com/Sample--57-Dynamic-load-balancing-tp31954754p32044953.html
Sent from the Synapse - User mailing list archive at Nabble.com.
Re: Sample #57 Dynamic load balancing
Posted by Afkham Azeez <af...@gmail.com>.
We have deployed and tested this in the same machine, as well as in a
distributed setup.
On Tue, Jul 12, 2011 at 12:48 PM, TrevorC <ma...@gmail.com> wrote:
>
> I wanna Know if you deploy everything in one node/workstation or you
> distribute them
>
> Afkham Azeez wrote:
> >
> > This happens if the clustering configuration is incorrect.
> > On Jun 29, 2011 6:58 PM, "TrevorC" <ma...@gmail.com> wrote:
> >>
> >> Hey Guys
> >>
> >> I got a problem wit sample 57 I cant run it.I have done everything
> >> instructed by sample documentation but when it come 2 client side I get
> >> error message "couldn't send the message to the server" and also apache
> >> synapse interface has an error message "DynamicloadbalancingEndpoint no
> >> application members available" .Any Suggestion
> >>
> >> Contribution will appreciated
> >>
> >> Kind Regards
> >> Trevor
> >> --
> >> View this message in context:
> >
> http://old.nabble.com/Sample--57-Dynamic-load-balancing-tp31954754p31954754.html
> >> Sent from the Synapse - User mailing list archive at Nabble.com.
> >>
> >
> >
>
> --
> View this message in context:
> http://old.nabble.com/Sample--57-Dynamic-load-balancing-tp31954754p32043784.html
> Sent from the Synapse - User mailing list archive at Nabble.com.
>
> *
*
Re: Sample #57 Dynamic load balancing
Posted by TrevorC <ma...@gmail.com>.
I wanna Know if you deploy everything in one node/workstation or you
distribute them
Afkham Azeez wrote:
>
> This happens if the clustering configuration is incorrect.
> On Jun 29, 2011 6:58 PM, "TrevorC" <ma...@gmail.com> wrote:
>>
>> Hey Guys
>>
>> I got a problem wit sample 57 I cant run it.I have done everything
>> instructed by sample documentation but when it come 2 client side I get
>> error message "couldn't send the message to the server" and also apache
>> synapse interface has an error message "DynamicloadbalancingEndpoint no
>> application members available" .Any Suggestion
>>
>> Contribution will appreciated
>>
>> Kind Regards
>> Trevor
>> --
>> View this message in context:
> http://old.nabble.com/Sample--57-Dynamic-load-balancing-tp31954754p31954754.html
>> Sent from the Synapse - User mailing list archive at Nabble.com.
>>
>
>
--
View this message in context: http://old.nabble.com/Sample--57-Dynamic-load-balancing-tp31954754p32043784.html
Sent from the Synapse - User mailing list archive at Nabble.com.
Re: Sample #57 Dynamic load balancing
Posted by Afkham Azeez <af...@gmail.com>.
This happens if the clustering configuration is incorrect.
On Jun 29, 2011 6:58 PM, "TrevorC" <ma...@gmail.com> wrote:
>
> Hey Guys
>
> I got a problem wit sample 57 I cant run it.I have done everything
> instructed by sample documentation but when it come 2 client side I get
> error message "couldn't send the message to the server" and also apache
> synapse interface has an error message "DynamicloadbalancingEndpoint no
> application members available" .Any Suggestion
>
> Contribution will appreciated
>
> Kind Regards
> Trevor
> --
> View this message in context:
http://old.nabble.com/Sample--57-Dynamic-load-balancing-tp31954754p31954754.html
> Sent from the Synapse - User mailing list archive at Nabble.com.
>
Re: Sample #57 Dynamic load balancing
Posted by TrevorC <ma...@gmail.com>.
here is the axis2.xml for axis server
TrevorC wrote:
>
> Here is the axis2.xml for synapse
>
> Hiranya Jayathilaka-3 wrote:
>>
>> Sample worked fine for me. Can you please share the axis2.xml file of
>> Synapse and the sample Axis2 server so I can have a look?
>>
>> Thanks,
>> Hiranya
>>
>> On Thu, Jun 30, 2011 at 12:41 AM, TrevorC <ma...@gmail.com> wrote:
>>
>>>
>>> Im working with synapse 2.0
>>>
>>> Hiranya Jayathilaka-3 wrote:
>>> >
>>> > What's the Synapse version you are working with?
>>> >
>>> > Thanks,
>>> > Hiranya
>>> >
>>> > On Wed, Jun 29, 2011 at 6:58 PM, TrevorC <ma...@gmail.com>
>>> wrote:
>>> >
>>> >>
>>> >> Hey Guys
>>> >>
>>> >> I got a problem wit sample 57 I cant run it.I have done everything
>>> >> instructed by sample documentation but when it come 2 client side I
>>> get
>>> >> error message "couldn't send the message to the server" and also
>>> apache
>>> >> synapse interface has an error message "DynamicloadbalancingEndpoint
>>> no
>>> >> application members available" .Any Suggestion
>>> >>
>>> >> Contribution will appreciated
>>> >>
>>> >> Kind Regards
>>> >> Trevor
>>> >> --
>>> >> View this message in context:
>>> >>
>>> http://old.nabble.com/Sample--57-Dynamic-load-balancing-tp31954754p31954754.html
>>> >> Sent from the Synapse - User mailing list archive at Nabble.com.
>>> >>
>>> >>
>>> >
>>> >
>>> > --
>>> > Hiranya Jayathilaka
>>> > Senior Software Engineer;
>>> > WSO2 Inc.; http://wso2.org
>>> > E-mail: hiranya@wso2.com; Mobile: +94 77 633 3491
>>> > Blog: http://techfeast-hiranya.blogspot.com
>>> >
>>> >
>>>
>>> --
>>> View this message in context:
>>> http://old.nabble.com/Sample--57-Dynamic-load-balancing-tp31954754p31957530.html
>>> Sent from the Synapse - User mailing list archive at Nabble.com.
>>>
>>>
>>
>>
>> --
>> Hiranya Jayathilaka
>> Senior Software Engineer;
>> WSO2 Inc.; http://wso2.org
>> E-mail: hiranya@wso2.com; Mobile: +94 77 633 3491
>> Blog: http://techfeast-hiranya.blogspot.com
>>
>>
> http://old.nabble.com/file/p31961865/axis2.xml axis2.xml
> http://old.nabble.com/file/p31961865/axis2.xml axis2.xml
>
http://old.nabble.com/file/p31961877/axis2.xml axis2.xml
--
View this message in context: http://old.nabble.com/Sample--57-Dynamic-load-balancing-tp31954754p31961877.html
Sent from the Synapse - User mailing list archive at Nabble.com.
Re: Sample #57 Dynamic load balancing
Posted by TrevorC <ma...@gmail.com>.
Here is the axis2.xml for synapse
Hiranya Jayathilaka-3 wrote:
>
> Sample worked fine for me. Can you please share the axis2.xml file of
> Synapse and the sample Axis2 server so I can have a look?
>
> Thanks,
> Hiranya
>
> On Thu, Jun 30, 2011 at 12:41 AM, TrevorC <ma...@gmail.com> wrote:
>
>>
>> Im working with synapse 2.0
>>
>> Hiranya Jayathilaka-3 wrote:
>> >
>> > What's the Synapse version you are working with?
>> >
>> > Thanks,
>> > Hiranya
>> >
>> > On Wed, Jun 29, 2011 at 6:58 PM, TrevorC <ma...@gmail.com> wrote:
>> >
>> >>
>> >> Hey Guys
>> >>
>> >> I got a problem wit sample 57 I cant run it.I have done everything
>> >> instructed by sample documentation but when it come 2 client side I
>> get
>> >> error message "couldn't send the message to the server" and also
>> apache
>> >> synapse interface has an error message "DynamicloadbalancingEndpoint
>> no
>> >> application members available" .Any Suggestion
>> >>
>> >> Contribution will appreciated
>> >>
>> >> Kind Regards
>> >> Trevor
>> >> --
>> >> View this message in context:
>> >>
>> http://old.nabble.com/Sample--57-Dynamic-load-balancing-tp31954754p31954754.html
>> >> Sent from the Synapse - User mailing list archive at Nabble.com.
>> >>
>> >>
>> >
>> >
>> > --
>> > Hiranya Jayathilaka
>> > Senior Software Engineer;
>> > WSO2 Inc.; http://wso2.org
>> > E-mail: hiranya@wso2.com; Mobile: +94 77 633 3491
>> > Blog: http://techfeast-hiranya.blogspot.com
>> >
>> >
>>
>> --
>> View this message in context:
>> http://old.nabble.com/Sample--57-Dynamic-load-balancing-tp31954754p31957530.html
>> Sent from the Synapse - User mailing list archive at Nabble.com.
>>
>>
>
>
> --
> Hiranya Jayathilaka
> Senior Software Engineer;
> WSO2 Inc.; http://wso2.org
> E-mail: hiranya@wso2.com; Mobile: +94 77 633 3491
> Blog: http://techfeast-hiranya.blogspot.com
>
>
http://old.nabble.com/file/p31961865/axis2.xml axis2.xml
http://old.nabble.com/file/p31961865/axis2.xml axis2.xml
--
View this message in context: http://old.nabble.com/Sample--57-Dynamic-load-balancing-tp31954754p31961865.html
Sent from the Synapse - User mailing list archive at Nabble.com.
Re: Sample #57 Dynamic load balancing
Posted by Hiranya Jayathilaka <hi...@gmail.com>.
Sample worked fine for me. Can you please share the axis2.xml file of
Synapse and the sample Axis2 server so I can have a look?
Thanks,
Hiranya
On Thu, Jun 30, 2011 at 12:41 AM, TrevorC <ma...@gmail.com> wrote:
>
> Im working with synapse 2.0
>
> Hiranya Jayathilaka-3 wrote:
> >
> > What's the Synapse version you are working with?
> >
> > Thanks,
> > Hiranya
> >
> > On Wed, Jun 29, 2011 at 6:58 PM, TrevorC <ma...@gmail.com> wrote:
> >
> >>
> >> Hey Guys
> >>
> >> I got a problem wit sample 57 I cant run it.I have done everything
> >> instructed by sample documentation but when it come 2 client side I get
> >> error message "couldn't send the message to the server" and also apache
> >> synapse interface has an error message "DynamicloadbalancingEndpoint no
> >> application members available" .Any Suggestion
> >>
> >> Contribution will appreciated
> >>
> >> Kind Regards
> >> Trevor
> >> --
> >> View this message in context:
> >>
> http://old.nabble.com/Sample--57-Dynamic-load-balancing-tp31954754p31954754.html
> >> Sent from the Synapse - User mailing list archive at Nabble.com.
> >>
> >>
> >
> >
> > --
> > Hiranya Jayathilaka
> > Senior Software Engineer;
> > WSO2 Inc.; http://wso2.org
> > E-mail: hiranya@wso2.com; Mobile: +94 77 633 3491
> > Blog: http://techfeast-hiranya.blogspot.com
> >
> >
>
> --
> View this message in context:
> http://old.nabble.com/Sample--57-Dynamic-load-balancing-tp31954754p31957530.html
> Sent from the Synapse - User mailing list archive at Nabble.com.
>
>
--
Hiranya Jayathilaka
Senior Software Engineer;
WSO2 Inc.; http://wso2.org
E-mail: hiranya@wso2.com; Mobile: +94 77 633 3491
Blog: http://techfeast-hiranya.blogspot.com
Re: Sample #57 Dynamic load balancing
Posted by TrevorC <ma...@gmail.com>.
Im working with synapse 2.0
Hiranya Jayathilaka-3 wrote:
>
> What's the Synapse version you are working with?
>
> Thanks,
> Hiranya
>
> On Wed, Jun 29, 2011 at 6:58 PM, TrevorC <ma...@gmail.com> wrote:
>
>>
>> Hey Guys
>>
>> I got a problem wit sample 57 I cant run it.I have done everything
>> instructed by sample documentation but when it come 2 client side I get
>> error message "couldn't send the message to the server" and also apache
>> synapse interface has an error message "DynamicloadbalancingEndpoint no
>> application members available" .Any Suggestion
>>
>> Contribution will appreciated
>>
>> Kind Regards
>> Trevor
>> --
>> View this message in context:
>> http://old.nabble.com/Sample--57-Dynamic-load-balancing-tp31954754p31954754.html
>> Sent from the Synapse - User mailing list archive at Nabble.com.
>>
>>
>
>
> --
> Hiranya Jayathilaka
> Senior Software Engineer;
> WSO2 Inc.; http://wso2.org
> E-mail: hiranya@wso2.com; Mobile: +94 77 633 3491
> Blog: http://techfeast-hiranya.blogspot.com
>
>
--
View this message in context: http://old.nabble.com/Sample--57-Dynamic-load-balancing-tp31954754p31957530.html
Sent from the Synapse - User mailing list archive at Nabble.com.
Re: Sample #57 Dynamic load balancing
Posted by Hiranya Jayathilaka <hi...@gmail.com>.
What's the Synapse version you are working with?
Thanks,
Hiranya
On Wed, Jun 29, 2011 at 6:58 PM, TrevorC <ma...@gmail.com> wrote:
>
> Hey Guys
>
> I got a problem wit sample 57 I cant run it.I have done everything
> instructed by sample documentation but when it come 2 client side I get
> error message "couldn't send the message to the server" and also apache
> synapse interface has an error message "DynamicloadbalancingEndpoint no
> application members available" .Any Suggestion
>
> Contribution will appreciated
>
> Kind Regards
> Trevor
> --
> View this message in context:
> http://old.nabble.com/Sample--57-Dynamic-load-balancing-tp31954754p31954754.html
> Sent from the Synapse - User mailing list archive at Nabble.com.
>
>
--
Hiranya Jayathilaka
Senior Software Engineer;
WSO2 Inc.; http://wso2.org
E-mail: hiranya@wso2.com; Mobile: +94 77 633 3491
Blog: http://techfeast-hiranya.blogspot.com