|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
||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.|