|
Problem(Abstract) |
If the sync is successful with the first attempt, all the
temp files are deleted.
If the sync fails during the first attempt and then later the sync is
successful, the newly created temp files get cleared, but not the old ones
(the ones created during the unsuccessful sync). |
|
|
|
Cause |
Scenario
1. Synchronization fails for some reason (for example: file system
full), IBM® WebSphere® Application Server cannot clean the files because
of the failure and temp files are left as is.
<Install_Root>\config\temp\cells\<cell_name>\applications\
2. The next synchronization is successful and only the newly
created temp files get cleared, but not the old ones (the ones
created during the unsuccessful synchronization)
|
|
|
Resolving the
problem |
In the above scenario, the node sync initiated a file
transfer application to download the ear file. The file transfer
application then sent a request for the first chunk of data and attempted
to save the downloaded data to the disk. The save attempt failed as the
disk was running out of space; therefore, it could not proceed further.
The dmgr was unaware of the client's failure and therefore did not perform
any cleanup operations as the file was not fully copied to the client. The
file transfer process is incomplete (due to lack of disk space) and
thereby leaving the temp files as is.
The file transfer is not an atomic task; in the sense that the file
transfer takes place in chunks of data for performance reasons. Each chunk
of data is transferred as a response to a client request. The client
decides the size of the chunk and the same is passed as a part of the
request. The dmgr just copies the chunk of the file as per the client
request. Though the request is to read the same file, each request is
independent of its predecessor and the client who sends these requests
re-assembles the file after the file is completely downloaded.
- The node sends a sync request to cell (dmgr).
- The cell manager identifies the modified documents, copies
them to the temp folder (config/temp) and then sends the response to node
with the URLs of modified documents.
- The node then uses the File Transfer service to download
the documents to local machine.
- The file transfer service internally sets a flag that
enables the file transfer server to delete the temp file once the download
is complete.
Whenever there is a request to transfer a file, the dmgr creates a temp
copy in the config/temp directory.
<Install_Root>\config\temp\cells\<cell_name>\applications\ .
- The dmgr deletes the temp copy only when the file is
completely read and copied to the client.
- The temp files get deleted only when the download process
is complete and successful.
The dmgr does not care to delete the temp files created during "failed
synchronization" because the deletion process happens only after the
successful file transfer. Also the dmgr cannot reuse these temp files
because the original document may have been updated, while the next sync
is attempted.
We can safely delete everything under the config/temp directory after the
sync operation.
Question:
The File transfer application is in dmgr, why is the dmgr not monitoring
this process? Is it possible to get the sync failure notification and
cleanup the failed config/temp files?
Answer:
As we are all aware, FileTransfer is a Web application that ships with
Application Server and runs in dmgr server. The FileTransferServer is
nothing but a servlet which listens for http requests to download/upload
files from and to the server. So, it is not possible for the
FileTransferServlet to monitor the file transfer status as the callbacks
are not possible using http protocol.
Question:
Why does the dmgr create a new version of the tmp files every minute,
which fills up the file system, instead of creating only one?
Answer:
Based on the automatic sync interval settings (default is 1 minute),
Application Server will try to do the sync operation. During this
operation it will create the temp files. If the sync operation is
successful, these files will be deleted automatically. If the sync
operation is NOT successful then Application Server will try to do the
next sync based on the automatic sync interval settings. During this
operation it will create a new set of files again in the config/temp. This
works as designed. |
|
|
|