This is a documentation review of parts I and II, link https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.1/html-single/developer_guide/
Please don't be scared by the size of the review, I really apologize, but I took it quite in detail, hence some of the issues are definitely not critical and it's up to you if you implement it. Sorry for such a long list

#1 Right in th beginning of the guide, there are two Beta references, remove them:
"FOR USE WITH RED HAT JBOSS DATA GRID 7.1 BETA" and "An advanced guide intended for developers using Red Hat JBoss Data Grid 7.1 Beta"

#2 https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.1/html-single/developer_guide/#per_invocation_flags_2
Replace:
Per-invocation flags can be used with data grids in Red Hat JBoss Data Grid to specify ...

with:
Per-invocation flags can be used with caches in Red Hat JBoss Data Grid to specify ...

#3 https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.1/html-single/developer_guide/#per_invocation_flag_functions
The link at the end of this section is not working.

#4 Swap sections 2.4.3 and 2.4.4.
Section 2.4.3 introduces custom interceptors, so I would expect that following chapter would tell me, how to do that. Also section 2.4.4 is a follow up to usage of Flags, hence I think it should be placed after 2.4.2

#5 https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.1/html-single/developer_guide/#limitations_of_map_methods
Section 2.4.4, subsection "Understanding the size() Method (Embedded Caches)", there is a JDG 7.1 Beta reference in the first sentence, remove it. The same issue is in the following paragraph "Understanding the size() Method (Remote Caches)".

#6 https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.1/html-single/developer_guide/#custom_interceptors
The warning box is IMHO out of date, since we're talking already about JDG 7.1. Remove it completely.

#7 https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.1/html-single/developer_guide/#custom_interceptors
Subsection 2.4.5.2 Custom Interceptor Design, third point in the list, modify the point a bit to be clearer:
"A custom interceptor must have JavaBean style setters defined for any property that is set through the property element in XML configuration."

#8 https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.1/html-single/developer_guide/#custom_interceptors
Subsection 2.4.5.3. Adding Custom Interceptors Programmatically. The way of how to add an interceptor changed in JDG 7.1. hence let't correct it.
The code snippet in "Obtain a Reference to the AdvancedCache" paragraph is correct, but remove the "Then use an addInterceptor() method to add the interceptor." and cover it in the next code snippet, as it's really self-explanatory.
Modify the code snippet of "Add the Interceptor" paragraph from:
advCache.addInterceptor(new MyInterceptor(), 0);

to:
advCache.getAsyncInterceptorChain().addInterceptor(new MyInterceptor(), 0);

#9 https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.1/html-single/developer_guide/#get_and_put_usage_in_distribution_mode
Move the whole section 2.5 after current 2.4.2. The point is that section 2.5 describes some logic of the remote PUT and how to avoid some behaviour using the Flags. The Flags are described in detail in section 2.4.2, hence I think it's more intuitive to have this information together. It's basically the same reason as for section 2.4.4 "Limitations of Map Methods"

#10 https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.1/html-single/developer_guide/#the_asynchronous_api_2
In the second paragraph, there is a sentence "Asynchronous methods return a Future that contains the result of the operation.". I would suggest making the "Future" emphasised in the same way as are the "Async" or "String" etc. are, since Future is a Java object that is returned from the operation.
Also in the following paragraph, there are some < and > angle brackets, so let's correct the last paragraph of section 3.1 to (with the same emphasising):
For example, in a cache parameterized as Cache<String, String>, Cache.put(String key, String value) returns a String, while Cache.putAsync(String key, String value) returns a Future<String>.

#11 https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.1/html-single/developer_guide/#about_asynchronous_processes
Just my observation, we use everywhere the whole name "Red Hat JBoss Data Grid" and in the last sentence of section 3.3, there is only "JBoss Data Grid". I don't know whether this is intentional

#12 https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.1/html-single/developer_guide/#configure_the_batching_api
The note at the end of the section is IMHO really obvious and it doesn't even make sense to have it here. I suggest removing or putting it maybe somewhere only once. I notice this note on several places across the guide.

#13 https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.1/html-single/developer_guide/#use_the_batching_api
Paragraph "Using batching", first paragraph, I suggest replacting "all modifications ... are replicated" with "all modifications ... are applied" or something similar, since in the context of JDG, the replication has a different meaning and it can be confusing IMO.

