1 Reply Latest reply on Jun 7, 2019 4:35 PM by pferraro

    Use of Infinispan within Wildfly

    csetera

      We recently updated to Wildfly 15.  As part of that upgrade, we ran into warnings about our use of the Infinispan subsystem within Wildfly that caught us off guard.  For a long time, we've created a few extra caches to use for our own purposes within the standalone.xml configuration riding on top of the standard JGroups configuration provided by Wildfly.  While this continues to work, we are concerned about the warnings relative to the long term viability of this use case.

       

      While we've found internet references that point to packaging Infinispan completely within our application deployable, the reality of doing that is that it further requires packaging and configuration of JGroups as well.  This implies two parallel JGroups configurations (ours and Wildfly), which doesn't seem quite right.

       

      Can anyone shed any light on the reasons for this being considered private? Are we going to have issues in the future if we continue to use the built-in Infinispan configuration inside of Wildfly?

       

      Thanks,
      Craig

        • 1. Re: Use of Infinispan within Wildfly
          pferraro

          Can anyone shed any light on the reasons for this being considered private?

          The org.infinispan module is private simply because there are no API/source or binary compatibility guarantees across releases.  Additionally, you cannot easily upgrade Infinispan independently from WildFly itself.

           

          Are we going to have issues in the future if we continue to use the built-in Infinispan configuration inside of Wildfly?

          When upgrading to a new version of WildFly, it is possible that your application might not compile without source code changes.  However this is true whether you bundle Infinispan within your application or use the version contained in WildFly.

           

          Generally, using a server managed Infinispan cache is easier to configure/use as it can leverage other server managed resources for its dependencies, e.g. JGroups channels, transaction manager, DataSources etc.