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* * *
