Warning: Can't synchronize with repository "(default)" (Unsupported version control system "svn": No module named svn). Look in the Trac log for more information.

Ticket #904 (closed defect: fixed)

Opened 13 years ago

Last modified 11 years ago

VisitManager startup timing issue

Reported by: thesamet Owned by: Chris Arndt
Priority: normal Milestone: 1.0.x bugfix
Component: Identity Version: 0.9a6
Severity: normal Keywords: visit, sovisit, needs review
Cc:

Description (last modified by Chris Arndt) (diff)

The VisitManager sometimes raises, at start up, the following exception:

Exception in thread VisitManager:
Traceback (most recent call last):
  File "/usr/lib/python2.4/threading.py", line 442, in __bootstrap
    self.run()
  File "/usr/lib/python2.4/site-packages/TurboGears-0.9a6-py2.4.egg/turbogears/visit/api.py", line 256, in run
    self.update_queued_visits( queue )
  File "/usr/lib/python2.4/site-packages/TurboGears-0.9a6-py2.4.egg/turbogears/visit/sovisit.py", line 56, in update_queued_visits
    conn.query( conn.sqlrepr(u) )
  File "/usr/lib/python2.4/site-packages/SQLObject-0.7.1dev_r1588-py2.4.egg/sqlobject/dbconnection.py", line 747, in query
    return self._dbConnection._query(self._connection, s)
  File "/usr/lib/python2.4/site-packages/SQLObject-0.7.1dev_r1588-py2.4.egg/sqlobject/dbconnection.py", line 302, in _query
    self._executeRetry(conn, conn.cursor(), s)
  File "/usr/lib/python2.4/site-packages/SQLObject-0.7.1dev_r1588-py2.4.egg/sqlobject/dbconnection.py", line 297, in _executeRetry
    return cursor.execute(query)
OperationalError: no such table: tg_visit

It happens when the table tg_visit does not exist. (I use sqlobject with sqlite in memory table, so it never exists at start up)

When looking at the visit/api.py and visit/sovisit.py, it was easy to note that the VisitManager is created (and started) a bit before the model is created...

Attachments

visit-create-model.diff Download (799 bytes) - added by Chris Arndt 11 years ago.

Change History

comment:1 Changed 13 years ago by jorge.vargas

  • Component changed from TurboGears to Identity
  • Milestone set to 1.0

so your suggesting switching them over?

wont this create a similar problem elsewhere?

comment:2 Changed 13 years ago by jorge.vargas

  • Milestone changed from 1.0 to 1.0b4

comment:3 Changed 12 years ago by alberto

  • Milestone changed from 1.0b4 to 1.1

comment:4 Changed 12 years ago by jorge.vargas

  • Milestone changed from 1.1 to 1.0.2

if this is a real bug it should be fix by switching over the calls, I think we should invetigate it.

comment:5 Changed 12 years ago by plewis

Here is the bit of code that is in question (from visit.api.start_extension)

def start_extension():
# ...
    _manager= _create_visit_manager( timeout )

    filter= VisitFilter()
    # Temporary until tg-admin can call create_extension_model
    create_extension_model()
# ...

def create_extension_model():
    # Create the data model of the VisitManager if one exists.
    if _manager:
        _manager.create_model()

So it's not as simple as reversing the order of the two calls.

Is this still an issue since Visit moved into model.py? Seems like tg_visit should get created along with all of the other user's tables.

comment:6 Changed 12 years ago by alberto

  • Milestone changed from 1.0.2 to 1.0.3

comment:7 Changed 12 years ago by faide

  • Milestone changed from 1.0.3 to 1.1

comment:8 Changed 11 years ago by khorn

Can anyone verify whether this is still a problem?

comment:9 Changed 11 years ago by faide

  • Milestone changed from 1.1 to 1.1.1

still an issue ?

comment:10 Changed 11 years ago by faide

  • Milestone changed from 1.6 to 1.5

comment:11 Changed 11 years ago by Chris Arndt

  • Keywords visit, sovisit, needs feedback added; visit sovisit removed
  • Milestone changed from 1.5 to 1.1

comment:12 Changed 11 years ago by Chris Arndt

  • Keywords review added; feedback removed
  • Severity changed from minor to normal
  • Description modified (diff)
  • Milestone changed from 1.1 to 1.0.x bugfix

Yes, this is still an issue, the corresponding code in visit.api is still unchanged.

So why not just let the VisitManager instance take care of creating it's model when it is instantiated and before it starts it's thread? Patch for 1.x branch attached.

Changed 11 years ago by Chris Arndt

comment:13 Changed 11 years ago by Chris Arndt

  • Owner changed from anonymous to Chris Arndt
  • Status changed from new to assigned

comment:14 Changed 11 years ago by Chris Arndt

  • Status changed from assigned to closed
  • Resolution set to fixed

Fixed in r5342.

Note: See TracTickets for help on using tickets.