The problem: You started a client application and got an error message ending with:
Could not find space: [space connection URL]
Solving this problem...
Possible cause
Checking if this is the cause
Solution
Cluster did not deploy, or cluster has wrong name.
In the GS-UI, switch to Deployments view using the button on the left (in GigaSpaces 5.X) or click the Deployments, Details tab on the left (in GigaSpaces 6.X).
In the tree under Service Grid Network on the left, expand Service Deployments. If you do not see a deployment called myDataGrid, this is what caused the problem.
Shut down all GigaSpaces instances and the GS-UI, and go back to Deploying the Data Grid above.
You changed the default lookup group in setenv.bat.
Open the following file in a text editor: <GigaSpaces Root>\bin\setenv.bat.
Search for the string LOOKUPGROUPS= If the string following the = is something other than gigaspaces-XY (where X is your version number and Y indicates your product edition), this is what caused the problem.
Take note of the current value of the LOOKUPGROUPS variable.
You need to re-run the application with a different space connection URL (substitute the current value of the LOOKUPGROUPS parameter for X):
If there are no arguments at the end of your URL, append ?groups=X to the end of the URL.
If you already have an argument at the end of the space URL, such as ?useLocalCache, append &groups=X to the end of the URL.
The problem: You started a client application and got the following error message:
Exception in thread "main" java.lang.NoClassDefFoundError:
com/j_spaces/core/client/FinderException
Solving this problem...
Cause
Solution
Example was placed in incorrect path.
Copy the example into the following path: <GigaSpaces Root>\examples\Basic\example-name.
Common Development Scenarios
The problem: On space side logs you will see a replication error when started a client application and got a SEVERE error message ending with:
Wrong clustered space usage - Replicator
Main reasons for the problem...
This error message indicates that there was a problem replicating a certain object to the target space. The problem could be caused by several reasons:
The replicated object no longer exists in the target space(in case it was updated, taken or deleted)
The object already exists in the target space(in case it was written for the first time and an object with the same id already exists in the target space)
The object version in the target space is different than the one in the source space (in case it was updated).
There are 3 different types of error messages which are related to each of the following space operations: Take, Write, Update.
This exception can be thrown in the following scenarios:
1) When an object was updated\written\taken on two different members of the same replication group, in parallel. This exception usually happens when one works with an active-active schema (meaning - primary spaces replicate to one another, e.g. sync-replicated or async-replicated schemas).
2) In a primary-backup topology, the source space replicated a certain object to the backup space and this object has already expired in the backup
Solving this problem...
Possible errors
Description of the errors
Take operation replication failed.
As mentioned above, this exception can be related to any destructive operation (write, take or update): In case of a replication of a take operation when the object does not exist in the target space, a "Wrong clustered space usage" error will be raised with the following message added to the space's log file: "UID X doesn't exist in target Y". The client is not aware of this exception since it only relates to the replication mechanism. The take operation, from the client perspective has succeeded, the replication of the take operation, on the other hand, has failed with this exception: EntryNotInSpaceException:
SEVERE [com.gigaspaces.core.cluster.replication]:
Wrong clustered space usage - Replicator:
Take operation failed Entry [UID: 530059587^64^3710d9206ba843afaf73b8f9ddf5e12fTO_PRICES^0^0, SeqKey: 3565925]
doesn't exists in target [tmServer_container1_1:tmServer] space.
.
Update operation replication failed.
When a space object is updated on different cluster nodes at the same time (this might happen in asynchronous replication mode), the last replication update event overrides the existing version, resetting the space object version number to ZERO. Therefore, the client is not aware of the replication failure, and from its perspective, the update operation has succeeded, but the replication operation, on the other hand, had failed with this exception thrown at the server side: EntryVersionConflictException:
SEVERE [com.gigaspaces.core.cluster.replication]:
Wrong clustered space usage - Replicator: Update operation (version=875741) on Entry UID: 776207364^50^382732ce058e46d8f2211286f0^0^0 (version=875741)was rejected
due to version conflict on target [dbCacheSpace_container3_1:dbCacheSpace] space.
.
Write operation replication failed.
In case of a write replication event for a space object that already exists, a Wrong clustered space usage "UID X already exists in space" error is added into the space log file. EntryAlreadyInSpaceException:
LRMI Connection--pool-5-thread-5 Wrong clustered space usage!
Replicator: Failed to replicate Entry Common.objects.entry.TradeEntry
from source space [oms_container:oms]
Reason: Write operation failed, entry with UID: -1299436563^44^6b8a6cd7-b1ce-44b2-aac8-e43406358211^0^0
already exists in space [omsqry_container:omsqry] space.
.
The solution: What you should do:Basically in all of the cases above you should make sure you do not have 2 or more different clients which are trying to operate on the same object via different space instances .
Wrong clustered space usage Exception
This error message indicates that there was a problem replicating a certain object to the target space. The problem could be caused by several reasons:
The replicated object no longer exists in the target space(in case it was updated, taken or deleted)
The object already exists in the target space(in case it was written for the first time and an object with the same id already exists in the target space)
The object version in the target space is different than the one in the source space (in case it was updated).
There are 3 different types of error messages which are related to each of the following space operations: Take, Write, Update.
This exception can be thrown in the following scenarios:
1) When an object was updated\written\taken on two different members of the same replication group, in parallel. This exception usually happens when one works with an active-active schema (meaning - primary spaces replicate to one another, e.g. sync-replicated or async-replicated schemas).
2) In a primary-backup topology, the source space replicated a certain object to the backup space and this object has already expired in the backup
Take operation replication failed
As mentioned above, this exception can be related to any destructive operation (write, take or update):
In case of a replication of a take operation when the object does not exist in the target space, a "Wrong clustered space usage" error will be raised with the following message added to the space's log file: "UID X doesn't exist in target Y".
The client is not aware of this exception since it only relates to the replication mechanism. The take operation, from the client perspective has succeeded, the replication of the take operation, on the other hand, has failed with this exception: EntryNotInSpaceException:
SEVERE [com.gigaspaces.core.cluster.replication]:
Wrong clustered space usage - Replicator:
Take operation failed Entry [UID: 530059587^64^3710d9206ba843afaf73b8f9ddf5e12fTO_PRICES^0^0, SeqKey: 3565925]
doesn't exists in target [tmServer_container1_1:tmServer] space.
Update operation replication failed
When a space object is updated on different cluster nodes at the same time (this might happen in asynchronous replication mode), the last replication update event overrides the existing version, resetting the space object version number to ZERO. Therefore, the client is not aware of the replication failure, and from its perspective, the update operation has succeeded, but the replication operation, on the other hand, had failed with this exception thrown at the server side:
EntryVersionConflictException:
SEVERE [com.gigaspaces.core.cluster.replication]:
Wrong clustered space usage - Replicator: Update operation (version=875741) on Entry UID: 776207364^50^382732ce058e46d8f2211286f0^0^0 (version=875741)was rejected
due to version conflict on target [dbCacheSpace_container3_1:dbCacheSpace] space.
Write operation replication failed
In case of a write replication event for a space object that already exists, a Wrong clustered space usage "UID X already exists in space" error is added into the space log file.
EntryAlreadyInSpaceException:
LRMI Connection--pool-5-thread-5 | Wrong clustered space usage!
Replicator: Failed to replicate Entry Common.objects.entry.TradeEntry
from source space [oms_container:oms]
Reason: Write operation failed, entry with UID: -1299436563^44^6b8a6cd7-b1ce-44b2-aac8-e43406358211^0^0
already exists in space [omsqry_container:omsqry] space.
What you should do:Basically in all of the cases above you should make sure you do not have 2 or more different clients which are trying to operate on the same object via different space instances .