Fixed Issues in GemFire 8.1.0

Last updated: January 28, 2015

Id Title Description Workaround for earlier gemfire versions
#51694 Index creation with gfsh fails when region had multiple levels. In gfsh index creation used to fail when region reference had nested levels: E.g.: create index --name=keyIndex --region="/Portfolio p, p.primaryPosition.positionList l" --expression="l.keyValue"
#51661 The REST API forces pdx read-serialized to be true while doing cluster configuration The REST API forces pdx read-serialized to be true while doing cluster configuration.
#51604 Modifying the PutAllOperationContext map is not supported The PutAllOperationContext getMap method returns a Map which allows keys to be added and removed. This is not supported. The PutAllOperationContext setMap method allows a map to be set that is null or whose iteration order is different than the original map or that has a different number of keys or just different keys. None of these are supported. Do not use the setMap method. Instead only use getMap and only do puts on the returned map on keys that the map already contains. You can also do entry iteration and call the Map.Entry setValue method. All other modifications can cause the putAll operation to not function correctly.
#51538 getAll may fail with IndexOutOfBoundsException The Region getAll method may fail with "IndexOutOfBoundsException: Cannot add object part beyond 100 elements". This can happen if you have installed an instance of AccessControl (using either the "security-client-accessor" or "security-client-accessor-pp" gemfire property) that denies authorization to a GetOperationContext.
#51526 GemFire Time Service creates a non-daemon thread that can prevent a VM from exiting Normaly the time service will shut down this thread when GemFire shuts down, but in the event that it does not this thread can keep a VM from exiting.
#51477 Query using ORDER BY throws ClassCastException if any value of the ORDER BY field is UNDEFINED In OQL when order by query is executed on field with UNDEFINED value, the query engine is throwing ClassCastException.
#51352 A new option to both the 'start locator' and 'start server' commands in Gfsh is the --include-system-classpath to allow the System CLASSPATH env. var to be "appended" to the Locator's/Server's CLASSPATH on start. In 8.0, the ability to include the System CLASSPATH environment variable as removed. In general, it is bad practice to set and use the System CLASSPATH environment variable for your Java applications as this affects all Java applications on the host system. New 8.1 is the ability to specify the --include-system-classpath option to both the 'start locator' and 'start server' Gfsh commands. This enables the user to "append" the value of the System CLASSPATH environment variable to the Locator's/Server's CLASSPATH on start. This is not the default behavior/option so you must explicitly specify --include-system-classpath to have the $CLASSPATH included. To specify application classes, the user had to use the --classpath option to the 'start server' command. Unfortunately, the 'start locator' had no such --classpath option. Refer to #50054 to workaround this limitation.
#51302 JSONFormatter - Automatically round the bigdecimal to float and bigint to int JSONFormatter - Automatically round the values of type bigdecimal to float due to the limitation of Jackson parser used. Applications should specify BigDecimal values as a String (enclosed with double quote) in JSON doc". These values will be parsed/stored as a strings inside gemfire and Applications/users has to take care for getting meaningful BigDeciaml values out of this string representation.
#51294 Manual start option for GatewayReceivers when configured with cache.xml There is no option to manually start GatewayReceivers when configured with cache.xml like GatewaySenders.
#51201 'start server' command --spring-xml-location configuration option bug prevents SDG from fully and properly configure an GemFire Server data node instance with Spring config. A bug was introduced in r48037 for the new GemFire 8.0 release that prevents a Spring context configuration file from properly configuring and bootstrapping a GemFire Server data node when launch through Gfsh using the 'start server' command's new --spring-xml-location option. This bug is caused by a premature Cache instance creation shown in the code snippet in the bug description... {{{ final Properties gemfireProperties = getDistributedSystemProperties(getProperties()); this.cache = new CacheFactory(gemfireProperties).create(); // BUG }}} Before the instance creation is decided below based on whether the user specified --spring-xml-location option or used the old --cache-xml-file option... {{{ this.cache = (isSpringXmlLocationSpecified() ? startWithSpring() : startWithGemFireApi(gemfireProperties)); }}} Unfortunately, as a result, and GemFire Server cannot be fully and properly configured using Spring config since Spring Data GemFire performs a lookup first an any existing Cache instance in the JVM. As such, any Cache specific configuration (e.g. PDX) or DistributionConfig properties (e.g. log-level, ports, etc) specified in Spring config are effectively ignored. For instance, in the following Spring config... {{{ <beans ...> <context:property-placeholder location="classpath:server.properties"/> <!-- <util:properties id="gemfireCacheConfigurationSettings" location="classpath:gemfire.properties"/> --> <util:properties id="gemfireProperties"> <prop key="name">SpringGemFirePeerCacheWithFunctions</prop> <prop key="mcast-port">0</prop> <prop key="log-file">./SpringGemFirePeerCacheWithFunctions.log</prop> <prop key="log-level">config</prop> <prop key="jmx-manager">true</prop> <prop key="jmx-manager-http-port">9090</prop> <prop key="jmx-manager-port">1199</prop> <prop key="jmx-manager-start">true</prop> <prop key="groups">testGroup</prop> <!-- <prop key="locators">localhost[11235]</prop> <prop key="start-locator">localhost[11235]</prop> --> </util:properties> <gfe:cache properties-ref="gemfireProperties" pdx-serializer-ref=".." pdx-persistent="true" pdx-read-serialized="true" pdx-ignore-unread-fields="false"/> <gfe:cache-server auto-startup="true" bind-address="${server.bind.address}" host-name-for-clients="${server.hostname.for.clients}" port="${server.port}" max-connections="${server.max.connections}"/> <gfe:replicated-region id="AppData" persistent="false"/> <gfe:annotation-driven/> <bean class="org.spring.data.gemfire.cache.execute.RegionFunctions"/> </beans> }}} The gemfireProperties bean specifying GemFire DistributionConfig properties to the Cache instance when the DS is created will be ignored as will any Cache specific attributes settings, such as the PDX attributes above. This can cause unexpected/surprising behavior on application deployment since SDG will find the unconfigured, premature Cache instance (which is by design). However, the 'AppData' Region will still be created as wells as the GemFire Function registered in org.spring.data.gemfire.cache.execute.RegionFunctions class in this example. As well, an actual "Cache Server" will be started on the configured port so long as the system port is available for use. Most things beyond the basic Cache configuration (attributes and properties) should still work. The only workaround in 8.0.0 is to augment the Spring config with a cache.xml file like so... {{{ <gfe:cache cache-xml-location="/path/to/cache.xml" ..> }}} In the Spring config, to configure GemFire Distributed System properties or PDX, for example. Basically any attribute on the <gfe:cache> SDG XML namespace element or any of GemFire's DistributionConfig properties must be specified with cache.xml and GemFire Java System properties respectively. The only other option is to start Spring configured GemFire Server data nodes externally (not with Gfsh's 'start server' command --spring-xml-location option) using a simple Java class with a main method like so... {{{ public class SpringGemFirePeerCacheApp { public static void main(final String... args) { new ClassPathXmlApplicationContext(getSpringXmlConfigurationFile(args)) } } }}} You can be as sophisticated or simple as you like with your "launcher" class.
#51175 Collections are not supported in GFSH Data commands GFSH data commands do not support collections (maps and lists).
#51139 NPE thrown from VMStatsMonitor.refreshStats() with IBM JDK During upgrading older version GemFire to newer versions with IBM JDK we face this issue. This will cause MBean stats to be represented incorrectly.
#51120 Locator fails to start properly if ssl-enabled is set to true Locator fails to start properly if the GemFire property ssl-enabled is set to true and jmx-manager-ssl is also set to true. Note that the "ssl-enabled" property has been deprecated in favor of the "cluster-ssl-enabled" property in 8.0. Use "jmx-manager-ssl-enabled" instead of "jmx-manager-ssl" and replace "ssl-enabled" with "cluster-ssl-enabled'.
#51111 GemFire redirects Tomcat/application log When GemFire is embedded in a container such as Tomcat, it will redirect all JDK logging output to the configured gemfire log. Thus, output which would typically go to the 'catalina' log, will not appear there anymore but it will appear in the gemfire log. Configure Tomcat to use log4j as the logging framework.
#51102 Query incorrectly returns UNDEFINED if a collection field is null in any of the objects in the region If region contains objects with a field of type collection and one or more such objects have value of the field as NULL, a query executed on such field returns UNDEFINED even if the object that satisfies the query has non NULL value for the field.
#51085 Query using LIKE with integer field throws ClassCastException if a query has LIKE predicate comparing Integer field to String (integerField LIKE 'String') a ClassCastException is thrown when there is an index on the integerField.
#51083 Querying non primitive fields in Pdx serialized objects returns wrong results If a query is executed on pdx serialized objects and the where clause contains a comparison involving non primitive fields (nonPrimitiveFieldObject = objToBeCompared), the query returns incorrect results Use equals method instead of = operator
#50920 Fatal error from asynchronous flusher thread when attempting to write an entry with keyId=0 to oplog It's caused by the region is still initializing (GII from other member), and on going operations are retried. It only happened when using async disk writer. Hold on operations until regions are initialized when the regions are using async disk writer.
#50779 Improperly formatted query results in serialization exception on the parser exception If a query executed remotely from client on a server does not have correct syntax a SerializationException is returned instead of an error message string. Use correct query syntax
#50520 EvictionAttributes API is missing a factory method for a LRU EvictionAttributes API is missing a factory method for a LRU, Entry-based Eviction Policy provided an EvictionAction, but default the "maximum entries".
#50054 The 'start locator' Gfsh command now allows the user to specify a CLASSPATH with the --classpath option. Prior to GemFire 8.1, the 'start locator', command unlike the 'start server' command in Gfsh, did not allow you to configure the CLASSPATH of a Locator on start. New for GemFire 8.1 is the ability to configure the Locator CLASSPATH on start using the --classpath option. This option, like the 'start server' command's --classpath option is a "prepend" function. Any application classes supplied by the user is prepended to the Locator CLASSPATH minuse the gemfire.jar, which always appears first on the CLASSPATH for obvious (e.g. security) reasons. The user either needed to modify the $GEMFIRE/lib/locator-dependencies.jar Manifest-only JAR file, specifically modifying the Class-Path Manifest Header or... The user could use the GemFire public API LocatorLauncher class directly on the OS command-line like so... $java -server -cp "$GEMFIRE/lib/locator-dependencies.jar:/path/to/application/classes.jar com.gemstone.gemfire.distributed.LocatorLauncher start LocatorName --port=11235
#49539 These stats are never updated, currently. Following stats in CacheClientProxy are never updated: 1. messagesNotQueuedConflated 2. messagesFailedQueued 3. messagesNotQueuedOriginator 1. Use ClientSubscriptionStats-eventsConflated to find out number of events conflated for the client.
#47526 client statistics are unavailable in servers if enable-network-partition-detection=true Due to inability to cleanly shut down the component that collects client statistics in server caches this mechanism is disabled when network partition detection is enabled.
#45093 Clients may throw a Null Pointer Exception without a message if the client's server runs out of file descriptors Clients may throw a Null Pointer Exception that has no message if the client's server runs out of file descriptors. The exception may also be reported in the server's log. Increase the file descriptor limit to the appropriate level.
#44710 A region configured with persist-backup="true" and data-policy="persistent-partition" throws IllegalStateException A region configured with persist-backup="true" and data-policy="persistent-partition" throws IllegalStateException. Do not set the deprecated persist-backup attribute.
#43781 Region put may do multiple serializations of the value A Region put invocation may serialize the value multiple times. If the region being put on has a DataPolicy of EMPTY and it is in a cache server that clients have subscriptions on then one serialization will be done to push the value to peers of the server and another serialization will be done to push the value to the subscribed clients. If the region is using a disk store and it is not partitioned then it may be serialized twice; once to distribute it to peers and once to write it to disk. You could preserialize the value into a byte[] and put the byte[] in the region. But in this case all readers if the cache need to be changed to deserialize the byte[]. See the internal class com.gemstone.gemfire.internal.util.BlobHelper. You can use its static methods serializeToBlob and deserializeBlob.
#42431 Region expiration may take longer than expected GemFire only uses a single thread to process expired region entries. This can cause expiration to take longer than expected as the schedule expiration queue up waiting for this single thread to process them. This bug is even worse if the expiration needs to remove the entry from disk or do a network hop. If you are not using GemFire transactions or are willing for a transaction to fail because of a conflict caused by a concurrent expiration then in GemFire 6.6 you can set -Dgemfire.EXPIRATIONS_CAUSE_CONFLICTS=true. This allows expirations to take advantage of multiple threads. If you then set -Dgemfire.EXPIRY_THREADS=XXX where XXX is the number of threads to use for expiration then you will have multiple threads doing concurrent expirations.