TCPPING in AS7

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

TCPPING in AS7

William DeCoste
Hi Brian,

Has anything changed in the config of AS7.1 from 7.0.x? I am not seeing
any jgroups traffic or discovery. This configuration worked fine in
7.0.x. When JGroups is loaded it just creates 2 1-node clusters. They
don't seem to see each other or even be trying.

Thanks -Bill

<subsystem xmlns="urn:jboss:domain:jgroups:1.1" default-stack="tcp">
<stack name="tcp">
<transport type="TCP" socket-binding="jgroups-tcp"/>
<protocol type="TCPPING">
<property name="timeout">
                         3000
</property>
<property name="initial_hosts">
                         127.0.250.1[7600],127.0.251.1[7600]
</property>
<property name="port_range">
                         1
</property>
<property name="num_initial_members">
                         2
</property>
</protocol>
<protocol type="MERGE2"/>
<protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd"/>
<protocol type="FD"/>
<protocol type="VERIFY_SUSPECT"/>
<protocol type="BARRIER"/>
<protocol type="pbcast.NAKACK"/>
<protocol type="UNICAST2"/>
<protocol type="pbcast.STABLE"/>
<protocol type="pbcast.GMS"/>
<protocol type="UFC"/>
<protocol type="MFC"/>
<protocol type="FRAG2"/>
</stack>
</subsystem>

--
Bill DeCoste
Principal Software Engineer, Red Hat
978-204-0920
[hidden email]

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: TCPPING in AS7

Brian Stansberry
Hi Paul, Richard:

Do you guys see anything wrong here?

- Brian

On 3/14/12 4:44 PM, William DeCoste wrote:

> Hi Brian,
>
> Has anything changed in the config of AS7.1 from 7.0.x? I am not seeing
> any jgroups traffic or discovery. This configuration worked fine in
> 7.0.x. When JGroups is loaded it just creates 2 1-node clusters. They
> don't seem to see each other or even be trying.
>
> Thanks -Bill
>
> <subsystem xmlns="urn:jboss:domain:jgroups:1.1" default-stack="tcp">
> <stack name="tcp">
> <transport type="TCP" socket-binding="jgroups-tcp"/>
> <protocol type="TCPPING">
> <property name="timeout">
> 3000
> </property>
> <property name="initial_hosts">
> 127.0.250.1[7600],127.0.251.1[7600]
> </property>
> <property name="port_range">
> 1
> </property>
> <property name="num_initial_members">
> 2
> </property>
> </protocol>
> <protocol type="MERGE2"/>
> <protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd"/>
> <protocol type="FD"/>
> <protocol type="VERIFY_SUSPECT"/>
> <protocol type="BARRIER"/>
> <protocol type="pbcast.NAKACK"/>
> <protocol type="UNICAST2"/>
> <protocol type="pbcast.STABLE"/>
> <protocol type="pbcast.GMS"/>
> <protocol type="UFC"/>
> <protocol type="MFC"/>
> <protocol type="FRAG2"/>
> </stack>
> </subsystem>
>


--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: TCPPING in AS7

kkhan
In reply to this post by William DeCoste
A guy at last night's JUG was complaining about this. He mentioned there is a new setting to make the cache replicated, which now needs explicitly turning on. The config from 7.0.x does not turn this on in 7.1, the new setting needs turning on. I guess (but have no idea) that it is one of these values from the infinispan 1.2 xsd:

    <xs:complexType name="cache-container">
        <xs:complexContent>
            <xs:extension base="tns:base-cache-container">
                <xs:sequence>
                    <xs:element name="transport" type="tns:transport" minOccurs="0">
                        <xs:annotation>
                            <xs:documentation>Overrides the transport characteristics for this cache container.</xs:documentation>
                        </xs:annotation>
                    </xs:element>
                    <xs:choice maxOccurs="unbounded">
                        <xs:element name="local-cache" type="tns:local-cache">
                            <xs:annotation>
                                <xs:documentation>Defines a LOCAL mode cache.</xs:documentation>
                            </xs:annotation>
                        </xs:element>
                        <xs:element name="replicated-cache" type="tns:replicated-cache">
                            <xs:annotation>
                                <xs:documentation>Defines a REPL_* mode cache.</xs:documentation>
                            </xs:annotation>
                        </xs:element>
                        <xs:element name="invalidation-cache" type="tns:invalidation-cache">
                            <xs:annotation>
                                <xs:documentation>Defines an INVALIDATION_* mode cache.</xs:documentation>
                            </xs:annotation>
                        </xs:element>
                        <xs:element name="distributed-cache" type="tns:distributed-cache">
                            <xs:annotation>
                                <xs:documentation>Defines a DIST_* mode cache.</xs:documentation>
                            </xs:annotation>
                        </xs:element>
                    </xs:choice>
                </xs:sequence>
            </xs:extension>
        </xs:complexContent>
On 14 Mar 2012, at 21:44, William DeCoste wrote:

> Hi Brian,
>
> Has anything changed in the config of AS7.1 from 7.0.x? I am not seeing
> any jgroups traffic or discovery. This configuration worked fine in
> 7.0.x. When JGroups is loaded it just creates 2 1-node clusters. They
> don't seem to see each other or even be trying.
>
> Thanks -Bill
>
> <subsystem xmlns="urn:jboss:domain:jgroups:1.1" default-stack="tcp">
> <stack name="tcp">
> <transport type="TCP" socket-binding="jgroups-tcp"/>
> <protocol type="TCPPING">
> <property name="timeout">
>                         3000
> </property>
> <property name="initial_hosts">
>                         127.0.250.1[7600],127.0.251.1[7600]
> </property>
> <property name="port_range">
>                         1
> </property>
> <property name="num_initial_members">
>                         2
> </property>
> </protocol>
> <protocol type="MERGE2"/>
> <protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd"/>
> <protocol type="FD"/>
> <protocol type="VERIFY_SUSPECT"/>
> <protocol type="BARRIER"/>
> <protocol type="pbcast.NAKACK"/>
> <protocol type="UNICAST2"/>
> <protocol type="pbcast.STABLE"/>
> <protocol type="pbcast.GMS"/>
> <protocol type="UFC"/>
> <protocol type="MFC"/>
> <protocol type="FRAG2"/>
> </stack>
> </subsystem>
>
> --
> Bill DeCoste
> Principal Software Engineer, Red Hat
> 978-204-0920
> [hidden email]
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: TCPPING in AS7

William DeCoste
I am using the OOTB 7.1 Infinispan config. I don't see anything from
jgroups or org.jboss.as.clustering indicating that either node is
forming a 2-node cluster. I saw this with 7.0.x.

Thanks -Bill

On 3/14/12 4:12 PM, Kabir Khan wrote:

> A guy at last night's JUG was complaining about this. He mentioned there is a new setting to make the cache replicated, which now needs explicitly turning on. The config from 7.0.x does not turn this on in 7.1, the new setting needs turning on. I guess (but have no idea) that it is one of these values from the infinispan 1.2 xsd:
>
>      <xs:complexType name="cache-container">
>          <xs:complexContent>
>              <xs:extension base="tns:base-cache-container">
>                  <xs:sequence>
>                      <xs:element name="transport" type="tns:transport" minOccurs="0">
>                          <xs:annotation>
>                              <xs:documentation>Overrides the transport characteristics for this cache container.</xs:documentation>
>                          </xs:annotation>
>                      </xs:element>
>                      <xs:choice maxOccurs="unbounded">
>                          <xs:element name="local-cache" type="tns:local-cache">
>                              <xs:annotation>
>                                  <xs:documentation>Defines a LOCAL mode cache.</xs:documentation>
>                              </xs:annotation>
>                          </xs:element>
>                          <xs:element name="replicated-cache" type="tns:replicated-cache">
>                              <xs:annotation>
>                                  <xs:documentation>Defines a REPL_* mode cache.</xs:documentation>
>                              </xs:annotation>
>                          </xs:element>
>                          <xs:element name="invalidation-cache" type="tns:invalidation-cache">
>                              <xs:annotation>
>                                  <xs:documentation>Defines an INVALIDATION_* mode cache.</xs:documentation>
>                              </xs:annotation>
>                          </xs:element>
>                          <xs:element name="distributed-cache" type="tns:distributed-cache">
>                              <xs:annotation>
>                                  <xs:documentation>Defines a DIST_* mode cache.</xs:documentation>
>                              </xs:annotation>
>                          </xs:element>
>                      </xs:choice>
>                  </xs:sequence>
>              </xs:extension>
>          </xs:complexContent>
> On 14 Mar 2012, at 21:44, William DeCoste wrote:
>
>> Hi Brian,
>>
>> Has anything changed in the config of AS7.1 from 7.0.x? I am not seeing
>> any jgroups traffic or discovery. This configuration worked fine in
>> 7.0.x. When JGroups is loaded it just creates 2 1-node clusters. They
>> don't seem to see each other or even be trying.
>>
>> Thanks -Bill
>>
>> <subsystem xmlns="urn:jboss:domain:jgroups:1.1" default-stack="tcp">
>> <stack name="tcp">
>> <transport type="TCP" socket-binding="jgroups-tcp"/>
>> <protocol type="TCPPING">
>> <property name="timeout">
>>                          3000
>> </property>
>> <property name="initial_hosts">
>>                          127.0.250.1[7600],127.0.251.1[7600]
>> </property>
>> <property name="port_range">
>>                          1
>> </property>
>> <property name="num_initial_members">
>>                          2
>> </property>
>> </protocol>
>> <protocol type="MERGE2"/>
>> <protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd"/>
>> <protocol type="FD"/>
>> <protocol type="VERIFY_SUSPECT"/>
>> <protocol type="BARRIER"/>
>> <protocol type="pbcast.NAKACK"/>
>> <protocol type="UNICAST2"/>
>> <protocol type="pbcast.STABLE"/>
>> <protocol type="pbcast.GMS"/>
>> <protocol type="UFC"/>
>> <protocol type="MFC"/>
>> <protocol type="FRAG2"/>
>> </stack>
>> </subsystem>
>>
>> --
>> Bill DeCoste
>> Principal Software Engineer, Red Hat
>> 978-204-0920
>> [hidden email]
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

--
Bill DeCoste
Principal Software Engineer, Red Hat
978-204-0920
[hidden email]

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: TCPPING in AS7

Richard Achmatowicz
In reply to this post by Brian Stansberry
Hi Bill

The configuration is valid. I tried it out on my local machine. I set up
two AS 7.1.1. instances, configured as you describe but using a
different set of IPv4 addresses (I used 192.168.0.103, 192.168.0.104 and
used "iptables -F" to let multicast messages through).

Because clustering services are installed on-demand, they need some
event to to start them, so I also deployed a small clustered web
application.

When I start both instances, no channels are started, as expected:
$ ./standalone.sh --server-config standalone-ha.xml
-Djboss.bind.address=192.168.0.103
-Djboss.bind.address.management=192.168.0.103 -Djboss.node.name=A
$ ./standalone.sh --server-config standalone-ha.xml
-Djboss.bind.address=192.168.0.104
-Djboss.bind.address.management=192.168.0.104 -Djboss.node.name=B

When I deployed the clustered web app on each application server
instance to trigger Infinispan web cache container and JGroups tcp
channel startup, I saw for example, on the first host A:

18:58:41,086 INFO  [org.jboss.as.clustering.infinispan] (MSC service
thread 1-8) JBAS010281: Started //default-host//my-clustered-webapp
cache from web container
18:58:41,096 INFO  
[org.infinispan.configuration.cache.EvictionConfigurationBuilder] (MSC
service thread 1-8) ISPN000152: Passivation configured without an
eviction policy being selected. Only manually evicted entities will be
pasivated.
18:58:41,099 INFO  
[org.infinispan.configuration.cache.EvictionConfigurationBuilder] (MSC
service thread 1-8) ISPN000152: Passivation configured without an
eviction policy being selected. Only manually evicted entities will be
pasivated.
18:58:41,220 INFO  [org.jboss.web] (MSC service thread 1-8) JBAS018210:
Registering web context: /my-clustered-webapp
18:58:41,230 INFO  [org.jboss.as.server] (Controller Boot Thread)
JBAS018559: Deployed "my-clustered-webapp.war"
18:58:41,333 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015951:
Admin console listening on http://192.168.0.103:9990
18:58:41,334 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015874:
JBoss AS 7.1.1.Final-SNAPSHOT "Thunder" started in 6719ms - Started 175
of 305 services (129 services are passive or on-demand)
18:58:50,673 INFO  
[org.jboss.as.clustering.impl.CoreGroupCommunicationService.lifecycle.web]
(Incoming-1,null) JBAS010247: New cluster view for partition web (id: 1,
delta: 1, merge: false) : [A/web, B/web]
18:58:50,687 INFO  
[org.infinispan.remoting.transport.jgroups.JGroupsTransport]
(Incoming-1,null) ISPN000094: Received new cluster view: [A/web|1]
[A/web, B/web]

So, it seems as though things work as expected.

I also tried to achieve the same effect by not deploying the web app and
setting the attribute start="EAGER" on a clustered Infinispan cache (in
this case, cache "repl" in the "web" cache container) to force them to
start as active services. When the application servers were started this
time, same result: clustering between the two nodes was visible.

If I instead set the start="EAGER" attribute on a cache container,
however, the channels do not get started automatically and I need to
deploy a web app as before to trigger starting of the transport.

So, are you using start=EAGER to start the cache instances, or deploying
an app to trigger them? The organization of Infinispan services has
changed a lot since 7.1.0. In particular, a cache container needs to
specify the <transport/> element in order for a transport to be used.

Richard

On 03/14/2012 05:47 PM, Brian Stansberry wrote:

