Okay, I'll admit that I've got no reason for this, though I do have questions:
1. Is mxODBC being accessed directly, or it being accessed via SQLAlchemy? 2. If it *is* via SQLAlchemy, can you switch to pyODBC instead, and see if that will work properly for you? 3. If it is *not* via SQLAlchemy, can you try pyODBC anyway? If the problem is with mxODBC, and you can't get that to work reliably, I'd look elsewhere. pyODBC seems like a viable candidate. On Wed, Jun 29, 2011 at 6:21 PM, Paul Kraus <[email protected]> wrote: > Ubuntu 32bit 10.04 TLS > Python 2.6.5 > > uname -a > Linux teletraan1 2.6.32-32-generic-pae #62-Ubuntu SMP Wed Apr 20 22:10:33 > UTC 2011 i686 GNU/Linux > > I am not even sure how to go about tracking this down. I think this has > something to do with mxodbc but like I said I am not even sure where to > start with this. > > Here is what have done so far. It seems to happen when there are a lot of > queries being processed by mxODBC so yesterday I rewrote some code and moved > things around and the problem seemed to go away no issue all day until the > end of the day where it crashed 3 times with in 30 minutes (high activity > part of day). > > Prior to all of this I was having random issues with mxODBC segfaulting and > as part of that hunt I eventually moved to the 32bit version of > ubuntu(suggested by egenix), problem persisted so I for kicks moved the DB > connection into the same function with the query so for each query it > connects, runs query, and then destroys itself. With this change the > segfaults stopped but these pthread_mutex_lock errors replaced them at the > exact time of the change. Prior to this change only segfaults, after this > change no segfaults but these mutex issues. > > Then I thought maybe it had something to do with scheduler. I had scheduler > running some order imports into the app over couple of minutes and the > pthread issues where happening like crazy. Set scheduler to make sure it ran > sequentially and this had no effect. Moved it to a cron script that checks > to see if its already running and I was off to testing today. As I said > earlier no issues all day long until the last half hour of the day (major > improvement) but obviously not a fix but I am more confident that this has > something to do with mxODBC. > > I can not reproduce this error on my own it only seems to appear when the > system is under heavy load (not if i would call it heavy but 8 users each > running a query every couple of seconds). > > PK > > -- > You received this message because you are subscribed to the Google Groups > "TurboGears" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/turbogears/-/2oMhTdRRXIcJ. > > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/turbogears?hl=en. > -- Michael J. Pedersen My IM IDs: Jabber/[email protected], AIM/pedermj022171 Yahoo/pedermj2002, MSN/[email protected] My LinkedIn Profile: http://www.linkedin.com/in/michaeljpedersen Twitter: pedersentg -- You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/turbogears?hl=en.
