GemFire Bugs Fixed in 6.6.1

Context Navigation

Created	ID	Summary	Bug Description	Workaround for Previous Versions
2011/07/29	#43757	Need new gemfire property: license-server-timeout	If "dynamic" is specified for either license-data-management or license-application-cache, but a vFabric License Server is not found or is not configured with the expected license, then startup of the GemFire instance may be delayed by 30 seconds. When GemFire attempts to acquire a license from a vFabric License Server it must go into a polling loop which terminates either when a license is attained or a timeout is reached. This timeout is currently hardcoded to 30000 milliseconds and can only be overridden by a System property: gemfire.licensing.licenseServerTimeout This polling loop is only entered if the keyword "dynamic" is specified instead of a serial number for either license-data-management or license-application-cache. This issue has been fixed. See "license-server-timeout" in the gemfire.properties reference section of the vFabric GemFire 6.6. User's Guide.	Specify a serial number instead of "dynamic" unless a vFabric License Server is correctly installed and configured.
2011/08/03	#43778	LicenseChecker logs nonsensical warning if writable-working-dir is set to current working dir which is read-only	This issue has been fixed.
2011/08/18	#43826	Fail startup if invalid non-default licensing is configured instead of using default evaluation license.	This issue has been fixed.
2011/08/18	#43827	Log when failing to acquire license from vFabric License Server needs better wording	The text of the WARNING that is logged when attempting to acquire a license from the vFabric License Server fails to acquire a server license is: "The specified serial number "dynamic" may be expired or invalid for Data Management Node license. Using default evaluation license." or "The specified serial number "dynamic" may be expired or invalid for Application Cache Node license. Using default evaluation license." It currently uses the same log statement as if a configured serial number failed to validate, but prints "dynamic" as the serial number. This means that GemFire failed to dynamically acquire a license from the vFabric License Server within the 30 second timeout. This issue has been fixed.	1) Verify that GemFire is being started in an ESX VM that has access to a properly configured vFabric License Server. 2) Verify that "dynamic" was used for either license-data-management or license-application-cache (not both) and that the vFabric License Server contains a license for that GemFire node type. 3) Try setting the license server timeout higher if it is currently too low. In GemFire 6.6.0, the default is 30000 milliseconds which can be overridden using the System property gemfire.licensing.licenseServerTimeout. Specify an integer in milliseconds.
2011/08/23	#43848	licensing may acquire a license from a vFabric License Server without specifying dynamic	GemFire may acquire a license from vFabric License Server without specifying dynamic for one of the license properties in gemfire.properties. If license-data-management and license-application-cache are both left empty, then GemFire may be able to acquire a license dynamically without waiting for it. Normally, GemFire will wait for up to the license server timeout which is 30 seconds by default; adjustable by changing the system property gemfire.licensing.licenseServerTimeout which specifies the timeout in milliseconds. It may be possible for one member to acquire a server license while another member acquires the default evaluation license. These two licenses are incompatible and are not allowed to co-exist within one distributed system. If this happens one or more GemFire members may throw IncompatibleSystemException during startup. This issue has been fixed.	If you are running GemFire on a VM that has access to a vFabric License Server which contains serial numbers usable by GemFire, then you should consistently use the keyword dynamic for either license-data-management or license-application-cache in gemfire.properties.
2011/08/23	#43850	Default for license writable-working-dir may be too confusing or surprising	A LicenseException may be thrown when starting or stopping a GemFire process if the local VMware vFabric directory contains license state or events files that are not writable by the current user. For example, if a vf.gf.dmn-license.cfg already exists in /opt/vmware/vFabric on a VM, then GemFire may fail to startup if the current user does not have write permission for that file. The resulting exception may look like: com.gemstone.gemfire.LicenseException: Failed to access/create local file /opt/vmware/vFabric/vf.gf.dmn-license.cfg: java.io.FileNotFoundException: /opt/vmware/vFabric/vf.gf.dmn-license.cfg (Permission denied). This issue has been fixed. Note that the "writable-working-dir" property is now replaced by "license-working-dir" in GemFire 6.6.1. See the gemfire.properties reference section of the vFabric GemFire 6.6. User's Guide for details.	One solution is to ensure that all users sharing a common VMware vFabric directory, such as /opt/vmware/vFabric, have a umask that allows each other to write to files they create. Another solution is to specify a writable-working-dir in gemfire.properties that is not shared with other users.
2011/08/30	#43871	Various gfsh issues	Fixed Issues: a) When starting gfsh, there used to be a pause to wait for user input after the banner text. Removed pause so that the user sees the gfsh prompt immediately. b) Improved error handling when wrong options are supplied to 'put' & 'debug' commands.
2011/09/14	#43905	Issues with 'ls' command in gfsh	Fixed Issues: a) 'ls' command now reports an error if multiple arguments are supplied. Multiple arguments are not allowed. b) 'ls -c' now works with a user specified region as a parameter.
2011/09/26	#43941	Peer and client counting per node is incorrect for licensing and may result in false license limit alerts	GemFire 6.6.0 may log false alerts about exceeding license limits for peers and/or clients. These alerts are caused by a bug in how GemFire interprets the quantity information in the license. Example of alert about exceeding peer limit: [severe 2011/10/16 14:53:00.872 PDT gemfire_2_1 tid=0x73] The number of peers, 2, exceeds the limit of 1 allowed by your Application Cache Node license "#####-#####-#####-#####-#####". Example of alert about exceeding client limit: [severe 2011/10/16 13:22:29.132 PDT tid=0x1] The number of clients, 6, exceeded the limit of 5 allowed by your license. This issue has been fixed.	Ignore false alerts that are logged about exceeding license limits for peers and/or clients.
2011/09/28	#43954	Licensing assumes 5 clients per server without Unlimited Client Upgrade	This issue has been fixed.
2011/09/28	#43959	cacheserver start throws NullPointerException	The cacheserver command shell script invokes the com.gemstone.gemfire.internal.cache.CacheServerLauncher Java class to start a GemFire Cache Distributed Member as a server. It is entirely possible for the .cacheserver.ser file to be left behind, for instance after a Cache Server crashes. It is also possible that the .cacheserver.ser file gets corrupted. Either way, the CacheServerLauncher class incorrectly handles the case when the file remains assuming that it will always be read correctly. When it cannot be read, the readStatus method and spinReadStatus method will return a null reference causing the check on the Status object's 'state' to throw a NullPointerException. In this situation, the check should just assume that the Cache Server process is no longer running and delete the existing .cacheserver.ser file. This is the behavior implemented by the fix.
2011/09/30	#43962	Existing locator hangs after recovering crashed machine	This issue has been fixed.
2011/10/07	#43987	discoverJTA() throws FailedSynchronizationException	This issue has been fixed.
2011/10/17	#44033	Recycled persistent datastores hang on restart with recovery threads stuck in GemFireCacheImpl.getHighestOrderHubTypeAssociatedWith()	This issue has been fixed.
2011/10/17	#44035	Licensing client logging only works for first GF connection and then results in a LogWriter reference leak	This issue has been fixed.
2011/10/31	#44107	license-data-management should allow spaces around multiple serial numbers and commas	This issue has been fixed.

