Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Infinispan support for distributed in-memory HttpSession caching #2843

Closed
nmittles opened this issue Oct 15, 2020 · 17 comments
Closed

Infinispan support for distributed in-memory HttpSession caching #2843

nmittles opened this issue Oct 15, 2020 · 17 comments
Assignees
Labels
common task Important common tasks that should be documented. content reviewed peer reviewed requires doc testing technical reviewed An SME reviewed and approved the documentation from a technical perspective.
Milestone

Comments

@nmittles
Copy link

nmittles commented Oct 15, 2020

In OpenLiberty we now officially support using Infinispan (version 11) for the JCache provider used by the sessionCache-1.0 feature. We need to document how to configure this for server/client mode, embedded mode, and reference Liberty docker container documentation as well.

Infinispan beta support was already documented in a blog post. We will be reusing and updating this content to build the Liberty doc.
https://openliberty.io/blog/2020/01/08/infinispan-open-liberty-openshift.html

OpenLiberty epic:
OpenLiberty/open-liberty#8835

@Charlotte-Holt
Copy link
Contributor

#2844

@dmuelle dmuelle added this to the 21.0.0.3 milestone Feb 1, 2021
@Rwalls1 Rwalls1 self-assigned this Feb 1, 2021
@Rwalls1
Copy link
Contributor

Rwalls1 commented Feb 3, 2021

Draft from @nmittles:

Title: Infinispan Support for Distributed In-memory HttpSession Caching

Summary: A key component of production-grade web applications is failover of non-persistent user session data (e.g. a shopping cart). In Open Liberty, the sessionCache-1.0 feature enables this failover aspect of high availability. The sessionCache-1-0 feature uses a JCache provider internally to create a distributed in-memory cache. No direct usage of the JCache (JSR 107) API is required; Open Liberty manages all communication with the JCache provider. The user is required to provide a JCache implementation. Open Liberty officially supports Infinispan as a JCache provider.
Open Liberty supports using Infinispan 11 with the sessionCache-1.0 feature. Infinispan can be configured in client/server mode (running as a standalone Infinispan server to which Open Liberty connects remotely) or in embedded mode (running in the same JVM as Open Liberty). This includes running Open Liberty Docker images in a Kubernetes environment such as OpenShift. For a broad overview of the sessionCache-1.0 feature, see distributed session caching.

Prereq: Obtain the Infinispan 11 library Jars for running in client/server mode with Maven

To download the Infinispan jars and corresponding prerequisite jars for client/server mode use the following pom.xml with the Maven commands below:

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>
   <groupId>io.openliberty</groupId>
  <artifactId>openliberty-infinispan-client</artifactId>
  <version>1.0</version>
  <!-- https://mvnrepository.com/artifact/org.infinispan/infinispan-jcache-remote -->
  <dependencies>
    <dependency>
      <groupId>org.infinispan</groupId>
      <artifactId>infinispan-jcache-remote</artifactId>
      <version>11.0.3.Final</version>
    </dependency>
  </dependencies>
</project>

Commands to download and cleanup the jars:

mvn -f ./pom.xml versions:use-latest-releases -DallowMajorUpdates=false
mvn -f ./pom.xml dependency:copy-dependencies -DoutputDirectory=${wlp.user.dir}/shared/resources/infinispan
rm -f ${wlp.user.dir}/shared/resources/infinispan/jboss-transaction-api*.jar

Prereq: Obtain the Infinispan 11 library Jars for running in embedded mode with Maven

To download the Infinispan jars and corresponding prerequisite jars for embedded mode use the following pom.xml with the Maven commands below:

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>io.openliberty</groupId>
  <artifactId>openliberty-infinispan</artifactId>
  <version>1.0</version>
  <!-- https://mvnrepository.com/artifact/org.infinispan/infinispan-jcache -->
  <dependencies>
    <dependency>
      <groupId>org.infinispan</groupId>
      <artifactId>infinispan-jcache</artifactId>
      <version>11.0.3.Final</version>
    </dependency>
  </dependencies>
</project>

Commands to download and cleanup the jars:

