Roundup Tracker - Issues

Issue 2551025

classification
Title: Fix travis-ci failures for mysql tests
Type: crash Severity: normal
Components: Database Versions: devel
process
Status: new Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: ber, jerrykan, rouilj, schlatterbeck
Priority: high Keywords:

Created on 2019-02-21 00:37 by rouilj, last changed 2019-03-25 22:57 by rouilj.

Messages
msg6361 Author: [hidden] (rouilj) Date: 2019-02-21 00:37
Hi Ralf:

In message <20190220094433.72uymum546o72qsu@runtux.com>,
Ralf Schlatterbeck writes:
>On Tue, Feb 19, 2019 at 08:45:09PM -0500, John P. Rouillard wrote:
>> 
>> Does anybody know how to fix the Travis CI errors with mysql?
>> Jerrykan/John K do you have any ideas? It would be good to release the
>> current head as roundup 2.0.a1 once it passes CI to pypi.
>
>Do we have an issue for this, I have just looked and haven't found one.

We should as soon as this email hits the tracker 8-). I removed the
roundup-devel mailing list as the creation of the ticket will be
forwarded there and I didn't want to chance having the ML on the nosy
list.

>That said: I looked into the travis errors and investigated this and had
>written some emails about it so I would have to dig this out of my mail
>logs.
>
>The failing tests seem to be a configuration issue with mysql that
>should be fixable by changing the mysql config.

Yeah, I think the errors were happening during tear down. A quick
search indicated that the error could be caused by an oversized
packet. So the question is why did it all of sudden start, and how do
you change it in travis?

Have a great week.
msg6362 Author: [hidden] (ber) Date: 2019-02-25 11:04
In order to be able to help it would be nice to have links to the
current findings (ci, and Ralf's previous mails).
msg6383 Author: [hidden] (rouilj) Date: 2019-03-10 16:14
I was unable to find Ralf's emails in the list other than one note that
it should be fixable by changing mysql's my.cnf.

Looking at doc/mysql.txt, a fix for this is condition to change the
max_allowed_packet size setting. See also:

  
https://stackoverflow.com/questions/7942154/mysql-error-2006-mysql-server-has-gone-away

which indicates it could also be an out of memory condition, connection
limit or a timeout being hit.
The interactive_timeout and wait_timeout values are by default: 28800
seconds or 8 hours and the entire run
takes only 20 minutes. There are no settings for these vars in my.cnf
that would reduce the value.
Max_connections is 151 by default, again I don't think this is an issue.

I tried to edit /etc/mysql/my.cnf change that to 500M (from 16M) and
restart the server. This seems to have been done correctly according to
the log:

 https://travis-ci.org/roundup-tracker/roundup/builds/504322490

see lines: 5851 and 5927

but the 14 errors are still there.

Looking at the errors, some look like an example of issue2550743 as
these failing tests are indexer based:

test/test_indexer.py::mysqlIndexerTest::test_basics FAILED             
 [ 28%]
test/test_indexer.py::mysqlIndexerTest::test_casesensitity FAILED      
 [ 28%]
test/test_indexer.py::mysqlIndexerTest::test_change FAILED             
 [ 28%]
test/test_indexer.py::mysqlIndexerTest::test_clear FAILED              
 [ 28%]
test/test_indexer.py::mysqlIndexerTest::test_extremewords FAILED       
 [ 28%]
test/test_indexer.py::mysqlIndexerTest::test_manyresults FAILED        
 [ 28%]
test/test_indexer.py::mysqlIndexerTest::test_stopwords FAILED          
 [ 28%]
test/test_indexer.py::mysqlIndexerTest::test_wordsplitting FAILED      
 [ 28%]

but these failing tests/errors:

test/test_mysql.py::mysqlSessionTest::testDestroy FAILED               
 [ 65%]
test/test_mysql.py::mysqlSessionTest::testGetAll FAILED                
 [ 65%]
test/test_mysql.py::mysqlSessionTest::testList FAILED                  
 [ 66%]
test/test_mysql.py::mysqlSessionTest::testSetSession FAILED            
 [ 66%]
test/test_mysql.py::mysqlSessionTest::testUpdateSession FAILED         
 [ 66%]
test/test_mysql.py::mysqlSpecialActionTestCase::testInnerMain FAILED   
 [ 66%]
test/test_mysql.py::mysqlSpecialActionTestCase::testInnerMain ERROR    
 [ 66%]

aren't AFAIK indexer based.

The errors always come from:

    def sql_close(self):
        self.log_info('close')
        try:
>           self.conn.close()
E           OperationalError: (2006, '')
roundup/backends/back_mysql.py:589: OperationalError

So I am stumped.
msg6433 Author: [hidden] (rouilj) Date: 2019-03-25 22:57
I rolled back the mysqlclient installed by pip from 1.3.14 (breaks test) 
to 1.3.13 (tests pass).

I don't know what in 1.3.14 causes mysql to exit with a 2006 error on 
close. Nothing in the changelog stood out as a possible cause/change.
History
Date User Action Args
2019-03-25 22:57:12rouiljsetmessages: + msg6433
2019-03-10 16:14:00rouiljsetnosy: + jerrykan
messages: + msg6383
2019-02-25 11:04:50bersetnosy: + ber
messages: + msg6362
2019-02-21 00:55:13rouiljsetpriority: high
title: [Roundup-devel] Does anybody have release plans for current roundup devel? -> Fix travis-ci failures for mysql tests
type: crash
components: + Database
versions: + devel
2019-02-21 00:37:10rouiljcreate