Timestamps are in GMT/BST.
[0:10] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[0:10] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Client Quit)
[2:13] * eddies (~eddies@unaffiliated/eddies) Quit (Quit: Leaving.)
[2:45] * eddies (~eddies@bb219-75-82-235.singnet.com.sg) has joined #duraspace
[2:45] * eddies (~eddies@bb219-75-82-235.singnet.com.sg) Quit (Changing host)
[2:45] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[5:05] * scottatm (~scottatm@adhcp218.evans.tamu.edu) Quit (Ping timeout: 252 seconds)
[6:35] -gibson.freenode.net- *** Looking up your hostname...
[6:35] -gibson.freenode.net- *** Checking Ident
[6:35] -gibson.freenode.net- *** Found your hostname
[6:35] -gibson.freenode.net- *** No Ident response
[6:36] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:36] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:36] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[9:48] * eddies (~eddies@unaffiliated/eddies) Quit (Ping timeout: 272 seconds)
[9:51] * eddies (~eddies@bb219-75-82-235.singnet.com.sg) has joined #duraspace
[9:51] * eddies (~eddies@bb219-75-82-235.singnet.com.sg) Quit (Changing host)
[9:51] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[10:07] * eddies (~eddies@unaffiliated/eddies) Quit (Quit: Leaving.)
[12:10] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[12:50] * elschlomo (~ruckus@HSI-KBW-046-005-164-187.hsi8.kabel-badenwuerttemberg.de) has joined #duraspace
[12:53] * ed_ (1809d1a2@gateway/web/freenode/ip.24.9.209.162) has joined #duraspace
[12:55] * Dan_Davis (4a4f9413@gateway/web/freenode/ip.74.79.148.19) has joined #duraspace
[12:57] * eddies (~eddies@cm18.epsilon183.maxonline.com.sg) has joined #duraspace
[12:58] * eddies (~eddies@cm18.epsilon183.maxonline.com.sg) Quit (Changing host)
[12:58] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[12:59] * cwilper (ad55a88f@gateway/web/freenode/ip.173.85.168.143) has joined #duraspace
[13:07] * ajs6f (89361cde@gateway/web/freenode/ip.137.54.28.222) has joined #duraspace
[13:08] <ajs6f> Chris is pleased about progress on submitted issues.
[13:14] <ajs6f> Frank is now assigned FCREPO-1027 and FCREPO-1023.
[13:15] <ajs6f> Chris has word from Thorny that folks from CDC are interested in helping with some development work in order to advance their own projects.
[13:15] <ajs6f> As well as NEH.
[13:16] <ajs6f> Dan skewers the medical establishment.
[13:17] <ajs6f> These projects concern publications after publisher embargoes are lifting.
[13:17] <ajs6f> Also, these groups are running Fedora in the cloud.
[13:18] <ajs6f> They're operating under a federal mandate to push efforts to the cloud.
[13:19] <ajs6f> Chris: Let's not waste time.
[13:19] <ajs6f> Adam: Anything for 3.6 that warrants discussion?
[13:19] <ajs6f> Dan: What about replacing JRDF?
[13:19] <ajs6f> https://jira.duraspace.org/browse/FCREPO-950
[13:19] <kompewter> [ [#FCREPO-950] Evaluate replacements for JRDF - DuraSpace JIRA ] - https://jira.duraspace.org/browse/FCREPO-950
[13:20] * barmintor (~ba2213@dyn-butler-158-112.dyn.columbia.edu) has joined #duraspace
[13:21] <ajs6f> http://incubator.apache.org/stanbol/
[13:21] <kompewter> [ Apache Stanbol - Welcome to Apache Stanbol (incubating) ] - http://incubator.apache.org/stanbol/
[13:22] <ajs6f> Adam: Stanbol uses Clerezza for storing structural RDF.
[13:23] <ajs6f> Chris: We do need to parse RDF in the core.
[13:23] <ajs6f> http://incubator.apache.org/clerezza/
[13:23] <kompewter> [ Welcome to Apache Clerezza ] - http://incubator.apache.org/clerezza/
[13:23] <ajs6f> http://incubator.apache.org/jena/
[13:23] <kompewter> [ Apache Jena - Welcome to Jena ] - http://incubator.apache.org/jena/
[13:24] <ajs6f> Adam, Chris: Jena is quite large, but may be modularized.
[13:25] <ajs6f> Chris: Seseme RIO is fairly light.
[13:25] <ajs6f> Seseme -> Sesame
[13:27] <ajs6f> Adam: What is the relationship of the RDF graph to the objects? This informs how much we want to invest in RDF infrastructure.
[13:27] * tdonohue (~tdonohue@c-67-177-108-221.hsd1.il.comcast.net) has joined #duraspace
[13:28] <ajs6f> Dan: The graph is central, but the implementation is different question.
[13:28] <barmintor> +1 in-memory linked lists
[13:28] <ajs6f> Adam: The graph is a graph, but that doesn't imply that it has to be in a triplestore.
[13:28] <ajs6f> Chris: We _will_ have to parse and deal with RDF.
[13:29] <ajs6f> Dan: Looking at SemWeb architecture (and Linked Data) they see RDF as sending messages. Not so much about triplestores.
[13:30] <ajs6f> Dan: Fedora fits well with that. The triplestore is not necessarily part of the core.
[13:30] <ajs6f> Dan: What does Fedora (in a large sense) need to ask at different scales?
[13:31] <ajs6f> Dan: Low-level questions: about graphs about _how_ the stuff is stored.
[13:31] <ajs6f> Dan: Not content-driven questions.
[13:32] <ajs6f> Dan: This about what Fedora _requires_, not what a given site might want to do.
[13:33] <ajs6f> Frank: Don't we need to abstract out these questions?
[13:33] <ajs6f> Everyone: Yes, and some of it has already happened (Trippi) and some needs to (High Level Store).
[13:35] <ajs6f> Adam: This all argues for changes in the core patterns of workflow.
[13:35] <ajs6f> Dan: High level storage implies those kins of changes.
[13:36] <ajs6f> Ben: Using modern Web service engines supports asynch patterns.
[13:37] <ajs6f> Ben: Which might be a necessary but not sufficient step.
[13:37] <ajs6f> Frank: We may soon have asynch HTTP which would open up the Web APIs.
[13:38] <ajs6f> Chris: This is lower level-- system-to-system interaction.
[13:38] <ajs6f> Adam: This is about the boundaries between arch styles.
[13:39] <ajs6f> Dan: Hopes that Fedora will be a mediator able to support multiple styles of interaction.
[13:41] <ajs6f> Adam: We needed to use other machinery for that mediating purpose precisely because Fedora doesn't do that so well right now.
[13:42] <ajs6f> Dan: Then there's moving from operation-centrism to data-centrism.
[13:44] <Dan_Davis> Ben: Rejiggering FESL configuration files to Spring configuration files
[13:45] <Dan_Davis> Ben: Needs feedback, want eyeballs on code.
[13:45] <eddies> Ben: calling for feedback on FCREPO-795 branch
[13:45] <barmintor> https://github.com/fcrepo/fcrepo/tree/fcrepo-795/fcrepo-installer/src/main/resources/config/spring/fesl
[13:45] <kompewter> [ fcrepo/fcrepo-installer/src/main/resources/config/spring/fesl at fcrepo-795 · fcrepo/fcrepo · GitHub ] - https://github.com/fcrepo/fcrepo/tree/fcrepo-795/fcrepo-installer/src/main/resources/config/spring/fesl
[13:46] <Dan_Davis> Ben: Stored under the installer.
[13:46] <barmintor> http://static.springsource.org/spring/docs/2.5.x/reference/extensible-xml.html
[13:46] <kompewter> [ Appendix B. Extensible XML authoring ] - http://static.springsource.org/spring/docs/2.5.x/reference/extensible-xml.html
[13:46] * ajs6f (89361cde@gateway/web/freenode/ip.137.54.28.222) Quit (Ping timeout: 245 seconds)
[13:47] <Dan_Davis> Chris: Is seeing how it all hangs together.
[13:48] <Dan_Davis> Chris: As opposed to all hanging separately.
[13:50] <Dan_Davis> Chris: Normally user configs go into properties files vs xml (unless there is a UI).
[13:51] <Dan_Davis> Ben: This is a good chance to clean up FESL configuration to make it easier to understand.
[13:55] <Dan_Davis> Eddie: This impl is much improved. Maybe needs related configurations be not widely separated so its less likely that you have unexpected consequences from a change.
[13:59] <Dan_Davis> Chris: Annotation may need one to parse through Java but having a everything in single XML file.
[14:02] <Dan_Davis> Ben: Maybe move annotations to core PEP code for basic CRUD.
[14:02] <Dan_Davis> Dan: I lost connection so someone needs to take notes.
[14:05] <barmintor> Ben: ActiveMQ has a dependency on an older version of slf4j until 3.6 comes out of snapshot, then we can move up to cxf 2.5 or 2.6
[14:07] <cwilper> End of Fedora committer call. Start of Fedora Office Hours: https://wiki.duraspace.org/display/~cwilper/Fedora+Office+Hours
[14:07] <kompewter> [ Fedora Office Hours - Chris Wilper - DuraSpace Wiki ] - https://wiki.duraspace.org/display/~cwilper/Fedora+Office+Hours
[14:09] <barmintor> cwilper: one of the things I've been trying to do "in the background" is make the test suite more efficient where possible
[14:10] <barmintor> since the length of builds is a disincentive to hacking :)
[14:10] <cwilper> My memory's fuzzy on that...I think we chatted about it before, but forgot what approaches you were considering.
[14:11] <barmintor> most of it is just re-using factories and clients
[14:11] <cwilper> Yes, long builds really suck.
[14:12] <barmintor> Anecdotally, the build really hangs on the loading of METS and ATOM demo objects in the fcrepo-server suite
[14:12] <barmintor> it takes as long as running the integration tests for one config
[14:13] <barmintor> I haven't yet tried turning off pretty-printing for the translations, but there's certainly a lot of IO there
[14:13] <cwilper> Oh yeah. Demo object conversions were taking a long time too. Not sure if they were done multiple times or not.
[14:14] <barmintor> Anyway, here's what I'm working on this morning:
[14:15] <barmintor> when I run the test suite against fcrepo-795, there's NPEs reported by cxf in the logs, but they don't appear to impact the tests. They're logged as warnings.
[14:16] <barmintor> cxf logs them as originating in the WS services
[14:16] <cwilper> Hrm. Stack trace?
[14:17] <barmintor> useless one- all in the cxf internal stack. trying to figure out how to get it to log the cause's stacktrace
[14:17] <barmintor> or maybe I just need to look up the cxf source. might be a client-side thing
[14:18] <barmintor> Can tell you more after I run the tests on this machine, my logs are at home
[14:19] * barmintor will be so glad to finish this issue
[14:20] <cwilper> ok. in another project i recall fussing a bit with telling java.util.logging output to go to cxf. Here's a doc on what cxf folks recommend for getting that going (see using SLF4J): http://cxf.apache.org/docs/debugging-and-logging.html
[14:20] <kompewter> [ Apache CXF -- Debugging and Logging ] - http://cxf.apache.org/docs/debugging-and-logging.html
[14:21] <cwilper> I have no idea whether Jiri followed that or not. Myself, I ended up using the SLF4J-recommended way in my other project. https://github.com/cwilper/fcrepo-cloudsync/blob/master/fcrepo-cloudsync-service/src/main/java/com/github/cwilper/fcrepo/cloudsync/service/CloudSyncContextListener.java#L74
[14:21] <kompewter> [ fcrepo-cloudsync/fcrepo-cloudsync-service/src/main/java/com/github/cwilper/fcrepo/cloudsync/service/CloudSyncContextListener.java at master · cwilper/fcrepo-cloudsync · GitHub ] - https://github.com/cwilper/fcrepo-cloudsync/blob/master/fcrepo-cloudsync-service/src/main/java/com/github/cwilper/fcrepo/cloudsync/service/CloudSyncContextListener.java#L74
[15:07] * ed_ (1809d1a2@gateway/web/freenode/ip.24.9.209.162) Quit (Ping timeout: 245 seconds)
[15:20] <barmintor> cwilper: This is the stacktrace I'm trying to figure out from the logs: https://gist.github.com/2586427
[15:20] <kompewter> [ NPE Warning in CXF WS interface — Gist ] - https://gist.github.com/2586427
[15:26] <cwilper> Well, here's where the NPE is thrown: http://grepcode.com/file/repo1.maven.org/maven2/org.apache.cxf/cxf-rt-frontend-jaxws/2.4.0/org/apache/cxf/jaxws/handler/soap/SOAPHandlerInterceptor.java#263
[15:26] <kompewter> [ GrepCode: org.apache.cxf.jaxws.handler.soap.SOAPHandlerInterceptor (.java) - Class - Source Code View ] - http://grepcode.com/file/repo1.maven.org/maven2/org.apache.cxf/cxf-rt-frontend-jaxws/2.4.0/org/apache/cxf/jaxws/handler/soap/SOAPHandlerInterceptor.java#263
[15:26] * eddies (~eddies@unaffiliated/eddies) Quit (Quit: Leaving.)
[15:29] <cwilper> Looks like SoapMessage.getMessage is returning null? Dunno why. Perhaps PEP.doFilter or AuthFilterJAAS.doFilter isn't setting something..
[15:32] <barmintor> or there's a NPE inside SOAPMessage.getMessage
[15:34] <barmintor> it happens on apia and apim, so I don't think it's AuthFilterJAAS, and it happens on configs besides C, so I don't think it's PEP.
[15:34] <barmintor> Unless AuthFilterJAAS filters both api's
[15:38] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has joined #duraspace
[15:44] * elschlomo (~ruckus@HSI-KBW-046-005-164-187.hsi8.kabel-badenwuerttemberg.de) Quit (Remote host closed the connection)
[16:04] * dgijonathan (~jgreen@142.176.125.37) has joined #duraspace
[16:10] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has left #duraspace
[16:15] <barmintor> ok, I have a notion
[16:15] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[16:16] <dgijonathan> I'm looking to do some fedora benchmarking on some various different system configurations.
[16:17] <dgijonathan> has anyone been doing this with 3.x?
[16:17] <dgijonathan> anyone have some scripts as a starting place?
[16:18] <barmintor> since cxf doesn't automatically follow ssl redirects, I changed Fedora client to use https://github.com/fcrepo/fcrepo/blob/fcrepo-795/fcrepo-client/fcrepo-client-admin/src/main/java/org/fcrepo/client/FedoraClient.java#L781 to figure out what the address for the endpoint should be. I think that's the source of the NPE warnings.
[16:18] <kompewter> [ fcrepo/fcrepo-client/fcrepo-client-admin/src/main/java/org/fcrepo/client/FedoraClient.java at fcrepo-795 · fcrepo/fcrepo · GitHub ] - https://github.com/fcrepo/fcrepo/blob/fcrepo-795/fcrepo-client/fcrepo-client-admin/src/main/java/org/fcrepo/client/FedoraClient.java#L781
[16:19] <barmintor> dgijonathan: some people have been doing benchmarking as part of the 3.6 development. Dan_Davis might know more.
[16:21] <barmintor> I need to go grab a sandwich, then I'll try to address the NPE thing
[16:27] <cwilper> dgijonathan: some tests have been done for older releases...and that code might be reusable. Also, the intent is to do it with JMeter for the 3.6 release. We have not defined each necessary kind of test yet, but I think there's a general notion that we want to exercise concurrent writes as well as reads.
[16:28] <cwilper> We have also talked about using an EC2 "Large" instance as a baseline. But importantly, having the tests be something other folks can take to their own environments.
[16:28] <cwilper> I know Eddie put together a start jmeter script...let me see if I can dig up a link.
[16:30] <cwilper> jgijonathan: have a look at https://github.com/fcrepo/fcrepo/blob/master/fcrepo-integrationtest/fcrepo-integrationtest-core/src/main/resources/jmeter/Fedora%20Test%20Plan.jmx
[16:30] <kompewter> [ fcrepo/fcrepo-integrationtest/fcrepo-integrationtest-core/src/main/resources/jmeter/Fedora Test Plan.jmx at master · fcrepo/fcrepo · GitHub ] - https://github.com/fcrepo/fcrepo/blob/master/fcrepo-integrationtest/fcrepo-integrationtest-core/src/main/resources/jmeter/Fedora%20Test%20Plan.jmx
[16:30] <dgijonathan> thats great, appreciate the link
[16:31] <dgijonathan> another thought along the same lines
[16:31] <cwilper> Yep. It's a starting point...just seeing how we can use jmeter to talk to Fedora. We did a hands-on exercise on a committer call a while back. Both SOAP and REST should be possible through Jmeter.
[16:32] <dgijonathan> what have peoples experience with fedora been in ec2? i assume the slower then local storage has some negative effect.
[16:32] <dgijonathan> or maybe not
[16:33] <cwilper> My own experience has been pretty good, but I really haven't exercised it to the level where storage performance would be a significant concern.
[16:34] <cwilper> I put together an AMI a while back that did a separate EBS volume for Fedora's low level file storage, distinct from the EBS volume used for the postgresql database.
[16:36] <cwilper> Btw what kinds of performance tests were you thinking about? It would be interesting to get your take.
[16:37] * dgijonathan (~jgreen@142.176.125.37) Quit (Quit: dgijonathan)
[16:49] * dgijonathan (~jgreen@142.176.125.37) has joined #duraspace
[16:54] * dgijonathan (~jgreen@142.176.125.37) Quit (Client Quit)
[16:55] * dgijonathan (~jgreen@142.176.125.37) has joined #duraspace
[17:21] * dgijonathan (~jgreen@142.176.125.37) Quit (Quit: dgijonathan)
[17:25] <barmintor> cwilper: what do you think about trying to get rid of the different API[X]StubFactory classes? They all do pretty much exactly the same thing.
[17:25] * dgijonathan (~jgreen@142.176.125.37) has joined #duraspace
[17:27] <dgijonathan> cwilper: we were thinking mostly about concurrent reads and writes.
[17:28] * dgijonathan (~jgreen@142.176.125.37) has left #duraspace
[17:46] <cwilper> barmintor: I'd support getting rid of them if there's a suitable replacement
[17:47] <barmintor> cwilper: I was thinking just reducing to one stub factory w/ generics
[17:47] <cwilper> +1. Haven't looked at them in a while but one is better than multiple.
[17:49] * mdiggory (~mdiggory@ip72-199-216-7.sd.sd.cox.net) has left #duraspace
[18:25] <barmintor> huzzah, that was the source of the NPEs
[18:45] <cwilper> what was?
[18:48] * cwilper_ (ad55a88f@gateway/web/freenode/ip.173.85.168.143) has joined #duraspace
[18:51] * cwilper (ad55a88f@gateway/web/freenode/ip.173.85.168.143) Quit (Ping timeout: 245 seconds)
[18:51] <barmintor> cwilper_: the NPEs were from pinging fedora/services/managementMTOM to test whether SSL was required or not
[18:53] * cwilper_ briefly considers the past tense of ping.
[18:53] <barmintor> pung? pang?
[18:54] <barmintor> should I rename cxf.xml to jaxws-impl.xml? That's what it is.
[18:55] <cwilper_> That's good you found the cause. Was it something that could be easily removed/replaces?
[18:55] <cwilper_> +1
[18:56] <barmintor> cwilper_: I changed it to test against fedora/wsdl (for apia) and to do a get against fedora/management/upload for apim
[18:56] <barmintor> those are both lightweight requests that return a simple 200 or 302
[18:56] <cwilper_> ok
[18:57] <barmintor> I also commented the security filter config to indicate that they're used by the client that way
[18:59] <barmintor> All right, I think I'm going to delete the old fesl-configs and do a final pre-merge test.
[18:59] * barmintor crosses his fingers
[18:59] <barmintor> (it was a surprisingly big change to move the server bean up into the applicationContext)
[19:55] <barmintor> deleting code is so satisfying.
[20:18] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has joined #duraspace
[20:38] * scottatm (~scottatm@adhcp218.evans.tamu.edu) has joined #duraspace
[20:59] <cwilper_> code deletion++ ..headed out for the night.
[21:01] * cwilper_ (ad55a88f@gateway/web/freenode/ip.173.85.168.143) Quit (Quit: Page closed)
[21:19] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) Quit (Quit: Later, taterz!)
[21:53] * tdonohue (~tdonohue@c-67-177-108-221.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.