mvn dependency:copy-dependencies -DoutputDirectory=infinispan
rm -f infinispan/cdi-api-*.jar
rm -f infinispan/javax.*.jar
rm -f infinispan/jboss-transaction-api*.jar
rm -f infinispan/microprofile-*-api-*.jar
rm -f infinispan/smallrye-config-*.jar

Configuring Infinispan in client/server mode with OpenShift

Infinispan can be configured in client/server mode. In this configuration, there is a standalone Infinispan server that houses all of the cache data. Each Open Liberty server then remotely connects to this Infinispan server to access an application's cached session data. Keep in mind that a cluster of Infinispan servers can be configured to share the workload and for failover purposes. This client/server mode can be beneficial in environments in which the Open Liberty servers are frequently starting and stopping because there is a cost associated with transferring the cache state to each Liberty server when running in embedded mode.
Sample server.xml for configuring client/server mode in Open Liberty:

<server>
    <featureManager>
        <feature>servlet-4.0</feature>
        <feature>sessionCache-1.0</feature>
    </featureManager>
    <httpEndpoint host="*"
                  id="defaultHttpEndpoint"
                  httpPort="9080"
                  httpsPort="9443" />
  <httpSessionCache libraryRef="InfinispanLib">
    <properties infinispan.client.hotrod.server_list="infinispan-server:11222"/>
    <properties infinispan.client.hotrod.auth_username="sampleUser"/>
    <properties infinispan.client.hotrod.auth_password="samplePassword"/>
    <properties infinispan.client.hotrod.auth_realm="default"/>
    <properties infinispan.client.hotrod.sasl_mechanism="PLAIN"/>
    <properties infinispan.client.hotrod.java_serial_whitelist=".*"/>
    <properties infinispan.client.hotrod.marshaller="org.infinispan.commons.marshall.JavaSerializationMarshaller"/>
  </httpSessionCache>
    <library id="InfinispanLib">
        <fileset dir="${shared.resource.dir}/infinispan" includes="*.jar"/>
    </library>
</server>