> Hi Paul, Richard:
>
> Do you guys see anything wrong here?
>
> - Brian
>
> On 3/14/12 4:44 PM, William DeCoste wrote:
>> Hi Brian,
>>
>> Has anything changed in the config of AS7.1 from 7.0.x? I am not seeing
>> any jgroups traffic or discovery. This configuration worked fine in
>> 7.0.x. When JGroups is loaded it just creates 2 1-node clusters. They
>> don't seem to see each other or even be trying.
>>
>> Thanks -Bill
>>
>> <subsystem xmlns="urn:jboss:domain:jgroups:1.1" default-stack="tcp">
>> <stack name="tcp">
>> <transport type="TCP" socket-binding="jgroups-tcp"/>
>> <protocol type="TCPPING">
>> <property name="timeout">
>> 3000
>> </property>
>> <property name="initial_hosts">
>> 127.0.250.1[7600],127.0.251.1[7600]
>> </property>
>> <property name="port_range">
>> 1
>> </property>
>> <property name="num_initial_members">
>> 2
>> </property>
>> </protocol>
>> <protocol type="MERGE2"/>
>> <protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd"/>
>> <protocol type="FD"/>
>> <protocol type="VERIFY_SUSPECT"/>
>> <protocol type="BARRIER"/>
>> <protocol type="pbcast.NAKACK"/>
>> <protocol type="UNICAST2"/>
>> <protocol type="pbcast.STABLE"/>
>> <protocol type="pbcast.GMS"/>
>> <protocol type="UFC"/>
>> <protocol type="MFC"/>
>> <protocol type="FRAG2"/>
>> </stack>
>> </subsystem>
>>
>
>

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: TCPPING in AS7

Richard Achmatowicz
In reply to this post by kkhan
He may have been referring to the fact that in AS 7.1.1 if you don't
include a <transport/> element in your cache container, you don't get a
transport. And in that case, caches in two instances of that cache
container would not communicate.

On 03/14/2012 07:12 PM, Kabir Khan wrote:

> A guy at last night's JUG was complaining about this. He mentioned there is a new setting to make the cache replicated, which now needs explicitly turning on. The config from 7.0.x does not turn this on in 7.1, the new setting needs turning on. I guess (but have no idea) that it is one of these values from the infinispan 1.2 xsd:
>
>      <xs:complexType name="cache-container">
>          <xs:complexContent>
>              <xs:extension base="tns:base-cache-container">
>                  <xs:sequence>
>                      <xs:element name="transport" type="tns:transport" minOccurs="0">
>                          <xs:annotation>
>                              <xs:documentation>Overrides the transport characteristics for this cache container.</xs:documentation>
>                          </xs:annotation>
>                      </xs:element>
>                      <xs:choice maxOccurs="unbounded">
>                          <xs:element name="local-cache" type="tns:local-cache">
>                              <xs:annotation>
>                                  <xs:documentation>Defines a LOCAL mode cache.</xs:documentation>
>                              </xs:annotation>
>                          </xs:element>
>                          <xs:element name="replicated-cache" type="tns:replicated-cache">
>                              <xs:annotation>
>                                  <xs:documentation>Defines a REPL_* mode cache.</xs:documentation>
>                              </xs:annotation>
>                          </xs:element>
>                          <xs:element name="invalidation-cache" type="tns:invalidation-cache">
>                              <xs:annotation>
>                                  <xs:documentation>Defines an INVALIDATION_* mode cache.</xs:documentation>
>                              </xs:annotation>
>                          </xs:element>
>                          <xs:element name="distributed-cache" type="tns:distributed-cache">
>                              <xs:annotation>
>                                  <xs:documentation>Defines a DIST_* mode cache.</xs:documentation>
>                              </xs:annotation>
>                          </xs:element>
>                      </xs:choice>
>                  </xs:sequence>
>              </xs:extension>
>          </xs:complexContent>
> On 14 Mar 2012, at 21:44, William DeCoste wrote:
>
>> Hi Brian,
>>
>> Has anything changed in the config of AS7.1 from 7.0.x? I am not seeing
>> any jgroups traffic or discovery. This configuration worked fine in
>> 7.0.x. When JGroups is loaded it just creates 2 1-node clusters. They
>> don't seem to see each other or even be trying.
>>
>> Thanks -Bill
>>
>> <subsystem xmlns="urn:jboss:domain:jgroups:1.1" default-stack="tcp">
>> <stack name="tcp">
>> <transport type="TCP" socket-binding="jgroups-tcp"/>
>> <protocol type="TCPPING">
>> <property name="timeout">
>>                          3000
>> </property>
>> <property name="initial_hosts">
>>                          127.0.250.1[7600],127.0.251.1[7600]
>> </property>
>> <property name="port_range">
>>                          1
>> </property>
>> <property name="num_initial_members">
>>                          2
>> </property>
>> </protocol>
>> <protocol type="MERGE2"/>
>> <protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd"/>
>> <protocol type="FD"/>
>> <protocol type="VERIFY_SUSPECT"/>
>> <protocol type="BARRIER"/>
>> <protocol type="pbcast.NAKACK"/>
>> <protocol type="UNICAST2"/>
>> <protocol type="pbcast.STABLE"/>
>> <protocol type="pbcast.GMS"/>
>> <protocol type="UFC"/>
>> <protocol type="MFC"/>
>> <protocol type="FRAG2"/>
>> </stack>
>> </subsystem>
>>
>> --
>> Bill DeCoste
>> Principal Software Engineer, Red Hat
>> 978-204-0920
>> [hidden email]
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: TCPPING in AS7

jtgreene
Administrator
We have to be careful about this in the future. We should preserve old
defaults for older configs.

On 3/15/12 1:01 AM, Richard Achmatowicz wrote:

> He may have been referring to the fact that in AS 7.1.1 if you don't
> include a<transport/>  element in your cache container, you don't get a
> transport. And in that case, caches in two instances of that cache
> container would not communicate.
>
> On 03/14/2012 07:12 PM, Kabir Khan wrote:
>> A guy at last night's JUG was complaining about this. He mentioned there is a new setting to make the cache replicated, which now needs explicitly turning on. The config from 7.0.x does not turn this on in 7.1, the new setting needs turning on. I guess (but have no idea) that it is one of these values from the infinispan 1.2 xsd:
>>
>>       <xs:complexType name="cache-container">
>>           <xs:complexContent>
>>               <xs:extension base="tns:base-cache-container">
>>                   <xs:sequence>
>>                       <xs:element name="transport" type="tns:transport" minOccurs="0">
>>                           <xs:annotation>
>>                               <xs:documentation>Overrides the transport characteristics for this cache container.</xs:documentation>
>>                           </xs:annotation>
>>                       </xs:element>
>>                       <xs:choice maxOccurs="unbounded">
>>                           <xs:element name="local-cache" type="tns:local-cache">
>>                               <xs:annotation>
>>                                   <xs:documentation>Defines a LOCAL mode cache.</xs:documentation>
>>                               </xs:annotation>
>>                           </xs:element>
>>                           <xs:element name="replicated-cache" type="tns:replicated-cache">
>>                               <xs:annotation>
>>                                   <xs:documentation>Defines a REPL_* mode cache.</xs:documentation>
>>                               </xs:annotation>
>>                           </xs:element>
>>                           <xs:element name="invalidation-cache" type="tns:invalidation-cache">
>>                               <xs:annotation>
>>                                   <xs:documentation>Defines an INVALIDATION_* mode cache.</xs:documentation>
>>                               </xs:annotation>
>>                           </xs:element>
>>                           <xs:element name="distributed-cache" type="tns:distributed-cache">
>>                               <xs:annotation>
>>                                   <xs:documentation>Defines a DIST_* mode cache.</xs:documentation>
>>                               </xs:annotation>
>>                           </xs:element>
>>                       </xs:choice>
>>                   </xs:sequence>
>>               </xs:extension>
>>           </xs:complexContent>
>> On 14 Mar 2012, at 21:44, William DeCoste wrote:
>>
>>> Hi Brian,
>>>
>>> Has anything changed in the config of AS7.1 from 7.0.x? I am not seeing
>>> any jgroups traffic or discovery. This configuration worked fine in
>>> 7.0.x. When JGroups is loaded it just creates 2 1-node clusters. They
>>> don't seem to see each other or even be trying.
>>>
>>> Thanks -Bill
>>>
>>> <subsystem xmlns="urn:jboss:domain:jgroups:1.1" default-stack="tcp">
>>> <stack name="tcp">
>>> <transport type="TCP" socket-binding="jgroups-tcp"/>
>>> <protocol type="TCPPING">
>>> <property name="timeout">
>>>                           3000
>>> </property>
>>> <property name="initial_hosts">
>>>                           127.0.250.1[7600],127.0.251.1[7600]
>>> </property>
>>> <property name="port_range">
>>>                           1
>>> </property>
>>> <property name="num_initial_members">
>>>                           2
>>> </property>
>>> </protocol>
>>> <protocol type="MERGE2"/>
>>> <protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd"/>
>>> <protocol type="FD"/>
>>> <protocol type="VERIFY_SUSPECT"/>
>>> <protocol type="BARRIER"/>
>>> <protocol type="pbcast.NAKACK"/>
>>> <protocol type="UNICAST2"/>
>>> <protocol type="pbcast.STABLE"/>
>>> <protocol type="pbcast.GMS"/>
>>> <protocol type="UFC"/>
>>> <protocol type="MFC"/>
>>> <protocol type="FRAG2"/>
>>> </stack>
>>> </subsystem>
>>>
>>> --
>>> Bill DeCoste
>>> Principal Software Engineer, Red Hat
>>> 978-204-0920
>>> [hidden email]
>>>
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: TCPPING in AS7

William DeCoste
In reply to this post by Richard Achmatowicz
Hi Richard,

I'm also deploying a clustered web app which causes JGroups and the rest
of clustering to load.

Maybe this is just a change in logging. I am seeing the following with
AS7.1.0:
2012/03/14 19:53:21,710 INFO  
[org.infinispan.remoting.transport.jgroups.JGroupsTransport]
(pool-17-thread-1) ISPN000094: Received new cluster view:
[ip-10-190-239-128/ejb|0] [ip-10-190-239-128/ejb]

Does "[ip-10-190-239-128/ejb|0] [ip-10-190-239-128/ejb]" indicate 2
nodes? This is on Express thus the strange node names.

I'm used to seeing jgroups debug logging of the pings that isn't
happening. Was definietly seeing different logging in 7.0.x.

Thanks -Bill

On 3/14/12 4:55 PM, Richard Achmatowicz wrote:

