 | Summary: A list of fixed bugs and known issues for GigaSpaces 5.2.1 (build 1720).
|
Overview
Below is a list of fixed bugs since GigaSpaces 5.2 (build 1708):
Core
- GS-1330 – Fixed: The CacheLoader loaded all data, ignoring partitions in ALL_IN_CACHE, therefore, all data was loaded to all members.
Query Engine
- GS-1158 – Fixed: SQLQuery falsely identified fields that start with GROUP as the GROUP BY parameter.
POJO and Spring
- GS-1152 – Fixed: The converter failed when trying to add additional fields (correlation id, message id, reply to, etc) to an ExternalEntry, after converting it to a POJO.
- APP-723 – WRITE_ONLY mode has been added to UpdateModifiers. It applies to write operations with modifiers and setUpdateModifiers in the proxy level. The reason behind this change is that write in POJOs without modifiers (or even when setUpdateModifiers is set on the proxy level) always uses the UPDATE_OR_WRITE modifier. This new modifier has been added in order to enable users to only perform write operations (and get an EntryAlreadyInSpace exception if the POJO already exists).
Configuration and Tools
- GS-147 – Fixed: entry with UID already exists in space log error was displayed when using a sync-replicated cluster with more then two spaces – the log level was reduced to FINE, when there was no real error.
- GS-1145 – Upgraded the GigaSpaces-Mule 1.3.x connector. Added various examples. To download, refer to the GigaSpaces-Mule Integration Package section.
- GS-1289 – Fixed: LookupFinder bug – client sometimes connected to a space with the same name in a different Jini group: This occured with two spaces that have the same name (different container), each a member of one shared Jini group and one unique one, and only three lookup services up, each registered for only one Jini group of the three (the two unique and the shared). If you used SpaceFinder.find() for the space with the shared group, and then looked for the space with one of the unique groups, while less than a minute passed between the finds – in the second find, you could have received a proxy to the wrong space.
The reason for this problem: In the LookupFinder class, there is a LookupFinalize thread cleaning the lookupCache. This thread has a 1 minute sleep between the loops, in case you perform two finds with less than a minute between them. The new group is concatenated to the previous, and if the first was the shared one, there is a chance that you will be directed to the lookup service of the shared group, and from there to the wrong space.
GigaSpaces Browser
- GS-635 – Fixed: The GigaSpaces Browser threw an exception when viewing one member in a partitioned space. The system does prevent from starting a cluster with only one member.
.NET
- GS-1159 – PBS is now supported.
Service Grid
- GS-1247 – Fixed: Failover didn't work during GSC shutdown.
