5 Replies Latest reply on Mar 1, 2016 6:38 PM by Paul Ferraro

    Infinispan configuration broke when migrating from WildFly 8 to WildFly 9

    Touko Vaarnamo Newbie

      Hi, I'm having trouble with Infinispan configuration when migrating from Wildfly 8 to Wildfly 9.  So this cache-container configuration used work fine in Wildfly 8:

       

      <cache-container default-cache="cache-default-name" module="org.infinispan"

                       name="cache-name">

          <transport lock-timeout="60000"/>

          <replicated-cache mode="ASYNC" name="cache-default-name">

              <locking acquire-timeout="300000" concurrency-level="500" isolation="REPEATABLE_READ"

                       striping="false"/>

              <transaction mode="NONE"/>

              <eviction max-entries="10000" strategy="LRU"/>

              <expiration max-idle="86400000"/><!-- Day in millis -->

          </replicated-cache>

      </cache-container>

       

      But now with Wildly 9 I had to replace the replicated-cache with a local-cache. Any idea what might be the cause?

        • 2. Re: Infinispan configuration broke when migrating from WildFly 8 to WildFly 9
          Wolf-Dieter Fink Master

          Do you have timeouts during start or hard?

          I can add that configuration without issues.

          • 3. Re: Infinispan configuration broke when migrating from WildFly 8 to WildFly 9
            Touko Vaarnamo Newbie

            Hi Paul, thanks for reaching out. The problem manifests itself in such a manner that the server does not start. There is no exception logged in the server log. The most informative thing I could find was:

             

                "Services that may be the cause:" => ["jboss.jgroups.factory.default"]

            • 4. Re: Infinispan configuration broke when migrating from WildFly 8 to WildFly 9
              Touko Vaarnamo Newbie

              Hi Wolf-Dieter, thanks for reaching out. As stated in the other reply, the server did not start. The fact that you were able to add that configuration suggests that the problem may lie elsewhere, possibly in the jgroups configuration.

               

              This is the jgroups config in use:

               

              <subsystem xmlns="urn:jboss:domain:jgroups:3.0">

                  <channels>

                      <channel name="channel-name-1"/>

                      <channel name="channel-name-2"/>

                      <channel name="channel-name-3"/>

                      <channel name="channel-name-4"/>

                  </channels>

                  <stacks default="jdbc_ping">

                      <stack name="jdbc_ping">

                          <transport socket-binding="jgroups-udp" type="UDP">

                              <property name="ip_mcast">false</property>

                          </transport>

                          <protocol type="JDBC_PING">

                              <property name="datasource_jndi_name">java:jboss/datasources/data-source-name

                              </property>

                          </protocol>

                          <protocol type="MERGE3"/>

                          <protocol socket-binding="jgroups-udp-fd" type="FD_SOCK"/>

                          <protocol type="FD"/>

                          <protocol type="VERIFY_SUSPECT"/>

                          <protocol type="pbcast.NAKACK2">

                              <property name="use_mcast_xmit">false</property>

                              <property name="use_mcast_xmit_req">false</property>

                          </protocol>

                          <protocol type="UNICAST3"/>

                          <protocol type="pbcast.STABLE"/>

                          <protocol type="pbcast.GMS"/>

                          <protocol type="UFC"/>

                          <protocol type="MFC"/>

                          <protocol type="FRAG2"/>

                          <protocol type="RSVP"/>

                      </stack>

                  </stacks>

              </subsystem>

              • 5. Re: Infinispan configuration broke when migrating from WildFly 8 to WildFly 9
                Paul Ferraro Master

                OK - I see the problem.  Your Infinispan <transport/> is not configured to use a specific channel, thus it tries to use the default channel, but your jgroups subsystem does not define a default channel.

                In summary, either configure your Infinispan <transport/> with a specific channel, e.g. <transport channel="channel-name-1"/>, or define a default channel in your jgroups subsystem, e.g. <channels default="channel-name-1">...</channels>