Known Issues in GemFire 6.6.2

Last updated: 05/02/2012

Ticket Created Title Description Workaround
#40791 06/11/09 Applications that use GemFire cache client processes should call Cache.close followed by DistributedSystem.disConnect If applications do not call DistributedSystem.disConnect, stale data may be encountered when the client reopens the cache and subscribes to updates. Applications that use GemFire cache client processes should call Cache.close followed by DistributedSystem.disConnect.
#42009 05/25/10 SystemConnectException thrown during connect after coordinator reports missing view acknowledgements Under highly volatile membership conditions there are cases where a new member is unable to join the distributed system when it should be able to. The membership coordinator reports missing view acknowledgements from one or more processes, including the new member. After the coordinator accepts the new member and sends out a new membership view, the new member should recognize that it has joined the distributed system. The new member should also acknowledge the new membership view. When this exception appears, it signals that these activities may not have occurred. Try reconnecting to the distributed system.
#42041 06/07/10 Calling Function.onServer repeatedly can cause socket exhaustion Heavy use of Function.OnServers from a client can cause sockets to churn and will cause "Too many open files" errors on the locator. If users see "Too many open files" errors as part of repeatedly calling Function.OnServers(), they should increase the ulimit settings on the box to avoid the issue. For example, on Windows, change TcpIP/Parameters/NumConnections in the registry.
#43536 06/07/11 Function APIs require that classes exist in the JVM's classpath The function APIs perform early deserialization during messaging of function results, filters, arguments, and the functions themselves. So the class for these objects must be on the JVM's classpath. It is not possible to define your own class loader just before you read a function result or get the arguments passed to your function code. Add the classes for functions, function arguments, function filters, and function results to your JVM's classpath.
#43750 07/27/11 Gateway toString erroneously indicates that the Gateway is connected The Gateway toString message indicates that the Gateway is connected to the remote site even when it is not connected. Here is an example: [info 2011/07/26 15:46:57.598 EDT <main> tid=0x1] Started Primary Gateway to LN connected to [LN-1=ln_host_1:6622, LN-2=ln_host_2:6622] To see if the Gateway is not actually connected, look for a warning like the following: [warning 2011/07/26 15:46:57.527 <main> tid=0x1] Primary Gateway to LN not connected to [LN-1=ln_host_1:6622, LN-2=ln_host_2:6622]: Could not connect. To see when the Gateway does connect to the remote site, look for a message like the following: [info 2011/07/26 16:07:36.187 EDT <Gateway Event Processor from NY to LN> tid=0x154] Primary Gateway to LN connected to [LN-1=ln_host_1:6622, LN-2=ln_host_2:6622]: Using com.gemstone.gemfire.cache.client.internal.pooling.PooledConnection@1bb1849: Connection[ln_host_2:6622] after 81 failed connect attempts
#43758 07/29/11 Suspended transaction from function execution unusable after primary rebalancing When multiple invocations of a function participate in a single transaction (suspending and resuming transactions for each invocation), a HA event may rebalance primaries, and it will not be possible to target the original transactional node for function execution. Use the system property gemfire.DISABLE_MOVE_PRIMARIES_ON_STARTUP to allow function execution to target the same member.
#43849 08/23/11 Attempts to use a writable-working-dir over NFS may result in hangs involving NIO file locking Attempting to use a writable-working-dir over NFS may result in hangs involving NIO file locking. Licensing uses java.nio.channels.FileChannel.lock to lock the license state and events files that are persisted to writable-working-dir. The call to FileChannel lock may hang in the JVM native layer. The stack dump of the hung thread may look similar to the following:
java.lang.Thread.State: RUNNABLE
    at Method)
    at java.nio.channels.FileChannel.lock(
    - locked <0xe02f5a80> (a java.lang.Object)
    at com.springsource.vfabric.licensing.client.LicenseManagerEnvironment.<init>(
    at com.springsource.vfabric.licensing.client.LicenseManagerFactory.getLicenseManager(
    at com.gemstone.gemfire.internal.licensing.VFabricLicenseEngine.getLicenseManager(
    at com.gemstone.gemfire.internal.licensing.VFabricLicenseEngine.acquireLicense(
    at com.gemstone.gemfire.internal.licensing.CacheLicenseChecker.acquireLicense(
    at com.gemstone.gemfire.internal.licensing.LicenseChecker.acquireLicense(
    - locked <0xe02604c8> (a com.gemstone.gemfire.internal.licensing.ServerLicenseChecker)
    at com.gemstone.gemfire.distributed.internal.InternalDistributedSystem.getLicenseChecker(
    - locked <0xdfd56c28> (a java.util.concurrent.atomic.AtomicReference)
    at com.gemstone.gemfire.distributed.internal.InternalDistributedSystem.initialize(
    at com.gemstone.gemfire.distributed.internal.InternalDistributedSystem.newInstance(
    at com.gemstone.gemfire.distributed.DistributedSystem.connect(
Specify a directory on a local drive for writable-working-dir instead of a directory that is accessed through NFS. The property writable-working-dir is specified in
#43866 08/26/11 Cache plugins may fail if read-serialized is true If read-serialized is set to true on your cache and you have plugin classes (for example CacheListener, CacheWriter, CacheLoader), then when those plugins are serialized as a PDX, the plugin will fail because GemFire will see the plugin as an instance of PdxInstance. This problem only occurs if your plugins are serialized as PDX because you have implemented PdxSerializable or have a PdxSerializer that will serialize the plugin class. Note that classes that implement Function are never passed to a PdxSerializer but can still implement PdxSerializable and then fail just like the other plugins. Do not implement PdxSerializable or change your PdxSerializer to serialize that plugin class. Instead, make your plugin class implement DataSerializable. This will prevent the plugin from being serialized by a PdxSerializer.
#43904 09/13/11 Gateways started before regions are created can cause updates to be lost If gateways are restarted and connected to remote sites before the local regions are created, then any events received by those gateways will cause exceptions and be dropped. In the case where gateways are defined in the same JVMs as the regions using xml, proper startup order is maintained and this will not happen. In the case where gateways are created and started in JVMs separate from those where regions are created, startup ordering may not be correct. Make sure that gateways are started after regions are created and initialized. In the case where gateways are created and started in JVMs separate from those where regions are created, they should be manually started after the regions are created. A RegionMembershipListener can be used to facilitate this.
#44229 11/30/11 Destroy operation on a region cause offline member to become unusable When some members are offline, a destroy (or local destroy) operation on a persistent region will cause the offline member to be unable to start. Start all offline members before destroying a persistent region.
#44399 01/19/12 Changing the distributed-system-id can cause PDX failures If the distributed-system-id is changed and a previously used one is re-used, then PdxType conflicts can occur. Do not change the distributed-system-id after it has been set.
#44404 01/19/12 Partitioned region single hop may fail to direct load balance requests to a newly joined server when optimize-for-write is set to false This problem is caused by stale metadata on the client. The problem occurs when the client is only performing read operations, and a Function has optimize-for-write set to false. Any write operations into the region will fix the problem. Perform a write operation into the region to fix the problem.
#44410 01/20/12 The load-conditioning-interval property does not work as expected when connecting to explicit endpoints When the load-conditioning-interval property is used with explicit servers instead of with locators, connections are still recycled after 5 minutes. The property works as expected when you are using locators to obtain connections for server communication. Use locators to obtain connections for server communication.
#44411 01/20/12 Querying on an enum field always returns an empty result set Querying on enum fields will return an empty result set even when there are qualifying rows. The only workaround available for this issue is to use a bind parameter for the enum field in the query. e.g. This query fails: select distinct * from /QueryRegion0 where aDay = Day.Wednesday When rewritten as : select distinct * from /QueryRegion0 where aDay = $1 and Day.Wednesday is passed as execution parameter, it succeeds
#44436 01/25/12 Implicit method invocation is not supported on PDX objects When the query engine needs to fetch a value from an object, it first looks for the public attribute by that name (symbol). If the name is not found, it creates an implicit getter method "getSymbol()" and tries to see if the method is available. If available, it fetches the value by invoking the method call. Currently, implicit method invocation is not supported on PDX types. In order to invoke an object's method during querying, you must call the method explicitly within the query string.
#44537 02/15/12 Cannot launch remote Cache Server/Locator from JMX Agent even after specifying 'remote-command' The JMX Agent property 'remote-command' is used to specify a remote command prefix, which invokes the commands that launch cacheserver & locator processes on remote machines. Currently, this functionality does not work.
#44576 02/23/12 Query acts as if a non-existent field exists A query may act as if a non-existent field exists and has the default value for the field type. This can only happen if the class that contains the field has been PDX serialized and you have at least two versions of your class; one without the field ("V1"), and one with the field ("V2"). The problem will only happen in a JVM in which the query execution originated when the JVM has read-serialized equal to false. Under these conditions, the query thread will deserialize the PDX back into a domain class. If the serialized data represents "V1" but the query thread deserializes the PDX into an instance of "V2", then the query will act as if the non-existent field exists. However, if read-serialized is set to true or if the query originated in a remote JVM, then the query will just use a PdxInstance for "V1"'s serialized data and will act as if the non-existent field does not exist. If your code invokes queries on objects that may have different versions, set read-serialized to true.
#44606 02/29/12 Registration of instantiators can cause Gateway deadlock Gateways experience deadlock when trying to register instantiators. The work-around is to register the instantiators in the hubs prior to creating the cache. This will prevent the InternalInstantiator .sendRegistrationMessageToServers call
#44617 03/02/12 Multiple callbacks for same transactional operation When a client initiated transaction fails over to new server, the first operation after failover can incorrectly have two callback events.
#44625 03/05/12 DiskAccessException in one peer causes a failure in another peer When updating a persistent partitioned region, if one member receives a DiskAccessException when writing to disk (for example, if the disk is full), their is a chance that one of the peers which did not receive the DiskAccessException may also close the region and bridge server. Ensure that sufficient space is available for gemfire persistent files. If this situation is encountered, fix the space issues and restart the failed members.
#44627 03/06/12 If the cacheserver status file (.cacheserver.ser) is deleted, the cacheserver shuts down The cacheserver's working directory contains a status file called .cacheserver.ser. This file is used for inter-process communication when stopping/starting a cacheserver. If this file or the directory containing it is deleted, the cacheserver shuts down. Do not delete the .cacheserver.ser file or the directory containing it.
#44636 03/07/12 Locator log file name cannot be changed Using the gemfire start-locator command, the locator log is always called locator.log and is located in the working directory. There is no way to change this. If the log-file property is defined in the file, it is ignored. There is no workaround for this issue. Customers should not try to set the locator log file name.
#44924 04/18/12 JMX Agent ignores JMX Agent reads properties from the or from the file specified by Agent command line option 'property-file'. JMX Agent ignores the file. Specify the SSL/security configuration system properties as arguments on the command line when starting the JMX Agent.