#14 https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.1/html-single/developer_guide/#batching_api_usage_example
This section is IMHO really obvious and even not entirely true, the preferred way to do bank account transactions is a real transaction. Nevertheless, this is a basic textboox example of using batching/transactions and we really don't have to mention it in our documentation. I would remove this section 4.4.3., but I leave the decision to you

#15 https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.1/html-single/developer_guide/#configure_the_grouping_api_2
The second point in the list says: "For more information about these group types, see Grouping API Operations." I would direct the link toward the sections 5.4.3 and 5.4.4., since they actually describe what the group types do.

#16 https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.1/html-single/developer_guide/#programmatically_configure_the_persistence_spi
Same thing with the note as in point #12.

#17 https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.1/html-single/developer_guide/#persistence_examples_2
In the last sentence of the paragraph, I would make the "Administration and Configuration Guide" a link to the guide to improve documentation user experience. Also same thing for the note as in #12.

#18 https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.1/html-single/developer_guide/#configure_the_cache_store_programmatically
In the code snippet, remove the line with ".flushLockTimeout(15000)" as this method is deprecated and should not be used anymore.

#19 https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.1/html-single/developer_guide/#cassandra_cache_store_sample_programmatic_configuration
The code snippet contains a few error even to compile, hence replace it with this one (changes on lines with .port, .consistencyLevel and .serialConsistencyLevel):

Configuration cacheConfig = new ConfigurationBuilder()
                .persistence()
                .addStore(CassandraStoreConfigurationBuilder.class)
                .addServer()
                .host("127.0.0.1")
                .port(9042)
                .addServer()
                .host("127.0.0.1")
                .port(9041)
                .autoCreateKeyspace(true)
                .keyspace("TestKeyspace")
                .entryTable("TestEntryTable")
                .consistencyLevel(ConsistencyLevel.LOCAL_ONE)
                .serialConsistencyLevel(ConsistencyLevel.SERIAL)
                .connectionPool()
                .heartbeatIntervalSeconds(30)
                .idleTimeoutSeconds(120)
                .poolTimeoutMillis(5)
                .build();

#20 https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.1/html-single/developer_guide/#the_configurationbuilder_api_2
Same thing as in #11.

#21 https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.1/html-single/developer_guide/#global_configuration_examples
Subsection 7.2.5.4
Same thing as in #11.

Subsection 7.2.6.2, in the code snippet, replace "maxEntries" with "size", since maxEntries is deprecated in favour of size.
Subsection 7.2.6.6, same as in #17.

#22
https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.1/html-single/developer_guide/#the_externalizable_api
https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.1/html-single/developer_guide/#customize_externalizers
Same this as in #11.

#23 https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.1/html-single/developer_guide/#about_synchronous_and_asynchronous_notifications
Extra slash in "Use the asyncListenerExecutor/ element in the configuration file ...". Also, just to clarify, I would add "element in the XML configuration file ..."

#24 https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.1/html-single/developer_guide/#cache_entry_modified_listener_configuration
Same this as in #17, but with "API Documentation".
Also I would emphasise the Listenable and FilteringListenable, as these are Java interfaces.

#25 https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.1/html-single/developer_guide/#the_cache_listener_api
Paragraph "Listener Annotation", third point.
There is: "Refer to for information regarding sync()". I guess something is missing after "Refer to", it could probably be link to section 9.3.4 About Synchronous and Asynchronous Notifications

#26 https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.1/html-single/developer_guide/#clustered_listener_example
There should be a few minor changes so the example would compile. Replace this code snippet with:

class CityStateFilter implements CacheEventFilter<String, Order> {
    private String state;
    private String city;

    public boolean accept(String orderId, Order oldOrder,
                          Metadata oldMetadata, Order newOrder,
                          Metadata newMetadata, EventType eventType) {
        switch (eventType.getType()) {
            // Only send update if the order is going to our city
            case CACHE_ENTRY_CREATED:
                return city.equals(newOrder.getCity()) &&
                        state.equals(newOrder.getState());
            // Only send update if our order has changed from our city to elsewhere or if is now going to our city
            case CACHE_ENTRY_MODIFIED:
                if (city.equals(oldOrder.getCity()) &&
                        state.equals(oldOrder.getState())) {
                    // If old city matches then we have to compare if new order is no longer going to our city
                    return !city.equals(newOrder.getCity()) ||
                            !state.equals(newOrder.getState());
                } else {
                    // If the old city doesn't match ours then only send update if new update does match ours
                    return city.equals(newOrder.getCity()) &&
                            state.equals(newOrder.getState());
                }
                // On remove we have to send update if our order was originally going to city
            case CACHE_ENTRY_REMOVED:
                return city.equals(oldOrder.getCity()) &&
                        state.equals(oldOrder.getState());
        }
        return false;
    }
}