The key piece is the <httpSessionCache> tag. The libraryRef="InfinispanLib" attribute references a shared library to load the Infinispan jars from. Finally, the embedded <properties> tags set the minimum configuration needed by the Infinispan Hot Rod client. This configuration uses PLAIN authentication, which should only be used for development purposes (see Infinispan's documentation on authentication for more details). For a complete list of supported properties, see the Infinispan documentation. Also, be sure to enable the sessionCache-1.0 feature.
Finally, start an Infinispan server in the OpenShift environment with the following command:

oc new-app --docker-image=infinispan/server --name=infinispan-server -e USER="sampleUser" -e PASS="samplePassword"

In the example above --name=infinispan-server maps to infinispan.client.hotrod.server_list="infinispan-server:11222" in the Open Liberty server.xml (11222 is the default port). Additionally, USER and PASS map to infinispan.client.hotrod.auth_username and infinispan.client.hotrod.auth_password respectively.

Configuring Infinispan in embedded mode with OpenShift

Infinispan can be configured in embedded mode. In this configuration, the Infinispan server resides in the same JVM as the Open Liberty server. Infinispan utilizes JGroups to allow multiple embedded servers to form a cluster. In our context of the sessionCache-1.0 feature, this clustering provides high availability of user session data. Embedded mode will generally perform faster per request than client/server mode. This is due to the network and serialization costs associated with the remote calls of client/server mode.
Sample server.xml for configuring embedded mode in Open Liberty:

<server>
    <featureManager>
        <feature>servlet-4.0</feature>
        <feature>mpMetrics-2.0</feature> <!-- one of the Infinispan JARs has a hard dependency on MicroProfile Metrics API -->
        <feature>mpReactiveStreams-1.0</feature> <!-- one of the Infinispan JARs has a hard dependency on Reactive Streams API -->
        <feature>sessionCache-1.0</feature>
    </featureManager>
    <httpEndpoint host="*"
                  id="defaultHttpEndpoint"
                  httpPort="9080"
                  httpsPort="9443" />
    <httpSessionCache libraryRef="InfinispanLib" uri="file:${shared.resource.dir}/infinispan/infinispan.xml"/>
    <library id="InfinispanLib">
        <fileset dir="${shared.resource.dir}/infinispan" includes="*.jar"/>
    </library>
</server>

The key piece is the <httpSessionCache> tag. The libraryRef="InfinispanLib" attribute references a shared library to load the Infinispan jars from. Finally, the uri="file:${shared.resource.dir}/infinispan/infinispan.xml" attribute points to Infinispan's own configuration file. Be sure to enabled the sessionCache-1.0, mpReactiveStreams-1.0, and mpMetrics-2.0 features. Currently mpMetrics-2.0 and mpReactiveStreams-1.0 are hard dependencies, but we're aiming to make these optional in the future.
Next, create the infinispan.xml referenced from the server.xml configuration:

<infinispan>
  <jgroups>
     <stack-file name="jgroups-kubernetes" path="/default-configs/default-jgroups-kubernetes.xml"/>
  </jgroups>
  <cache-container>
    <transport stack="jgroups-kubernetes" />
  </cache-container>
</infinispan>

The JGroups stack is what determines how the Infinispan servers form a cluster. The sample infinispan.xml uses the default Kubernetes template to enable clustering in OpenShift. See Configuring Infinispan 10 for Infinispan's complete documentation on setting up a cluster.
Next, create a headless Kubernetes service to enable the Kubernetes JGroups transport stack to form a cluster. The key here is for the name of the selector to match one of the labels associated with the Open Liberty applications running in OpenShift. For example, an application defined using the command oc new-app --image-stream=ol-runtime-infinispan-embedded:1.0.0 --name=embedded-servera -l name=ol-runtime-infinispan-embedded has a label of name=ol-runtime-infinispan-embedded. This label then matches the service defined below, and triggers the application to be a part of the service.

oc create -f service.yaml
apiVersion: v1
kind: Service
metadata:
  name: infinispan-embedded
spec:
  clusterIP: None
  ports:
  - name: discovery
    port: 7800
    protocol: TCP
    targetPort: 7800
  selector:
    name: ol-runtime-infinispan-embedded
  sessionAffinity: None
  type: ClusterIP
status:
  loadBalancer: {}

Finally, create a jvm.options file in the main Open Liberty server directory. This file sets jgroups.dns.query which points to the DNS record that should return all the members of the Infinispan cluster. If the environment doesn't support IPv6 then set -Djava.net.preferIPv4Stack=true. See the following sample jvm.options file:

# Set if IPv6 is not supported. 
-Djava.net.preferIPv4Stack=true
# This value matches the DNS lookup of the headless service defined in the previous step. The domain might vary based on the OpenShift environment.
-Djgroups.dns.query=infinispan-embedded.myproject.svc.cluster.local

For an OpenShift environment, server.xml, infinispan.xml, service.yaml, and jvm.options are the four files needed to configure Infinispan in embedded mode. To run outside of an OpenShift environment, a server.xml with the proper features enabled, a shared library for Infinispan, and the following tag is all that is required:

<httpSessionCache libraryRef="InfinispanLib"/>

@dmuelle dmuelle modified the milestones: 21.0.0.3, 21.0.0.4 Feb 4, 2021
@Rwalls1 Rwalls1 added the common task Important common tasks that should be documented. label Apr 2, 2021
@Rwalls1
Copy link
Contributor

Rwalls1 commented Apr 6, 2021

@nmittles Please review: https://draft-openlibertyio.mybluemix.net/docs/latest/configuring-infinispan-support.html

The draft mentions references to the JCache session persistence feature that will contain the proposed updates related to this topic that I mentioned in issue #1290

@Rwalls1
Copy link
Contributor

Rwalls1 commented Apr 9, 2021

Feedback from @nmittles in slack:
I find these two sentences confusing, although I'll admit I'm not actually on the sessions team. Our team was pulled to help with the specific development/integration effort for Infinispan. It might be best to run the opening portion of this doc past Allan Zhang and his team that owns session caching.
Applications provide failover of non-persistent user session data when multiple instances are needed to avoid performance interruptions and maintain high availability. However, sessions that are non-persistent don't provide a way to store user data that can be used across multiple requests.
This method provides more flexibility by reducing startup times in application environments that contain servers that start and stop regularly to maintain high availability of data.
The above sentence makes me ask "more flexibility than what?" It doesn't actually reduce startup time. The server will come up in ruffly the same amount of time. The problem is that each Liberty server in a cluster needs to sync its cached data, so when servers are coming up and down, both the servers that are still up and the new ones coming up have to work hard to communicate/sync with one another.

Also for me the sentence is hard to read, as it contains "in...", "that..", "that...", "to...". I'm not sure what the "to maintain high availability of data" adds to the sentence. Is it saying that it provides more flexibility to maintain high availability of data? What is the flexibility? Improved startup time (which is performance and not flexibility)? Or does the "to maintain high availability of data" mean this applies to servers that start and stop regularly for HA purposes, which doesn't make sense but is how it reads. Also the improved startup time is missing context, so it sounds like setting up session cache in this way improved startup performance in general, when I think you meant for it to be in comparison to embedded mode. The whole point of mentioning that the caches need to be synced when servers stop/start was to explain why you would use client/server vs embedded.

I'm getting the impression that we're trying to really limit our word count for these docs? As even the sentence before this one is also a mouthful. I find myself rereading the sentence a couple times to unpack it.
Infinispan can be configured in client/server mode. In this configuration, there is a standalone Infinispan server that houses all of the cache data. Each Open Liberty server then remotely connects to this Infinispan server to access an application's cached session data. (original)
When you configure Infinispan in client/server mode with OpenShift, you can connect to a remote Infinispan server with Open Liberty to access cached HTTP session data from applications. (current draft)
When configuring Infinispan in client/server mode on OpenShift, you connect Open Liberty to a remote Infinispan server for accessing cached application session data. (alternative if we must be shorter)
In the embedded mode section:
To create a service switch to To create this service
I'd prefer to remove The label provides the name of the service that contains the applications.and find a way to include this example:
For example, an application defined using the command oc new-app --image-stream=ol-runtime-infinispan-embedded:1.0.0 --name=embedded-servera -l name=ol-runtime-infinispan-embedded has a label of name=ol-runtime-infinispan-embedded. This label then matches the service defined below, and triggers the application to be a part of the service.

I know its long, but this is a really key piece to have the label and the selector match up. If this isn't setup right, it's really hard/frustrating to debug. Maybe we can find a way to shorten the label example.
Another thought on the reasons for client/server vs embedded. Maybe we do a short help me decide section and drop that content from the client/server and embedded sections all together?

Also, throughout the doc I'm thinking mode with OpenShift might sound better as mode on OpenShift. I'll let you decide which you prefer.

@Rwalls1 Rwalls1 modified the milestones: 21.0.0.4, 21.0.0.5 Apr 12, 2021
@nmittles
Copy link
Author

nmittles commented May 5, 2021

@Rwalls1

Infinispan doc review II:
CURRENT: To provide high availability features in Open Liberty, you must configure a JCache provider.
Sounds like all possible HA features come from a JCache provider, not sure this is true. Allan should be able to confirm this.

CURRENT: When you configure Infinispan in client/server mode on OpenShift, you can connect Open Liberty to a remote Infinispan server that accesses cached HTTP session data from applications.

PROPOSED: When you configure Infinispan in client/server mode on OpenShift, you can connect Open Liberty to a remote Infinispan server that accesses cached HTTP session application data. (or remove 'application' completely?)

CURRENT: This method improves performance by making data synchronization easier in application environments that must facilitate communication among multiple servers.

PROPOSED: new section on deciding between client/server and embedded modes.
Embedded mode will generally perform faster per request than client/server mode. This is due to the network and serialization costs associated with the remote calls of client/server mode. However in client/server mode, a cluster of Infinispan servers can be configured to share the workload and for failover purposes. Additionally, client/server mode can be beneficial in environments in which your Open Liberty servers are frequently starting and stopping due to the synchronization costs when adding an embedded Infinispan server to a cluster.

CURRENT: When you configure Infinispan in embedded mode on OpenShift, you can connect to Infinispan servers with Open Liberty that are created in the same Java Virtual Machine (JVM). Infinispan provides access to JGroups, which enables servers that are in embedded in the JVM to form a cluster. This cluster of embedded servers in embedded mode provides high availability of user HTTP session data by performing user requests faster. To configure Infinispan in embedded mode, configure the server.xml file, as shown in the following example:

PROPOSED: When you configure Infinispan in embedded mode on OpenShift, an Infinispan server runs in the same Java Virtual Machine (JVM) as Open Liberty. Multiple embedded Infinispan servers can utilize JGroups(http://www.jgroups.org) to form a cluster providing high availability of user HTTP session data across all members. To configure Infinispan in embedded mode, configure the server.xml file, as shown in the following example:

CURRENT: After configuring embedded mode, configure the infinispan element in the server.xml file to create an infinispan.xml file:

PROPOSED: After configuring embedded mode in the server.xml file, create the referenced infinispan.xml file to enable the JGroups Kubernetes transport stack:

CURRENT: The JGroups stack determines how the Infinispan servers form a cluster. The infinispan.xml file uses the default Kubernetes template to enable clustering in OpenShift. For more information, see the JCache Session Persistence feature.

PROPOSED: <The wrong link is referenced. Instead it should be "Setting Up Infinispan Clusters" https://infinispan.org/docs/11.0.x/titles/embedding/embedding.html#setting_up_clusters >

CURRENT: This label matches the name value of the selector key that is defined in the server.xml file to integrate the application into the service.

PROPOSED: This label matches the name value of the selector key that is defined in the service.yaml to integrate the application into the service.

@Rwalls1
Copy link
Contributor

Rwalls1 commented May 6, 2021

@nmittles
Copy link
Author

Worked with @Rwalls1 on a few minor tweaks. At this point, the Infinispan configuration doc looks good to me from a technical perspective.

@Rwalls1 Rwalls1 added the technical reviewed An SME reviewed and approved the documentation from a technical perspective. label May 13, 2021
@Rwalls1 Rwalls1 modified the milestones: 21.0.0.5, 21.0.0.6 May 14, 2021
@dmuelle
Copy link
Member

dmuelle commented May 19, 2021

Content review:

This topic looks really good- very clear and easy to follow. I just have a few comments and minor edit suggestions

Intro

  • edit suggestion:
    To improve performance, applications can provide resources with high availability to create more reliability at run time. With Open Liberty, you can use the JCache Session Persistence feature to configure a JCache provider to enable features of high availability.
    --->
    Applications that provide resources with high availability are more reliable at run time. With the Open Liberty JCache Session Persistence feature, you can configure a JCache provider to enable features of high availability.

  • 2nd pp- edit suggestion to reduce wordiness and provide concrete example:

HTTP sessions store data that identifies users from HTTP requests. This data can enhance the user experience, for example, by storing preferences or providing shopping cart retrieval. However, HTTP sessions that are non-persistent don’t provide a way to store user data that can be used across multiple requests. To address this limitation, the JCache Session Persistence feature uses distributed session caching to share user session data between different instances and improve high availability features in failover situations. When you configure a JCache provider with the JCache Session Persistence feature, you can enable distributed in-memory HttpSession caching.

  • Open Liberty supports Infinispan 11 as a JCache provider when you enable the JCache Session Persistence feature.

I think you should make it clear that infinispan is just one option- as stated the user might think you have to use it vs Hazelcast or another.

  • Configuring Infinispan in client/server mode also helps synchronize data among Open Liberty servers that frequently start and stop to maintain availability when you add an embedded Infinispan server to a cluster.

I'm not sure what the last part means- i think its based on this sentence from the blog post:

This client/server mode can be beneficial in environments in which your Open Liberty servers are frequently starting and stopping because there is a cost associated with transferring the cache state to each Liberty server when running in embedded mode.

but they don't seem to say the same thing- can you clarify the benefit of client/server?

Before you begin

  • To complete either method, you need to download the corresponding Infinispan 11 library JAR files.
    --->
    To configure Infinispan in either embedded or client/server mode, you must download the corresponding Infinispan 11 library JAR files.

  • Are the pom.xml and command examples in this section specific to running on OpenShift? If so, should make clear. I think this section needs some mention of how OpenShift fits in- is it the only way? Why would a user want to use it w/ infinispan? It's not explained or even mentioned really in the whole topic. I dont think it needs to go into detail but should give some explanation as to why you need or want OpenShift for this task.

Configuring Infinispan in client/server mode on OpenShift

  • When you configure Infinispan in client/server mode on OpenShift, you can connect Open Liberty to a remote Infinispan server that accesses cached HTTP session data.

I think the remote server stores the data, rather than accesses it? The OP says:
there is a standalone Infinispan server that houses all of the cache data.

  • For both examples- I recommend adding the explanation of the server.xml. It's not that much content and it makes the example more clear. I'm not convinced these examples belong on the feature page, esp since it would create two distinct copies of the same example that would have to be maintained individually. The original post explains the content of the examples in a couple sentences and I think we can do the same here.

  • Some detail from OP was lost- like PLAIN auth is only for dev purposes. And we should make clear that the properties element is used to specify provider-specifc properties that are from the infinispan doc. see the explanation in the OP that starts "The key piece is...". I think most if not all that info should be here- esp if somewhere down the line the blog post gets redirected to this doc.

  • The deserialization example from the blog post is missing- is it needed?

Configuring Infinispan in embedded mode on OpenShift

  • same as the previous server.xml example, i think the explanation belongs in this topic, not on the feature page. Also, i think it shouldbe more clear that you reference the infinispan config file from the uri attribute. As stated, it's hard to tell you're referring to something in the previous example. If you add the explanation though this will be resolved.

  • For jvm.options file, should be more clear that Djava.net.preferIPv4Stack is only needed if your env doesnt support IPv6, otherwise, you dont need it at all.

  • I think the topic needs some kind of results section- what have you achieved or enabled by completing the task. Doesn;t need to be much but should give some indication that the user has completed the config and this is what they can expect as a result. For example- see: https://docs-draft-openlibertyio.mybluemix.net/docs/21.0.0.6/analyzing-logs-elk.html#_results

  • I think you could add a See also section at the end that links to the Distributed session caching doc and any related external resources, like infinispan and openshift docs

@Rwalls1
Copy link
Contributor

Rwalls1 commented Jun 2, 2021

@dmuelle Thanks, I've addressed your feedback: https://docs-draft-openlibertyio.mybluemix.net/docs/21.0.0.6/configuring-infinispan-support.html
Are the pom.xml and command examples in this section specific to running on OpenShift? If so, should make clear. I think this section needs some mention of how OpenShift fits in- is it the only way? Why would a user want to use it w/ infinispan? It's not explained or even mentioned really in the whole topic. I dont think it needs to go into detail but should give some explanation as to why you need or want OpenShift for this task.
The pom.xml and command examples are not specific to running on OpenShift. After speaking with the SME, I confirmed that OpenShift is used because it is convenient for users as OpenShift and Infinispan are both projects that are supported by RedHat. So, if a customer is on OpenShift, they should have Infinispan available for free. I don't think there's a logical place in this topic to provide enough context to explain this properly, so I didn't add any additional explanation. I think it might be best to create a supporting document at some point that provides details about the common use cases for Infinispan and other JCache providers and benefits of each within the context of Open Liberty. Then, we could link to that new doc from here to provide additional context.
Some detail from OP was lost- like PLAIN auth is only for dev purposes. And we should make clear that the properties element is used to specify provider-specific properties that are from the infinispan doc. see the explanation in the OP that starts "The key piece is...". I think most if not all that info should be here- esp if somewhere down the line the blog post gets redirected to this doc.
I've updated the doc to include detail about dev purposes. However, I think the link that is provided when properties is mentioned is sufficient to explain what specific properties are being referenced.
I think you could add a See also section at the end that links to the Distributed session caching doc and any related external resources, like infinispan and openshift docs
I don't think a See also section is needed because I think all the relevant related links are included within the context of the doc.
The deserialization example from the blog post is missing- is it needed?
The example isn't needed, the serialization was moved from the jvm.options file to the server.xml file with the <properties infinispan.client.hotrod.java_serial_whitelist=".*"/> line.

@dmuelle
Copy link
Member

dmuelle commented Jun 2, 2021

Looks good- You might add a heading for Configure Infinispan in embedded mode without OpenShift as it kind of gets lost at the end of the tpic and a user might not understand that you don't necessarily have to use OpenShift to use Infinispan.

@Rwalls1
Copy link
Contributor

Rwalls1 commented Jun 3, 2021

@dmuelle Thanks, I've made that update.

@Rwalls1
Copy link
Contributor

Rwalls1 commented Jun 3, 2021

@ManasiGandhi
Copy link
Contributor

ManasiGandhi commented Jun 7, 2021

@Rwalls1 The topic looks good! A few edit suggestions

Peer review

Configuring Infinispan as a JCache provider

  • “To address this limitation, the JCache Session Persistence feature uses distributed session caching to share user session data between different instances and improve high availability features in failover situations.” Acrolinx is flagging “distributed session caching”. Can you reword the sentence by using “distributed session cache” instead?

  • “When Infinispan is configured in embedded mode, it performs requests faster than when it is configured in client/server mode.” Suggestion- “When Infinispan is configured in embedded mode, it performs requests faster than when it is configured in client/server mode.” Also, for later mentions.

  • “When Infinispan is configured in embedded mode, it performs requests faster than when it is configured in client/server mode. This faster performance is due to the network and serialization costs that are associated with the remote calls that happen when Infinispan is configured in client/server mode.” These two sentences don’t seem to be coherent. If Infinispan performs faster in embedded mode, why does the next sentence say that, “This faster performance…. that happen when Infinispan is configured in client/server mode.” Also, can you rephrase, “it performs requests faster”, maybe “, it processes requests faster”.

Before you begin

  • “Then, run the following commands from the command line to download and cleanup the JAR files:”, Change to, “Then, run the following commands from the command line to download and clean up the JAR files:”, both mentions.

Configuring Infinispan in client/server mode on OpenShift

  • “This configuration uses PLAIN authentication, which you should only use for development purposes.” Could you link the “PLAIN authentication” to an anchor, possibly for more specific reference?

Configuring Infinispan in embedded mode on OpenShift

  • “Multiple embedded Infinispan servers can use JGroups to form a cluster that provides high availability of user HTTP session data across all members.” Could you link “cluster” to an anchor, for more specific reference?

  • “If the environment doesn’t support the IPv6 protocol, you can specify the Djava.net.preferIPv4Stack option and set the option to "true".” Remove the quotes from “true”.

Configuring Infinispan in embedded mode without OpenShift

  • “You can also configure Infinispan in embedded mode without OpenShift. To configure without OpenShift, configure the httpSessionCache element in the server.xml file, as shown in the following example:” Could you combine the two sentences for clarity and conciseness, maybe, “You can also configure Infinispan in embedded mode without OpenShift by configuring the server.xml file, as shown in the following example:”

@Rwalls1
Copy link
Contributor

Rwalls1 commented Jun 8, 2021

@ManasiGandhi Thanks, I've addressed your feedback:
“When Infinispan is configured in embedded mode, it performs requests faster than when it is configured in client/server mode.” Suggestion- “When Infinispan is configured in embedded mode, it performs requests faster than when it is configured in client/server mode.” Also, for later mentions.
I didn't add the monospacing because I don't think it's needed to properly refer to the mode.
“This configuration uses PLAIN authentication, which you should only use for development purposes.” Could you link the “PLAIN authentication” to an anchor, possibly for more specific reference?
We don't have a documented method for doing this in asciidoc, so I left as is. This is something that we should discuss in the future.
“Multiple embedded Infinispan servers can use JGroups to form a cluster that provides high availability of user HTTP session data across all members.” Could you link “cluster” to an anchor, for more specific reference?
We don't have a documented method for doing this in asciidoc, so I left as is. This is something that we should discuss in the future.

@Rwalls1
Copy link
Contributor

Rwalls1 commented Jun 9, 2021

@Rwalls1
Copy link
Contributor

Rwalls1 commented Jun 9, 2021

Doc has been merged to Vnext and will be published for 21.0.0.6

@Rwalls1 Rwalls1 closed this as completed Jun 9, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
common task Important common tasks that should be documented. content reviewed peer reviewed requires doc testing technical reviewed An SME reviewed and approved the documentation from a technical perspective.
Projects
None yet
Development

No branches or pull requests

5 participants