VMware

vFabric GemFire 6.6.3 Release Notes

vFabric GemFire 6.6.3 | 13 JUN 2012

Last Document Update: 16 OCT 2012

What's in the Release Notes

The release notes cover the following topics:

What's New in vFabric GemFire 6.6.3

vFabric GemFire 6.6.3 includes the following changes and enhancements. This release also incorporates changes and enhancements from vFabric GemFire 6.6.0 and 6.6.1 and vFabric GemFire 6.6.2.

  • Numerous bug fixes and performance enhancements. For a list of specific bugs that were fixed, see Resolved Issues.
  • In GemFire 6.6.2, you can configure the parallel dispatching of gateway events by setting the gateway concurrency-level greater than 1. The ordering for such events in 6.6.2 is based on either "key" (which means all updates to the same key are sent in order) or based on "thread" (which means that all updates from a thread are sent in order.)

    In GemFire 6.6.3, we have added support for ordering gateway events that share the same partitioning key when custom partitioning is used. When applications use the PartitionResolver, then all entries that share the same "partitioning key" (RoutingObject) are guaranteed to be dispatched in order. You configure this ordering by using order-policy="partition". For example, in cache.xml:

    <gateway id="DB1" concurrency-level="10" order-policy="partition">

    or in the Java API:

    Gateway gateway = ...;
    gateway.setOrderPolicy(Gateway.OrderPolicy.PARTITION);
    For more information on using concurrent gateways, see the Multi-site Configuration chapter under "Topologies and Communication" and the Events and Event Handling chapter under "Developing with vFabric GemFire."

  • Option to send a gateway event to a subset of gateway hubs. Previously a gateway event could be sent to either one gateway hub or to all of them. Now it can be sent to a subset of gateway hubs. To configure a subset of gateway hubs, supply the hub id with a comma-separated list of gateway hub ids. For example, in cache.xml:
    <region-attributes ... enable-gateway="true" hub-id="DB1,DB2">

    or in the Java API:

    RegionFactory factory = ...;
    factory = factory.setGatewayHubId("DB1,DB2");
     
  • Performance enhancement for client single-hop access to partitioned regions. When using client single-hop access (pr-single-hop-enabled=true), you can also set thread-local-connections=true, which configures threads to use dedicated connections. This can help you improve performance by scaling the number of client connections.
  • Addition of a ping message from server to client to prevent idle subscription connections from being dropped by the firewall. This ping message helps in the case where no normal messages are being sent between the server and client.

The following changes apply to vFabric Suite 5.2 components, including vFabric GemFire:

  • New vfabric repository RPM. As with each new release of vFabric Suite, if you use Red Hat Enterprise Linux (RHEL), you install a new VMware repository configuration RPM. This new installation enables you to easily browse and install the vFabric component RPMs associated with vFabric Suite 5.2, such as vFabric GemFire 6.6.3. In addition, the 5.2 repository RPM installation now asks you immediately to accept the End User License Agreement (EULA). In previous releases, you accepted the EULA the first time you installed a vFabric component associated with the Suite release. See RHEL: Install vFabric GemFire from the VMware RPM Repository.
  • vfabric-all repository deprecated. The VMware RPM repository vfabric-all is deprecated and will no longer be updated with new RPMs.

Upgrading to vFabric GemFire 6.6.3

To upgrade from an earlier version of GemFire to the current version, see the Upgrading vFabric GemFire topic in the vFabric GemFire User's Guide under "Getting Started with vFabric GemFire." Also review product changes documented in What's New in vFabric GemFire 6.6.3.

In addition, if you are upgrading to vFabric GemFire 6.6.3 from a version of GemFire earlier than 6.6.0, see the vFabric GemFire 6.6.1 and 6.6.0 Release Notes and vFabric GemFire 6.6.2 Release Notes to determine what changes are required for you to migrate to vFabric GemFire 6.6.X.

Note: Starting in 6.6.2, GemFire uses a new PDX serialization format. If you use PDX serialization and are performing a rolling upgrade from GemFire 6.6.0 or GemFire 6.6.1 to GemFire 6.6.3, you must set the system property -Dgemfire.serializationVersion=6.6.0 or -Dgemfire.serializationVersion=6.6.1 (as appropriate) on each member that is being upgraded to 6.6.3. See the Upgrading to GemFire 6.6.2 section in the vFabric GemFire 6.6.2 Release Notes for additional details. If you are upgrading from GemFire 6.6.2 to 6.6.3, you do not need to set the -Dgemfire.serializationVersion system property.

Resolved Issues

For a list of bugs that are fixed in GemFire 6.6.3 and that are resolved in the VMware bug tracking system, see BugsFixedGemFire663.html.

In addition, the following bugs related to the vFabric GemFire modules have been fixed:

  • Only create a single pool that has been configured in cache-client.xml. This issue has been resolved.
  • gemfire-modules-session-external jar does not get embedded in a war when the war file is embedded within an ear file. This issue has been resolved.
  • CommitSessionValve throws exception on invalidated sessions. This issue has been resolved.
  • slf4j jars are missing from Tomcat distribution. This isue has been resolved.

Known Issues

For a list of issues that have been registered as bugs in the VMware bug tracking system, see BugNotesGemFire663.html.

Java applications on 64-bit platforms hang or use 100% CPU

If your Java applications suddenly start to use 100% CPU, you may be experiencing the leap second bug. This bug is found in the Linux kernel and can severely affect Java programs. In particular, you may notice that your GemFire locators hang upon start up and method invocations using Thread.sleep(n) where n is a small number will actually sleep for much longer period of time than defined by the method.

To verify that you are experiencing this bug, check the host's dmesg output for the following message:

[10703552.860274] Clock: inserting leap second 23:59:60 UTC

To fix this problem, issue the following commands on your affected Linux machines:

prompt> /etc/init.d/ntp stop
prompt> date -s "$(date)"

See the following web site for more information:

http://blog.wpkg.org/2012/07/01/java-leap-second-bug-30-june-1-july-2012-fix/