|
| Message |
Asking member %n1 for %n2 primary partitions |
| Parameters |
%n1 - the node id this node asks to transfer partitions from; %n2 - the number of partitions this node is willing to take |
| Severity |
4-Debug Level 4 |
| Cause |
When a storage-enabled partitioned service starts on a Coherence node, it first receives the configuration update that informs it about other storage-enabled service nodes and the current partition ownership information. That information allows it to calculate the "fair share" of partitions that each node is supposed to own at the end of the re-distribution process. This message demarcates a beginning of the transfer request to a specified node for a number of partitions to move toward the "fair" ownership distribution. |
| Action |
None. |
| Message |
Transferring %n1 out of %n2 primary partitions to member %n3 requesting %n4 |
| Parameters |
%n1 - the number of primary partitions this node transferring to a requesting node; %n2 - the total number of primary partitions this node currently owns; %n3 - the node id that this transfer is for; %n4 - the number of partitions that the requesting node asked for |
| Severity |
4-Debug Level 4 |
| Cause |
During the partition distribution protocol, a node that owns less than a "fair share" of primary partitions requests any of the nodes that own more than the fair share to transfer a portion of owned partitions. The owner may choose to send any number of partitions less or equal to the requested amount. This message demarcates the beginning of the corresponding primary data transfer. |
| Action |
None. |
| Message |
Transferring %n1 out of %n2 partitions to a machine-safe backup 1 at member %n3 (under %n4) |
| Parameters |
%n1 - the number of backup partitions this node transferring to a different node; %n2 - the total number of partitions this node currently owns that are "endangered" (do not have a backup); %n3 - the node id that this transfer is for; %n4 - the number of partitions that the transferee can take before reaching the "fair share" amount |
| Severity |
4-Debug Level 4 |
| Cause |
After the primary partition ownership is completed, nodes start distributing the backups, ensuring the "strong backup" policy, that places backup ownership to nodes running on machines that are different from the primary owners' machines. This message demarcates the beginning of the corresponding backup data transfer. |
| Action |
None. |
| Message |
Transferring backup%n1] for partition %n2 from member %n3 to member %n4 |
| Parameters |
%n1 - the index of the backup partition that this node transferring to a different node; %n2 - the partition number that is being transferred; %n3 the node id of the previous owner of this backup partition; %n4 the node id that the backup partition is being transferred to. |
| Severity |
5-Debug Level 5 |
| Cause |
During the partition distribution protocol, a node that determines that a backup owner for one of its primary partitions is overloaded may choose to transfer the backup ownership to another, underloaded node. This message demarcates the beginning of the corresponding backup data transfer. |
| Action |
None. |
| Message |
Failed backup transfer for partition %n1 to member %n2; restoring owner from: %n2 to: %n3 |
| Parameters |
%n1 the partition number for which a backup transfer was in-progress; %n2 the node id that the backup partition was being transferred to; %n3 the node id of the previous backup owner of the partition |
| Severity |
4-Debug Level 4 |
| Cause |
This node was in the process of transferring a backup partition to a new backup owner when that node left the service. This node is restoring the backup ownership to the previous backup owner. |
| Action |
None. |
| Message |
Deferring the distribution due to %n1 pending configuration updates |
| Parameters |
%n1 |
| Severity |
5-Debug Level 5 |
| Cause |
This node is in the process of updating the global ownership map (notifying other nodes about ownership changes) when the periodic scheduled distribution check takes place. Before the previous ownership changes (most likely due to a previously completed transfer) are finalized and acknowledged by the other service members, this node will postpone subsequent scheduled distribution checks. |
| Action |
None. |
| Message |
Limiting primary transfer to %n1 KB (%n2 partitions) |
| Parameters |
%n1 - the size in KB of the transfer that was limited; %n2 the number of partitions that were transfered |
| Severity |
4-Debug Level 4 |
| Cause |
When a node receives a request for some number of primary partitions from an underloaded node, it may transfer any number of partitions (up to the requested amount) to the requestor. The size of the transfer is limited by the <distributed-scheme/transfer-threshold> configuration element. This message indicates that the distribution algorithm limited the transfer to the specified number of partitions due to the transfer-threshold. |
| Action |
None. |
| Message |
DistributionRequest was rejected because the receiver was busy. Next retry in %n1 ms |
| Parameters |
%n1 - the time in milliseconds before the next distribution check will be scheduled |
| Severity |
6-Debug Level 6 |
| Cause |
This (underloaded) node issued a distribution request to another node asking for one or more partitions to be transferred. However, the other node declined to initiate the transfer as it was in the process of completing a previous transfer with a different node. This node will wait at least the specified amount of time (to allow time for the previous transfer to complete) before the next distribution check. |
| Action |
None. |
| Message |
Restored from backup %n1 partitions |
| Parameters |
%n1 - the number of partitions being restored |
| Severity |
3-Informational |
| Cause |
The primary owner for some backup partitions owned by this node has left the service. This node is restoring those partitions from backup storage (assuming primary ownership). This message is followed by a list of the partitions that are being restored. |
| Action |
None. |
| Message |
Re-publishing the ownership for partition %n1 (%n2) |
| Parameters |
%n1 the partition number whose ownership is being re-published; %n2 the node id of the primary partition owner, or 0 if the partition is orphaned |
| Severity |
4-Debug Level 4 |
| Cause |
This node is in the process of transferring a partition to another node when a service membership change occurred, necessitating redistribution. This message indicates this node re-publishing the ownership information for the partition whose transfer is in-progress. |
| Action |
None. |
| Message |
%n1> Ownership conflict for partition %n2 with member %n3 (%n4!=%n5) |
| Parameters |
%n1 - the number of attempts made to resolve the ownership conflict; %n2 - the partition whose ownership is in dispute; %n3 - the node id of the service member in disagreement about the partition ownership; %n4 - the node id of the partition's primary owner in this node's ownership map; %n5 - the node id of the partition's primary owner in the other node's ownership map |
| Cause |
If a service membership change occurs while the partition ownership is in-flux, it is possible for the ownership to become transiently out-of-sync and require reconciliation. This message indicates that such a conflict was detected, and denotes the attempts to resolve it. |
| Severity |
4-Debug Level 4 |
| Action |
None. |
| Message |
Assigned %n1 orphaned primary partitions |
| Parameters |
%n1 - the number of orphaned primary partitions that were re-assigned |
| Severity |
2-Warning |
| Cause |
This service member (the most senior storage-enabled) has detected that one or more partitions have no primary owner (orphaned), most likely due to several nodes leaving the service simultaneously. The remaining service members agree on the partition ownership, after which the storage-senior assigns the orphaned partitions to itself. This message is followed by a list of the assigned orphan partitions. This message indicates that data in the corresponding partitions may have been lost. |
| Action |
None. |
| Message |
validatePolls: This service timed-out due to unanswered handshake request. Manual intervention is required to stop the members that have not responded to this Poll |
| Parameters |
none |
| Severity |
1-Error |
| Cause |
When a node joins a clustered service, it performs a handshake with each clustered node running the service. A missing handshake response prevents this node from joining the service. Most commonly, it is caused by an unresponsive (e.g. deadlocked) service thread. |
| Action |
Corrective action may require locating and shutting down the JVM running the unresponsive service. See Metalink Note 845363.1 for more details. |
|
| Message |
java.lang.RuntimeException: Storage is not configured |
| Parameters |
None |
| Severity |
1-Error |
| Cause |
A cache request was made on a service that has no storage-enabled service members. Only storage-enabled service members may process cache requests, so there must be at least one storage-enabled member. |
| Action |
Check the configuration/deployment to ensure that members intended to store cache data are configured to be storage-enabled. This is controlled by the <distributed-scheme/local-storage> configuration element, or by the -Dtangosol.coherence.distributed.localstorage command-line override. |
| Message |
An entry was inserted into the backing map for the partitioned cache "%s" that is not owned by this member; the entry will be removed." |
| Parameters |
%s - the name of the cache into which insert was attempted |
| Severity |
1-Error |
| Cause |
The backing map for a partitioned cache may only contain keys that are owned by that member. Cache requests are routed to the service member owning the requested keys, ensuring that service members will only process requests for keys which they own. This message indicates that the backing map for a cache detected an insertion for a key which is not owned by the member. This is most likely caused by a direct use of the backing-map as opposed to the exposed cache APIs (e.g.
${xhtml}) in user code running on the cache server. This message is followed by a Java exception stack trace showing where the insertion was made. |
| Action |
Examine the user-code implicated by the stack-trace to ensure that any backing-map operations are safe. This error can be indicative of an incorrect implementation of
${xhtml} |
| Message |
Exception occured during filter evaluation: %s; removing the filter... |
| Parameters |
%s - the description of the filter that failed during evaluation |
| Severity |
1-Error |
| Cause |
An exception was thrown while evaluating a filter for a
${xhtml} registered on this cache. As a result, some MapEvents may not have been issued. Additionally, to prevent further failures, the filter (and associated MapListener) will be removed. This message is followed by a Java exception stack trace showing where the failure occurred. |
| Action |
Review filter implementation and the associated stack trace for errors. |
| Message |
Exception occured during event transformation: %s; removing the filter... |
| Parameters |
%s - the description of the filter that failed during event transformation |
| Severity |
1-Error |
| Cause |
An Exception was thrown while the specified filter was transforming a
${xhtml} for a
${xhtml} registered on this cache. As a result, some MapEvents may not have been issued. Additionally, to prevent further failures, the filter (and associated MapListener) will be removed. This message is followed by a Java exception stack trace showing where the failure occurred. |
| Action |
Review filter implementation and the associated stack trace for errors. |
| Message |
Exception occurred during index rebuild: %s |
| Parameters |
%s - the stack trace for the exception that occurred during index rebuild* |
| Severity |
1-Error |
| Cause |
An Exception was thrown while adding or rebuilding an index. A likely cause of this is a faulty
${xhtml} implementation. As a result of the failure, the associated index is removed. This message is followed by a Java exception stack trace showing where the failure occurred. |
| Action |
Review the ValueExtractor implementation and associated stack trace for errors. |
| Message |
Exception occurred during index update: %s |
| Parameters |
%s - the stack trace for the exception that occurred during index update |
| Severity |
1-Error |
| Cause |
An Exception was thrown while updating an index. A likely cause of this is a faulty
${xhtml} implementation. As a result of the failure, the associated index is removed. This message is followed by a Java exception stack trace showing where the failure occurred. |
| Action |
Review the ValueExtractor implementation and associated stack trace for errors. |
| Message |
Exception occurred during query processing: %s |
| Parameters |
%s - the stack trace for the exception that occurred while processing a query |
| Severity |
1-Error |
| Cause |
An Exception was thrown while processing a query. A likely cause of this is an error in the implementation of the
${xhtml} used by the query. This message is followed by a Java exception stack trace showing where the failure occurred. |
| Action |
Review the Filter implementation and associated stack trace for errors. |
| Message |
BackingMapManager %s1: returned "null" for a cache: %s2 |
| Parameters |
%s1 - the classname of the
${xhtml} implementation that returned a null backing-map; %s2 - the name of the cache for which the BackingMapManager returned null |
| Severity |
1-Error |
| Cause |
A BackingMapManager returned null for a backing-map for the specified cache. |
| Action |
Review the specified BackingMapManager implementation for errors and to ensure that it will properly instantiate a backing map for the specified cache. |
| Message |
BackingMapManager %s1: failed to instantiate a cache: %s2 |
| Parameters |
%s1 - the classname of the
${xhtml} implementation that failed to create a backing-map; %s2 - the name of the cache for which the BackingMapManager failed |
| Severity |
1-Error |
| Cause |
A BackingMapManager unexpectedly threw an Exception while attempting to instantiate a backing-map for the specified cache. |
| Action |
Review the specified BackingMapManager implementation for errors and to ensure that it will properly instantiate a backing map for the specified cache. |
| Message |
BackingMapManager %s1: failed to release a cache: %s2 |
| Parameters |
%s1 - the classname of the
${xhtml} implementation that failed to release a backing-map; %s2 - the name of the cache for which the BackingMapManager failed |
| Severity |
1-Error |
| Cause |
A BackingMapManager unexpectedly threw an Exception while attempting to release a backing-map for the specified cache. |
| Action |
Review the specified BackingMapManager implementation for errors and to ensure that it will properly release a backing map for the specified cache. |
| Message |
Unexpected event during backing map operation: key=%s1; expected=%s2; actual=%s3 |
| Parameters |
%s1 - the key being modified by the cache; %s2 - the expected backing-map event from the cache operation in progress; %s3 - the actual MapEvent received |
| Severity |
6-Debug Level 6 |
| Cause |
While performing a cache operation, an unexpected MapEvent was received on the backing-map. This indicates that a concurrent operation was performed directly on the backing-map and is most likely caused by direct manipulation of the backing-map as opposed to the exposed cache APIs (e.g.
${xhtml}) in user code running on the cache server. |
| Action |
Examine any user-code that may directly modify the backing map to ensure that any backing-map operations are safe. |
| Message |
Application code running on "%s1" service thread(s) should not call %s2 as this may result in deadlock. The most common case is a CacheFactory call from a custom CacheStore implementation. |
| Parameters |
%s1 - the name of the service which has made a re-entrant call; %s2 - the name of the method on which a re-entrant call was made |
| Severity |
2 |
| Cause |
While executing application code on the specified service, a re-entrant call (a request to the same service) was made. Coherence does not support re-entrant service calls, so any application code (CacheStore, EntryProcessor, etc.) running on the service thread(s) should avoid making cache requests. See the Constraints on Re-entrant Calls for more details. |
| Action |
Remove re-entrant calls from application code running on the service thread(s) and consider using alternative design strategies as outlined in the Constraints on Re-entrant Calls |
| Message |
Repeating %s1 for %n1 out of %n2 items due to re-distribution of %s2 |
| Parameters |
%s1 - the description of the request that must be repeated; %n1 - the number of items that are outstanding due to re-distribution; %n2 - the total number of items requested; %s2 - the list of partitions that are in the process of re-distribution and for which the request must be repeated |
| Severity |
5-Debug Level 5 |
| Cause |
When a cache request is made, the request is sent to the service members owning the partitions to which the request refers. If one or more of the partitions that a request refers to is in the process of being transferred (e.g. due to re-distribution), the request is rejected by the (former) partition owner and is automatically resent to the new partition owner. |
| Action |
None. |
| Message |
Error while starting cluster: com.tangosol.net.RequestTimeoutException: Timeout during service start: ServiceInfo(%s) |
| Parameters |
%s - information on the service that could not be started |
| Severity |
1-Error |
| Cause |
When joining a service, every service in the cluster must respond to the join request. If one or more nodes have a service that does not respond within the timeout period, the join times out. |
| Action |
See Metalink Note 845363.1 |
| Message |
Failed to restart services: com.tangosol.net.RequestTimeoutException: Timeout during service start: ServiceInfo(%s) |
| Parameters |
%s - information on the service that could not be started |
| Severity |
1-Error |
| Cause |
When joining a service, every service in the cluster must respond to the join request. If one or more nodes have a service that does not respond within the timeout period, the join times out. |
| Action |
See Metalink Note 845363.1 |
|
