Exceptions raised when using sweat.py

[vaz-ar]

two exceptions are raised when using sweat.py:

Exception AttributeError: "'NoneType' object has no attribute 'is_closed'" in <bound method FrontendApp.__del__ of <coldsweat.frontend.FrontendApp object at 0x7f47b5c3c150>> ignored
Exception AttributeError: "'NoneType' object has no attribute 'is_closed'" in <bound method FeverApp.__del__ of <coldsweat.fever.FeverApp object at 0x7f47b5c3c050>> ignored

[passiomatic]

Looks like you have _db set to None for an unrecognized cause. When do you get those exceptions? Which sweat command are you using? Thx.

[vaz-ar]

$ python sweat.py refresh
Fetch completed. See log file for more information
Exception AttributeError: "'NoneType' object has no attribute 'is_closed'" in <bound method FrontendApp.__del__ of <coldsweat.frontend.FrontendApp object at 0x7fdfefd8f150>> ignored
Exception AttributeError: "'NoneType' object has no attribute 'is_closed'" in <bound method FeverApp.__del__ of <coldsweat.fever.FeverApp object at 0x7fdfefd8f050>> ignored

It also occured with the import command.

[passiomatic]

I'll look into it if I can reproduce this behavior. I'm assuming you are running latest version and all the required packages are up-to-date. Also database schema is up-to-date too. Could you please copy-paste your config file -- with database user/password redacted, of course :)

Do you see any exception if you set processes: 0 in the config file?

[vaz-ar]

I got the problem on a fresh install, and yes I updated the requirements before starting. Since it is a fresh install I assume that the database schema was up to date, but I still ran the update command, which didn't solve the problem (the exceptions are also raised with this command).

My config file is the default one (connection_url: sqlite:///data/coldsweat.db).

Additionnal informations: I deployed coldsweat using gunicorn and nginx as described in the wiki

[passiomatic]

OK, thank you. It could be something involving sqlite and multiprocessing, since by default Coldsweat ships with processes: 4. Please try to set processes to zero and let me know if you still getting the exceptions.

Deploy method should not interfere since you are getting errors via the command line interface,

[vaz-ar]

Ok thanks, I'll try and let you know

[vaz-ar]

Sorry I couldn't try it and now my installation is completely broken, I'll need to reinstall my server and I don't have the time right now.

[passiomatic]

Sorry I couldn't try it and now my installation is completely broken, I'll need to reinstall my server and I don't have the time right now.

No problem. I'll keep the ticket open so we can pinpoint what is causing the exceptions later.

[cosmigo]

I'm getting this exception on a fresh install in a virtalenv - MacOSX 10.10.4 - I could not find anything about "locking protocol" problems on peewee yet.

python sweat.py fetch
Traceback (most recent call last):
  File "sweat.py", line 12, in <module>
    run()
  File "/Users/dsc/Projects/coldsweat/coldsweat/commands.py", line 198, in run
    cc.run_command(command_name, command_options, command_args)
  File "/Users/dsc/Projects/coldsweat/coldsweat/commands.py", line 47, in run_command
    handler(options, args)        
  File "/Users/dsc/Projects/coldsweat/coldsweat/commands.py", line 91, in command_refresh
    self.fetch_all_feeds()
  File "/Users/dsc/Projects/coldsweat/coldsweat/controllers.py", line 298, in fetch_all_feeds
    self.fetch_feeds(feeds)
  File "/Users/dsc/Projects/coldsweat/coldsweat/controllers.py", line 275, in fetch_feeds
    p.map(feed_worker, feeds)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/multiprocessing/pool.py", line 250, in map
    return self.map_async(func, iterable, chunksize).get()
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/multiprocessing/pool.py", line 554, in get
    raise self._value
peewee.OperationalError: locking protocol

[passiomatic]

Yes, I can reproduce the problem on sqlite using multiprocessing Yosemite too. Locking protocol seems related more to sqlite than Peewee.

About the subject recently I was reading this: http://beets.radbox.org/blog/sqlite-nightmare.html

[passiomatic]

Interesting enough I cannot reproduce the error anymore on Yosemite 10.10.5. I'm using a brewed Python and default configuration (except for log.level=DEBUG) and the coldsweat/tests/markup/subscriptions.xml feeds. Also I'm using the 0.9.6-wip branch.

Sqlite3 info are:

Python 2.7.9 (default, Apr 27 2015, 18:58:46) 
[GCC 4.2.1 Compatible Apple LLVM 6.1.0 (clang-602.0.49)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sqlite3 as s
>>> s.version_info
(2, 6, 0)
>>> s.sqlite_version
'3.8.9'

Can you please run the test again on latest Yosemite and post you sqlite3 module version?

[cosmigo]

I upgraded all packages yet am still getting the error with processes > 0. I'm getting another sqlite3 version (3.8.5).

Tempita==0.5.2
WebOb==1.4.1
feedparser==5.2.1
peewee==2.6.4
pysqlite==2.8.1
wsgiref==0.1.2

Python 2.7.10 (default, Jul 14 2015, 19:46:27) 
[GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.39)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sqlite3 as s
>>> s.version_info
(2, 6, 0)
>>> s.sqlite_version
'3.8.5'
>>> 

I will try the new branch then and see.

[passiomatic]

0.9.6 ATM adds very little to the mix. What's beyond my comprehension is that you are using a newer Python version which comes with a older sqlite release. So I'm wondering how sqlite gets compiled into Python.

[passiomatic]

I'm closing this cause I cannot reproduce the issue anymore. Seems related to the sqlite version compiled with Python, though.