org.rhq.core.clientapi.server.drift

Interface DriftServerService

public interface DriftServerService

This class defines the drift server API that the agent uses for things like sending change set reports, sending change set content, and performing inventory sync.

Author:

Jay Shaughnessy, John Sanda

Method Summary

Methods

Modifier and Type	Method and Description
org.rhq.core.domain.drift.DriftSnapshot	getCurrentSnapshot(int driftDefinitionId)
Map<Integer,List<org.rhq.core.domain.drift.DriftDefinition>>	getDriftDefinitions(Set<Integer> resourceIds)
org.rhq.core.domain.drift.DriftSnapshot	getSnapshot(int driftDefinitionId, int startVersion, int endVersion)
void	repeatChangeSet(int resourceId, String driftDefName, int version)
void	sendChangesetZip(int resourceId, long zipSize, InputStream zipStream) The agent invokes this method to send a change set in a zip file.
void	sendFilesZip(int resourceId, String driftDefName, String token, long zipSize, InputStream zipStream) The agent invokes this method to send change set content to the server.
void	updateCompliance(int resourceId, String drfitDefName, org.rhq.core.domain.drift.DriftComplianceStatus complianceStatus)

Method Detail

sendChangesetZip

void sendChangesetZip(int resourceId,
                    long zipSize,
                    InputStream zipStream)

The agent invokes this method to send a change set in a zip file. The agent will call this method to report the initial change set when starting drift detection and subsequently whenever drift is detected. The format of the change set report is described in ChangeSetWriter. This method starts the following work flow:

• A request is sent to JMS queue so that the change set can be processed asynchronously allowing control to return back to the agent as quickly as possible. It also allows the server to be able to more quickly service other agent and/or web requests.
• The server streams and persists the change set.
• The server sends an acknowledgement to the agent to let it know that the change set was successfully persisted. The agent will refrain from sending any more change sets until this step has completed.
• The server sends a request to the agent for any content referenced in the change set that is not yet in the database.

Note that because the change set bits are streamed out of band, if any errors occur during the streaming, exception will not be propagated back up the call stack on the agent side in the thread that initiated the call. This is the reason for the acknowledgement step.

Parameters:

resourceId - The id of the resource to which this change set belongs. This parameter may obsolete since the resource id is specified in the change set headers.

zipSize - The total number of bytes to be streamed

zipStream - A RemoteInputStream

sendFilesZip

@Asynchronous(guaranteedDelivery=true)
void sendFilesZip(int resourceId,
                                               String driftDefName,
                                               String token,
                                               long zipSize,
                                               InputStream zipStream)

The agent invokes this method to send change set content to the server. The content are files referenced in a change set that the agent previously sent to the server. The zip file is assumed to be flat, that is it contains only files, no directories. The name of each file should be the SHA hash of the file contents. File names and paths are not relevant as the server only stores content which is identified by the SHA hashes. This method starts the following work flow:

• A request is sent to a JMS queue so that the work can be performed asynchronously allowing control to return back to the agent as quickly as possible. It also allows the server to more quickly service other agent and/or web requests.
• The server streams and persists each file.
• The server sends an acknowledgement to the agent to let it know that the content has been successfully persisted.

Note that that the guaranteed delivery on this method is weak due to the streaming being done asynchronously. If the first attempt at streaming fails the stream will likey be dead and subsequent retries will fail as well. Because the streaming is done out of band, any network IO errors will not be propagated back up the call stack on the agent side in the thread that initiated this method call. This is the reaosn for the acknowledgement step.

Parameters:

resourceId - The id of the resource to which the change set content belongs

driftDefName - The drift definition name. This is needed for the acknowledgement step.

token - A token needed for the acknowledgement step that allows the agent to uniquely identify the zip file that was sent.

zipSize - The total number of bytes to be streamed.

zipStream - A RemoteStream

repeatChangeSet

@Asynchronous
void repeatChangeSet(int resourceId,
                                String driftDefName,
                                int version)

getDriftDefinitions

Map<Integer,List<org.rhq.core.domain.drift.DriftDefinition>> getDriftDefinitions(Set<Integer> resourceIds)

Parameters:

resourceIds - The resourceIds for which to fetch definitions.

Returns:

A Map from resourceId to its list of DriftDefinitions. Resources without DriftDefinitions are not included in the Map.

getCurrentSnapshot

org.rhq.core.domain.drift.DriftSnapshot getCurrentSnapshot(int driftDefinitionId)

getSnapshot

org.rhq.core.domain.drift.DriftSnapshot getSnapshot(int driftDefinitionId,
                                                  int startVersion,
                                                  int endVersion)

updateCompliance

void updateCompliance(int resourceId,
                    String drfitDefName,
                    org.rhq.core.domain.drift.DriftComplianceStatus complianceStatus)