[
https://issues.apache.org/jira/browse/JCRVLT-633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Irina Chirita updated JCRVLT-633:
---------------------------------
Description:
When using "vlt rcp" to copy content between servers, if there is a mismatch
between the source and the target on the node type child ordering, then the
process will stop silently. There is an error in the logs, however the task
JSON returns the status ENDED instead of ERROR. Therefore any tool making use
of the JSON status property will not show the error making error detection more
difficult.
----
To reproduce, follow the below steps.
# On the source environment create a node that supports child ordering (e.g.,
sling:OrderedFolder)
For example, /content/dam/test/folderA. The source will have other folders and
assets in /content/dam/test in such a way that the sync takes a few minutes.
# On the target environment create a node with the same name in the same path
(/content/dam/test/folderA) that does not support child ordering (e.g.,
sling:Folder)
# Use "vlt rcp" via json/http interface to copy sync from the source to the
target server the top-level folder (e.g. /content/dam/test):
* create task
* start task
* get info of task progress
Expected result:
* when making a call to get info of the task progress, the JSON returned
should have a new "state" ERROR to indicate that a problem occurred during
processing
Actual result:
* When making a call to get info of the task progress, the JSON returned has a
"state" ENDED and HTTP code is 200, therefore there is no way of knowing that a
problem occurred when synchronising large amount of data unless logs are being
checked regularly.
* This may hinder automation whereby a sync task would run regularly on a
schedule and we would like the error to be raised at the level where the call
is being made.
was:
When using "vlt rcp" to copy content between servers, if there is a mismatch
between the source and the target on the node type child ordering, then the
process will stop silently. There is an error in the logs, however the task
JSON returns the status ENDED instead of ERROR. Therefore any tool making use
of the JSON status property will not show the error making error detection more
difficult.
----
To reproduce .... TBC
with an error in the logs, however the , node properties are correctly updated
or removed, and child nodes are correctly added or removed, but child node
ordering is not updated.
1. create a node that supports child ordering (e.g., nt:unstructured or
sling:OrderedFolder)
For example, /content/test/folderA
2. create 3 nodes (e.g., nt:unstructured) underneath that node
/content/test/folderA/one
/content/test/folderA/two
/content/test/folderA/three
3. use "vlt rcp" to copy that folder elsewhere:
{noformat}
vlt rcp -r -u
http://admin:admin@localhost:4502/crx/-/jcr:root/content/test/folderA
http://admin:admin@localhost:4502/crx/-/jcr:root/content/test/folderB
{noformat}
4. check that the newly created target folder "folderB" exists and has the
correct child content in the correct order.
5. delete the node "one" from "folderB"
6. re-run the "vlt rcp" command
This should bring the target folder back into sync with the source folder, but
it will instead create the node "one" as the last child in the target folder,
rather than the first.
> VLT RCP doesn't fail task when child node ordering error occurs
> ---------------------------------------------------------------
>
> Key: JCRVLT-633
> URL: https://issues.apache.org/jira/browse/JCRVLT-633
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: RCP
> Affects Versions: 3.5.6
> Reporter: Irina Chirita
> Priority: Major
>
> When using "vlt rcp" to copy content between servers, if there is a mismatch
> between the source and the target on the node type child ordering, then the
> process will stop silently. There is an error in the logs, however the task
> JSON returns the status ENDED instead of ERROR. Therefore any tool making use
> of the JSON status property will not show the error making error detection
> more difficult.
> ----
> To reproduce, follow the below steps.
> # On the source environment create a node that supports child ordering
> (e.g., sling:OrderedFolder)
> For example, /content/dam/test/folderA. The source will have other folders
> and assets in /content/dam/test in such a way that the sync takes a few
> minutes.
> # On the target environment create a node with the same name in the same
> path (/content/dam/test/folderA) that does not support child ordering (e.g.,
> sling:Folder)
> # Use "vlt rcp" via json/http interface to copy sync from the source to the
> target server the top-level folder (e.g. /content/dam/test):
> * create task
> * start task
> * get info of task progress
> Expected result:
> * when making a call to get info of the task progress, the JSON returned
> should have a new "state" ERROR to indicate that a problem occurred during
> processing
> Actual result:
> * When making a call to get info of the task progress, the JSON returned has
> a "state" ENDED and HTTP code is 200, therefore there is no way of knowing
> that a problem occurred when synchronising large amount of data unless logs
> are being checked regularly.
> * This may hinder automation whereby a sync task would run regularly on a
> schedule and we would like the error to be raised at the level where the call
> is being made.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
