[
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 Server Bundle" 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's JSON returns the status ENDED with HTTP code 200 suggesting processing
has completed successfully. Therefore any tool making use of the JSON status
property will not show any issue 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 a few times
Expected result:
* all nodes are synchronised successfully
* if an issue occurs (on folderA), 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:
* All nodes that should be processed after folderA are not actually
synchronised onto the target server.
* 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 amounts 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, 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.
> 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: Improvement
> Components: RCP
> Affects Versions: 3.5.6
> Reporter: Irina Chirita
> Priority: Major
>
> When using "VLT RCP Server Bundle" 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's JSON returns the status ENDED with HTTP code 200
> suggesting processing has completed successfully. Therefore any tool making
> use of the JSON status property will not show any issue 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 a few times
> Expected result:
> * all nodes are synchronised successfully
> * if an issue occurs (on folderA), 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:
> * All nodes that should be processed after folderA are not actually
> synchronised onto the target server.
> * 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 amounts 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)