class OrderDateConverter implements CacheEventConverter<String, Order, Date> {
    private String state;
    private String city;

    public Date convert(String orderId, Order oldValue,
                        Metadata oldMetadata, Order newValue,
                        Metadata newMetadata, EventType eventType) {
        // If remove we do not care about date - this tells listener to remove its data
        if (eventType.isRemove()) {
            return null;
        } else if (eventType.isModified()) {
            if (state.equals(newValue.getState()) &&
                    city.equals(newValue.getCity())) {
                // If it is a modification meaning the destination has changed to ours then we allow it
                return newValue.getDate();
            } else {
                // If destination is no longer our city it means it was changed from us so send null
                return null;
            }
        } else {
            // This was a create so we always send date
            return newValue.getDate();
        }
    }
}

#27 https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.1/html-single/developer_guide/#clustered_listener_example
Remove this "final" keywords from the code snippets.

#28 One issue I remembered late: https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.1/html-single/developer_guide/#cassandra_cache_store_sample_programmatic_configuration
The Cassandra cache store is not part of the JDG core libraries, hence to make it work, you have to add it on the classpath, for example with Maven via adding following code snippet to pom.xml

<dependency>
 	<groupId>org.infinispan</groupId>
 	<artifactId>infinispan-cachestore-cassandra</artifactId>
 	<version>${version.infinispan}</version>
</dependency>

#29 https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.1/html-single/developer_guide/#remote_event_client_listener_example
Number 3 in the list, there is a wrong version for JDG. The correct version for JDG 7.1 is 8.4.0-Final-redhat-1

Also another occurence of #11.

#30 https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.1/html-single/developer_guide/#filtering_remote_events
Subsection 9.6.4.2, paragraph right before "Add Filter Factory to the Listeneter" headline.
There is a sentence "The following example extends the EventLogListener implementation provided in Remote Event Client Listener Example (See )", after "See" there should be a link to section 9.6.3.

#31 https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.1/html-single/developer_guide/#customizing_remote_events
Another occurrence of #11.

#32 https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.1/html-single/developer_guide/#event_marshalling
Emphasise KeyValueFilter and Coverter as these are regular Java classes.

#33 https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.1/html-single/developer_guide/#jsr_107_jcache_api_2
Another occurrence of #11.

#34 https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.1/html-single/developer_guide/#option_2_adding_the_necessary_files_to_the_classpath
There is a JDG 7.1.0.Beta reference, remove it. Also the version of the artifacts must be 8.4.0.Final-redhat-1, not 8.4.0.ER6-redhat-1.

#35
https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.1/html-single/developer_guide/#clustering_jcache_instances
https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.1/html-single/developer_guide/#the_rest_interface
Another occurence of #11.

#36 https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.1/html-single/developer_guide/#java_client_code
The import should be formatted one import, one line. Also, you can merge it to the following example.

Another occurrence of #11 after the example.

#37 https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.1/html-single/developer_guide/#about_hot_rod
Another occurences of #11.

#40 https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.1/html-single/developer_guide/#hot_rod_java_client_2
In the "Procedure: Download Hot Rod Java Client" section, there are some brackets, don't know what they mean.
Also it the point 5., there is a ${VERSION}, which should probably be replaced by 7.1

#41 https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.1/html-single/developer_guide/#hot_rod_java_client_versioned_api
In the "Using Versioned Methods", replace "remoteCache.getVersioned("car");" with "remoteCache.getWithMetadata("car");", since getVersioned method is deprecated.
Do the same in the next code snippet "UsingReplace")

#42 https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.1/html-single/developer_guide/#hot_rod_c_client_asynchronous_api
There is a JDG 7.1.Beta reference, also occurence of #11. The same applies to the following 13.8.9, 13.8.12, 13.8.13, 13.9.6, 13.9.7, 13.9.10 sections.

#43 https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.1/html-single/developer_guide/#hot_rod_c_client_working_with_sites
Occurences of #11 and #17. The same in 13.9.8.

