| 00:00.22 | *** join/#storm _mup_ (~mup@li37-90.members.linode.com) |
| 01:04.02 | *** join/#storm fbru02 (~fbru02@dhcp184-48-107-179.gos.lax.wayport.net) |
| 02:45.36 | *** join/#storm patricioe (~patricioe@108-68-106-29.lightspeed.sntcca.sbcglobal.net) |
| 04:11.53 | *** join/#storm fbru02 (~fbru02@dhcp184-48-107-157.gos.lax.wayport.net) |
| 04:52.01 | *** join/#storm fbru02 (~fbru02@dhcp184-48-107-157.gos.lax.wayport.net) |
| 06:47.30 | *** join/#storm stub (~stub@canonical/launchpad/stub) |
| 07:47.51 | *** join/#storm ant384 (~ghoul@unaffiliated/ant384) |
| 08:38.14 | *** join/#storm bigjools (~quassel@canonical/launchpad/bigjools) |
| 12:49.04 | *** join/#storm bigkevmcd (~kevin@87-194-156-112.bethere.co.uk) |
| 13:20.29 | *** join/#storm esteve (~quassel@91.126.88.6) |
| 13:46.06 | *** join/#storm awarner (~andrew@38.117.157.28) |
| 13:49.29 | *** join/#storm fbru02 (~fbru02@dhcp184-48-107-157.gos.lax.wayport.net) |
| 14:01.16 | *** join/#storm fbru02 (~fbru02@dhcp184-48-107-157.gos.lax.wayport.net) |
| 14:51.41 | *** join/#storm fbru02 (~fbru02@dhcp184-48-107-157.gos.lax.wayport.net) |
| 15:04.26 | *** join/#storm fbru02 (~fbru02@dhcp184-48-107-157.gos.lax.wayport.net) |
| 15:35.10 | *** join/#storm fbru02 (~fbru02@adsl-99-52-211-46.dsl.lsan03.sbcglobal.net) |
| 15:47.28 | *** join/#storm SuperShabam (~quassel@24-104-129.146.hfc.mediarain.com) |
| 15:58.12 | *** join/#storm _mup_ (~mup@li37-90.members.linode.com) |
| 16:27.40 | *** join/#storm fbru02 (~fbru02@vz144.citysearch.com) |
| 16:33.28 | *** join/#storm fbru02 (~fbru02@vz144.citysearch.com) |
| 16:46.26 | *** join/#storm patricioe (~patricioe@108-68-106-29.lightspeed.sntcca.sbcglobal.net) |
| 16:46.39 | *** join/#storm peregrine81 (~peregrine@108-231-126-61.lightspeed.milwwi.sbcglobal.net) |
| 16:47.35 | *** join/#storm nick-storm (6ce77e3d@gateway/web/freenode/ip.108.231.126.61) |
| 17:09.46 | peregrine81 | anyone have any experience with storm and heroku? |
| 17:11.17 | peregrine81 | I seem to be getting transaction locks and "Canceled on identification as a pivot, during write" from pg |
| 17:36.58 | therve | peregrine81, it's probably using postgres 9 |
| 17:37.08 | peregrine81 | definitely is |
| 17:37.11 | peregrine81 | whats the issue |
| 17:37.14 | therve | so you need to use storm trunk, and psycopg 2.4 |
| 17:37.24 | therve | it's because of the default isolation level |
| 17:38.51 | peregrine81 | alright looking into it, I am on the right psycopg 2.4 |
| 18:02.04 | peregrine81 | alright that fixed my PG errrors |
| 18:02.07 | peregrine81 | thanks therve |
| 18:02.16 | peregrine81 | could I bounce another question off you? |
| 18:06.34 | peregrine81 | anyway to make storm play nice across server intstances? |
| 18:12.14 | therve | peregrine81, what do you mean? |
| 18:12.31 | peregrine81 | across heroku web instances the caching is causing all sorts of issues |
| 18:13.10 | peregrine81 | the same api calls using the same db, with different web instances, return different results |
| 18:14.00 | therve | which framework do you use? do you commit/rollback the store at each request? |
| 18:14.36 | peregrine81 | we are committing |
| 18:14.42 | peregrine81 | do we need to rollback after each request as well? |
| 18:15.11 | therve | nope |
| 18:15.26 | therve | you need to rollback if it fails |
| 18:15.54 | therve | well you can deactivate the cache if it doesn't work for you |
| 18:16.05 | therve | but it should be validated against the db |
| 18:16.55 | peregrine81 | well we set cache=None, and got the same result. we set cache.set_size(0) and got the same result as well |
| 18:21.00 | therve | ah |
| 18:21.08 | therve | maybe the problem is not the cache then :) |
| 18:21.18 | peregrine81 | thats what I am thinking |
| 18:21.21 | peregrine81 | just cannot see where |
| 18:21.32 | peregrine81 | the code is pretty bsic. store.add(model), store.commit() |
| 18:21.52 | peregrine81 | the request creates a user on one instance, and trys to login in with that user on another instance as soon as the request returns |
| 18:22.10 | peregrine81 | it seems like the commit is happening asyc |
| 18:22.26 | therve | because your user is not already there in the second instance? |
| 18:22.42 | peregrine81 | correct |
| 18:23.00 | therve | ah, so it's indeed not a cache problem |
| 18:23.08 | peregrine81 | create(add/commit), get (model.find) get returns no resutls |
| 18:23.19 | peregrine81 | if on different instances |
| 18:23.27 | peregrine81 | if its the same or one instance its a-ok |
| 18:23.29 | therve | peregrine81, and a bit later, it succeeds on the other instance? |
| 18:23.44 | peregrine81 | usually very soon after creating |
| 18:23.55 | therve | right, but you have a race condition |
| 18:23.58 | peregrine81 | right |
| 18:25.22 | peregrine81 | seems like even waiting 5 seconds between requests |
| 18:25.26 | peregrine81 | still have the same issue |
| 18:33.24 | therve | yeah I don't know without seeing the code, really |
| 18:33.42 | therve | maybe something to do with the way heroku is setup |
| 20:02.05 | *** join/#storm m4v (~znc@unaffiliated/m4v) |
| 20:59.02 | *** join/#storm awarner_ (~andrew@38.117.157.28) |
| 21:01.59 | *** join/#storm awarner (~andrew@38.117.157.28) |
| 21:09.57 | *** join/#storm awarner_ (~andrew@38.117.157.28) |
| 21:55.33 | james_w | hi |
| 21:55.50 | james_w | so I'm using storm with sqlite as a step to porting to postgres |
| 21:56.40 | james_w | but moving to storm from raw sqlite3 api use has led to a large increase in the number of locked database situtations |
| 21:58.02 | james_w | reading sqlite.py it sounds like the extra work storm does to get back to SERIALIZABLE could be the cause of this, because it will start transactions at SELECT where they wouldn't before |
| 21:58.10 | james_w | does that sound reasonable? |
| 21:58.49 | james_w | if so, is there a way (hacking the source is fine) to back that out to have storm not do that and to see what effect it has on the locking? |
| 21:59.54 | james_w | it's not obvious to me at first look whether I want to be dropping the commit etc. methods from SQLiteConnection, or making them no-ops, or something else |
| 22:10.11 | james_w | tries the obvious thing |
| 22:25.35 | jkakar | james_w: Heya. :) |
| 22:25.46 | james_w | hey jkakar, how are you? |
| 22:25.56 | jkakar | james_w: Doing pretty awesomely thanks. How about you? |
| 22:26.01 | james_w | good thanks |
| 22:26.04 | james_w | except that I hate sqlite |
| 22:26.39 | jkakar | james_w: Yeah, I know. I wonder if the basic issue you're having is that SQLite is not a multiuser database. |
| 22:26.42 | jkakar | ? |
| 22:26.47 | james_w | oh for sure |
| 22:27.08 | james_w | but switching to storm rather than sqlite3 didn't change that fact |
| 22:27.18 | james_w | the whole point of this is to move off of sqlite |
| 22:27.26 | james_w | but we're trying to do it incrementally |
| 22:27.27 | jkakar | So a question is, where do you want to start transactions? Or do you never want to start them at all (at least in testing/development)? |
| 22:27.33 | jkakar | Yeah, sounds like a good plan. |
| 22:28.02 | james_w | I don't know :-) |
| 22:28.06 | jkakar | Although, I wonder if you'll spend more time futzing with SQLite than by just moving directly to PostgreSQL...? I guess you have deployment issues and things to consider. |
| 22:28.30 | james_w | SERIALIZABLE is probably right |
| 22:28.50 | james_w | yeah, I'm starting to think that eating the downtime and migration and lack of testing will be easier than this |
| 22:29.40 | jkakar | james_w: Have you seen storm/databases/sqlite.py:146 and then also storm/databases/sqlite.py:195? |
| 22:29.40 | james_w | I'm just confused as to what storm is doing to make the difference |
| 22:29.54 | jkakar | james_w: The story at the end of that module might be enlightening. :) |
| 22:30.13 | james_w | yeah, that's what I read to lead to me this avenue of investigation |
| 22:30.31 | james_w | but I've just deleted all of that stuff and I'm still seeing the locking problems |
| 22:30.53 | jkakar | james_w: Okay. I think you're probably up shit creek trying to fix all this stuff. But you may have a much bigger paddle than I do. :) |
| 22:31.01 | james_w | heh |
| 22:31.53 | jkakar | james_w: You said "lack of testing"... do you have a dataset that's so big you can't spin up a test environment and make sure everything works with PostgreSQL? |
| 22:32.09 | james_w | jkakar, not really |
| 22:32.21 | jkakar | Sorry, am mostly asking dumb questions to see if there's some advice I can give that will help, but I'm sure you've already thought through all the obvious stuff. |
| 22:32.39 | james_w | more that we'll be pivoting from sqlite + sqlite3 to postgres + storm in one go in production |
| 22:32.56 | jkakar | Ah, okay. Well... unit tests are great. :) |
| 22:32.56 | james_w | so we can minimise it with testing elsewhere, but I'd still prefer to vary one thing at a time |
| 22:33.03 | jkakar | Yeah, understandable. |
| 22:33.06 | james_w | um, yeah... |
| 22:33.08 | jkakar | Haha |
| 22:33.09 | james_w | shuffles |
| 22:33.19 | james_w | let |
| 22:33.27 | james_w | 's call this project "legacy" |
| 22:33.30 | jkakar | :) |
| 22:34.01 | james_w | but now it is time for me to cook dinner and leave this for tomorrow |
| 22:34.05 | james_w | thanks for the advice |
| 22:36.22 | jkakar | james_w: Anytime. |
| 22:36.25 | jkakar | Talk is cheap. :) |
| 23:08.38 | *** join/#storm bigjools (~quassel@60-241-216-21.static.tpgi.com.au) |
| 23:08.45 | *** join/#storm bigjools (~quassel@canonical/launchpad/bigjools) |