Load Testing ModeShape Versioning
mashama Jul 3, 2013 12:31 PMI need some help understanding the behavior of the versioning system in the context of a rather unrealistic load test. The version history json output from modeshape-rest is attached. Basicly I have 10 concurrent users utilizing 2 connections to write a 75KB file to a nt:file node that is versioned. What concerns me are snippets like:
"1.26[9]": {
"id": "61a53fc317f1e70b6e7d6c-fc38-4408-a904-b64e71bbfa11"
},
"1.26[10]": {
"id": "61a53fc317f1e7818be43e-570d-4297-ae94-11d23725cb86"
},
In the above json snippet you see version numbers like 1.26[9] and 1.26[7]. I have seen the bracketed numbers before in the context of overwriting the same nt:file or nt:folder node where that node is not versioned. It seems like in those cases the bracketed numbers appended to the node relative path name to get around the issue of not being able to add sibiling nodes with the same relative path. I am worried that by virtue of this happening version history is actually being lost. Locking at the following snippet you will see that the predecessor does not actually point to the previous bracketed number version.
"jcr:predecessors": ["http://chp-ws70:8080/modeshape-rest/salesapp/carrier-group-2170/items/jcr:system/jcr:versionStorage/c0/df/9c/c0df9c793f462fb08f64cd08a49534819d288acb/jcr:rootVersion"],
"jcr:uuid": "47daec1d-a062-4f5f-a2d9-f7623a143284",
"children": {"jcr:frozenNode": {
"self": "http://chp-ws70:8080/modeshape-rest/salesapp/carrier-group-2170/items/jcr:system/jcr:versionStorage/c0/df/9c/c0df9c793f462fb08f64cd08a49534819d288acb/1.0[3]/jcr:frozenNode",
"id": "61a53fc317f1e76687eeb5-237e-4fde-b488-8313b568d8c3"
}}
I realize that I probably should be doing something at the application level to deal with this, but what that is (locking, checking isCheckedOut, merging, etc.) I have yet to ascertain. I just wanted to reach out to your team and see if you had any thoughts about this. Thanks again!
#ModeShapeROCKS!
-
versions.json.zip 6.9 KB