#44 https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.1/html-single/developer_guide/#creating_a_hot_rod_c_net_project
Wrong versions of JDG are referenced, use 8.4.0.Final instead of 8.3.0.Final.

#45 https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.1/html-single/developer_guide/#script_execution_using_the_hot_rod_c_client_2
Another occurence of #11.

#46 https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.1/html-single/developer_guide/#hot_rod_node_js_client
Wrong JDG 7.1.Beta references and occurrences of #11 through the whole chapter.

#50 https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.1/html-single/developer_guide/#creating_and_using_infinispan_queries_in_red_hat_jboss_data_grid
I'm not sure what the guidlines are, is it OK to reference it as Infinispan (@mgencur)? It would be possible to do just "Querying", "Querying API" or "Query DSL"... But as I said, don't know what the guidelines are.
Also I see multiple occurences of #11.:
We should also note somewhere that if you want to use Querying, you have to use other Maven dependency:

<dependency>
 <groupId>org.infinispan</groupId>
 <artifactId>infinispan-embedded-query</artifactId>
 <version>${version.infinispan}</version>
</dependency>

#51 https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.1/html-single/developer_guide/#configure_indexing_programmatically
The code snippet should be updated, some of the methods are deprecated and some are even removed. Replace the code snippet with the following:

SearchMapping mapping = new SearchMapping();
mapping.entity(Author.class).indexed().providedId()
        .property("name", ElementType.METHOD).field()
        .property("surname", ElementType.METHOD).field();

Properties properties = new Properties();
properties.put(org.hibernate.search.cfg.Environment.MODEL_MAPPING, mapping);
properties.put("[other.options]", "[...]");

Configuration infinispanConfiguration = new ConfigurationBuilder()
        .indexing()
        .index(Index.LOCAL)
        .withProperties(properties)
        .build();

DefaultCacheManager cacheManager = new DefaultCacheManager(infinispanConfiguration);

Cache<Long, Author> cache = cacheManager.getCache();
SearchManager sm = Search.getSearchManager(cache);

Author author = new Author(1, "FirstName", "Surname");
cache.put(author.getId(), author);

QueryBuilder qb = sm.buildQueryBuilderForClass(Author.class).get();
Query q = qb.keyword().onField("name").matching("FirstName").createQuery();
CacheQuery cq = sm.getQuery(q, Author.class);
Assert.assertEquals(cq.getResultSize(), 1);

#52 https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.1/html-single/developer_guide/#field
I'm not sure why the descriptions of analyze and norms are in the black boxes.

#53 https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.1/html-single/developer_guide/#analyzer_definitions
Second code snippet, change it to:

Analyzer analyzer = Search.getSearchManager(cache).getAnalyzer("customanalyzer")

#54 https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.1/html-single/developer_guide/#retrieving_an_analyzer
I'm not sure why the description of stemming analyzer is in a black box.
Also change the following code snippet to

SearchManager manager = Search.getSearchManager(cache);

org.apache.lucene.queryparser.classic.QueryParser parser = new QueryParser(
        org.apache.lucene.util.Version.LUCENE_5_5_1,
        "title",
        manager.getAnalyzer(Song.class)
);

org.apache.lucene.search.Query luceneQuery =
        parser.parse("title:sky Or title_stemmed:diamond");

// wrap Lucene query in a org.infinispan.query.CacheQuery
CacheQuery cacheQuery = manager.getQuery(luceneQuery, Song.class);

List result = cacheQuery.list();
//return the list of matching objects

Also after the snippet, change the "searchFactory" to "searchManager" to be clearer.

#55 https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.1/html-single/developer_guide/#analyzerdef_for_solr
https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.1/html-single/developer_guide/#available_analyzers

I'm not sure why we mention Apache Solr in our documentation, I think it's obsolete technology now. It should be Hibernate Search instead. @anistor, could you confirm?

#56 https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.1/html-single/developer_guide/#building_a_lucene_query
Last paragraph before the first code snippet, last sentence:
"The QueryBuilder is derived from the SearchFactory."

should be changed to:
"The QueryBuilder is derived from the SearchManager."

Also the next (the second) code snippet should be changed to:

SearchManager searchManager = Search.getSearchManager(cache);
        QueryBuilder mythQB = searchManager.buildQueryBuilderForClass(Myth.class)
                .overridesForField("history","stem_analyzer_definition")
                .get();

