Timestamps are in GMT/BST.
[0:36] * cbeer (cbeer@2600:3c03::f03c:91ff:fedf:a498) has joined #duraspace
[3:20] * joaomelo__ (~joaomelo@bl23-41-52.dsl.telepac.pt) Quit (Remote host closed the connection)
[6:47] -leguin.freenode.net- *** Looking up your hostname...
[6:47] -leguin.freenode.net- *** Checking Ident
[6:47] -leguin.freenode.net- *** Found your hostname
[6:47] -leguin.freenode.net- *** No Ident response
[6:47] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:47] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:47] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[8:03] * Asger (~abr@eduroam-nat.statsbiblioteket.dk) has joined #duraspace
[9:27] * Asger (~abr@eduroam-nat.statsbiblioteket.dk) Quit (Ping timeout: 246 seconds)
[9:29] * Asger (~abr@eduroam-nat.statsbiblioteket.dk) has joined #duraspace
[9:35] * Asger (~abr@eduroam-nat.statsbiblioteket.dk) Quit (Ping timeout: 255 seconds)
[9:35] * Asger (~abr@eduroam-nat.statsbiblioteket.dk) has joined #duraspace
[9:47] * Asger (~abr@eduroam-nat.statsbiblioteket.dk) Quit (Ping timeout: 240 seconds)
[9:48] * Asger (~abr@eduroam-nat.statsbiblioteket.dk) has joined #duraspace
[10:02] * Asger (~abr@eduroam-nat.statsbiblioteket.dk) Quit (Ping timeout: 252 seconds)
[10:17] * Asger (~abr@nat.statsbiblioteket.dk) has joined #duraspace
[13:38] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[13:44] * fasseg (~fas@HSI-KBW-078-043-007-220.hsi4.kabel-badenwuerttemberg.de) has joined #duraspace
[13:44] <fasseg> hola...
[13:44] <fasseg> do i remember corectly that we meet an hour later than before?
[13:47] * tdonohue (~tdonohue@c-50-129-94-92.hsd1.il.comcast.net) has joined #duraspace
[13:54] * eddies (~eddies@bb116-15-102-91.singnet.com.sg) has joined #duraspace
[13:54] * eddies (~eddies@bb116-15-102-91.singnet.com.sg) Quit (Changing host)
[13:54] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[13:54] * Dan_Davis (4a4f9413@gateway/web/freenode/ip.74.79.148.19) has joined #duraspace
[13:57] * EdF (1809d1a2@gateway/web/freenode/ip.24.9.209.162) has joined #duraspace
[14:05] * ajs6f (~Adium@d-137-155-210.bootp.Virginia.EDU) has joined #duraspace
[14:11] <fasseg> dropped :/
[14:14] <ajs6f> Also dropped— Dan, rescue me!
[14:20] <Dan_Davis> I can't volunteer until I know what happens after the first of the year, but now I am coding full time I am interested in working on the next release. Messaging update would be a good first task.
[14:26] <eddies> https://github.com/fcrepo/fcrepo/pull/9
[14:26] <kompewter> [ Fcrepo 1024 by damkjaer · Pull Request #9 · fcrepo/fcrepo · GitHub ] - https://github.com/fcrepo/fcrepo/pull/9
[14:27] <eddies> http://fedora-commons.1317035.n2.nabble.com/fcrepo-dev-Synchronization-on-getIngestWriter-in-DefaultDOManager-tc6972143.html
[14:27] <kompewter> [ Fedora Commons Developers - [fcrepo-dev] Synchronization on getIngestWriter in DefaultDOManager | List View ] - http://fedora-commons.1317035.n2.nabble.com/fcrepo-dev-Synchronization-on-getIngestWriter-in-DefaultDOManager-tc6972143.html
[14:28] <eddies> http://fedora-commons.1317035.n2.nabble.com/fcrepo-dev-RE-Ingest-performances-td7578534.html
[14:28] <kompewter> [ Fedora Commons Developers - [fcrepo-dev] RE : Ingest performances ] - http://fedora-commons.1317035.n2.nabble.com/fcrepo-dev-RE-Ingest-performances-td7578534.html
[14:30] <eddies> In org.fcrepo.server.storage.DefaultDOManager, the getIngestWriter method should not be synchronized as it seems there is only a single instance of that class for the server. The internal objects of this class seem to be correctly synchronized (pid generation) of new objects are recreated on each call (inside Translator, a new DODeserializer is created and the same happens inside the Validator).
[14:30] <eddies> I've tested with FOXML ingestion and now almost all the CPUs are used. I've not been deeper to check that every inserted object is not corrupted, but after a quick look, it seems OK. I guess the same kind of patch could also apply on object deletion.
[14:32] <ajs6f> Yes, I think it would. The problem is that the PID cannot be determined
[14:32] <ajs6f> until just before the call to objectExists(). And moving the
[14:32] <ajs6f> pidLock.getWriteLock() up here would essentially do the same as You
[14:32] <ajs6f> suggest.
[14:33] <eddies> I just had a quick look at the code. As far as I can see (and I may not
[14:33] <eddies> be right) one problem may be the following:
[14:33] <eddies> Assume both threads with same PID are inside the method getIngestWriter
[14:33] <eddies> and has passed the method-call objectExists(...). At this point neither
[14:33] <eddies> of the objects exists assuming none of the threads has yet reached
[14:33] <eddies> registerObject(...).
[14:33] <eddies> If one of the threads then get the writeLock, does what it needs to do
[14:33] <eddies> and releases the writeLock before the second thread reaches writeLock,
[14:33] <eddies> then the second thread will reach registerObject(...). As far as I can
[14:33] <eddies> tell, inside registerObject(...) an SQLException will be thrown since
[14:33] <eddies> the row already exists in the database, and the method
[14:33] <eddies> unregisterObject(...) will be called actually unregistering a legally
[14:33] <eddies> created object.
[15:08] <eddies> https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+FCREPO+AND+status+%3D+Received+ORDER+BY+created+DESC%2C+updated+DESC%2C+priority+DESC
[15:08] <kompewter> [ Issue Navigator - DuraSpace JIRA ] - https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+FCREPO+AND+status+%3D+Received+ORDER+BY+created+DESC%2C+updated+DESC%2C+priority+DESC
[15:09] <eddies> https://jira.duraspace.org/browse/FCREPO-1167
[15:09] <kompewter> [ [#FCREPO-1167] Inclusion of "datatype" in addRelationship request causing fatal Tomcat error - DuraSpace JIRA ] - https://jira.duraspace.org/browse/FCREPO-1167
[15:09] <kompewter> [ https://jira.duraspace.org/browse/FCREPO-1167 ] - [#FCREPO-1167] Inclusion of "datatype" in addRelationship request causing fatal Tomcat error - DuraSpace JIRA
[15:09] <ajs6f> https://jira.duraspace.org/browse/FCREPO-1164
[15:09] <kompewter> [ [#FCREPO-1164] Solrizer error when the solr_doc contains a value that is nil, that will be updated - DuraSpace JIRA ] - https://jira.duraspace.org/browse/FCREPO-1164
[15:09] <kompewter> [ https://jira.duraspace.org/browse/FCREPO-1164 ] - [#FCREPO-1164] Solrizer error when the solr_doc contains a value that is nil, that will be updated - DuraSpace JIRA
[15:15] * Asger (~abr@nat.statsbiblioteket.dk) Quit (Remote host closed the connection)
[15:24] <cbeer> eddies: i'm terrible at reading calendar invites. that last one from you is a reminder of the call in 5 minutes, right?
[15:24] <eddies> aye
[15:26] * barmintor (~ba2213@dyn-128-59-158-133.dyn.columbia.edu) has joined #duraspace
[15:29] <barmintor> trying to dial in; getting a busy signal
[15:31] <eddies> via Skype or the phone #?
[15:31] <barmintor> via the phone; just got on
[15:36] <eddies> https://wiki.duraspace.org/display/REPONEXT/2012-11-15+ff-tech+Meeting
[15:36] <kompewter> [ Log In - DuraSpace Wiki ] - https://wiki.duraspace.org/display/REPONEXT/2012-11-15+ff-tech+Meeting
[15:57] * escowles (48c461fd@gateway/web/freenode/ip.72.196.97.253) has joined #duraspace
[15:57] * BigD (~dfleming@128.54.47.19) has joined #duraspace
[15:57] <BigD> hiya - this is declan
[16:00] <barmintor> BigD: Do you have the mapping you use for MODS to RDF online? I've been starting to work with the MIT-SIMILE stylesheets, but am interested in alternatives.
[16:03] <Dan_Davis> I think of this the other way around. authoritative in the original and RDF for finding.
[16:03] <barmintor> eddies: this is the reasoning behind the metadata service story https://wiki.duraspace.org/display/REPONEXT/Objects+can+be+associated+with+a+descriptive+metadata+service
[16:03] <kompewter> [ Log In - DuraSpace Wiki ] - https://wiki.duraspace.org/display/REPONEXT/Objects+can+be+associated+with+a+descriptive+metadata+service
[16:03] <Dan_Davis> Unless RDF is the original.
[16:05] <Dan_Davis> Great! there is the notion of rebuilding.
[16:05] <barmintor> Dan_Davis: I think a weakness of that approach, for repos that are stil changing, is the implication that your descriptions are files/serializations rather than statements/characteristics.
[16:08] <Dan_Davis> Don't want to interrupt listening, but there is a notion of a layered information model that it would be nice to discuss.
[16:39] <BigD> barmintor: http://libraries.ucsd.edu/blogs/dams/new-version-of-dams-data-model/ is the latest data model
[16:39] <kompewter> [ UCSD Library Digital Asset Management System » New Version of DAMS Data Model - The Library ] - http://libraries.ucsd.edu/blogs/dams/new-version-of-dams-data-model/
[16:39] <barmintor> thanks BigD
[16:40] <BigD> barmintor: is that what you meant?
[16:40] <BigD> barmintor: there's a lot there, escowles can help navigate
[16:40] * barmintor is looking
[16:42] * fasseg (~fas@HSI-KBW-078-043-007-220.hsi4.kabel-badenwuerttemberg.de) Quit (Remote host closed the connection)
[16:44] <BigD> where's the agenda page for the call?
[16:45] <cbeer> BigD: not sure you have access, but: https://wiki.duraspace.org/display/REPONEXT/2012-11-15+ff-tech+Meeting
[16:45] <kompewter> [ Log In - DuraSpace Wiki ] - https://wiki.duraspace.org/display/REPONEXT/2012-11-15+ff-tech+Meeting
[16:46] <BigD> hmm, be willing to scrape it and mail it? dfleming@ucsd.edu
[16:46] <BigD> i don't even know who i was talking to
[16:47] <BigD> cbeer: did it all sound ok? i only made up 30% of it ;)
[16:48] <cbeer> BigD: sent. we're regretting not appointing a note taker
[16:53] <eddies> just got dropped
[16:54] <eddies> and i can't reconnect
[16:54] <eddies> i will take that as a divine suggestion that the call has exceeded its time
[16:54] <ajs6f> We're heading out, too.
[16:54] <ajs6f> Bye, Eddie.
[16:55] * ajs6f (~Adium@d-137-155-210.bootp.Virginia.EDU) Quit (Quit: Leaving.)
[16:55] <eddies> i really hate confluence sometimes
[16:56] <BigD> cbeer: gracias!
[16:56] <BigD> twas fun rambling at you all!
[16:56] <eddies> i'm not smart enough to figure out how to add ppl to a particular section of a space :-P
[17:01] <BigD> barmintor: did you talk about databank after I got off? i'd love to hear about it!
[17:02] <barmintor> BigD: only briefly. I'm going to start some online discussion, and we'll probably discuss next week on the call
[17:05] <BigD> cool
[17:05] <BigD> got a link i can just look at?
[17:05] <BigD> i'm databank ignorant
[17:10] <Dan_Davis> eddie, so long as you provide permission then I can get the mechanics done. No one can know every product.
[17:12] <Dan_Davis> ben, thanks. It would be nice to participate in the discussion.
[17:13] * escowles (48c461fd@gateway/web/freenode/ip.72.196.97.253) Quit (Quit: Page closed)
[17:19] <barmintor> BigD, Dan-Davis: just a stub https://wiki.duraspace.org/display/REPONEXT/Oxford+Databank
[17:19] <kompewter> [ Log In - DuraSpace Wiki ] - https://wiki.duraspace.org/display/REPONEXT/Oxford+Databank
[17:22] * linux4u (~james@employed.library.emory.edu) Quit (Read error: Connection reset by peer)
[17:52] * linux4u (~james@employed.library.emory.edu) has joined #duraspace
[17:53] * eddies (~eddies@unaffiliated/eddies) Quit (Quit: Leaving.)
[17:53] * BigD (~dfleming@128.54.47.19) Quit (Quit: Leaving.)
[18:07] * BigD (~dfleming@128.54.47.19) has joined #duraspace
[18:14] * BigD (~dfleming@128.54.47.19) Quit (Quit: Leaving.)
[18:14] * ForteTuba (80fdd80c@gateway/web/freenode/ip.128.253.216.12) has joined #duraspace
[18:15] * BigD (~dfleming@128.54.47.19) has joined #duraspace
[18:17] * Dan_Davis (4a4f9413@gateway/web/freenode/ip.74.79.148.19) Quit (Quit: Page closed)
[18:18] <BigD> barmintor: i've got a duraspace wiki login, but i'm not worthy to see that link ;)
[18:19] <cbeer> BigD: they're working on it, I gather.
[18:20] <cbeer> apparently the way confluence permissions combine is causing them trouble
[18:21] <cbeer> in the meantime:
[18:21] <cbeer> https://github.com/dataflow/RDFDatabank Source code
[18:21] <cbeer> https://damssupport.ouls.ox.ac.uk/trac/databank/wiki/metadataSchema RDF metadata conventions
[18:21] <cbeer> http://www.dataflow.ox.ac.uk/index.php/as-a-developer Developer documentation
[18:21] <kompewter> [ dataflow/RDFDatabank · GitHub ] - https://github.com/dataflow/RDFDatabank
[18:21] <kompewter> [ Developer Resources ] - http://www.dataflow.ox.ac.uk/index.php/as-a-developer
[18:21] <kompewter> [ metadataSchema – Databank service ] - https://damssupport.ouls.ox.ac.uk/trac/databank/wiki/metadataSchema
[18:58] * BigD (~dfleming@128.54.47.19) Quit (Quit: Leaving.)
[19:02] * BigD (~dfleming@128.54.47.19) has joined #duraspace
[19:06] * linux4u (~james@employed.library.emory.edu) Quit (Remote host closed the connection)
[19:28] * ForteTuba (80fdd80c@gateway/web/freenode/ip.128.253.216.12) Quit (Quit: Page closed)
[19:48] * EdF (1809d1a2@gateway/web/freenode/ip.24.9.209.162) Quit (Ping timeout: 245 seconds)
[19:49] * BigD (~dfleming@128.54.47.19) Quit (Quit: Leaving.)
[19:55] * BigD (~dfleming@128.54.47.19) has joined #duraspace
[19:58] * linux4u (~james@employed.library.emory.edu) has joined #duraspace
[22:02] * mhwood (mwood@mhw.ulib.iupui.edu) Quit (Remote host closed the connection)
[22:16] * BigD (~dfleming@128.54.47.19) has left #duraspace
[22:57] * tdonohue (~tdonohue@c-50-129-94-92.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.