the ticket you linked to looks like it is not failing on the connection,
but rather failing on a query. these 2 line are of interest to me:
File "/base/data/home/apps/s~gk-hercules/1.365624770532609305/gluon/dal.py",
line 4115, in execute
return self.log_execute(command.decode('utf8'), *a, **b)
File "/base/data/home/apps/s~gk-hercules/1.365624770532609305/gluon/dal.py",
line 1703, in log_execute
ret = self.cursor.execute(*a, **b)
any chance you are able to open dal.py and put in some debug logging at those
lines an run it again? I'm curious what query/command web2py is trying to run
on the database. that might open the door to the missing answer!
cfh
On Monday, March 4, 2013 11:07:13 PM UTC-8, Philip Kilner wrote:
>
> Hi Christian,
>
> On 05/03/13 06:12, Christian Foster Howes wrote:
> > hrm....maybe it's time for GAE's next code update. i frequently notice
> > a degradation in performance just before they announce a new SDK
> version.
> >
>
> Interesting observation - will look out for that.
>
> > i'm not seeing anything out of the ordinary on my GAE apps right now,
> > but i do agree that the GAE team is not as transparent as i would like.
> >
> > i would suggest that you read the logs very carefully - there are lots
> > of different deadlineexceeded exceptions (literally the same class names
> > with different paths) and try adding extra logging to see where things
> > are getting stuck.
> >
>
> Actually, I'm not getting past a db connection so there is nothing in my
> application code to log, and the logged errors accessible in the console
> are very, very varied [1].
>
> > i don't know if web2py does automatic migrations on cloudsql, and in
> > production i always do my SQL by hand....but i'm old school and
> pessimistic.
> >
>
> It does - I did have a failed migration (how I wish their CloudSQL
> offering was based on Postgres!), but the app was buzzing away happily
> with the help of "fake_migrate_all" for a good while after that.
>
> The migration issues is messier than I'd like it to be on the this
> platform (CloudSQL being as fragile as MySQL in that regard, and the
> problem being compounded for me by the lack of tickets and my
> uncertainty as to the fix given that the pickles are in the problem db).
>
> I think perhaps that I too need to take an "old school and pessimistic"
> approach on this platform (and MySQL in general for that matter).
>
> BTW, in case anyone wonders why I'm using "fake_migrate_all" rather than
> a per-table approach, it's because the error I was responding to
> refereed to my (unmodified) auth_user table - I've simply not been able
> to get in to revert that since this happened.
>
>
> [1] https://code.google.com/p/googleappengine/issues/detail?id=8918
>
> --
>
> Regards,
>
> PhilK
>
>
> e: [email protected] <javascript:> - m: 07775 796 747
>
> 'work as if you lived in the early days of a better nation'
> - alasdair gray
>
--
---
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
