|
#41973
|
05/13/10
|
InternalGemFireError: Unable to restore the persistent bucket after recovering from crash
|
When using persistent colocated partitioned regions, if a member crashes during the initial creation of a bucket, after recovery the member may throw an "InternalGemFireError: Unable to restore the persistent bucket" upon restart.
|
|
|
#42265
|
08/11/10
|
Hang with concurrent partitioned region operations
|
In very rare cases, if you have partitioned regions configured with persistence or overflow and have set conserve-sockets to false, several concurrent operations on different members can result in a hang.
|
|
|
#42458
|
11/11/10
|
Query and Cache operation in a deadlock
|
A query and cache operation (update, destroy) can be in a deadlock if Region has eviction enabled and persistence to disk is used for region entries. The deadlock can happen because of opposite sequence of locking of Region Entry and Index by cache operation thread and query thread. Query locks the Index first and then locks the Region Entry to read the value from disk. Cache operation thread locks Region Entry first and locks the Index later to update the index.
The fix resolves the deadlock by reversing the sequence of locking for cache operation thread for only overflow regions. This is avoided for other regions for performance reasons.
|
|
|
#42528
|
12/15/10
|
Locator embedded with CacheServer does not direct clients to that server
|
Embedding a locator in a cache server process using the start-locator gemfire property causes the locator to direct client connections to other cache servers instead of the server where the locator is embedded.
|
|
|
#42781
|
02/16/11
|
Extra invalidate event included in TxEvent
|
A transaction callback may wrongly get an extra invalidate event when invalidating an entry with a null value.
|
|
|
#42938
|
03/16/11
|
InternalGemFireError on client transaction failover
|
An InternalGemFireError error may be thrown when a client initiated transaction fails over on multiple server failures.
|
|
|
#43552
|
06/09/11
|
Persistent colocated regions with recovery-delay>=0 can hang on restart
|
Having several persistent partitioned regions that are colocated can result in a hang on restart if recovery-delay is set to a non zero value.
|
|
|
#43685
|
07/13/11
|
Severe alerts with ack-severe-alert-threshold set
|
When running with the ack-severe-alert-threshold property set, there may be severe messages logged to the system log that look like this:
"20 seconds have elapsed waiting for the partitioned region lock held by ...".
These severe alerts can be safely ignored.
|
Ignore severe alerts related to "waiting for the partitioned region lock" if ack-severe-alert-threshold is set.
|
|
#43752
|
07/27/11
|
TransactionDataRebalancedException thrown rather than TransactionDataNotColocatedException
|
When the colocation scheme is incorrect, transactions should throw aTransactionDataNotColocatedException. Instead the transactions throw TransactionDataRebalancedExceptions.
|
|
|
#43793
|
08/08/11
|
PdxSerializer javadocs have incorrect example code
|
The code example in the PdxSerializer javadocs is incorrect. The fromData method signature is incorrect.
The following is the corrected example:
public class User {
final public String name;
final public int userId;
public User(String name, int userId) {
this.name = name;
this.userId = userId;
}
}
public class MyPdxSerializer implements PdxSerializer {
public boolean toData(Object o, PdxWriter out) {
if (o instanceof User) {
User u = (User)o;
out.writeString("name", u.name);
out.writeInt("userId", u.userId);
return true;
} else {
return false;
}
}
public Object fromData(Class<?> clazz, PdxReader in) {
if (User.class.isAssignableFrom(clazz)) {
return new User(in.readString("name"), in.readInt("userId"));
} else {
return null;
}
}
}
|
|
|
#43805
|
08/11/11
|
Java level deadlock with expiration and partitioned regions
|
In rare cases when using partitioned regions with entry expiration, starting a new member or rebalancing can lead to a Java-level deadlock.
|
|
|
#43828
|
08/18/11
|
Query support for COUNT(*) aggregate function
|
COUNT queries (SELECT COUNT(*) from /regionName <where clause>) are now supported by the Gemfire Query Engine.
|
In older versions of GemFire, you can use (SELECT * FROM /region).size with replicated regions.
|
|
#43830
|
08/18/11
|
Cache XML parameterization for non-loner cache
|
Cache XML parameters for non-loner caches are not getting replaced by system properties or by using the gemfire property file. The fix puts the cache.xml parameter (Strings like ${parameter}) replacements in the correct cache config object in GemFire so that the parameter is replaced by the value passed in by the GemFire user.
|
|
|
#43835
|
08/19/11
|
Arrays of a domain class that is PDX serialized may cause exceptions when read-serialized is true or doing a query
|
When doing a query or if read-serialized is true, then an array of domain classes that is serialized as a PDX may cause exceptions.
The exceptions can be ClassNotFoundException or a failure to assign an element to the array. PdxInstanceImpl.hashCode or PdxInstanceImpl.equals will be in the call stack.
|
Change the array type to Object[] in your code.
|
|
#43838
|
08/19/11
|
PdxInstance.getField will always deserialize all nested arrays as Object[]
|
PdxInstance.getField will deserialize all arrays in that field's value as an Object[]. The only exception to this is array nested in an object that used standard java.io.serialization.
This can cause ClassCastException. For example if the field had a nested DataSerializable that also had a nested array, then the DataSerializable would try to cast the result of readObjectArray to its array type. This attempt would fail because the array was deserialized as an Object[].
|
|
|
#43876
|
09/02/11
|
IndexNameConflictException during cache startup
|
This exception can appear in cases where an index is created on a partitioned region using cache.xml, and the index creation request is sent to all nodes already containing that partitioned region. The fix suppresses the logging of this exception when it appears due to the above scenario.
|
|
|
#43896
|
09/09/11
|
Recovery of persistent member does not rebalance primaries
|
When a member hosting a persistent partitioned region recovers from disk, the primaries are not rebalanced on recovery unless the redundancy of the region is still impaired after recovery. This results in imbalanced primary load after a member is restarted.
|
|
|
#43899
|
09/12/11
|
Hang recovering persistent colocated regions with concurrent puts
|
When using persistent colocated regions, there is a race condition that may lead to hang if the persistent members are restarted while partitioned region accessors are doing concurrent puts. The concurrent put may trigger a bucket creation on one of data stores, which can lead to a deadlock.
|
Do not start the accessors until the persistent members have recovered.
|
|
#43910
|
09/15/11
|
6.5 disk store files may fail with NullPointerException during a 6.6 offline compaction
|
If you use GemFire 6.6 to do an offline compaction of a disk store that was created with GemFire 6.5, it may fail with a NullPointerException.
|
|
|
#43927
|
09/21/11
|
Deadlock resulting from simultaneous index creation and cache operations on persistent regions
|
Creating an index programmatically through the API while performing cache operations (update, destroy) can result in a deadlock if the Region has eviction enabled and if persistence to disk is used for region entries. The deadlock occurs when the cache operation thread first locks a Region Entry and then waits for index initialization. For overflow regions, the index initialization thread waits on a Region Entry lock in order to populate the index with existing Region Entries. The fix resolves the deadlock by reversing the cache operation thread's sequence of locking the Region Entry first and then waiting for index initialization. Instead, the cache operation waits for index initialization first. This sequence is used for overflow regions only and is avoided in other regions for performance reasons.
|
|
|
#43936
|
09/22/11
|
Some cache operations may fail during PDX auto serialization due to a CacheClosedException
|
Some cache operations may fail during PDX auto serialization because of a CacheClosedException. The CacheCloseException is ignored in certain cases, but a bug in the auto serializer caused it not to be ignored.
|
|
|
#44013
|
10/13/11
|
Incorrect results for queries using IN clause using numbers and the "short" field type
|
This issue occurred with queries that use the IN clause with numbers when the numbers are compared to a SHORT field. Queries return incorrect results because numbers in the IN clause are typecasted to Integer, and the comparison of Short and Integer always returns false. The fix for this issue now checks for field types and converts integers to shorts before performing any comparison.
|
|
|
#44045
|
10/18/11
|
Member receiving ConflictingPersistentDataException waits for conflicting member
|
If a member receives a ConflictingPersistentDataException upon startup and is later restarted, the restarted member may end up waiting for the member with which it detected a conflict.
|
After receiving a ConflictingPersistentDataException, if a member is restarted and is then determined to be waiting on the conflicting member, revoke the conflicting member.
|
|
#44046
|
10/18/11
|
Failure in index creation during region initialization brings down the cache
|
This is seen when multiple GemFire nodes are started at the same time, and the nodes start initializing the same partitioned region with indexes defined in the XML file.
As part of the region creation, the index creation messages are sent to the participating nodes. If the regions internal ID is not yet generated (early in the region creation stage), the receiver node returns an exception back to the sender node, which causes the sender to close its cache.
|
|
|
#44060
|
10/19/11
|
Some arrays are passed to PdxSerializer
|
If you add a PdxSerializer, it may be passed instances of Array.
|
If getClass().isArray(), then return false.
|
|
#44105
|
10/28/11
|
Problem when using DISTINCT and ORDER BY in the same query
|
Query using ORDER BY returns duplicate values even though the DISTINCT keyword is used. This problem occurs when a region (either local or partitioned) has duplicate values in the region. The fix corrects the internal object comparison and DISTINCT queries no longer return duplicate values.
|
|
|
#44112
|
11/01/11
|
Cache server logs severe message if DataSerializer class cannot be loaded
|
The cache server tries to load DataSerializer classes even if the classes are never used. This results in a severe log message.
|
|
|
#44123
|
11/05/11
|
Cache update with Map Indexes
|
This issue can occur when creating an Index using a Map of Region values. A Map Index can be created on all keys (using '*') or on a set of particular keys like '['sun', 'yahoo']'. This bug is introduced when you create a Map Index on a set of keys, but not on all keys. When performing an update on the Map Index, a sub-index for the key is fetched from the Map Index. The bug appears if the key cannot be found in the index expression. The fix addresses non-existent keys in the Map Index when the updated value in the cache contains keys in its map that do not match Map Index keys.
|
|
|
#44184
|
11/17/11
|
InternalGemFireError using CustomExpiry with persistent partitioned regions
|
Using a CustomExpiry with a persistent partitioned region results in an InternalGemfireError when recovering the persistent region from disk.
|
|
|
#44190
|
11/18/11
|
The "index already exists" exception appears too frequently in error logs and notifications
|
The "index already exists" exception can appear in cases where an index is created on a partitioned region using cache.xml, and the index creation request is sent to all nodes already containing that partitioned region. The "index already exists" exception log level has been changed from "error/warning" level to the "info" level to reduce extraneous error logging.
|
|
|
#44191
|
11/18/11
|
Partition Region Index statistics
|
Index on Partition Region used to have separate statistics for each bucket, so user would see more than one Index statistics for an Index on PR in VSD.
Index Statistics in PR has been combined to be one for one PR rather for separate buckets. Now only one index statistics will be shown for an index on a PR in VSD. No of index keys in index would be reported for each bucket i.e. if no of unique keys is k and no of buckets is r then index statistics would show maximum k*r index keys if all bucket indexes have that key.
|
|
|
#44192
|
11/18/11
|
Unable to use QueryService.getIndex(region, indexname) API with partitioned regions
|
The QueryService.getIndex(region, indexname) API was only implemented for replicated regions. Now the API can be used with partitioned regions.
|
|
|
#44193
|
11/18/11
|
Cache XML parameterization with duplicate parameters
|
The same parameter cannot be used more than once in a cache.xml file. This limitation caused issues when using replacement variables in cache.xml. This issue has now been resolved.
|
|
|
#44267
|
12/09/11
|
TreeMap and TreeSet may fail to deserialize
|
If you serialize a TreeMap or TreeSet that has a PDX-serialized Comparator and you have read-serialized set to true, then deserialization will fail with a ClassCastException saying that a PdxInstance cannot be cast to a Comparator.
|
Make sure the Comparator is not serialized as a PDX. If you are using the auto serializer, then specify a pattern that does not match your Comparator class. If you are using PdxSerializer, have it return false for instances of Comparator. If you are using PdxSerializable, do not implement this interface on your Comparator class.
|
|
#44268
|
12/12/11
|
IllegalMonitorException thrown during cache operations on regions with multiple indexes
|
This exception can appear during cache operations (for example, put, update, destroy, and so on) when multiple indexes are present on a Region. The issue is caused by erroneous locking and unlocking of multiple indexes by the cache operation thread. The fix for this issue now tracks the locking and unlocking of each index correctly.
|
|
|
#44271
|
12/14/11
|
Region keys must not be serialized using PDX
|
Region keys must not be serialized using PDX. Doing so with persistent keys will cause a NullPointerException during recovery, and will also cause a NullPointerException on an operation if a key has not been serialized. Using PDX serialization on region keys in a partitioned region with read-serialized set to true can cause consistency issues.
|
Use DataSerializable or DataSerializer for region key classes.
In 6.6.2 and later, region keys can be serialized using PDX as long as read-serialized is not set to true and the PDX disk store is configured to be different than the disk store that contains the regions with the PDX serialized keys.
|
|
#44276
|
12/15/11
|
containsKey operation not backwards compatible
|
GemFire 6.6.0 did not support the containsKey operation from older clients. This backwards compatibility problem has been fixed in 6.6.2.
|
|
|
#44336
|
01/04/12
|
ConcurrentModificationException when destroying or clearing a persistent region
|
A clear or destroy operation on a persistent region may fail with a ConcurrentModificationException.
|
|
|
#44343
|
01/04/12
|
Simulated results of rebalance do not match the actual results
|
If you call RebalanceFactory.simulate once and then RebalanceFactory.start on a quiescent system, you may receive slightly different results in the two sets of RebalanceResults.
|
|
|
#44350
|
01/06/12
|
Deadlock updating colocated region in callback
|
In rare cases, updating a colocated region using a callback while rebalancing can lead to a deadlock, even when using conserve-sockets=false.
|
|
|
#44365
|
01/11/12
|
Failed distributed system connections cause memory leak
|
If a distributed system fails with an exception during its initial creation it may leak memory.
|
|
|
#44375
|
01/12/12
|
Unexpected TransactionDataNodeDepartedException returned to client
|
When client is connected to an empty GemFire member, the client may wrongly get a TransactionDataNodeHasDeparted when the empty member is killed.
|
|
|
#44378
|
01/12/12
|
InternalGemFireError after rebalancing a persistent partitioned region
|
In rare cases, after rebalancing a persistent partitioned region, a subsequent put to a partition region may throw an InternalGemFireError from PartitionedRegionDataStore.grabFreeBucket.
|
|
|
#44384
|
01/16/12
|
Query reattempts during rebalancing
|
This issue appears during rebalancing when query reattempts are occurring more quickly than members are being updated with node failure and bucket relocation information. As a result, query attempts fail continuously because the query request is retried on the same node which has disappeared, and the Local cache has not been updated with this information.
This fix adds a 10 millisecond wait between query reattempts so that the query thread yields to member update thread during rebalancing.
|
|
|
#44392
|
01/17/12
|
Incorrectly configured member using non-persistent PDX registry with persistent regions not detected
|
When using PDX serialization, the type registry must be persistent if the regions are persistent. If types are only defined through cache server accessors, GemFire does not detect this error.
On restart, deserializing a type will throw an unknown pdx type error.
|
|
|
#44408
|
01/20/12
|
Backup command prints out 15 second warning
|
The backup command may print out a message saying "15 seconds have
elapsed while waiting for replies," even though the backup is in fact working.
|
|
|
#44413
|
01/23/12
|
GemFire internal thread enlists in external JTA transaction
|
In presence of an external JTA transaction manager, GemFire will wrongly register in a JTA transaction if TransactionManager.getTransaction() returns a non null value.
|
|
|
#44431
|
01/24/12
|
Deadlock resulting from simultaneous index creation and cache operations on persistent regions
|
Creating an index programmatically through the API while performing cache operations (update, destroy) can result in a deadlock if the Region has eviction enabled and if persistence to disk is used for region entries.
The deadlock occurs when the cache operation thread first locks a Region Entry and then waits for index initialization. For overflow regions, the index initialization thread waits on a Region Entry lock in order to populate the index with existing Region Entries.
The fix resolves the deadlock by reversing the cache operation thread's sequence of locking the Region Entry first and then waiting for index initialization. Instead, the cache operation waits for index initialization first. This sequence is used for overflow regions only and is avoided in other regions for performance reasons.
|
|
|
#44457
|
01/30/12
|
PdxReadSerialized set incorrectly during query against index
|
This issue is encountered when a partitioned region does not have all the buckets created in the cache, and consequently when a query is run against the region, the remaining buckets are created for the partitioned region. If indexes were previously created on the partitioned region, the creation of the buckets also causes the creation of indexes. The index creation process sets its own PdxReadSerialized value and reverts the PdxReadSerialized value of the query thread.
The fix prevents PdxReadSerialized from being reverted when a query thread causes the creation of an index.
|
|
|
#44482
|
02/02/12
|
A replace(K,V,V) call by the client does not work with server-side value constraints
|
When there is a value constraint on the server and the client does a replace(K,V,V) call, the server incorrectly throws a ClassCastException.
|
|
|
#44484
|
02/03/12
|
Hang recovering persistent colocated regions
|
If multiple persistent partitioned regions are colocated with the same parent, and two members have different regions defined, the system may hang on recovery because the different members are recovering the colocated regions in different orders.
|
|
|
#44533
|
02/14/12
|
Unexpected PartitionedRegionStorageException using persistent colocated regions
|
In some circumstances, after members with persistent colocated regions recovered from disk, an accessor member could receive a PartitionedRegionStorageException saying no data stores are available, even though there are in fact data stores available.
|
|
|
#44538
|
02/15/12
|
Deadlock while closing a persistent region
|
If a persistent region is created by using the deprecated AttributesFactor.setDiskDirs method, rather than specifying the disk store, there is a possibility that a call to close the region will hang if oplog compaction is happening in the background.
|
|
|
#44572
|
02/22/12
|
Issue with queries using both a LIMIT clause and one index
|
This issue can occur when a query specifies a LIMIT and is using only one index, but all the specified WHERE conditions do not use that index. (For example, the query "SELECT * FROM /region WHERE status='active' AND ID > 2 AND ID < 10" uses an index on ID only.) In the query "SELECT DISTINCT * FROM /test WHERE status ='inactive' AND (ID > -1 AND ID < 100) LIMIT 10", the LIMIT is applied on the intermediate results returned from the index, and then the 'status' condition is not applied to the correct number of results.
The fix applies the LIMIT condition correctly on queries that use indexes as well as some other scenarios for queries using indexes.
|
|
|
#44586
|
02/24/12
|
InternalGemFireError with client transaction and function execution
|
When a client executes a function on a replicated region from within a transaction, an InternalGemFireError may be thrown if the transaction is hosted by the member to which the client is connected.
|
|