Before using LIXA to manage your transactions you might be interested in checking the compiled software quality.
LIXA has its own test suite implemented with Autotest. A specific build configuration is necessary to enable all the tests:
tar xvzf lixa-X.Y.Z.tar.gz
cd lixa-X.Y.Z
./configure --prefix=/tmp/lixa --enable-crash
make check
If the binary code produced by the compiler is fine, and your system is fine too, all the test must complete without errors.
Some case tests, specifically MT/1.0/* and MT/2.0/*, stress the LIXA software with a massive multithread workload. Sometimes the tests fail due to the configuration of your system and/or your user account. There are two well known issues:
max files: the case tests open approximately 1000 files (TCP/IP sockets); command ulimit -n must return the value 1024 or more
stack size: if the stack size is too large, 32 bit platform can experience addressing limit errors; reduce the default stack size to 4096 if necessary with command ulimit -s 4096
Due to practical reasons, for some features there is not automatic testing: tests that requires too many configurations become very difficult to develop and to maintain. Here's a list of features that are not automatically tested and how you can manually test them if necessary:
Oracle Instant Client: it does not provide a
standard oracle_env.sh and a SqlNet
configuration should be done in advance. To test it, use sample
programs provided and follow the reference manual for environment
set-up, program build and test
Oracle Pro*C: the "sys_include" statement of file
pcscfg.cfg requires a lot of hacking for
proper configuration, especially if the user installed the "zip"
package and/or the system is Ubuntu Linux. To test it, use sample
programs provided and follow the reference manual for environment
set-up, program build and test
Oracle Pro*COBOL: not yet available. To test it, use sample programs provided and follow the reference manual for environment set-up, program build and test
If you are interested in checking the internals of LIXA you can activate memory or thread check using Valgrind (it's assumed you already have installed Valgrind). If you were insterested in memory usage analysis, this is the sequence of commands you would use:
export CLIENT_CHECK_TYPE=memory export SERVER_CHECK_TYPE=memory make check
If you were interested in thread usage analysis, this is the sequence of commands you would use:
export CLIENT_CHECK_TYPE=thread export SERVER_CHECK_TYPE=thread make check
Check type can be set independently: you may check memory behavior of the client component without checking memory behavior of the server component and vice versa.
Valgrind is a very good tool, but can not understand some optimizations and detects some wrong memory leaks (false positives). Nevertheless if you were suspecting there is a memory leak inside LIXA, this would be a good start point to discover where the issue is.
Sometimes it may be useful to execute the case tests under the supervision of gdb instead of running it directly from the shell. Both client and server can be executed inside gdb using these commands:
export CLIENT_CHECK_TYPE=debug export SERVER_CHECK_TYPE=debug make check
Running a case test inside gdb may change the exit code checked by automake tests. You can not use this option as a default test option, but it may be useful to inspect some strange problems because gdb produce the stack trace related to the issue.