Chapter 7. Known issues

To avoid this invalid intermediate state, execute both infinispan-session-management:add and affinity=local:add operations within a batch.

batch
/subsystem=distributable-web/infinispan-session-management=ism-0:add(cache-container=web,granularity=SESSION)
/subsystem=distributable-web/infinispan-session-management=ism-0/affinity=local:add()
run-batch -v

An interoperability test involving Red Hat JBoss Enterprise Application Platform 8.0 and Red Hat Data Grid on OpenShift Container Platform shows an issue where writes to an Infinispan remote cache causes an internal server error. When the remote-cache-container is configured to use the default marshaller, JBoss Marshalling, cache writes cause HotRod to throw errors because only byte[] instances are supported.

Caused by: java.lang.IllegalArgumentException: Only byte[] instances are supported currently!
	at org.infinispan.client.hotrod@14.0.17.Final-redhat-00002//org.infinispan.client.hotrod.marshall.BytesOnlyMarshaller.checkByteArray(BytesOnlyMarshaller.java:27)

Configure the remote-cache-container to use the ProtoStream marshaller marshaller=PROTOSTREAM:

/subsystem=infinispan/remote-cache-container=<RHDG_REMOTE_CACHE_CONTAINER_RESOURCE_NAME>:write-attribute(name=marshaller,value=PROTOSTREAM)

The ConnectRetryCount parameter controls the number of reconnection attempts when there is a connection failure. This parameter is set to 1 by default, enabling connection resiliency.

To disable connection resiliency, change the ConnectRetryCount parameter from 1 to 0. You can set connection properties in the datasource configuration section of the server configuration file standalone.xml or domain.xml. For more information about how to configure datasource settings, see How to configure datasource settings in EAP for OpenShift and How to specify connection properties in the Datasource Configuration for JBoss EAP on the Red Hat Customer Portal.

In JBoss EAP 7.4, the python liveness probe reports "not alive" when there are deployment errors that would result in restarting the container.

In JBoss EAP 8.0, the liveness probe :9990/health/live uses the server management model to determine readiness. If the server-state is running, and there are no boot or deployment errors, then the liveness check reports UP when the server process is running.

Therefore, deployment errors can result in a pod that is running but is "not ready". This would only affect applications that have intermittent errors during deployment. If these errors always occur during deployment, the container will never be ready and the pod would be in a CrashLoopBackoff state.

If there are deployment errors that result in a pod that is running but is reporting "not ready", examine the server boot process, resolve the deployment issue causing the errors, and then verify that the server deploys correctly.

If the deployment errors cannot be fixed, change the startup probe to use the /ready HTTP endpoint so that boot errors will trigger a pod restart. For example, if you deploy a JBoss EAP application with Helm, configure the liveness probe by updating the deploy.livenessProbe field:

deploy:
  livenessProbe:
    httpGet:
      path: /health/ready