Created	ID	Summary	Bug Description
2011/09/28	#25	The RegionSizeFunction causes the cache xml generator to fail in debug mode	The RegionSizeFunction causes the cache xml generator to fail in debug mode (enable.debug.listener=true). This issue has been fixed.
2011/10/05	#26	When a Hibernate application uses enums, application classes are required on the GemFire cache server	When a Hibernate application uses enums, application classes are required on the GemFire cache server. This issue has been fixed. You can now avoid having to put application classes on the GemFire cache server by using com.gemstone.gemfire.modules.hibernate.EnumType in place of org.hibernate.type.EnumType by modifying the Hibernate configuration.
2011/10/07	#27	Not all GemFire cache servers bootstrapped by Hibernate Cache Module	Hibernate Cache Module now bootstraps on all available GemFire cache servers. This prevents a potential imbalance in region creation for client/server deployments with a small number of clients.
2011/10/20	#28	Modify default session attribute persistence policy from 'delta_immediate' to 'delta_queued'	For the generic HTTP session replication module, session attribute changes are immediately propagated. This provides greater integrity, but reduced performance. Using the delta_queued policy batches up changes for propagation just prior to the session going out of scope (i.e. once the complete servlet/filter chain has been processed) and the response being sent back to the client. Setting delta_queued as the default aligns with similar default functionality for the tcServer HTTP module.
2011/10/20	#29	For tcServer HTTP module modify default persistence policy to commit at the end of each request	Currently the tcServer HTTP module persists session attribute changes as they are made. To fix this, enable CommitSessionValve by default in order to persist changes at the end of each request.