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 <[email protected]> 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 <[email protected]> >>> 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: **[email protected]* <[email protected]>* 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: **[email protected]* <[email protected]>* 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.
