annotate tests/0017/run-test.sh @ 548:e18843dc0aea

Implement a rudimentary API for audioDB::liszt The API is rudimentary because we've dropped support for the incremental retrieval of tracks and their number of vectors (at the API level; the SOAP and command-line support is still there -- no changes should be visible). This is potentially bad for the large-scale databases, of course; one million tracks will take of the order of 16MB of RAM, more if I'm unlucky about how std::string.c_str() is implemented. Both this liszt operation and querying (and sampling, forthcoming...) would benefit from a `cursor-like' interface to retrieval results: for an API like that, instead of getting a struct with the data there, you get a cookie with which you can ask the database for successive results. This would be neat for all sorts of reasons. In the meantime, at least this change fixes SOAP memory leaks related to liszt. Make liszt.o part of LIBOBJS rather than ordinary OBJS, so that the liszt functionality is actually compiled into the library. Add a test for this library functionality; also modify the command-line test file to run the SOAP server on its own port.
author mas01cr
date Wed, 11 Feb 2009 12:38:03 +0000
parents fe4dc39b2dd7
children
rev   line source
mas01cr@252 1 #! /bin/bash
mas01cr@96 2
mas01cr@96 3 . ../test-utils.sh
mas01cr@96 4
mas01cr@96 5 if [ -f testdb ]; then rm -f testdb; fi
mas01cr@96 6
mas01cr@96 7 ${AUDIODB} -d testdb -N
mas01cr@96 8
mas01cr@96 9 # tests that the lack of -l when the query sequence is shorter doesn't
mas01cr@96 10 # segfault.
mas01cr@96 11
mas01cr@96 12 intstring 2 > testfeature
mas01cr@96 13 floatstring 0 1 >> testfeature
mas01cr@96 14 floatstring 1 0 >> testfeature
mas01cr@96 15
mas01cr@96 16 ${AUDIODB} -d testdb -I -f testfeature
mas01cr@96 17
mas01cr@96 18 # sequence queries require L2NORM
mas01cr@96 19 ${AUDIODB} -d testdb -L
mas01cr@96 20
mas01cr@96 21 start_server ${AUDIODB} 10017
mas01cr@96 22
mas01cr@96 23 echo "query point (0.0,0.5)"
mas01cr@96 24 intstring 2 > testquery
mas01cr@96 25 floatstring 0 0.5 >> testquery
mas01cr@96 26
mas01cr@96 27 # FIXME: this actually revealed a horrible failure mode of the server:
mas01cr@96 28 # since we were throwing exceptions from the constructor, the
mas01cr@96 29 # destructor wasn't getting called and so we were retaining 2Gb of
mas01cr@96 30 # address space, leading to immediate out of memory errors for the
mas01cr@96 31 # /second/ call. We fix that by being a bit more careful about our
mas01cr@96 32 # exception handling and cleanup discipline, but how to test...?
mas01cr@96 33
mas01cr@96 34 expect_client_failure ${AUDIODB} -c localhost:10017 -d testdb -Q sequence -f testquery
mas01cr@96 35 expect_client_failure ${AUDIODB} -c localhost:10017 -d testdb -Q sequence -f testquery -n 1
mas01cr@96 36
mas01cr@96 37 check_server $!
mas01cr@96 38
mas01cr@96 39 echo "query point (0.5,0.0)"
mas01cr@96 40 intstring 2 > testquery
mas01cr@96 41 floatstring 0.5 0 >> testquery
mas01cr@96 42
mas01cr@96 43 expect_client_failure ${AUDIODB} -c localhost:10017 -d testdb -Q sequence -f testquery
mas01cr@96 44 expect_client_failure ${AUDIODB} -c localhost:10017 -d testdb -Q sequence -f testquery -n 1
mas01cr@96 45
mas01cr@96 46 check_server $!
mas01cr@96 47
mas01cr@96 48 # see if the server can actually produce any output at this point
mas01cr@96 49 ${AUDIODB} -c localhost:10017 -d testdb -Q sequence -l 1 -f testquery -n 1 > testoutput
mas01cr@96 50 echo testfeature 0 0 1 > test-expected-output
mas01cr@96 51 cmp testoutput test-expected-output
mas01cr@96 52
mas01cr@96 53 stop_server $!
mas01cr@96 54
mas01cr@96 55 exit 104