[ https://jira.jboss.org/jira/browse/JBTM-390?page=com.atlassian.jira.plugi... ] Jonathan Halliday updated JBTM-390: ----------------------------------- Fix Version/s: 4.4 (was: 4.4.CR2) Most JTS test now run locally. Some issues still exist: no JTA test coverage, no JDBC test coverage, excessive memory usage by ant/junit, excessive buffering of output (may be related to memory usage), occasional unexplained hanging of tests on husdon only (ORB shutdown blocking?). These are relatively low priority. Pushing to next release. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBTM-390?page=com.atlassian.jira.plugi... ] Jonathan Halliday updated JBTM-390: ----------------------------------- Fix Version/s: 4.6 (was: 4.5) JacORB hang appears to be resolved. Next up: JDBC tests and JTA build tests. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBTM-390?page=com.atlassian.jira.plugi... ] Jonathan Halliday commented on JBTM-390: ---------------------------------------- Traced an intermittant failure in crash-recovery-12 test group to a problem with port binding in the recovery manager. Those tests kill and restart the recovery manager in quick sucession. The port sometimes does not get released fast enough, so it's not available for the restarted process to acquire. This is less of an issue for the DTF cluster as the run is slow enough that the problem does not manifest. In local mode however it occurs frequently enough to be really annoying. Added a simple delay-retry block to the recovery manager startup for test mode only, which seems to deal with the problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBTM-390?page=com.atlassian.jira.plugi... ] Jonathan Halliday updated JBTM-390: ----------------------------------- Fix Version/s: 4.7 (was: 4.6) pushing to the next release for ongoing refinement. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBTM-390?page=com.atlassian.jira.plugi... ] Jonathan Halliday commented on JBTM-390: ---------------------------------------- re: the jdbc tests. Most tests use two db accounts. They get the connection info from a properties file, which is machine (testnode) specific. They construct table and other identifier names using the username from that file. By giving each node its own pair of db accounts, they therefore don't interfere with eachother when running tests simultaneously. That's a surprisingly common case, as it's typical to initiate a test run spanning multiple nodes (e.g. different O/S). On the up side this is flexible enough that we can do clever stuff like splitting a test over two nodes and having them actually use the same accounts, to simulate e.g. a distributed tx with nodes connecting to a shared db. On the down side, we need lots of db accounts set up and can use only test nodes that have been configured. This is ok for the DTF, which has a stable set of 10 nodes. It's a pain for hudson, which has lots more. Therefore, the following changes will be made: 1) Table and other identifier names will be done through a utility function to provide a single point where we can change the strategy. Initially the change will be: include the node name (hostname, with some munging because e.g. '-' is ok in hostnames but not some db's identifiers) in the table name, in addition to the username. This actually changes the semantics of the tests somewhat, but only for multinode cases like the one described above, which we don't currently run anyhow. 2) The mechanism for reading properties file will be extended so that if it does not find a properties file for the named host on which it's running, it will use a default one. Thus DTF nodes can remain unchanged, whilst hudson slave nodes will share a single pair of db accounts but not conflict because of the table naming strategy change. That leaves the problem of getting the db drivers in the first place, which is for another comment. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBTM-390?page=com.atlassian.jira.plugi... ] Jonathan Halliday updated JBTM-390: ----------------------------------- Fix Version/s: 4.8.0 (was: 4.7.0) Pushing to 4.8 for ongoing refinements. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBTM-390?page=com.atlassian.jira.plugi... ] Jonathan Halliday closed JBTM-390. ---------------------------------- Resolution: Done -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira