Repository: geode Updated Branches: refs/heads/next-gen-native-client-software-grant 86df4a7c2 -> 03781bd1c
http://git-wip-us.apache.org/repos/asf/geode/blob/03781bd1/src/tests/cpp/scripts/using_runCSDriver ---------------------------------------------------------------------- diff --git a/src/tests/cpp/scripts/using_runCSDriver b/src/tests/cpp/scripts/using_runCSDriver deleted file mode 100644 index d99d463..0000000 --- a/src/tests/cpp/scripts/using_runCSDriver +++ /dev/null @@ -1,161 +0,0 @@ -This file contains the setup and usage instructions for running the C# -XML framework. - - 1. Ensure that .NET 2.0 runtime is installed on the client machines (available here: - http://www.microsoft.com/downloads/details.aspx?FamilyID=0856EACB-4362-4B0D-8EDD-AAB15C5E04F5&displaylang=en) - - 2. By default it uses plink to start clients on remote machines. So download plink.exe - and put it in your path. (http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html). - Alternatively it can use passwordless ssh with public-key authentication by - specifying the "--auto-ssh" option. For this to work on Windows, the sshd daemon - must run as a domain admin user who has the permissions to access network shares - and other resources. For more information on configuring this mode see this: - http://ist.uwaterloo.ca/~kscully/CygwinSSHD_W2K3.html - - 3. Run the script setCLITrust.bat on all the windows machines where - clients will be created. This script is inside tests/scripts directory - of ThinClient branch. - - 4. Ensure that the user has permission to be able to create shares on the - machine where driver shall be invoked. - - 5. When using local console login (or RDP) run OS_BUILD_DIR/framework/csharp/bin/FwkDriver.exe - Usage: FwkDriver [OPTION] [<host1> ...] - <host1> ... are (optional) hostnames of the machines on which to - distribute the clients. Each host can optionally have the hostGroup - name prefixed to it with ':' e.g. CS:host1; the hostGroup should not - be '*' which implicitly stands for all hosts - Options are: - --xml=FILE An XML file having the test to be executed. - This option can be specified multiple times - --list=FILE A file containing a list XML files having the tests to be executed - --pool=POOLOPTION where POOLOPTIONs are poolwithendpoints/poolwithlocator to run the existing tests with pool option. - --at=TIME The time at which to execute the regression test - --auto-ssh Use ssh configured for passwordless login instead of plink as remote shell - Note that this shall only work if sshd is running as a domain user having - permissions to access network shares and other resources on given hosts. - --bbServer=HOST:PORT The <host>:<port> to use for connecting to - external TCP BlackBoard server. This is to be used - when an external BBserver is being used instead - of the internal one. - --bbPasswd Use the external BBserver to get the passwords. - --driverPort The port to use for running the Driver service. - - At least one XML file should be specified using one of --xml or --list options - Both options can be provided in which case all the specified tests in - both will be run. - - The --bbServer, --bbPasswd, --driverPort options should never be specified - directly since they are only useful when launching it through external - scripts like runCSDriver.sh - - 6. When using a ssh session run OS_BUILD_DIR/framework/csharp/bin/runCSDriver.sh. - Usage: runCSDriver.sh [OPTION] [<host1> ...] - <host1> ... are (optional) hostnames of the machines on which to - distribute the clients. Each host can optionally have the hostGroup - name prefixed to it with ':' e.g. CS:host1; the hostGroup should not - be '*' which implicitly stands for all hosts - Options are: - --xml=FILE An XML file having the test to be executed. - This option can be specified multiple times - --list=FILE A file containing a list XML files having the tests to be executed - --pool=POOLOPTION where POOLOPTIONs are poolwithendpoints/poolwithlocator to run the existing tests with pool option. - --database This to be used for upload the data in database for regression history. Need to be mentioned at every regression run. - --at=TIME The time at which to execute the regression test - --auto-ssh Use ssh configured for passwordless login instead of plink as remote shell - Note that this shall only work if sshd is running as a domain user having - permissions to access network shares and other resources on given hosts. - - At least one XML file should be specified using one of --xml or --list options - Both options can be provided in which case all the specified tests in - both will be run. - - -Example usage: - - OS_BUILD_DIR/framework/csharp/bin/FwkDriver --list=nativeNightly.list CS:pc33 CS:pc34 pc34 pc35 pc36 pc37 pc38 -or - OS_BUILD_DIR/framework/csharp/bin/runCSDriver.sh --list=nativeNightly.list CS:pc33 CS:pc34 pc34 pc35 pc36 pc37 pc38 - -With Pool Option: - OS_BUILD_DIR/framework/csharp/bin/FwkDriver --pool=poolwithendpoints --list=nativeNightly.list CS:pc33 CS:pc34 pc34 pc35 pc36 pc37 pc38 -or - OS_BUILD_DIR/framework/csharp/bin/FwkDriver --pool=poolwithlocator --list=nativeNightly.list CS:pc33 CS:pc34 pc34 pc35 pc36 pc37 pc38 - -Note that the XML file path (given in --xml option or inside the list) should -be relative to base xml directory like in C++. -The list file itself should be the path relative to the current directory. - -The current directory can contain a gfcsharp.properties or gfcpp.properties -file to set the default properties for the clients (preference is in the -given order). The following variables can be set in file "gfcsharp.env" in the -current directory (line starting with # indicates a comment and is ignored): - - FWK_WINLOGDIR="...": - root of the path where the logs have to be created in Windows notation - FWK_UNIXLOGDIR="...": - root of the path where unix cacheserver logs have to be created in - Unix notation; this is required when starting the cacheserver on a - UNIX machine (more on this below) and should point to the same - directory as FWK_WINLOGDIR for it to work correctly - GFE_DIR="...": - the path of the UNIX java cacheserver product; required when one of - server client machine lists a UNIX machine - GFE_CLASSPATH="...": - any additional CLASSPATH for the UNIX java cacheservers - GF_JAVA="..." - Provied the java path ( e.g. /gcm/where/jdk/1.6.0_7/x86_64.linux/bin/java ). - GF_JAVA.WIN="..." - Provide the java path for windows to execute LatestProp class file( e.g. //inf1/shared/jdk/1.6.0_7/x86_64.linux/bin/java ). - GFE_DIR.WIN="..." - Provide java cacheserver product path for windows to execute LatestProp class file ( e.g. //bass/bass1/users/rkumar/project/trunk/product ). - - -Note that the gfcsharp.env is not a shell script and no "export" or other -commands should be given. Any other environment variables like CLASSPATH -can also be provided here (note that the local path for the jars can be -provided in CLASSPATH since that shall be converted to the share format -by the framework automatically) or other environment variables specified -in OS_BUILD_DIR/framework/csharp/bin/run.env can be overridden here. -The double quotes around the values are optional even if there are spaces. - -If no FWK_WINLOGDIR is provided then by default the logs will be created -in OS_BUILD_DIR/tests/results/csharpfwk. A subdirectory named -FwkCS_<timestamp directory> shall be created that contains the logs for a -particular run and a link to the latest timestamp directory will also be -created. There will be separate sub directories created for separate XMLs -inside this directory, and each sub-directory for an XML will contain a -separate sub-directory for each test listed in the XML. The directory name -will be the name of the test. The top-level directory shall contain a -Driver.log file which records all the actions taken by the driver in that -particular run, and at the end of the run an error.report shall be generated -inside the top-level directory as well as inside each of the XML sub-directories. - -Using C# framework it is possible to launch java servers on linux/solaris machines as follows: - - * Specify FWK_LOGDIR.WIN and FWK_LOGDIR.LIN/FWK_LOGDIR.SUN to point to the same - network directory (e.g. //ns320/users/swale/csresults and /home/swale/csresults - respectively) in gfcsharp.env - * Specify the GFE_DIR.LIN/GFE_DIR.SUN to point to the location of unix cacheserver - (e.g. /gcm/where/cplusplus/thirdparty/linux/gfe/product) in gfcsharp.env - For each of the above variables use <var>.<host type> where host type can - be one of WIN, LIN or SUN - * Now you can use any unix hostname for the CS hostgroup. However, note that - there should be at least one windows machine in that hostgroup that will - actually run the C# code that will perform setup/start/stop of - cacheservers remotely. For example: - FwkDriver --xml=Native/failoverTest.xml CS:bass CS:trout CS:pc34 pc31 pc32 - * To ensure that all servers are started on linux servers use the first - host as windows one and all others as linux ones. The framework has been - modified so as to start choosing the servers to use from the second one - in the list. Also it means that the number of linux hosts in the CS hostgroup - should be equal to the number of clients being started in that group, - otherwise cycling of clients among hosts will cause servers to be - started on windows hosts. For example: - FwkDriver --xml=RemoteQuery/failoverQueryTest.xml CS:pc33 CS:bass CS:trout pc33 pc34 pc36 - This will start JCS1 on pc33 but the actual servers shall be launched - from the second server in the host-group list i.e. bass, so that the two - servers will be started on bass and trout respectively from pc33, while - other clients will be launched on pc33/pc34/pc36 -This is useful for regressions where windows servers can go OutOfMemory -due to limited amount of available memory. http://git-wip-us.apache.org/repos/asf/geode/blob/03781bd1/src/tests/cpp/scripts/using_runDriver ---------------------------------------------------------------------- diff --git a/src/tests/cpp/scripts/using_runDriver b/src/tests/cpp/scripts/using_runDriver deleted file mode 100644 index c9fcee0..0000000 --- a/src/tests/cpp/scripts/using_runDriver +++ /dev/null @@ -1,166 +0,0 @@ -This file describes the command line arguments used by the runDriver script, -the files that may be used as values for some of the command line arguments, -and shows some common uses for runDriver. - -First the arguments runDriver accepts: - -This option indicates that the debug build executables and libraries should be -used. This will affect the paths used in setting PATH and LD_LIBRARY_PATH. - -D - -These next four all cause valgrind to be used, and each will cause a different tool -to be used. These are mutually exclusive, but the script does not error out. -It is simply a "first one wins" situation. After the tool to use has been set, -subsequent options that would otherwise set are just ignored. -You should just use one of these next four options: - -M -- use valgrind with memcheck - -C -- use valgrind with cachegrind - -H -- use valgrind with massif - -P -- use valgrind with callgrind - -This option allows you to specify a particular xml test file to include in the run. -This option may be used multiple times, and can be used in addition to the -l option. -The xml file should have path information relative to the <build_results>/framework/xml directory. - -x <xml file> - -This option allows you to specify a text file containing a number of text xml files. -Each xml file in this file will be added to the test, just as though it had been -specified using the -x option. This means the path relative to ..../framework/xml -is required. This is used for regression testing. - -l <file containing names of xml files> - - -This option specifies how many times each test should be run. Each xml test file -will be processed this number of times. The default is 1. This is used in perf testing -where a single run is not adequate to generate reliable numbers. - -r <n> - -This option causes the framework to start a unicast locator for topic resolution, -nstead of using the default multicast topic resolution. This will cause a -different locator to be used for each run of an xml test, to prevent pollution -from leftover processes that the framework failed to kill. - -u - -This option causes the framework to start the test with pool along with the specified pool option - -p <pool option> -where <pool option>= poolwithendpoints/poolwithlocator - -This option causes the test to use statically built executables and libraries, -instead of the dynamically linked. This is used in regression tests to make sure -both types are tested. This will affect the paths used in setting PATH -and LD_LIBRARY_PATH. - -s - -This option allows valgrind to be used with only the clients specified, -instead of trying to run all client under valgrind. This option can be specified -multiple times, allowing any number of clients to be run under valgrind. - -t client_id - -The next three options allow you specify the location of the build to use on a -particular OS. The platform that runDriver is executed on will default to the -build that runDriver is being executed out of. The specification is in the form -of hostname:absolute_path_to_build with the directory above product being the -location to specify. - -L <host>:<build_location> -- linux build to use - -S <host>:<build_location> -- solaris build to use - -W <host>:<build_location> -- windows build to use - -This option allows you to specify the location of the valgrind install. -Not very sophisticated, only one location is active for a entire test run. -The default location is /gcm/where/cplusplus/perftools/valgrind. - -V path_to_valgrind - -This option allows you to specify what directory will be used as the base location -for the test run, all files and directories created as part of the run will be -under this location. -The default is the current working directory when runDriver is invoked. - -d test_directory - -This option allows email recipients to be specified. The content of the error.report -file for the entire test run will be emailed to the specified recipients. -This option may be used multiple times to specify multiple recipients. - -m mail_address - -This option allows you to specify a file containing additional command line -arguments. Its purpose is to allow you place common, or lengthy arguments into -a file, and use that file whenever appropriate by using this option. Any -argument is allowed, with the exception of hostnames, as they do not have a option -that prefaces them. You can include the -h option that specifies a file with host -names in it. The file is consumed and its arguments processed as soon as it is -encountered on the commandline. So where it appears relative to other command line -options may be important. This option may be used multiple times. You could have -different options files for different purposes, and they may be used in -conjunction with each other at times. - -o options_file - -It is important to note some behaviors that result from using an options file. -Some arguments are "last one wins" arguments, others are "first one wins", this -causes the order of the arguments on the command line relative to the -o option -to be important. Some arguments cannot be unset, such as the -D, -M, etc options. -If you set this in an options file, you cannot override it on the command line, -even after the -o. Some arguments can appears many times, their content -aggregating with the previous occurances. This prevents you from overriding -something like email recipients on the command line. Whatever is on the command -line is simply added to anything that may have been specified through the use of -the -o option. - -This option allows you to place the hosts you wish to use into a file, and just -specify that file on the command line. - -h <file_containing_host_name> - -Lastly, rundriver expects all arguments after the options to be host names to -use in the test. It aggregates these names with any hosts that might have been -specified using the -h option. If no host are specified in either manner, the -host runDriver is executing on will be the only host used in the test. - host list - -This option allows you to upload the regression results into database table to keep the regression history. - -R -Some examples of runDriver use: - -~/mybuild/framework/scripts/runDriver -x Misc/quickTest.xml \ - -W tkeith-desk:/cygdrive/C/Temp/Built/trunk tiny tkeith-desk hs20a - -This is an example of needing to run a single test, using the current working -directory as the test directory, and using a mix of linux and windows machines. - - -~/mybuild/framework/scripts/runDriver -x Perf/perfBenchmark.xml -r 10 \ - -h grid_machines.txt - -Is an example of how runDriver could be used to run perfBenchmark 10 times on a -set of machines in an Intel ( or other vendor ) lab. - -~/mybuild/framework/scripts/runDriver -x Native/getAll.xml -p poolwithendpoints bensa - -~/mybuild/framework/scripts/runDriver -x Native/getAll.xml -p poolwithlocator bensa - -~/mybuild/framework/scripts/runDriver -x Native/getAll.xml bensa - -The above 3 examples will enable the xmls to run with pool with various pool options ie -The 1st one will run with pool,with serverendpoints -2nd one with pool,with locators and -3rd will run without pool which is the default. - -/export/tiny1/users/tkeith/regression/framework/scripts/runDriver \ - -l short_nightly.list \ - -h /export/tiny2/users/tkeith/regression/regHostsA.txt \ - -o /export/tiny2/users/tkeith/regression/regEmail.txt \ - -o /export/tiny2/users/tkeith/regression/regBuilds.txt - -This is an example of how it might be used for regression runs. -The list of xml tests are in /export/tiny1/users/tkeith/regression/framework/xml/short_nightly.list -and the list of hosts to use is in regHostsA.txt -and the list of email recipients is in regEmail.txt -and the builds to use in the regression run are in regBuilds.txt. - - -It is important to note that runDriver has no option to do an git pull and -clean build. This is handled by the runBuild script. In a cron, it should be run -prior to the regression test themselves, allowing enough time for it to complete -prior to the regression tests starting. - - -The files specified by the -o -h and -l options are allowed to have comments. -The comments are indicated by a # symbol. The contents of these files -will have everything between a # and the end of line, stripped before the -file is consumed. this allows trailing comments in addition to whole line comments. http://git-wip-us.apache.org/repos/asf/geode/blob/03781bd1/src/tests/cpp/scripts/using_scalePerfDriver ---------------------------------------------------------------------- diff --git a/src/tests/cpp/scripts/using_scalePerfDriver b/src/tests/cpp/scripts/using_scalePerfDriver deleted file mode 100644 index c1ace97..0000000 --- a/src/tests/cpp/scripts/using_scalePerfDriver +++ /dev/null @@ -1,6 +0,0 @@ -#Steps to run yet to come. -#use runScalePerf script for cpp run -Example for cpp run: Need 8 hosts to run the tests -/export/w1-gst-dev01a/users/rkumar/project/ThinClient/build-artifacts/linux/framework/scripts/runScalePerf /export/w1-gst-dev01a/users/rkumar/project/ThinClient/build-artifacts/linux /export/gcm/where/jdk/1.6.0_26/x86_64.linux/bin/java /gcm/where/gemfire/70/snaps.Any/snapshots.34944/gf70MAINTsancout/product . w1-gst-dev01 w1-gst-dev02 w1-gst-dev03 w1-gst-dev04 w1-gst-dev05 w1-gst-dev06 w1-gst-dev07 w1-gst-dev08 -#use FwkDriver.exe for c# run -OS_BUILD_DIR/framework/csharp/bin/FwkDriver.exe --list=scale.list CS1:w1-gst-dev01 CS1:w1-gst-dev02 CS1:w1-gst-dev03 CS1:w1-gst-dev04 CS2:w1-gst-dev05 CS2:w1-gst-dev06 CS3:w1-gst-dev07 CS3:w1-gst-dev08 http://git-wip-us.apache.org/repos/asf/geode/blob/03781bd1/src/tests/cpp/scripts/waitForBBKey.sh ---------------------------------------------------------------------- diff --git a/src/tests/cpp/scripts/waitForBBKey.sh b/src/tests/cpp/scripts/waitForBBKey.sh deleted file mode 100755 index 3d97a4a..0000000 --- a/src/tests/cpp/scripts/waitForBBKey.sh +++ /dev/null @@ -1,26 +0,0 @@ -#!/bin/bash - -[ "$#" -gt 3 -o "$#" -lt 2 ] && echo "`basename "$0"`: Incorrect number[$#] of args: $@." && exit 1 - -# maximum wait for 30min if no time is given -maxSecs=1800 -[ "$#" -eq 3 ] && maxSecs="$3" - -bbVal="`FwkBB get "$1" "$2" 2>/dev/null`" -numIters=1 -while [ -z "${bbVal}" ]; do - sleep 1 - if [ "${numIters}" -ge "${maxSecs}" ]; then - break - fi - ((numIters++)) - bbVal="`FwkBB get "$1" "$2" 2>/dev/null`" -done - -echo ${bbVal} - -if [ -z "${bbVal}" ]; then - exit 1 -else - exit 0 -fi http://git-wip-us.apache.org/repos/asf/geode/blob/03781bd1/src/tests/cpp/scripts/waitForTask.sh ---------------------------------------------------------------------- diff --git a/src/tests/cpp/scripts/waitForTask.sh b/src/tests/cpp/scripts/waitForTask.sh deleted file mode 100755 index 8a86965..0000000 --- a/src/tests/cpp/scripts/waitForTask.sh +++ /dev/null @@ -1,72 +0,0 @@ -#!/bin/bash - -export local=`hostname` -export GF_FQDN=`nslookup $local 2>/dev/null | ${AWK:-awk} '/^Name:/{print $2}'` - -tag="" -numClients=1 -while getopts ":t:c:p:m:" op -do - case $op in - ( "m" ) ((scnt++)) ; waitMinutes="$OPTARG" ;; - ( "t" ) ((scnt++)) ; tag="$OPTARG" ;; - ( "c" ) ((scnt++)) ; numClients="$OPTARG" ;; - ( "p" ) ((scnt++)) ; seqid="$OPTARG" ;; - ( * ) echo "Unknown argument provided: -$OPTARG, ignoring." ; echo "" ;; - esac - ((scnt++)) -done - -while [ ${scnt:-0} -gt 0 ] -do - shift - ((scnt--)) -done - -# Where are we now? -currDir=`pwd` -bnam=`basename $currDir` - -mkdir -p ../pids/$GF_FQDN/$bnam -echo "${$}" > ../pids/$GF_FQDN/$bnam/waitForTask_pid - -# cnt specified which client to setup: -cnt=$numClients - -# Base for dir names -gfdb=GFEJC${tag:+_}$tag - -tdir=${gfdb}_$cnt -if [ ! -d $tdir ] -then - echo $tdir does not exist. - exit 0 -fi - -grep "seqid $seqid finished" $currDir/$tdir/JC${tag:+_}$tag${cnt:+_}$cnt.log -status=$? -num=0 -sleepTime=10 ## Note: changing this impacts the calculation used to set sleepsPerMinute -sleepsPerMinute=6 -((limit=$waitMinutes*$sleepsPerMinute)) -((logLimit=$limit/3)) -while [ $status -ne 0 ] -do - sleep $sleepTime - ((num++)) - if [ $num -gt $limit ] - then - echo "ERROR: Wait for task timed out after $waitMinutes minutes." - exit 1 - fi - ((val=$num%$logLimit)) - if [ $val -eq 0 ] - then - ((minutes=$num/$sleepsPerMinute)) - echo "Wait for task has waited for $minutes minutes." - fi - grep "seqid $seqid finished" $currDir/$tdir/JC${tag:+_}$tag${cnt:+_}$cnt.log - status=$? -done - -exit 0