> Hi Bill
>
> The configuration is valid. I tried it out on my local machine. I set
> up two AS 7.1.1. instances, configured as you describe but using a
> different set of IPv4 addresses (I used 192.168.0.103, 192.168.0.104
> and used "iptables -F" to let multicast messages through).
>
> Because clustering services are installed on-demand, they need some
> event to to start them, so I also deployed a small clustered web
> application.
>
> When I start both instances, no channels are started, as expected:
> $ ./standalone.sh --server-config standalone-ha.xml
> -Djboss.bind.address=192.168.0.103
> -Djboss.bind.address.management=192.168.0.103 -Djboss.node.name=A
> $ ./standalone.sh --server-config standalone-ha.xml
> -Djboss.bind.address=192.168.0.104
> -Djboss.bind.address.management=192.168.0.104 -Djboss.node.name=B
>
> When I deployed the clustered web app on each application server
> instance to trigger Infinispan web cache container and JGroups tcp
> channel startup, I saw for example, on the first host A:
>
> 18:58:41,086 INFO  [org.jboss.as.clustering.infinispan] (MSC service
> thread 1-8) JBAS010281: Started //default-host//my-clustered-webapp
> cache from web container
> 18:58:41,096 INFO  
> [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (MSC
> service thread 1-8) ISPN000152: Passivation configured without an
> eviction policy being selected. Only manually evicted entities will be
> pasivated.
> 18:58:41,099 INFO  
> [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (MSC
> service thread 1-8) ISPN000152: Passivation configured without an
> eviction policy being selected. Only manually evicted entities will be
> pasivated.
> 18:58:41,220 INFO  [org.jboss.web] (MSC service thread 1-8)
> JBAS018210: Registering web context: /my-clustered-webapp
> 18:58:41,230 INFO  [org.jboss.as.server] (Controller Boot Thread)
> JBAS018559: Deployed "my-clustered-webapp.war"
> 18:58:41,333 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015951:
> Admin console listening on http://192.168.0.103:9990
> 18:58:41,334 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015874:
> JBoss AS 7.1.1.Final-SNAPSHOT "Thunder" started in 6719ms - Started
> 175 of 305 services (129 services are passive or on-demand)
> 18:58:50,673 INFO  
> [org.jboss.as.clustering.impl.CoreGroupCommunicationService.lifecycle.web]
> (Incoming-1,null) JBAS010247: New cluster view for partition web (id:
> 1, delta: 1, merge: false) : [A/web, B/web]
> 18:58:50,687 INFO  
> [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> (Incoming-1,null) ISPN000094: Received new cluster view: [A/web|1]
> [A/web, B/web]
>
> So, it seems as though things work as expected.
>
> I also tried to achieve the same effect by not deploying the web app
> and setting the attribute start="EAGER" on a clustered Infinispan
> cache (in this case, cache "repl" in the "web" cache container) to
> force them to start as active services. When the application servers
> were started this time, same result: clustering between the two nodes
> was visible.
>
> If I instead set the start="EAGER" attribute on a cache container,
> however, the channels do not get started automatically and I need to
> deploy a web app as before to trigger starting of the transport.
>
> So, are you using start=EAGER to start the cache instances, or
> deploying an app to trigger them? The organization of Infinispan
> services has changed a lot since 7.1.0. In particular, a cache
> container needs to specify the <transport/> element in order for a
> transport to be used.
>
> Richard
>
> On 03/14/2012 05:47 PM, Brian Stansberry wrote:
>> Hi Paul, Richard:
>>
>> Do you guys see anything wrong here?
>>
>> - Brian
>>
>> On 3/14/12 4:44 PM, William DeCoste wrote:
>>> Hi Brian,
>>>
>>> Has anything changed in the config of AS7.1 from 7.0.x? I am not seeing
>>> any jgroups traffic or discovery. This configuration worked fine in
>>> 7.0.x. When JGroups is loaded it just creates 2 1-node clusters. They
>>> don't seem to see each other or even be trying.
>>>
>>> Thanks -Bill
>>>
>>> <subsystem xmlns="urn:jboss:domain:jgroups:1.1" default-stack="tcp">
>>> <stack name="tcp">
>>> <transport type="TCP" socket-binding="jgroups-tcp"/>
>>> <protocol type="TCPPING">
>>> <property name="timeout">
>>> 3000
>>> </property>
>>> <property name="initial_hosts">
>>> 127.0.250.1[7600],127.0.251.1[7600]
>>> </property>
>>> <property name="port_range">
>>> 1
>>> </property>
>>> <property name="num_initial_members">
>>> 2
>>> </property>
>>> </protocol>
>>> <protocol type="MERGE2"/>
>>> <protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd"/>
>>> <protocol type="FD"/>
>>> <protocol type="VERIFY_SUSPECT"/>
>>> <protocol type="BARRIER"/>
>>> <protocol type="pbcast.NAKACK"/>
>>> <protocol type="UNICAST2"/>
>>> <protocol type="pbcast.STABLE"/>
>>> <protocol type="pbcast.GMS"/>
>>> <protocol type="UFC"/>
>>> <protocol type="MFC"/>
>>> <protocol type="FRAG2"/>
>>> </stack>
>>> </subsystem>
>>>
>>
>>
>

--
Bill DeCoste
Principal Software Engineer, Red Hat
978-204-0920
[hidden email]

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: TCPPING in AS7

Richard Achmatowicz
On 03/14/2012 08:15 PM, William DeCoste wrote:

> Hi Richard,
>
> I'm also deploying a clustered web app which causes JGroups and the
> rest of clustering to load.
>
> Maybe this is just a change in logging. I am seeing the following with
> AS7.1.0:
> 2012/03/14 19:53:21,710 INFO  
> [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> (pool-17-thread-1) ISPN000094: Received new cluster view:
> [ip-10-190-239-128/ejb|0] [ip-10-190-239-128/ejb]
>
> Does "[ip-10-190-239-128/ejb|0] [ip-10-190-239-128/ejb]" indicate 2
> nodes? This is on Express thus the strange node names.
One node. IIRC, the first element [ip-10-190-239-128/ejb|0] indicates
the host which triggered the view change, and the second element
[ip-10-190-239-128/ejb] is the new group membership.

>
> I'm used to seeing jgroups debug logging of the pings that isn't
> happening. Was definietly seeing different logging in 7.0.x.
>
> Thanks -Bill
>
> On 3/14/12 4:55 PM, Richard Achmatowicz wrote:
>> Hi Bill
>>
>> The configuration is valid. I tried it out on my local machine. I set
>> up two AS 7.1.1. instances, configured as you describe but using a
>> different set of IPv4 addresses (I used 192.168.0.103, 192.168.0.104
>> and used "iptables -F" to let multicast messages through).
>>
>> Because clustering services are installed on-demand, they need some
>> event to to start them, so I also deployed a small clustered web
>> application.
>>
>> When I start both instances, no channels are started, as expected:
>> $ ./standalone.sh --server-config standalone-ha.xml
>> -Djboss.bind.address=192.168.0.103
>> -Djboss.bind.address.management=192.168.0.103 -Djboss.node.name=A
>> $ ./standalone.sh --server-config standalone-ha.xml
>> -Djboss.bind.address=192.168.0.104
>> -Djboss.bind.address.management=192.168.0.104 -Djboss.node.name=B
>>
>> When I deployed the clustered web app on each application server
>> instance to trigger Infinispan web cache container and JGroups tcp
>> channel startup, I saw for example, on the first host A:
>>
>> 18:58:41,086 INFO  [org.jboss.as.clustering.infinispan] (MSC service
>> thread 1-8) JBAS010281: Started //default-host//my-clustered-webapp
>> cache from web container
>> 18:58:41,096 INFO  
>> [org.infinispan.configuration.cache.EvictionConfigurationBuilder]
>> (MSC service thread 1-8) ISPN000152: Passivation configured without
>> an eviction policy being selected. Only manually evicted entities
>> will be pasivated.
>> 18:58:41,099 INFO  
>> [org.infinispan.configuration.cache.EvictionConfigurationBuilder]
>> (MSC service thread 1-8) ISPN000152: Passivation configured without
>> an eviction policy being selected. Only manually evicted entities
>> will be pasivated.
>> 18:58:41,220 INFO  [org.jboss.web] (MSC service thread 1-8)
>> JBAS018210: Registering web context: /my-clustered-webapp
>> 18:58:41,230 INFO  [org.jboss.as.server] (Controller Boot Thread)
>> JBAS018559: Deployed "my-clustered-webapp.war"
>> 18:58:41,333 INFO  [org.jboss.as] (Controller Boot Thread)
>> JBAS015951: Admin console listening on http://192.168.0.103:9990
>> 18:58:41,334 INFO  [org.jboss.as] (Controller Boot Thread)
>> JBAS015874: JBoss AS 7.1.1.Final-SNAPSHOT "Thunder" started in 6719ms
>> - Started 175 of 305 services (129 services are passive or on-demand)
>> 18:58:50,673 INFO  
>> [org.jboss.as.clustering.impl.CoreGroupCommunicationService.lifecycle.web]
>> (Incoming-1,null) JBAS010247: New cluster view for partition web (id:
>> 1, delta: 1, merge: false) : [A/web, B/web]
>> 18:58:50,687 INFO  
>> [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
>> (Incoming-1,null) ISPN000094: Received new cluster view: [A/web|1]
>> [A/web, B/web]
>>
>> So, it seems as though things work as expected.
>>
>> I also tried to achieve the same effect by not deploying the web app
>> and setting the attribute start="EAGER" on a clustered Infinispan
>> cache (in this case, cache "repl" in the "web" cache container) to
>> force them to start as active services. When the application servers
>> were started this time, same result: clustering between the two nodes
>> was visible.
>>
>> If I instead set the start="EAGER" attribute on a cache container,
>> however, the channels do not get started automatically and I need to
>> deploy a web app as before to trigger starting of the transport.
>>
>> So, are you using start=EAGER to start the cache instances, or
>> deploying an app to trigger them? The organization of Infinispan
>> services has changed a lot since 7.1.0. In particular, a cache
>> container needs to specify the <transport/> element in order for a
>> transport to be used.
>>
>> Richard
>>
>> On 03/14/2012 05:47 PM, Brian Stansberry wrote:
>>> Hi Paul, Richard:
>>>
>>> Do you guys see anything wrong here?
>>>
>>> - Brian
>>>
>>> On 3/14/12 4:44 PM, William DeCoste wrote:
>>>> Hi Brian,
>>>>
>>>> Has anything changed in the config of AS7.1 from 7.0.x? I am not
>>>> seeing
>>>> any jgroups traffic or discovery. This configuration worked fine in
>>>> 7.0.x. When JGroups is loaded it just creates 2 1-node clusters. They
>>>> don't seem to see each other or even be trying.
>>>>
>>>> Thanks -Bill
>>>>
>>>> <subsystem xmlns="urn:jboss:domain:jgroups:1.1" default-stack="tcp">
>>>> <stack name="tcp">
>>>> <transport type="TCP" socket-binding="jgroups-tcp"/>
>>>> <protocol type="TCPPING">
>>>> <property name="timeout">
>>>> 3000
>>>> </property>
>>>> <property name="initial_hosts">
>>>> 127.0.250.1[7600],127.0.251.1[7600]
>>>> </property>
>>>> <property name="port_range">
>>>> 1
>>>> </property>
>>>> <property name="num_initial_members">
>>>> 2
>>>> </property>
>>>> </protocol>
>>>> <protocol type="MERGE2"/>
>>>> <protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd"/>
>>>> <protocol type="FD"/>
>>>> <protocol type="VERIFY_SUSPECT"/>
>>>> <protocol type="BARRIER"/>
>>>> <protocol type="pbcast.NAKACK"/>
>>>> <protocol type="UNICAST2"/>
>>>> <protocol type="pbcast.STABLE"/>
>>>> <protocol type="pbcast.GMS"/>
>>>> <protocol type="UFC"/>
>>>> <protocol type="MFC"/>
>>>> <protocol type="FRAG2"/>
>>>> </stack>
>>>> </subsystem>
>>>>
>>>
>>>
>>
>

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: TCPPING in AS7

William DeCoste
OK, that's what I thought - the 2 nodes aren't seeing each other. Thanks
for confirming the config is ok. I never see any logging with a
membership of more than one. And I never saw any change if I killed a node.

On 3/14/12 5:18 PM, Richard Achmatowicz wrote:

> On 03/14/2012 08:15 PM, William DeCoste wrote:
>> Hi Richard,
>>
>> I'm also deploying a clustered web app which causes JGroups and the
>> rest of clustering to load.
>>
>> Maybe this is just a change in logging. I am seeing the following
>> with AS7.1.0:
>> 2012/03/14 19:53:21,710 INFO  
>> [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
>> (pool-17-thread-1) ISPN000094: Received new cluster view:
>> [ip-10-190-239-128/ejb|0] [ip-10-190-239-128/ejb]
>>
>> Does "[ip-10-190-239-128/ejb|0] [ip-10-190-239-128/ejb]" indicate 2
>> nodes? This is on Express thus the strange node names.
> One node. IIRC, the first element [ip-10-190-239-128/ejb|0] indicates
> the host which triggered the view change, and the second element
> [ip-10-190-239-128/ejb] is the new group membership.
>>
>> I'm used to seeing jgroups debug logging of the pings that isn't
>> happening. Was definietly seeing different logging in 7.0.x.
>>
>> Thanks -Bill
>>
>> On 3/14/12 4:55 PM, Richard Achmatowicz wrote:
>>> Hi Bill
>>>
>>> The configuration is valid. I tried it out on my local machine. I
>>> set up two AS 7.1.1. instances, configured as you describe but using
>>> a different set of IPv4 addresses (I used 192.168.0.103,
>>> 192.168.0.104 and used "iptables -F" to let multicast messages
>>> through).
>>>
>>> Because clustering services are installed on-demand, they need some
>>> event to to start them, so I also deployed a small clustered web
>>> application.
>>>
>>> When I start both instances, no channels are started, as expected:
>>> $ ./standalone.sh --server-config standalone-ha.xml
>>> -Djboss.bind.address=192.168.0.103
>>> -Djboss.bind.address.management=192.168.0.103 -Djboss.node.name=A
>>> $ ./standalone.sh --server-config standalone-ha.xml
>>> -Djboss.bind.address=192.168.0.104
>>> -Djboss.bind.address.management=192.168.0.104 -Djboss.node.name=B
>>>
>>> When I deployed the clustered web app on each application server
>>> instance to trigger Infinispan web cache container and JGroups tcp
>>> channel startup, I saw for example, on the first host A:
>>>
>>> 18:58:41,086 INFO  [org.jboss.as.clustering.infinispan] (MSC service
>>> thread 1-8) JBAS010281: Started //default-host//my-clustered-webapp
>>> cache from web container
>>> 18:58:41,096 INFO  
>>> [org.infinispan.configuration.cache.EvictionConfigurationBuilder]
>>> (MSC service thread 1-8) ISPN000152: Passivation configured without
>>> an eviction policy being selected. Only manually evicted entities
>>> will be pasivated.
>>> 18:58:41,099 INFO  
>>> [org.infinispan.configuration.cache.EvictionConfigurationBuilder]
>>> (MSC service thread 1-8) ISPN000152: Passivation configured without
>>> an eviction policy being selected. Only manually evicted entities
>>> will be pasivated.
>>> 18:58:41,220 INFO  [org.jboss.web] (MSC service thread 1-8)
>>> JBAS018210: Registering web context: /my-clustered-webapp
>>> 18:58:41,230 INFO  [org.jboss.as.server] (Controller Boot Thread)
>>> JBAS018559: Deployed "my-clustered-webapp.war"
>>> 18:58:41,333 INFO  [org.jboss.as] (Controller Boot Thread)
>>> JBAS015951: Admin console listening on http://192.168.0.103:9990
>>> 18:58:41,334 INFO  [org.jboss.as] (Controller Boot Thread)
>>> JBAS015874: JBoss AS 7.1.1.Final-SNAPSHOT "Thunder" started in
>>> 6719ms - Started 175 of 305 services (129 services are passive or
>>> on-demand)
>>> 18:58:50,673 INFO  
>>> [org.jboss.as.clustering.impl.CoreGroupCommunicationService.lifecycle.web]
>>> (Incoming-1,null) JBAS010247: New cluster view for partition web
>>> (id: 1, delta: 1, merge: false) : [A/web, B/web]
>>> 18:58:50,687 INFO  
>>> [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
>>> (Incoming-1,null) ISPN000094: Received new cluster view: [A/web|1]
>>> [A/web, B/web]
>>>
>>> So, it seems as though things work as expected.
>>>
>>> I also tried to achieve the same effect by not deploying the web app
>>> and setting the attribute start="EAGER" on a clustered Infinispan
>>> cache (in this case, cache "repl" in the "web" cache container) to
>>> force them to start as active services. When the application servers
>>> were started this time, same result: clustering between the two
>>> nodes was visible.
>>>
>>> If I instead set the start="EAGER" attribute on a cache container,
>>> however, the channels do not get started automatically and I need to
>>> deploy a web app as before to trigger starting of the transport.
>>>
>>> So, are you using start=EAGER to start the cache instances, or
>>> deploying an app to trigger them? The organization of Infinispan
>>> services has changed a lot since 7.1.0. In particular, a cache
>>> container needs to specify the <transport/> element in order for a
>>> transport to be used.
>>>
>>> Richard
>>>
>>> On 03/14/2012 05:47 PM, Brian Stansberry wrote:
>>>> Hi Paul, Richard:
>>>>
>>>> Do you guys see anything wrong here?
>>>>
>>>> - Brian
>>>>
>>>> On 3/14/12 4:44 PM, William DeCoste wrote:
>>>>> Hi Brian,
>>>>>
>>>>> Has anything changed in the config of AS7.1 from 7.0.x? I am not
>>>>> seeing
>>>>> any jgroups traffic or discovery. This configuration worked fine in
>>>>> 7.0.x. When JGroups is loaded it just creates 2 1-node clusters. They
>>>>> don't seem to see each other or even be trying.
>>>>>
>>>>> Thanks -Bill
>>>>>
>>>>> <subsystem xmlns="urn:jboss:domain:jgroups:1.1" default-stack="tcp">
>>>>> <stack name="tcp">
>>>>> <transport type="TCP" socket-binding="jgroups-tcp"/>
>>>>> <protocol type="TCPPING">
>>>>> <property name="timeout">
>>>>> 3000
>>>>> </property>
>>>>> <property name="initial_hosts">
>>>>> 127.0.250.1[7600],127.0.251.1[7600]
>>>>> </property>
>>>>> <property name="port_range">
>>>>> 1
>>>>> </property>
>>>>> <property name="num_initial_members">
>>>>> 2
>>>>> </property>
>>>>> </protocol>
>>>>> <protocol type="MERGE2"/>
>>>>> <protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd"/>
>>>>> <protocol type="FD"/>
>>>>> <protocol type="VERIFY_SUSPECT"/>
>>>>> <protocol type="BARRIER"/>
>>>>> <protocol type="pbcast.NAKACK"/>
>>>>> <protocol type="UNICAST2"/>
>>>>> <protocol type="pbcast.STABLE"/>
>>>>> <protocol type="pbcast.GMS"/>
>>>>> <protocol type="UFC"/>
>>>>> <protocol type="MFC"/>
>>>>> <protocol type="FRAG2"/>
>>>>> </stack>
>>>>> </subsystem>
>>>>>
>>>>
>>>>
>>>
>>
>

--
Bill DeCoste
Principal Software Engineer, Red Hat
978-204-0920
[hidden email]

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: TCPPING in AS7

Richard Achmatowicz
Are you sure your multicast messages are getting through? Bela has a
utility called McastSendTest and McastReeceiverTest in the JGroups
distro which allows checking if the network is set up OK for multicast.

On 03/14/2012 08:21 PM, William DeCoste wrote:

> OK, that's what I thought - the 2 nodes aren't seeing each other.
> Thanks for confirming the config is ok. I never see any logging with a
> membership of more than one. And I never saw any change if I killed a
> node.
>
> On 3/14/12 5:18 PM, Richard Achmatowicz wrote:
>> On 03/14/2012 08:15 PM, William DeCoste wrote:
>>> Hi Richard,
>>>
>>> I'm also deploying a clustered web app which causes JGroups and the
>>> rest of clustering to load.
>>>
>>> Maybe this is just a change in logging. I am seeing the following
>>> with AS7.1.0:
>>> 2012/03/14 19:53:21,710 INFO  
>>> [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
>>> (pool-17-thread-1) ISPN000094: Received new cluster view:
>>> [ip-10-190-239-128/ejb|0] [ip-10-190-239-128/ejb]
>>>
>>> Does "[ip-10-190-239-128/ejb|0] [ip-10-190-239-128/ejb]" indicate 2
>>> nodes? This is on Express thus the strange node names.
>> One node. IIRC, the first element [ip-10-190-239-128/ejb|0] indicates
>> the host which triggered the view change, and the second element
>> [ip-10-190-239-128/ejb] is the new group membership.
>>>
>>> I'm used to seeing jgroups debug logging of the pings that isn't
>>> happening. Was definietly seeing different logging in 7.0.x.
>>>
>>> Thanks -Bill
>>>
>>> On 3/14/12 4:55 PM, Richard Achmatowicz wrote:
>>>> Hi Bill
>>>>
>>>> The configuration is valid. I tried it out on my local machine. I
>>>> set up two AS 7.1.1. instances, configured as you describe but
>>>> using a different set of IPv4 addresses (I used 192.168.0.103,
>>>> 192.168.0.104 and used "iptables -F" to let multicast messages
>>>> through).
>>>>
>>>> Because clustering services are installed on-demand, they need some
>>>> event to to start them, so I also deployed a small clustered web
>>>> application.
>>>>
>>>> When I start both instances, no channels are started, as expected:
>>>> $ ./standalone.sh --server-config standalone-ha.xml
>>>> -Djboss.bind.address=192.168.0.103
>>>> -Djboss.bind.address.management=192.168.0.103 -Djboss.node.name=A
>>>> $ ./standalone.sh --server-config standalone-ha.xml
>>>> -Djboss.bind.address=192.168.0.104
>>>> -Djboss.bind.address.management=192.168.0.104 -Djboss.node.name=B
>>>>
>>>> When I deployed the clustered web app on each application server
>>>> instance to trigger Infinispan web cache container and JGroups tcp
>>>> channel startup, I saw for example, on the first host A:
>>>>
>>>> 18:58:41,086 INFO  [org.jboss.as.clustering.infinispan] (MSC
>>>> service thread 1-8) JBAS010281: Started
>>>> //default-host//my-clustered-webapp cache from web container
>>>> 18:58:41,096 INFO  
>>>> [org.infinispan.configuration.cache.EvictionConfigurationBuilder]
>>>> (MSC service thread 1-8) ISPN000152: Passivation configured without
>>>> an eviction policy being selected. Only manually evicted entities
>>>> will be pasivated.
>>>> 18:58:41,099 INFO  
>>>> [org.infinispan.configuration.cache.EvictionConfigurationBuilder]
>>>> (MSC service thread 1-8) ISPN000152: Passivation configured without
>>>> an eviction policy being selected. Only manually evicted entities
>>>> will be pasivated.
>>>> 18:58:41,220 INFO  [org.jboss.web] (MSC service thread 1-8)
>>>> JBAS018210: Registering web context: /my-clustered-webapp
>>>> 18:58:41,230 INFO  [org.jboss.as.server] (Controller Boot Thread)
>>>> JBAS018559: Deployed "my-clustered-webapp.war"
>>>> 18:58:41,333 INFO  [org.jboss.as] (Controller Boot Thread)
>>>> JBAS015951: Admin console listening on http://192.168.0.103:9990
>>>> 18:58:41,334 INFO  [org.jboss.as] (Controller Boot Thread)
>>>> JBAS015874: JBoss AS 7.1.1.Final-SNAPSHOT "Thunder" started in
>>>> 6719ms - Started 175 of 305 services (129 services are passive or
>>>> on-demand)
>>>> 18:58:50,673 INFO  
>>>> [org.jboss.as.clustering.impl.CoreGroupCommunicationService.lifecycle.web]
>>>> (Incoming-1,null) JBAS010247: New cluster view for partition web
>>>> (id: 1, delta: 1, merge: false) : [A/web, B/web]
>>>> 18:58:50,687 INFO  
>>>> [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
>>>> (Incoming-1,null) ISPN000094: Received new cluster view: [A/web|1]
>>>> [A/web, B/web]
>>>>
>>>> So, it seems as though things work as expected.
>>>>
>>>> I also tried to achieve the same effect by not deploying the web
>>>> app and setting the attribute start="EAGER" on a clustered
>>>> Infinispan cache (in this case, cache "repl" in the "web" cache
>>>> container) to force them to start as active services. When the
>>>> application servers were started this time, same result: clustering
>>>> between the two nodes was visible.
>>>>
>>>> If I instead set the start="EAGER" attribute on a cache container,
>>>> however, the channels do not get started automatically and I need
>>>> to deploy a web app as before to trigger starting of the transport.
>>>>
>>>> So, are you using start=EAGER to start the cache instances, or
>>>> deploying an app to trigger them? The organization of Infinispan
>>>> services has changed a lot since 7.1.0. In particular, a cache
>>>> container needs to specify the <transport/> element in order for a
>>>> transport to be used.
>>>>
>>>> Richard
>>>>
>>>> On 03/14/2012 05:47 PM, Brian Stansberry wrote:
>>>>> Hi Paul, Richard:
>>>>>
>>>>> Do you guys see anything wrong here?
>>>>>
>>>>> - Brian
>>>>>
>>>>> On 3/14/12 4:44 PM, William DeCoste wrote:
>>>>>> Hi Brian,
>>>>>>
>>>>>> Has anything changed in the config of AS7.1 from 7.0.x? I am not
>>>>>> seeing
>>>>>> any jgroups traffic or discovery. This configuration worked fine in
>>>>>> 7.0.x. When JGroups is loaded it just creates 2 1-node clusters.
>>>>>> They
>>>>>> don't seem to see each other or even be trying.
>>>>>>
>>>>>> Thanks -Bill
>>>>>>
>>>>>> <subsystem xmlns="urn:jboss:domain:jgroups:1.1" default-stack="tcp">
>>>>>> <stack name="tcp">
>>>>>> <transport type="TCP" socket-binding="jgroups-tcp"/>
>>>>>> <protocol type="TCPPING">
>>>>>> <property name="timeout">
>>>>>> 3000
>>>>>> </property>
>>>>>> <property name="initial_hosts">
>>>>>> 127.0.250.1[7600],127.0.251.1[7600]
>>>>>> </property>
>>>>>> <property name="port_range">
>>>>>> 1
>>>>>> </property>
>>>>>> <property name="num_initial_members">
>>>>>> 2
>>>>>> </property>
>>>>>> </protocol>
>>>>>> <protocol type="MERGE2"/>
>>>>>> <protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd"/>
>>>>>> <protocol type="FD"/>
>>>>>> <protocol type="VERIFY_SUSPECT"/>
>>>>>> <protocol type="BARRIER"/>
>>>>>> <protocol type="pbcast.NAKACK"/>
>>>>>> <protocol type="UNICAST2"/>
>>>>>> <protocol type="pbcast.STABLE"/>
>>>>>> <protocol type="pbcast.GMS"/>
>>>>>> <protocol type="UFC"/>
>>>>>> <protocol type="MFC"/>
>>>>>> <protocol type="FRAG2"/>
>>>>>> </stack>
>>>>>> </subsystem>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: TCPPING in AS7

William DeCoste
There is no multicast - it's not supported in EC2. It's all point to
point TCP. Thus TCPPING. The was working in AS7.0.x. Maybe there's an
iptables issue that's preventing the 2 from seeing each other. Looking
into other causes.

Thanks -Bill

On 3/14/12 5:25 PM, Richard Achmatowicz wrote:

> Are you sure your multicast messages are getting through? Bela has a
> utility called McastSendTest and McastReeceiverTest in the JGroups
> distro which allows checking if the network is set up OK for multicast.
>
> On 03/14/2012 08:21 PM, William DeCoste wrote:
>> OK, that's what I thought - the 2 nodes aren't seeing each other.
>> Thanks for confirming the config is ok. I never see any logging with
>> a membership of more than one. And I never saw any change if I killed
>> a node.
>>
>> On 3/14/12 5:18 PM, Richard Achmatowicz wrote:
>>> On 03/14/2012 08:15 PM, William DeCoste wrote:
>>>> Hi Richard,
>>>>
>>>> I'm also deploying a clustered web app which causes JGroups and the
>>>> rest of clustering to load.
>>>>
>>>> Maybe this is just a change in logging. I am seeing the following
>>>> with AS7.1.0:
>>>> 2012/03/14 19:53:21,710 INFO  
>>>> [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
>>>> (pool-17-thread-1) ISPN000094: Received new cluster view:
>>>> [ip-10-190-239-128/ejb|0] [ip-10-190-239-128/ejb]
>>>>
>>>> Does "[ip-10-190-239-128/ejb|0] [ip-10-190-239-128/ejb]" indicate 2
>>>> nodes? This is on Express thus the strange node names.
>>> One node. IIRC, the first element [ip-10-190-239-128/ejb|0]
>>> indicates the host which triggered the view change, and the second
>>> element [ip-10-190-239-128/ejb] is the new group membership.
>>>>
>>>> I'm used to seeing jgroups debug logging of the pings that isn't
>>>> happening. Was definietly seeing different logging in 7.0.x.
>>>>
>>>> Thanks -Bill
>>>>
>>>> On 3/14/12 4:55 PM, Richard Achmatowicz wrote:
>>>>> Hi Bill
>>>>>
>>>>> The configuration is valid. I tried it out on my local machine. I
>>>>> set up two AS 7.1.1. instances, configured as you describe but
>>>>> using a different set of IPv4 addresses (I used 192.168.0.103,
>>>>> 192.168.0.104 and used "iptables -F" to let multicast messages
>>>>> through).
>>>>>
>>>>> Because clustering services are installed on-demand, they need
>>>>> some event to to start them, so I also deployed a small clustered
>>>>> web application.
>>>>>
>>>>> When I start both instances, no channels are started, as expected:
>>>>> $ ./standalone.sh --server-config standalone-ha.xml
>>>>> -Djboss.bind.address=192.168.0.103
>>>>> -Djboss.bind.address.management=192.168.0.103 -Djboss.node.name=A
>>>>> $ ./standalone.sh --server-config standalone-ha.xml
>>>>> -Djboss.bind.address=192.168.0.104
>>>>> -Djboss.bind.address.management=192.168.0.104 -Djboss.node.name=B
>>>>>
>>>>> When I deployed the clustered web app on each application server
>>>>> instance to trigger Infinispan web cache container and JGroups tcp
>>>>> channel startup, I saw for example, on the first host A:
>>>>>
>>>>> 18:58:41,086 INFO  [org.jboss.as.clustering.infinispan] (MSC
>>>>> service thread 1-8) JBAS010281: Started
>>>>> //default-host//my-clustered-webapp cache from web container
>>>>> 18:58:41,096 INFO  
>>>>> [org.infinispan.configuration.cache.EvictionConfigurationBuilder]
>>>>> (MSC service thread 1-8) ISPN000152: Passivation configured
>>>>> without an eviction policy being selected. Only manually evicted
>>>>> entities will be pasivated.
>>>>> 18:58:41,099 INFO  
>>>>> [org.infinispan.configuration.cache.EvictionConfigurationBuilder]
>>>>> (MSC service thread 1-8) ISPN000152: Passivation configured
>>>>> without an eviction policy being selected. Only manually evicted
>>>>> entities will be pasivated.
>>>>> 18:58:41,220 INFO  [org.jboss.web] (MSC service thread 1-8)
>>>>> JBAS018210: Registering web context: /my-clustered-webapp
>>>>> 18:58:41,230 INFO  [org.jboss.as.server] (Controller Boot Thread)
>>>>> JBAS018559: Deployed "my-clustered-webapp.war"
>>>>> 18:58:41,333 INFO  [org.jboss.as] (Controller Boot Thread)
>>>>> JBAS015951: Admin console listening on http://192.168.0.103:9990
>>>>> 18:58:41,334 INFO  [org.jboss.as] (Controller Boot Thread)
>>>>> JBAS015874: JBoss AS 7.1.1.Final-SNAPSHOT "Thunder" started in
>>>>> 6719ms - Started 175 of 305 services (129 services are passive or
>>>>> on-demand)
>>>>> 18:58:50,673 INFO  
>>>>> [org.jboss.as.clustering.impl.CoreGroupCommunicationService.lifecycle.web]
>>>>> (Incoming-1,null) JBAS010247: New cluster view for partition web
>>>>> (id: 1, delta: 1, merge: false) : [A/web, B/web]
>>>>> 18:58:50,687 INFO  
>>>>> [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
>>>>> (Incoming-1,null) ISPN000094: Received new cluster view: [A/web|1]
>>>>> [A/web, B/web]
>>>>>
>>>>> So, it seems as though things work as expected.
>>>>>
>>>>> I also tried to achieve the same effect by not deploying the web
>>>>> app and setting the attribute start="EAGER" on a clustered
>>>>> Infinispan cache (in this case, cache "repl" in the "web" cache
>>>>> container) to force them to start as active services. When the
>>>>> application servers were started this time, same result:
>>>>> clustering between the two nodes was visible.
>>>>>
>>>>> If I instead set the start="EAGER" attribute on a cache container,
>>>>> however, the channels do not get started automatically and I need
>>>>> to deploy a web app as before to trigger starting of the transport.
>>>>>
>>>>> So, are you using start=EAGER to start the cache instances, or
>>>>> deploying an app to trigger them? The organization of Infinispan
>>>>> services has changed a lot since 7.1.0. In particular, a cache
>>>>> container needs to specify the <transport/> element in order for a
>>>>> transport to be used.
>>>>>
>>>>> Richard
>>>>>
>>>>> On 03/14/2012 05:47 PM, Brian Stansberry wrote:
>>>>>> Hi Paul, Richard:
>>>>>>
>>>>>> Do you guys see anything wrong here?
>>>>>>
>>>>>> - Brian
>>>>>>
>>>>>> On 3/14/12 4:44 PM, William DeCoste wrote:
>>>>>>> Hi Brian,
>>>>>>>
>>>>>>> Has anything changed in the config of AS7.1 from 7.0.x? I am not
>>>>>>> seeing
>>>>>>> any jgroups traffic or discovery. This configuration worked fine in
>>>>>>> 7.0.x. When JGroups is loaded it just creates 2 1-node clusters.
>>>>>>> They
>>>>>>> don't seem to see each other or even be trying.
>>>>>>>
>>>>>>> Thanks -Bill
>>>>>>>
>>>>>>> <subsystem xmlns="urn:jboss:domain:jgroups:1.1"
>>>>>>> default-stack="tcp">
>>>>>>> <stack name="tcp">
>>>>>>> <transport type="TCP" socket-binding="jgroups-tcp"/>
>>>>>>> <protocol type="TCPPING">
>>>>>>> <property name="timeout">
>>>>>>> 3000
>>>>>>> </property>
>>>>>>> <property name="initial_hosts">
>>>>>>> 127.0.250.1[7600],127.0.251.1[7600]
>>>>>>> </property>
>>>>>>> <property name="port_range">
>>>>>>> 1
>>>>>>> </property>
>>>>>>> <property name="num_initial_members">
>>>>>>> 2
>>>>>>> </property>
>>>>>>> </protocol>
>>>>>>> <protocol type="MERGE2"/>
>>>>>>> <protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd"/>
>>>>>>> <protocol type="FD"/>
>>>>>>> <protocol type="VERIFY_SUSPECT"/>
>>>>>>> <protocol type="BARRIER"/>
>>>>>>> <protocol type="pbcast.NAKACK"/>
>>>>>>> <protocol type="UNICAST2"/>
>>>>>>> <protocol type="pbcast.STABLE"/>
>>>>>>> <protocol type="pbcast.GMS"/>
>>>>>>> <protocol type="UFC"/>
>>>>>>> <protocol type="MFC"/>
>>>>>>> <protocol type="FRAG2"/>
>>>>>>> </stack>
>>>>>>> </subsystem>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

--
Bill DeCoste
Principal Software Engineer, Red Hat
978-204-0920
[hidden email]

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: TCPPING in AS7

Richard Achmatowicz
Sorry. Brain malfunction.

On 03/14/2012 08:29 PM, William DeCoste wrote:

> There is no multicast - it's not supported in EC2. It's all point to
> point TCP. Thus TCPPING. The was working in AS7.0.x. Maybe there's an
> iptables issue that's preventing the 2 from seeing each other. Looking
> into other causes.
>
> Thanks -Bill
>
> On 3/14/12 5:25 PM, Richard Achmatowicz wrote:
>> Are you sure your multicast messages are getting through? Bela has a
>> utility called McastSendTest and McastReeceiverTest in the JGroups
>> distro which allows checking if the network is set up OK for multicast.
>>
>> On 03/14/2012 08:21 PM, William DeCoste wrote:
>>> OK, that's what I thought - the 2 nodes aren't seeing each other.
>>> Thanks for confirming the config is ok. I never see any logging with
>>> a membership of more than one. And I never saw any change if I
>>> killed a node.
>>>
>>> On 3/14/12 5:18 PM, Richard Achmatowicz wrote:
>>>> On 03/14/2012 08:15 PM, William DeCoste wrote:
>>>>> Hi Richard,
>>>>>
>>>>> I'm also deploying a clustered web app which causes JGroups and
>>>>> the rest of clustering to load.
>>>>>
>>>>> Maybe this is just a change in logging. I am seeing the following
>>>>> with AS7.1.0:
>>>>> 2012/03/14 19:53:21,710 INFO  
>>>>> [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
>>>>> (pool-17-thread-1) ISPN000094: Received new cluster view:
>>>>> [ip-10-190-239-128/ejb|0] [ip-10-190-239-128/ejb]
>>>>>
>>>>> Does "[ip-10-190-239-128/ejb|0] [ip-10-190-239-128/ejb]" indicate
>>>>> 2 nodes? This is on Express thus the strange node names.
>>>> One node. IIRC, the first element [ip-10-190-239-128/ejb|0]
>>>> indicates the host which triggered the view change, and the second
>>>> element [ip-10-190-239-128/ejb] is the new group membership.
>>>>>
>>>>> I'm used to seeing jgroups debug logging of the pings that isn't
>>>>> happening. Was definietly seeing different logging in 7.0.x.
>>>>>
>>>>> Thanks -Bill
>>>>>
>>>>> On 3/14/12 4:55 PM, Richard Achmatowicz wrote:
>>>>>> Hi Bill
>>>>>>
>>>>>> The configuration is valid. I tried it out on my local machine. I
>>>>>> set up two AS 7.1.1. instances, configured as you describe but
>>>>>> using a different set of IPv4 addresses (I used 192.168.0.103,
>>>>>> 192.168.0.104 and used "iptables -F" to let multicast messages
>>>>>> through).
>>>>>>
>>>>>> Because clustering services are installed on-demand, they need
>>>>>> some event to to start them, so I also deployed a small clustered
>>>>>> web application.
>>>>>>
>>>>>> When I start both instances, no channels are started, as expected:
>>>>>> $ ./standalone.sh --server-config standalone-ha.xml
>>>>>> -Djboss.bind.address=192.168.0.103
>>>>>> -Djboss.bind.address.management=192.168.0.103 -Djboss.node.name=A
>>>>>> $ ./standalone.sh --server-config standalone-ha.xml
>>>>>> -Djboss.bind.address=192.168.0.104
>>>>>> -Djboss.bind.address.management=192.168.0.104 -Djboss.node.name=B
>>>>>>
>>>>>> When I deployed the clustered web app on each application server
>>>>>> instance to trigger Infinispan web cache container and JGroups
>>>>>> tcp channel startup, I saw for example, on the first host A:
>>>>>>
>>>>>> 18:58:41,086 INFO  [org.jboss.as.clustering.infinispan] (MSC
>>>>>> service thread 1-8) JBAS010281: Started
>>>>>> //default-host//my-clustered-webapp cache from web container
>>>>>> 18:58:41,096 INFO  
>>>>>> [org.infinispan.configuration.cache.EvictionConfigurationBuilder]
>>>>>> (MSC service thread 1-8) ISPN000152: Passivation configured
>>>>>> without an eviction policy being selected. Only manually evicted
>>>>>> entities will be pasivated.
>>>>>> 18:58:41,099 INFO  
>>>>>> [org.infinispan.configuration.cache.EvictionConfigurationBuilder]
>>>>>> (MSC service thread 1-8) ISPN000152: Passivation configured
>>>>>> without an eviction policy being selected. Only manually evicted
>>>>>> entities will be pasivated.
>>>>>> 18:58:41,220 INFO  [org.jboss.web] (MSC service thread 1-8)
>>>>>> JBAS018210: Registering web context: /my-clustered-webapp
>>>>>> 18:58:41,230 INFO  [org.jboss.as.server] (Controller Boot Thread)
>>>>>> JBAS018559: Deployed "my-clustered-webapp.war"
>>>>>> 18:58:41,333 INFO  [org.jboss.as] (Controller Boot Thread)
>>>>>> JBAS015951: Admin console listening on http://192.168.0.103:9990
>>>>>> 18:58:41,334 INFO  [org.jboss.as] (Controller Boot Thread)
>>>>>> JBAS015874: JBoss AS 7.1.1.Final-SNAPSHOT "Thunder" started in
>>>>>> 6719ms - Started 175 of 305 services (129 services are passive or
>>>>>> on-demand)
>>>>>> 18:58:50,673 INFO  
>>>>>> [org.jboss.as.clustering.impl.CoreGroupCommunicationService.lifecycle.web]
>>>>>> (Incoming-1,null) JBAS010247: New cluster view for partition web
>>>>>> (id: 1, delta: 1, merge: false) : [A/web, B/web]
>>>>>> 18:58:50,687 INFO  
>>>>>> [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
>>>>>> (Incoming-1,null) ISPN000094: Received new cluster view:
>>>>>> [A/web|1] [A/web, B/web]
>>>>>>
>>>>>> So, it seems as though things work as expected.
>>>>>>
>>>>>> I also tried to achieve the same effect by not deploying the web
>>>>>> app and setting the attribute start="EAGER" on a clustered
>>>>>> Infinispan cache (in this case, cache "repl" in the "web" cache
>>>>>> container) to force them to start as active services. When the
>>>>>> application servers were started this time, same result:
>>>>>> clustering between the two nodes was visible.
>>>>>>
>>>>>> If I instead set the start="EAGER" attribute on a cache
>>>>>> container, however, the channels do not get started automatically
>>>>>> and I need to deploy a web app as before to trigger starting of
>>>>>> the transport.
>>>>>>
>>>>>> So, are you using start=EAGER to start the cache instances, or
>>>>>> deploying an app to trigger them? The organization of Infinispan
>>>>>> services has changed a lot since 7.1.0. In particular, a cache
>>>>>> container needs to specify the <transport/> element in order for
>>>>>> a transport to be used.
>>>>>>
>>>>>> Richard
>>>>>>
>>>>>> On 03/14/2012 05:47 PM, Brian Stansberry wrote:
>>>>>>> Hi Paul, Richard:
>>>>>>>
>>>>>>> Do you guys see anything wrong here?
>>>>>>>
>>>>>>> - Brian
>>>>>>>
>>>>>>> On 3/14/12 4:44 PM, William DeCoste wrote:
>>>>>>>> Hi Brian,
>>>>>>>>
>>>>>>>> Has anything changed in the config of AS7.1 from 7.0.x? I am
>>>>>>>> not seeing
>>>>>>>> any jgroups traffic or discovery. This configuration worked
>>>>>>>> fine in
>>>>>>>> 7.0.x. When JGroups is loaded it just creates 2 1-node
>>>>>>>> clusters. They
>>>>>>>> don't seem to see each other or even be trying.
>>>>>>>>
>>>>>>>> Thanks -Bill
>>>>>>>>
>>>>>>>> <subsystem xmlns="urn:jboss:domain:jgroups:1.1"
>>>>>>>> default-stack="tcp">
>>>>>>>> <stack name="tcp">
>>>>>>>> <transport type="TCP" socket-binding="jgroups-tcp"/>
>>>>>>>> <protocol type="TCPPING">
>>>>>>>> <property name="timeout">
>>>>>>>> 3000
>>>>>>>> </property>
>>>>>>>> <property name="initial_hosts">
>>>>>>>> 127.0.250.1[7600],127.0.251.1[7600]
>>>>>>>> </property>
>>>>>>>> <property name="port_range">
>>>>>>>> 1
>>>>>>>> </property>
>>>>>>>> <property name="num_initial_members">
>>>>>>>> 2
>>>>>>>> </property>
>>>>>>>> </protocol>
>>>>>>>> <protocol type="MERGE2"/>
>>>>>>>> <protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd"/>
>>>>>>>> <protocol type="FD"/>
>>>>>>>> <protocol type="VERIFY_SUSPECT"/>
>>>>>>>> <protocol type="BARRIER"/>
>>>>>>>> <protocol type="pbcast.NAKACK"/>
>>>>>>>> <protocol type="UNICAST2"/>
>>>>>>>> <protocol type="pbcast.STABLE"/>
>>>>>>>> <protocol type="pbcast.GMS"/>
>>>>>>>> <protocol type="UFC"/>
>>>>>>>> <protocol type="MFC"/>
>>>>>>>> <protocol type="FRAG2"/>
>>>>>>>> </stack>
>>>>>>>> </subsystem>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: TCPPING in AS7

William DeCoste
Frack, it sure is iptables. Thanks for your help!

On 3/14/12 5:30 PM, Richard Achmatowicz wrote:

> Sorry. Brain malfunction.
>
> On 03/14/2012 08:29 PM, William DeCoste wrote:
>> There is no multicast - it's not supported in EC2. It's all point to
>> point TCP. Thus TCPPING. The was working in AS7.0.x. Maybe there's an
>> iptables issue that's preventing the 2 from seeing each other.
>> Looking into other causes.
>>
>> Thanks -Bill
>>
>> On 3/14/12 5:25 PM, Richard Achmatowicz wrote:
>>> Are you sure your multicast messages are getting through? Bela has a
>>> utility called McastSendTest and McastReeceiverTest in the JGroups
>>> distro which allows checking if the network is set up OK for multicast.
>>>
>>> On 03/14/2012 08:21 PM, William DeCoste wrote:
>>>> OK, that's what I thought - the 2 nodes aren't seeing each other.
>>>> Thanks for confirming the config is ok. I never see any logging
>>>> with a membership of more than one. And I never saw any change if I
>>>> killed a node.
>>>>
>>>> On 3/14/12 5:18 PM, Richard Achmatowicz wrote:
>>>>> On 03/14/2012 08:15 PM, William DeCoste wrote:
>>>>>> Hi Richard,
>>>>>>
>>>>>> I'm also deploying a clustered web app which causes JGroups and
>>>>>> the rest of clustering to load.
>>>>>>
>>>>>> Maybe this is just a change in logging. I am seeing the following
>>>>>> with AS7.1.0:
>>>>>> 2012/03/14 19:53:21,710 INFO  
>>>>>> [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
>>>>>> (pool-17-thread-1) ISPN000094: Received new cluster view:
>>>>>> [ip-10-190-239-128/ejb|0] [ip-10-190-239-128/ejb]
>>>>>>
>>>>>> Does "[ip-10-190-239-128/ejb|0] [ip-10-190-239-128/ejb]" indicate
>>>>>> 2 nodes? This is on Express thus the strange node names.
>>>>> One node. IIRC, the first element [ip-10-190-239-128/ejb|0]
>>>>> indicates the host which triggered the view change, and the second
>>>>> element [ip-10-190-239-128/ejb] is the new group membership.
>>>>>>
>>>>>> I'm used to seeing jgroups debug logging of the pings that isn't
>>>>>> happening. Was definietly seeing different logging in 7.0.x.
>>>>>>
>>>>>> Thanks -Bill
>>>>>>
>>>>>> On 3/14/12 4:55 PM, Richard Achmatowicz wrote:
>>>>>>> Hi Bill
>>>>>>>
>>>>>>> The configuration is valid. I tried it out on my local machine.
>>>>>>> I set up two AS 7.1.1. instances, configured as you describe but
>>>>>>> using a different set of IPv4 addresses (I used 192.168.0.103,
>>>>>>> 192.168.0.104 and used "iptables -F" to let multicast messages
>>>>>>> through).
>>>>>>>
>>>>>>> Because clustering services are installed on-demand, they need
>>>>>>> some event to to start them, so I also deployed a small
>>>>>>> clustered web application.
>>>>>>>
>>>>>>> When I start both instances, no channels are started, as expected:
>>>>>>> $ ./standalone.sh --server-config standalone-ha.xml
>>>>>>> -Djboss.bind.address=192.168.0.103
>>>>>>> -Djboss.bind.address.management=192.168.0.103 -Djboss.node.name=A
>>>>>>> $ ./standalone.sh --server-config standalone-ha.xml
>>>>>>> -Djboss.bind.address=192.168.0.104
>>>>>>> -Djboss.bind.address.management=192.168.0.104 -Djboss.node.name=B
>>>>>>>
>>>>>>> When I deployed the clustered web app on each application server
>>>>>>> instance to trigger Infinispan web cache container and JGroups
>>>>>>> tcp channel startup, I saw for example, on the first host A:
>>>>>>>
>>>>>>> 18:58:41,086 INFO  [org.jboss.as.clustering.infinispan] (MSC
>>>>>>> service thread 1-8) JBAS010281: Started
>>>>>>> //default-host//my-clustered-webapp cache from web container
>>>>>>> 18:58:41,096 INFO  
>>>>>>> [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (MSC
>>>>>>> service thread 1-8) ISPN000152: Passivation configured without
>>>>>>> an eviction policy being selected. Only manually evicted
>>>>>>> entities will be pasivated.
>>>>>>> 18:58:41,099 INFO  
>>>>>>> [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (MSC
>>>>>>> service thread 1-8) ISPN000152: Passivation configured without
>>>>>>> an eviction policy being selected. Only manually evicted
>>>>>>> entities will be pasivated.
>>>>>>> 18:58:41,220 INFO  [org.jboss.web] (MSC service thread 1-8)
>>>>>>> JBAS018210: Registering web context: /my-clustered-webapp
>>>>>>> 18:58:41,230 INFO  [org.jboss.as.server] (Controller Boot
>>>>>>> Thread) JBAS018559: Deployed "my-clustered-webapp.war"
>>>>>>> 18:58:41,333 INFO  [org.jboss.as] (Controller Boot Thread)
>>>>>>> JBAS015951: Admin console listening on http://192.168.0.103:9990
>>>>>>> 18:58:41,334 INFO  [org.jboss.as] (Controller Boot Thread)
>>>>>>> JBAS015874: JBoss AS 7.1.1.Final-SNAPSHOT "Thunder" started in
>>>>>>> 6719ms - Started 175 of 305 services (129 services are passive
>>>>>>> or on-demand)
>>>>>>> 18:58:50,673 INFO  
>>>>>>> [org.jboss.as.clustering.impl.CoreGroupCommunicationService.lifecycle.web]
>>>>>>> (Incoming-1,null) JBAS010247: New cluster view for partition web
>>>>>>> (id: 1, delta: 1, merge: false) : [A/web, B/web]
>>>>>>> 18:58:50,687 INFO  
>>>>>>> [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
>>>>>>> (Incoming-1,null) ISPN000094: Received new cluster view:
>>>>>>> [A/web|1] [A/web, B/web]
>>>>>>>
>>>>>>> So, it seems as though things work as expected.
>>>>>>>
>>>>>>> I also tried to achieve the same effect by not deploying the web
>>>>>>> app and setting the attribute start="EAGER" on a clustered
>>>>>>> Infinispan cache (in this case, cache "repl" in the "web" cache
>>>>>>> container) to force them to start as active services. When the
>>>>>>> application servers were started this time, same result:
>>>>>>> clustering between the two nodes was visible.
>>>>>>>
>>>>>>> If I instead set the start="EAGER" attribute on a cache
>>>>>>> container, however, the channels do not get started
>>>>>>> automatically and I need to deploy a web app as before to
>>>>>>> trigger starting of the transport.
>>>>>>>
>>>>>>> So, are you using start=EAGER to start the cache instances, or
>>>>>>> deploying an app to trigger them? The organization of Infinispan
>>>>>>> services has changed a lot since 7.1.0. In particular, a cache
>>>>>>> container needs to specify the <transport/> element in order for
>>>>>>> a transport to be used.
>>>>>>>
>>>>>>> Richard
>>>>>>>
>>>>>>> On 03/14/2012 05:47 PM, Brian Stansberry wrote:
>>>>>>>> Hi Paul, Richard:
>>>>>>>>
>>>>>>>> Do you guys see anything wrong here?
>>>>>>>>
>>>>>>>> - Brian
>>>>>>>>
>>>>>>>> On 3/14/12 4:44 PM, William DeCoste wrote:
>>>>>>>>> Hi Brian,
>>>>>>>>>
>>>>>>>>> Has anything changed in the config of AS7.1 from 7.0.x? I am
>>>>>>>>> not seeing
>>>>>>>>> any jgroups traffic or discovery. This configuration worked
>>>>>>>>> fine in
>>>>>>>>> 7.0.x. When JGroups is loaded it just creates 2 1-node
>>>>>>>>> clusters. They
>>>>>>>>> don't seem to see each other or even be trying.
>>>>>>>>>
>>>>>>>>> Thanks -Bill
>>>>>>>>>
>>>>>>>>> <subsystem xmlns="urn:jboss:domain:jgroups:1.1"
>>>>>>>>> default-stack="tcp">
>>>>>>>>> <stack name="tcp">
>>>>>>>>> <transport type="TCP" socket-binding="jgroups-tcp"/>
>>>>>>>>> <protocol type="TCPPING">
>>>>>>>>> <property name="timeout">
>>>>>>>>> 3000
>>>>>>>>> </property>
>>>>>>>>> <property name="initial_hosts">
>>>>>>>>> 127.0.250.1[7600],127.0.251.1[7600]
>>>>>>>>> </property>
>>>>>>>>> <property name="port_range">
>>>>>>>>> 1
>>>>>>>>> </property>
>>>>>>>>> <property name="num_initial_members">
>>>>>>>>> 2
>>>>>>>>> </property>
>>>>>>>>> </protocol>
>>>>>>>>> <protocol type="MERGE2"/>
>>>>>>>>> <protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd"/>
>>>>>>>>> <protocol type="FD"/>
>>>>>>>>> <protocol type="VERIFY_SUSPECT"/>
>>>>>>>>> <protocol type="BARRIER"/>
>>>>>>>>> <protocol type="pbcast.NAKACK"/>
>>>>>>>>> <protocol type="UNICAST2"/>
>>>>>>>>> <protocol type="pbcast.STABLE"/>
>>>>>>>>> <protocol type="pbcast.GMS"/>
>>>>>>>>> <protocol type="UFC"/>
>>>>>>>>> <protocol type="MFC"/>
>>>>>>>>> <protocol type="FRAG2"/>
>>>>>>>>> </stack>
>>>>>>>>> </subsystem>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

--
Bill DeCoste
Principal Software Engineer, Red Hat
978-204-0920
[hidden email]

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: TCPPING in AS7

William DeCoste
In reply to this post by Richard Achmatowicz
Frack, it sure is iptables. Thanks for your help!

On 3/14/12 5:30 PM, Richard Achmatowicz wrote:

> Sorry. Brain malfunction.
>
> On 03/14/2012 08:29 PM, William DeCoste wrote:
>> There is no multicast - it's not supported in EC2. It's all point to
>> point TCP. Thus TCPPING. The was working in AS7.0.x. Maybe there's an
>> iptables issue that's preventing the 2 from seeing each other.
>> Looking into other causes.
>>
>> Thanks -Bill
>>
>> On 3/14/12 5:25 PM, Richard Achmatowicz wrote:
>>> Are you sure your multicast messages are getting through? Bela has a
>>> utility called McastSendTest and McastReeceiverTest in the JGroups
>>> distro which allows checking if the network is set up OK for multicast.
>>>
>>> On 03/14/2012 08:21 PM, William DeCoste wrote:
>>>> OK, that's what I thought - the 2 nodes aren't seeing each other.
>>>> Thanks for confirming the config is ok. I never see any logging
>>>> with a membership of more than one. And I never saw any change if I
>>>> killed a node.
>>>>
>>>> On 3/14/12 5:18 PM, Richard Achmatowicz wrote:
>>>>> On 03/14/2012 08:15 PM, William DeCoste wrote:
>>>>>> Hi Richard,
>>>>>>
>>>>>> I'm also deploying a clustered web app which causes JGroups and
>>>>>> the rest of clustering to load.
>>>>>>
>>>>>> Maybe this is just a change in logging. I am seeing the following
>>>>>> with AS7.1.0:
>>>>>> 2012/03/14 19:53:21,710 INFO  
>>>>>> [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
>>>>>> (pool-17-thread-1) ISPN000094: Received new cluster view:
>>>>>> [ip-10-190-239-128/ejb|0] [ip-10-190-239-128/ejb]
>>>>>>
>>>>>> Does "[ip-10-190-239-128/ejb|0] [ip-10-190-239-128/ejb]" indicate
>>>>>> 2 nodes? This is on Express thus the strange node names.
>>>>> One node. IIRC, the first element [ip-10-190-239-128/ejb|0]
>>>>> indicates the host which triggered the view change, and the second
>>>>> element [ip-10-190-239-128/ejb] is the new group membership.
>>>>>>
>>>>>> I'm used to seeing jgroups debug logging of the pings that isn't
>>>>>> happening. Was definietly seeing different logging in 7.0.x.
>>>>>>
>>>>>> Thanks -Bill
>>>>>>
>>>>>> On 3/14/12 4:55 PM, Richard Achmatowicz wrote:
>>>>>>> Hi Bill
>>>>>>>
>>>>>>> The configuration is valid. I tried it out on my local machine.
>>>>>>> I set up two AS 7.1.1. instances, configured as you describe but
>>>>>>> using a different set of IPv4 addresses (I used 192.168.0.103,
>>>>>>> 192.168.0.104 and used "iptables -F" to let multicast messages
>>>>>>> through).
>>>>>>>
>>>>>>> Because clustering services are installed on-demand, they need
>>>>>>> some event to to start them, so I also deployed a small
>>>>>>> clustered web application.
>>>>>>>
>>>>>>> When I start both instances, no channels are started, as expected:
>>>>>>> $ ./standalone.sh --server-config standalone-ha.xml
>>>>>>> -Djboss.bind.address=192.168.0.103
>>>>>>> -Djboss.bind.address.management=192.168.0.103 -Djboss.node.name=A
>>>>>>> $ ./standalone.sh --server-config standalone-ha.xml
>>>>>>> -Djboss.bind.address=192.168.0.104
>>>>>>> -Djboss.bind.address.management=192.168.0.104 -Djboss.node.name=B
>>>>>>>
>>>>>>> When I deployed the clustered web app on each application server
>>>>>>> instance to trigger Infinispan web cache container and JGroups
>>>>>>> tcp channel startup, I saw for example, on the first host A:
>>>>>>>
>>>>>>> 18:58:41,086 INFO  [org.jboss.as.clustering.infinispan] (MSC
>>>>>>> service thread 1-8) JBAS010281: Started
>>>>>>> //default-host//my-clustered-webapp cache from web container
>>>>>>> 18:58:41,096 INFO  
>>>>>>> [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (MSC
>>>>>>> service thread 1-8) ISPN000152: Passivation configured without
>>>>>>> an eviction policy being selected. Only manually evicted
>>>>>>> entities will be pasivated.
>>>>>>> 18:58:41,099 INFO  
>>>>>>> [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (MSC
>>>>>>> service thread 1-8) ISPN000152: Passivation configured without
>>>>>>> an eviction policy being selected. Only manually evicted
>>>>>>> entities will be pasivated.
>>>>>>> 18:58:41,220 INFO  [org.jboss.web] (MSC service thread 1-8)
>>>>>>> JBAS018210: Registering web context: /my-clustered-webapp
>>>>>>> 18:58:41,230 INFO  [org.jboss.as.server] (Controller Boot
>>>>>>> Thread) JBAS018559: Deployed "my-clustered-webapp.war"
>>>>>>> 18:58:41,333 INFO  [org.jboss.as] (Controller Boot Thread)
>>>>>>> JBAS015951: Admin console listening on http://192.168.0.103:9990
>>>>>>> 18:58:41,334 INFO  [org.jboss.as] (Controller Boot Thread)
>>>>>>> JBAS015874: JBoss AS 7.1.1.Final-SNAPSHOT "Thunder" started in
>>>>>>> 6719ms - Started 175 of 305 services (129 services are passive
>>>>>>> or on-demand)
>>>>>>> 18:58:50,673 INFO  
>>>>>>> [org.jboss.as.clustering.impl.CoreGroupCommunicationService.lifecycle.web]
>>>>>>> (Incoming-1,null) JBAS010247: New cluster view for partition web
>>>>>>> (id: 1, delta: 1, merge: false) : [A/web, B/web]
>>>>>>> 18:58:50,687 INFO  
>>>>>>> [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
>>>>>>> (Incoming-1,null) ISPN000094: Received new cluster view:
>>>>>>> [A/web|1] [A/web, B/web]
>>>>>>>
>>>>>>> So, it seems as though things work as expected.
>>>>>>>
>>>>>>> I also tried to achieve the same effect by not deploying the web
>>>>>>> app and setting the attribute start="EAGER" on a clustered
>>>>>>> Infinispan cache (in this case, cache "repl" in the "web" cache
>>>>>>> container) to force them to start as active services. When the
>>>>>>> application servers were started this time, same result:
>>>>>>> clustering between the two nodes was visible.
>>>>>>>
>>>>>>> If I instead set the start="EAGER" attribute on a cache
>>>>>>> container, however, the channels do not get started
>>>>>>> automatically and I need to deploy a web app as before to
>>>>>>> trigger starting of the transport.
>>>>>>>
>>>>>>> So, are you using start=EAGER to start the cache instances, or
>>>>>>> deploying an app to trigger them? The organization of Infinispan
>>>>>>> services has changed a lot since 7.1.0. In particular, a cache
>>>>>>> container needs to specify the <transport/> element in order for
>>>>>>> a transport to be used.
>>>>>>>
>>>>>>> Richard
>>>>>>>
>>>>>>> On 03/14/2012 05:47 PM, Brian Stansberry wrote:
>>>>>>>> Hi Paul, Richard:
>>>>>>>>
>>>>>>>> Do you guys see anything wrong here?
>>>>>>>>
>>>>>>>> - Brian
>>>>>>>>
>>>>>>>> On 3/14/12 4:44 PM, William DeCoste wrote:
>>>>>>>>> Hi Brian,
>>>>>>>>>
>>>>>>>>> Has anything changed in the config of AS7.1 from 7.0.x? I am
>>>>>>>>> not seeing
>>>>>>>>> any jgroups traffic or discovery. This configuration worked
>>>>>>>>> fine in
>>>>>>>>> 7.0.x. When JGroups is loaded it just creates 2 1-node
>>>>>>>>> clusters. They
>>>>>>>>> don't seem to see each other or even be trying.
>>>>>>>>>
>>>>>>>>> Thanks -Bill
>>>>>>>>>
>>>>>>>>> <subsystem xmlns="urn:jboss:domain:jgroups:1.1"
>>>>>>>>> default-stack="tcp">
>>>>>>>>> <stack name="tcp">
>>>>>>>>> <transport type="TCP" socket-binding="jgroups-tcp"/>
>>>>>>>>> <protocol type="TCPPING">
>>>>>>>>> <property name="timeout">
>>>>>>>>> 3000
>>>>>>>>> </property>
>>>>>>>>> <property name="initial_hosts">
>>>>>>>>> 127.0.250.1[7600],127.0.251.1[7600]
>>>>>>>>> </property>
>>>>>>>>> <property name="port_range">
>>>>>>>>> 1
>>>>>>>>> </property>
>>>>>>>>> <property name="num_initial_members">
>>>>>>>>> 2
>>>>>>>>> </property>
>>>>>>>>> </protocol>
>>>>>>>>> <protocol type="MERGE2"/>
>>>>>>>>> <protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd"/>
>>>>>>>>> <protocol type="FD"/>
>>>>>>>>> <protocol type="VERIFY_SUSPECT"/>
>>>>>>>>> <protocol type="BARRIER"/>
>>>>>>>>> <protocol type="pbcast.NAKACK"/>
>>>>>>>>> <protocol type="UNICAST2"/>
>>>>>>>>> <protocol type="pbcast.STABLE"/>
>>>>>>>>> <protocol type="pbcast.GMS"/>
>>>>>>>>> <protocol type="UFC"/>
>>>>>>>>> <protocol type="MFC"/>
>>>>>>>>> <protocol type="FRAG2"/>
>>>>>>>>> </stack>
>>>>>>>>> </subsystem>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

--
Bill DeCoste
Principal Software Engineer, Red Hat
978-204-0920
[hidden email]

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: TCPPING in AS7

Paul Ferraro
In reply to this post by Richard Achmatowicz
On 14/03/12 19:55, Richard Achmatowicz wrote:

> Hi Bill
>
> The configuration is valid. I tried it out on my local machine. I set up
> two AS 7.1.1. instances, configured as you describe but using a
> different set of IPv4 addresses (I used 192.168.0.103, 192.168.0.104 and
> used "iptables -F" to let multicast messages through).
>
> Because clustering services are installed on-demand, they need some
> event to to start them, so I also deployed a small clustered web
> application.
>
> When I start both instances, no channels are started, as expected:
> $ ./standalone.sh --server-config standalone-ha.xml
> -Djboss.bind.address=192.168.0.103
> -Djboss.bind.address.management=192.168.0.103 -Djboss.node.name=A
> $ ./standalone.sh --server-config standalone-ha.xml
> -Djboss.bind.address=192.168.0.104
> -Djboss.bind.address.management=192.168.0.104 -Djboss.node.name=B
>
> When I deployed the clustered web app on each application server
> instance to trigger Infinispan web cache container and JGroups tcp
> channel startup, I saw for example, on the first host A:
>
> 18:58:41,086 INFO [org.jboss.as.clustering.infinispan] (MSC service
> thread 1-8) JBAS010281: Started //default-host//my-clustered-webapp
> cache from web container
> 18:58:41,096 INFO
> [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (MSC
> service thread 1-8) ISPN000152: Passivation configured without an
> eviction policy being selected. Only manually evicted entities will be
> pasivated.
> 18:58:41,099 INFO
> [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (MSC
> service thread 1-8) ISPN000152: Passivation configured without an
> eviction policy being selected. Only manually evicted entities will be
> pasivated.
> 18:58:41,220 INFO [org.jboss.web] (MSC service thread 1-8) JBAS018210:
> Registering web context: /my-clustered-webapp
> 18:58:41,230 INFO [org.jboss.as.server] (Controller Boot Thread)
> JBAS018559: Deployed "my-clustered-webapp.war"
> 18:58:41,333 INFO [org.jboss.as] (Controller Boot Thread) JBAS015951:
> Admin console listening on http://192.168.0.103:9990
> 18:58:41,334 INFO [org.jboss.as] (Controller Boot Thread) JBAS015874:
> JBoss AS 7.1.1.Final-SNAPSHOT "Thunder" started in 6719ms - Started 175
> of 305 services (129 services are passive or on-demand)
> 18:58:50,673 INFO
> [org.jboss.as.clustering.impl.CoreGroupCommunicationService.lifecycle.web]
> (Incoming-1,null) JBAS010247: New cluster view for partition web (id: 1,
> delta: 1, merge: false) : [A/web, B/web]
> 18:58:50,687 INFO
> [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> (Incoming-1,null) ISPN000094: Received new cluster view: [A/web|1]
> [A/web, B/web]
>
> So, it seems as though things work as expected.
>
> I also tried to achieve the same effect by not deploying the web app and
> setting the attribute start="EAGER" on a clustered Infinispan cache (in
> this case, cache "repl" in the "web" cache container) to force them to
> start as active services. When the application servers were started this
> time, same result: clustering between the two nodes was visible.

Just to clarify...
Starting a cache container eagerly will only start the cache manager,
not its channel.  The cache container's channel is started only when the
1st non-local cache is started.  To have a channel connect on server
startup, you'll want to eagerly start a non-local cache (via start="EAGER").

> If I instead set the start="EAGER" attribute on a cache container,
> however, the channels do not get started automatically and I need to
> deploy a web app as before to trigger starting of the transport.
>
> So, are you using start=EAGER to start the cache instances, or deploying
> an app to trigger them? The organization of Infinispan services has
> changed a lot since 7.1.0. In particular, a cache container needs to
> specify the <transport/> element in order for a transport to be used.
>
> Richard
>
> On 03/14/2012 05:47 PM, Brian Stansberry wrote:
>> Hi Paul, Richard:
>>
>> Do you guys see anything wrong here?
>>
>> - Brian
>>
>> On 3/14/12 4:44 PM, William DeCoste wrote:
>>> Hi Brian,
>>>
>>> Has anything changed in the config of AS7.1 from 7.0.x? I am not seeing
>>> any jgroups traffic or discovery. This configuration worked fine in
>>> 7.0.x. When JGroups is loaded it just creates 2 1-node clusters. They
>>> don't seem to see each other or even be trying.
>>>
>>> Thanks -Bill
>>>
>>> <subsystem xmlns="urn:jboss:domain:jgroups:1.1" default-stack="tcp">
>>> <stack name="tcp">
>>> <transport type="TCP" socket-binding="jgroups-tcp"/>
>>> <protocol type="TCPPING">
>>> <property name="timeout">
>>> 3000
>>> </property>
>>> <property name="initial_hosts">
>>> 127.0.250.1[7600],127.0.251.1[7600]
>>> </property>
>>> <property name="port_range">
>>> 1
>>> </property>
>>> <property name="num_initial_members">
>>> 2
>>> </property>
>>> </protocol>
>>> <protocol type="MERGE2"/>
>>> <protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd"/>
>>> <protocol type="FD"/>
>>> <protocol type="VERIFY_SUSPECT"/>
>>> <protocol type="BARRIER"/>
>>> <protocol type="pbcast.NAKACK"/>
>>> <protocol type="UNICAST2"/>
>>> <protocol type="pbcast.STABLE"/>
>>> <protocol type="pbcast.GMS"/>
>>> <protocol type="UFC"/>
>>> <protocol type="MFC"/>
>>> <protocol type="FRAG2"/>
>>> </stack>
>>> </subsystem>
>>>
>>
>>
>

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: TCPPING in AS7

kkhan
In reply to this post by Richard Achmatowicz
I guess that is what the user is seeing here? https://community.jboss.org/thread/196946
On 15 Mar 2012, at 00:01, Richard Achmatowicz wrote:

> He may have been referring to the fact that in AS 7.1.1 if you don't
> include a <transport/> element in your cache container, you don't get a
> transport. And in that case, caches in two instances of that cache
> container would not communicate.
>
> On 03/14/2012 07:12 PM, Kabir Khan wrote:
>> A guy at last night's JUG was complaining about this. He mentioned there is a new setting to make the cache replicated, which now needs explicitly turning on. The config from 7.0.x does not turn this on in 7.1, the new setting needs turning on. I guess (but have no idea) that it is one of these values from the infinispan 1.2 xsd:
>>
>>     <xs:complexType name="cache-container">
>>         <xs:complexContent>
>>             <xs:extension base="tns:base-cache-container">
>>                 <xs:sequence>
>>                     <xs:element name="transport" type="tns:transport" minOccurs="0">
>>                         <xs:annotation>
>>                             <xs:documentation>Overrides the transport characteristics for this cache container.</xs:documentation>
>>                         </xs:annotation>
>>                     </xs:element>
>>                     <xs:choice maxOccurs="unbounded">
>>                         <xs:element name="local-cache" type="tns:local-cache">
>>                             <xs:annotation>
>>                                 <xs:documentation>Defines a LOCAL mode cache.</xs:documentation>
>>                             </xs:annotation>
>>                         </xs:element>
>>                         <xs:element name="replicated-cache" type="tns:replicated-cache">
>>                             <xs:annotation>
>>                                 <xs:documentation>Defines a REPL_* mode cache.</xs:documentation>
>>                             </xs:annotation>
>>                         </xs:element>
>>                         <xs:element name="invalidation-cache" type="tns:invalidation-cache">
>>                             <xs:annotation>
>>                                 <xs:documentation>Defines an INVALIDATION_* mode cache.</xs:documentation>
>>                             </xs:annotation>
>>                         </xs:element>
>>                         <xs:element name="distributed-cache" type="tns:distributed-cache">
>>                             <xs:annotation>
>>                                 <xs:documentation>Defines a DIST_* mode cache.</xs:documentation>
>>                             </xs:annotation>
>>                         </xs:element>
>>                     </xs:choice>
>>                 </xs:sequence>
>>             </xs:extension>
>>         </xs:complexContent>
>> On 14 Mar 2012, at 21:44, William DeCoste wrote:
>>
>>> Hi Brian,
>>>
>>> Has anything changed in the config of AS7.1 from 7.0.x? I am not seeing
>>> any jgroups traffic or discovery. This configuration worked fine in
>>> 7.0.x. When JGroups is loaded it just creates 2 1-node clusters. They
>>> don't seem to see each other or even be trying.
>>>
>>> Thanks -Bill
>>>
>>> <subsystem xmlns="urn:jboss:domain:jgroups:1.1" default-stack="tcp">
>>> <stack name="tcp">
>>> <transport type="TCP" socket-binding="jgroups-tcp"/>
>>> <protocol type="TCPPING">
>>> <property name="timeout">
>>>                         3000
>>> </property>
>>> <property name="initial_hosts">
>>>                         127.0.250.1[7600],127.0.251.1[7600]
>>> </property>
>>> <property name="port_range">
>>>                         1
>>> </property>
>>> <property name="num_initial_members">
>>>                         2
>>> </property>
>>> </protocol>
>>> <protocol type="MERGE2"/>
>>> <protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd"/>
>>> <protocol type="FD"/>
>>> <protocol type="VERIFY_SUSPECT"/>
>>> <protocol type="BARRIER"/>
>>> <protocol type="pbcast.NAKACK"/>
>>> <protocol type="UNICAST2"/>
>>> <protocol type="pbcast.STABLE"/>
>>> <protocol type="pbcast.GMS"/>
>>> <protocol type="UFC"/>
>>> <protocol type="MFC"/>
>>> <protocol type="FRAG2"/>
>>> </stack>
>>> </subsystem>
>>>
>>> --
>>> Bill DeCoste
>>> Principal Software Engineer, Red Hat
>>> 978-204-0920
>>> [hidden email]
>>>
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: TCPPING in AS7

Richard Achmatowicz
No, he includes the transport. I'll ask him for more details and follow up.

On 03/16/2012 07:13 AM, Kabir Khan wrote:

> I guess that is what the user is seeing here? https://community.jboss.org/thread/196946
> On 15 Mar 2012, at 00:01, Richard Achmatowicz wrote:
>
>> He may have been referring to the fact that in AS 7.1.1 if you don't
>> include a<transport/>  element in your cache container, you don't get a
>> transport. And in that case, caches in two instances of that cache
>> container would not communicate.
>>
>> On 03/14/2012 07:12 PM, Kabir Khan wrote:
>>> A guy at last night's JUG was complaining about this. He mentioned there is a new setting to make the cache replicated, which now needs explicitly turning on. The config from 7.0.x does not turn this on in 7.1, the new setting needs turning on. I guess (but have no idea) that it is one of these values from the infinispan 1.2 xsd:
>>>
>>>      <xs:complexType name="cache-container">
>>>          <xs:complexContent>
>>>              <xs:extension base="tns:base-cache-container">
>>>                  <xs:sequence>
>>>                      <xs:element name="transport" type="tns:transport" minOccurs="0">
>>>                          <xs:annotation>
>>>                              <xs:documentation>Overrides the transport characteristics for this cache container.</xs:documentation>
>>>                          </xs:annotation>
>>>                      </xs:element>
>>>                      <xs:choice maxOccurs="unbounded">
>>>                          <xs:element name="local-cache" type="tns:local-cache">
>>>                              <xs:annotation>
>>>                                  <xs:documentation>Defines a LOCAL mode cache.</xs:documentation>
>>>                              </xs:annotation>
>>>                          </xs:element>
>>>                          <xs:element name="replicated-cache" type="tns:replicated-cache">
>>>                              <xs:annotation>
>>>                                  <xs:documentation>Defines a REPL_* mode cache.</xs:documentation>
>>>                              </xs:annotation>
>>>                          </xs:element>
>>>                          <xs:element name="invalidation-cache" type="tns:invalidation-cache">
>>>                              <xs:annotation>
>>>                                  <xs:documentation>Defines an INVALIDATION_* mode cache.</xs:documentation>
>>>                              </xs:annotation>
>>>                          </xs:element>
>>>                          <xs:element name="distributed-cache" type="tns:distributed-cache">
>>>                              <xs:annotation>
>>>                                  <xs:documentation>Defines a DIST_* mode cache.</xs:documentation>
>>>                              </xs:annotation>
>>>                          </xs:element>
>>>                      </xs:choice>
>>>                  </xs:sequence>
>>>              </xs:extension>
>>>          </xs:complexContent>
>>> On 14 Mar 2012, at 21:44, William DeCoste wrote:
>>>
>>>> Hi Brian,
>>>>
>>>> Has anything changed in the config of AS7.1 from 7.0.x? I am not seeing
>>>> any jgroups traffic or discovery. This configuration worked fine in
>>>> 7.0.x. When JGroups is loaded it just creates 2 1-node clusters. They
>>>> don't seem to see each other or even be trying.
>>>>
>>>> Thanks -Bill
>>>>
>>>> <subsystem xmlns="urn:jboss:domain:jgroups:1.1" default-stack="tcp">
>>>> <stack name="tcp">
>>>> <transport type="TCP" socket-binding="jgroups-tcp"/>
>>>> <protocol type="TCPPING">
>>>> <property name="timeout">
>>>>                          3000
>>>> </property>
>>>> <property name="initial_hosts">
>>>>                          127.0.250.1[7600],127.0.251.1[7600]
>>>> </property>
>>>> <property name="port_range">
>>>>                          1
>>>> </property>
>>>> <property name="num_initial_members">
>>>>                          2
>>>> </property>
>>>> </protocol>
>>>> <protocol type="MERGE2"/>
>>>> <protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd"/>
>>>> <protocol type="FD"/>
>>>> <protocol type="VERIFY_SUSPECT"/>
>>>> <protocol type="BARRIER"/>
>>>> <protocol type="pbcast.NAKACK"/>
>>>> <protocol type="UNICAST2"/>
>>>> <protocol type="pbcast.STABLE"/>
>>>> <protocol type="pbcast.GMS"/>
>>>> <protocol type="UFC"/>
>>>> <protocol type="MFC"/>
>>>> <protocol type="FRAG2"/>
>>>> </stack>
>>>> </subsystem>
>>>>
>>>> --
>>>> Bill DeCoste
>>>> Principal Software Engineer, Red Hat
>>>> 978-204-0920
>>>> [hidden email]
>>>>
>>>> _______________________________________________
>>>> jboss-as7-dev mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>> _______________________________________________
>> jboss-as7-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: TCPPING in AS7

kkhan
The guy at the JUG also complained about something similar to https://community.jboss.org/thread/196873
On 16 Mar 2012, at 13:30, Richard Achmatowicz wrote:

> No, he includes the transport. I'll ask him for more details and follow up.
>
> On 03/16/2012 07:13 AM, Kabir Khan wrote:
>> I guess that is what the user is seeing here? https://community.jboss.org/thread/196946
>> On 15 Mar 2012, at 00:01, Richard Achmatowicz wrote:
>>
>>> He may have been referring to the fact that in AS 7.1.1 if you don't
>>> include a<transport/>  element in your cache container, you don't get a
>>> transport. And in that case, caches in two instances of that cache
>>> container would not communicate.
>>>
>>> On 03/14/2012 07:12 PM, Kabir Khan wrote:
>>>> A guy at last night's JUG was complaining about this. He mentioned there is a new setting to make the cache replicated, which now needs explicitly turning on. The config from 7.0.x does not turn this on in 7.1, the new setting needs turning on. I guess (but have no idea) that it is one of these values from the infinispan 1.2 xsd:
>>>>
>>>>     <xs:complexType name="cache-container">
>>>>         <xs:complexContent>
>>>>             <xs:extension base="tns:base-cache-container">
>>>>                 <xs:sequence>
>>>>                     <xs:element name="transport" type="tns:transport" minOccurs="0">
>>>>                         <xs:annotation>
>>>>                             <xs:documentation>Overrides the transport characteristics for this cache container.</xs:documentation>
>>>>                         </xs:annotation>
>>>>                     </xs:element>
>>>>                     <xs:choice maxOccurs="unbounded">
>>>>                         <xs:element name="local-cache" type="tns:local-cache">
>>>>                             <xs:annotation>
>>>>                                 <xs:documentation>Defines a LOCAL mode cache.</xs:documentation>
>>>>                             </xs:annotation>
>>>>                         </xs:element>
>>>>                         <xs:element name="replicated-cache" type="tns:replicated-cache">
>>>>                             <xs:annotation>
>>>>                                 <xs:documentation>Defines a REPL_* mode cache.</xs:documentation>
>>>>                             </xs:annotation>
>>>>                         </xs:element>
>>>>                         <xs:element name="invalidation-cache" type="tns:invalidation-cache">
>>>>                             <xs:annotation>
>>>>                                 <xs:documentation>Defines an INVALIDATION_* mode cache.</xs:documentation>
>>>>                             </xs:annotation>
>>>>                         </xs:element>
>>>>                         <xs:element name="distributed-cache" type="tns:distributed-cache">
>>>>                             <xs:annotation>
>>>>                                 <xs:documentation>Defines a DIST_* mode cache.</xs:documentation>
>>>>                             </xs:annotation>
>>>>                         </xs:element>
>>>>                     </xs:choice>
>>>>                 </xs:sequence>
>>>>             </xs:extension>
>>>>         </xs:complexContent>
>>>> On 14 Mar 2012, at 21:44, William DeCoste wrote:
>>>>
>>>>> Hi Brian,
>>>>>
>>>>> Has anything changed in the config of AS7.1 from 7.0.x? I am not seeing
>>>>> any jgroups traffic or discovery. This configuration worked fine in
>>>>> 7.0.x. When JGroups is loaded it just creates 2 1-node clusters. They
>>>>> don't seem to see each other or even be trying.
>>>>>
>>>>> Thanks -Bill
>>>>>
>>>>> <subsystem xmlns="urn:jboss:domain:jgroups:1.1" default-stack="tcp">
>>>>> <stack name="tcp">
>>>>> <transport type="TCP" socket-binding="jgroups-tcp"/>
>>>>> <protocol type="TCPPING">
>>>>> <property name="timeout">
>>>>>                         3000
>>>>> </property>
>>>>> <property name="initial_hosts">
>>>>>                         127.0.250.1[7600],127.0.251.1[7600]
>>>>> </property>
>>>>> <property name="port_range">
>>>>>                         1
>>>>> </property>
>>>>> <property name="num_initial_members">
>>>>>                         2
>>>>> </property>
>>>>> </protocol>
>>>>> <protocol type="MERGE2"/>
>>>>> <protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd"/>
>>>>> <protocol type="FD"/>
>>>>> <protocol type="VERIFY_SUSPECT"/>
>>>>> <protocol type="BARRIER"/>
>>>>> <protocol type="pbcast.NAKACK"/>
>>>>> <protocol type="UNICAST2"/>
>>>>> <protocol type="pbcast.STABLE"/>
>>>>> <protocol type="pbcast.GMS"/>
>>>>> <protocol type="UFC"/>
>>>>> <protocol type="MFC"/>
>>>>> <protocol type="FRAG2"/>
>>>>> </stack>
>>>>> </subsystem>
>>>>>
>>>>> --
>>>>> Bill DeCoste
>>>>> Principal Software Engineer, Red Hat
>>>>> 978-204-0920
>>>>> [hidden email]
>>>>>
>>>>> _______________________________________________
>>>>> jboss-as7-dev mailing list
>>>>> [hidden email]
>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>> _______________________________________________
>>>> jboss-as7-dev mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev