Zotonic
Zotonic
zotonic@conference.zotonic.com
Thursday, 26 April 2012< ^ >
arjan has set the subject to: Zotonic - the Erlang CMS
Room Configuration

GMT+2
[00:24:15] maas.maarten.zeeman leaves the room
[07:11:57] maas.maarten.zeeman joins the room
[07:35:09] maas.maarten.zeeman leaves the room
[08:01:31] maas.maarten.zeeman joins the room
[08:02:45] maas.maarten.zeeman leaves the room
[08:42:07] Marc Worrell leaves the room: Disconnected: connection closed
[08:49:18] arjan joins the room
[08:51:28] arjan leaves the room
[08:53:15] arjan joins the room
[09:24:45] maas.maarten.zeeman joins the room
[11:01:01] Marc Worrell joins the room
[11:09:54] <fl> Looking at the log, I think that z_install_data:install_modules fails because there is no match for pgsql:equery (because the model does not exist... looking into why it does not get created and why we didn't notice failures while creating it)
[11:18:22] <arjan> maybe the queries just take too long
[11:18:29] <arjan> I see a timeout error
[11:18:42] <arjan> what happens if you disable one site, start zotonic, stop zotonic, enable the site, start again
[11:18:48] <arjan> that probably works
[11:25:07] <fl> About the timeout: the timeout in the sites manager is 3600s; the timeout in the pgsql part is 50s; we might stumble upon the 50s limit but apart from that, I still wonder why z_install_data has been started while the model is not succesfully created
[11:29:01] <fl> ah, ok, I think my previous question is answered: z_install:install uses pgsql:with_transaction which does both the creation of the model and the installation of the data; if the last part fails, everything is probably rolled back (which is why I don't see the schema)
[11:32:50] <arjan> 50s seems like plenty of time to me to install everything
[11:33:35] <fl> @arjan: I did what you proposed i.e. disabled site1 and started zotonic again: the schema for site2 is created...
[11:34:04] <fl> yes, 50s is a lot of time... although I'm using a smallish system
[11:42:23] <arjan> the log contains timestamps
[11:42:31] <arjan> can you see if that 50s is reached?
[11:48:10] Marc Worrell leaves the room: Disconnected: connection closed
[11:58:53] <fl> For the site2 model:
[11:58:55] <fl> 15:47:12.759 [info] Installing database "site2"@"127.0.0.1":5432 "zotonic"
[11:59:04] <fl> 15:47:17.322 [info] DEBUG: z_install_data:35 {site2,"Install start."}
[11:59:13] <fl> 15:47:17.333 [info] DEBUG: z_install_data:57 "Inserting modules"
[11:59:26] <fl> 15:47:17.474 [error] CRASH REPORT
[11:59:39] <fl> which is the timeout
[11:59:48] <fl> 5s...
[12:00:39] <fl> pgsql.erl defines TIMEOUT as 50000 = 50s
[12:00:47] <fl> So we must be hitting another timeout
[12:12:28] <arjan> yes when the site supervisor is started
[12:13:48] <arjan> I know that marc has some thoughts on this
[12:14:00] <arjan> we stumbled into this issue a few times before
[12:14:11] <arjan> but did not get around to solve it
[12:14:27] <arjan> or you maas.maarten.zeeman?
[12:15:33] <maas.maarten.zeeman> ?
[12:15:41] <maas.maarten.zeeman> just catching up with reading.
[12:16:03] <maas.maarten.zeeman> Yes 5000 as timeout is all over the place.
[12:17:10] <maas.maarten.zeeman> My main dev machine is a atom netbook. That works fine with the 5s timeouts.
[12:18:52] <arjan> hmm
[12:24:03] <maas.maarten.zeeman> Does it timeout while inserting the module entries in postgres? Or somewhere else? Can't really see right now.
[12:27:10] <arjan> I think the problem is that z_sites_sup:start_link timeouts when it gets added as child to z_sites_manager
[12:34:28] <maas.maarten.zeeman> Hmm, the start_link of z_installer does the db initialization. After that it returns ignore. So that is done in the supervisor process.
[12:36:51] <maas.maarten.zeeman> Too bad it needs the depcache and z_trans
[12:53:29] <maas.maarten.zeeman> Funny, the installer is not really a supervised child, but it is made to act like one. Nice trick (or not?)
[12:56:28] hc joins the room
[12:56:48] <maas.maarten.zeeman> Thinking out loud here. In order to prevent the timeout we could also make a two stage startup process. In that case, the installer could attach the normal processes to the supervisor, after a successfull install. There is not much point anyway in starting the rest when the install fails.
[12:59:25] <maas.maarten.zeeman> z_sites_sup would be happy then even though the install takes a bit of time.
[13:04:48] <arjan> makes sense to me
[13:04:56] <arjan> z_sites_startup does the same thing
[13:05:15] <maas.maarten.zeeman> k didn't know that.
[13:14:22] <maas.maarten.zeeman> I have to go.
[13:15:41] maas.maarten.zeeman leaves the room
[14:28:56] maas.maarten.zeeman joins the room
[14:31:04] hc leaves the room
[16:50:31] maas.maarten.zeeman leaves the room
[18:24:33] maas.maarten.zeeman joins the room
[23:07:11] arjan leaves the room
Powered by ejabberd Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!