#57 https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.1/html-single/developer_guide/#building_a_lucene_query
Section 17.2.3.2. Keyword Queries, below Table 17.1. Keyword query parameters
The is a missformated highlighting in the first point "history FieldBridge".

The next code snippet should be changed a bit. Change:
public Date setCreationDate(Date creationDate) { ...

to
public void setCreationDate(Date creationDate) { ...

#58 https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.1/html-single/developer_guide/#building_a_lucene_query
Subsection 17.2.3.3. Fuzzy Queries
The code snippet should be changed to:

Query luceneQuery = mythQB.keyword()
        .fuzzy()
        .withEditDistanceUpTo(1)
        .withPrefixLength(1)
        .onField("history")
        .matching("starm")
        .createQuery();

Also the first two sentences in the following paragraph should be replaced with (or something like that):
"The withEditDistanceUpTo is the maximum value of the edit distance (Levenshtein distance) to consider two terms matching. It is an integer 0 and 2 and the default value is 2. "

#59 https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.1/html-single/developer_guide/#building_a_lucene_query
Subsection 17.2.3.7. Combining Queries
In the code snippet, there is one place in the third query that uses "mythQb" instead of "mythQB". Latter is the correct one.

#60 https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.1/html-single/developer_guide/#building_a_lucene_query
Subsection 17.2.4.3. Sorting
In the code snippet,, replace "SortField.STRING" with "SortField.STRING_FIRST"

#61 https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.1/html-single/developer_guide/#building_a_lucene_query
Subsection 17.2.4.6. Raise an Exception on Time Limit

SearchManagerImplementor searchManager = (SearchManagerImplementor) Search.getSearchManager(cache);
searchManager.setTimeoutExceptionFactory(new MyTimeoutExceptionFactory());
CacheQuery cacheQuery = searchManager.getQuery(luceneQuery, Book.class);

//define the timeout in seconds
cacheQuery.timeout(2, TimeUnit.SECONDS);

try {
    cacheQuery.list();
}
catch (MyTimeoutException e) {
    //do something, too slow
}

private static class MyTimeoutExceptionFactory implements TimeoutExceptionFactory {
    @Override
    public RuntimeException createTimeoutException(String message, String queryDescription) {
        return new MyTimeoutException();
    }
}

public static class MyTimeoutException extends RuntimeException {
}

#62 https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.1/html-single/developer_guide/#result_size
Code snippet Determining the Result Size of a Query, correct it to:

CacheQuery cacheQuery = Search.getSearchManager(cache).getQuery(luceneQuery,
                Book.class);
//return the number of matching books without loading a single one
assert 3245 == cacheQuery.getResultSize();

CacheQuery cacheQueryLimited =
        Search.getSearchManager(cache).getQuery(luceneQuery, Book.class);
cacheQuery.maxResults(10);
List results = cacheQuery.list();
assert 10 == results.size();
//return the total number of matching books regardless of pagination
assert 3245 == cacheQuery.getResultSize();

#63 https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.1/html-single/developer_guide/#understanding_results
In the first sentence is "Luke ...". I was actually quite confused what a Luke is, hence I would add a link to it: https://github.com/DmitryKey/luke

#64 https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.1/html-single/developer_guide/#enabling_infinispan_query_dsl_based_queries
Same as #17.

#65 https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.1/html-single/developer_guide/#hr_cpp_remote_querying
Ther are JDG Z.1.Beta references in sections 20.4, 20.5.

#66 https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.1/html-single/developer_guide/#enable_jmx_for_cachemanagers
In the code snippet, there are two dots in front of globalJmxStatistics(). One is correct.

#67
https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.1/html-single/developer_guide/#monitoring
https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.1/html-single/developer_guide/#red_hat_jboss_data_grid_as_lucene_directory

These sections above are located under PART II. CREATING AND USING INFINISPAN QUERIES IN RED HAT JBOSS DATA GRID, but it doesn't really make sense, because it has nothing to do with Infinispan Query, hence these chapters should be moved somewhere else. I suggest part IV. ADVANCED FEATURES IN RED HAT JBOSS DATA GRID.

#68 https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.1/html-single/developer_guide/#red_hat_jboss_data_grid_modules
There is a reference to JBoss EAP 6. I would remove the "6", since it can be used in both 6 and 7.

I have one more issue in mind, but first I need to consult it more with devs. Uff, sorry about that :-D