Log of the #duraspace-ff channel on chat.freenode.net

Using timezone: Eastern Standard Time
* Guest31354 leaves01:07
* awoods leaves05:23
* awoods joins05:36
* ajs6f joins07:11
* dwilcox joins07:33
<ajs6f>awoods: How do you feel about the Java 8 stuff?07:59
* acoburn joins08:39
* mikeAtUVa joins08:58
<awoods>ajs6f: I feel like it is an improvement that should get into master. How do you feel about it?09:03
* ksclarke joins09:05
* github-ff joins09:06
[migration-utils] ruebot opened pull request #10: First pass at FCREPO-1524. (master...FCREPO-1524) http://git.io/vUT11
* github-ff leaves
<ajs6f>awoods: Yes, sure, but do we have the mojo?
<escowles>awoods: i'm looking for a place to add a note about files being stored (by default) named after their sha1 digest -- does Backup and Restore feature page seem like the right place to you? it could also go in the modeshape artifact page too, but i would expect users to look for it in backup and restore first09:07
* osmandin joins09:08
<awoods>escowles: do you have a link?
<escowles>the backup & restore page: https://wiki.duraspace.org/display/FEDORA4x/Backup+and+Restore
modeshape artifacts: https://wiki.duraspace.org/display/FEDORA4x/ModeShape+Artifacts+Layout
<awoods>escowles: backup/restore seems like a good fit. ...it may also be worth collapsing (or generally de-emphasizing) the fcr:backup and fcr:restore endpoints on that page, in favor of highlighting the async flow.09:10
ajs6f: Is it safe to assume you would be available to address any issues that may arise in testing the J8 work?09:11
<ajs6f>awoods: Yep.
<escowles>awoods: i'll add the note to the backup/restore page now, and work on improving the transparent persistence page (https://wiki.duraspace.org/display/FF/Design+-+Transparent+Persistence) that can be merged in there when that's ready09:12
<awoods>acoburn: I am not going to have time this morning to push much on the karaf testing, as I am trying to get the fcrepo-vagrant working with the new camel webapp.
escowles: sounds like a plan09:13
acoburn: if someone else can verify your features.xml work, I would be satisfied that it works... and that the issue is in my configuration.09:14
All: acoburn's ticket for review: https://jira.duraspace.org/browse/FCREPO-1479
<acoburn>awoods: btw, were you testing with the latest v3.0.3 karaf?09:15
<awoods>acoburn: /opt/karaf/apache-karaf-3.0.3/
<acoburn>awoods: there is a JRE value that needs to be changed from the default in that version in order to install camel/activemq09:16
<awoods>ajs6f: how would you like to see the J8 work proceed? Would you like it in before OR2015?
acoburn: Thanks, but I will need to change focus this morning.09:17
<ajs6f>awoods: That's the question: do we have the time to give it the attention deserved? That wasn't clear to me from Thursday's call.
<acoburn>if anyone wants to test that ticket, ping me — there are some karaf configurations that need to be changed to get everything work in development
<awoods>acoburn: could you add some notes to the README or to the wiki or to the ticket?
<acoburn>awoods: will do09:18
<awoods>ajs6f: for me the question is, do we have time before OR2015
<ajs6f>awoods: You mean even if we had hands-on-deck?09:19
<awoods>ajs6f: coupled with that question is, is the size of the update worth the risk going into OR2015?
<ajs6f>awoods: If it's not obviously worth it to you, then it obviously isn't worth it.
<awoods>ajs6f: Such a refactor going into OR2015 (given the lack of hands-on-deck) seems risky, no?09:21
ajs6f: and what is the user-facing upside?
<ajs6f>awoods: Yes, definitely. BUt leaving it for another month means I'm not going to be rebasing it and it's going to be _much_ harder to do later.
<awoods>ajs6f: why does it mean you will not be rebasing it?09:22
<ajs6f>awoods: I am not going to have the time. Rebasing that PR is a big deal.09:23
awoods: Unless you want that to be most of my time spent on Fedora.
<awoods>ajs6f: We have four weeks before OR2015. Let's give getting your branch in a shot. I will put out a call for testing (and put my own focus on it) later next week.09:27
<ajs6f>awoods: Okay, I'm ready to move. But don't take any risks with which you're not comfortable.
<awoods>ajs6f: let's test the heck out of it... I'm confident in your work.09:28
<ajs6f>SUCKER!09:30
<awoods>ajs6f: as you know, I am at the NE-FUG the first half of next week... we will go from there.
<ajs6f>awoods: Good.09:32
* ksclarke leaves10:08
* ksclarke joins
* whikloj joins10:28
<osmandin>afk10:59
* dwilcox leaves11:09
* dwilcox joins11:21
* jgpawletko joins11:28
* dwilcox leaves11:48
<awoods>acoburn/escowles: There seems to be an unfortunate bug in the "camel" version of the "activemq" library.11:59
GOOD
<dependency>
<groupId>org.apache.activemq</groupId>
<artifactId>activemq-spring</artifactId>
<version>5.10.0</version>
</dependency>
BAD
<dependency>
<groupId>org.apache.activemq</groupId>12:00
<artifactId>activemq-camel</artifactId>
<version>5.10.0</version>
</dependency>
The end result is that deploying fcrepo-camel-toolbox.war and fcrepo.war together in the same tomcat7 using the activemq-camel library requires that fcrepo.war be deployed first (which is actually non-deterministic).
The bug is that activemq-camel does not reconnect to a topic if the topic is not available at start-up, as it should.
This is just an FYI causing trouble with the updated fcrepo4-vagrant.
In the past, we were using the fcrepo-message-consumer, which uses the activemq-spring library, successfully.
<escowles>awoods: that's good to know -- i have occasionally seen problems with activemq, but attributed it to my local apps also using activemq12:01
<awoods>escowles: in terms of vagrant, maybe the solution is to run fcrepo4 via jetty before starting fcrepo-camel-toolbox using tomcat7.12:02
<escowles>awoods: or we could update the deployment scripts to make sure fcrepo4.war is deployed first12:03
<acoburn>escowles: but when the container is restarted, wouldn't the issue re-emerge if the camel part is started first?
<awoods>escowles: tomcat7 is non-deterministic in its deployment order.12:04
* dwilcox joins
<escowles>awoods: acoburn: very good point -- we can update the init scripts to start jetty before tomcat to make sure that works
<awoods>escowles: yes, starting jetty before tomcat could work.12:05
escowles: I will try that now...
<acoburn>awoods: in karaf I have never encountered this — the activemq component keeps trying to connect until there's something to connect to
is this something specific to tomcat/jetty?
<awoods>acoburn: not sure12:08
acoburn: I know that fcrepo-message-consumer works in the situation and fcrepo-camel-toolbox does not.
acoburn: the catalina.out messages make it very clear that fcrepo-camel-toolbox keeps trying to reconnect... but never does.12:09
acoburn: whereas, fcrepo-message-consumer tries to reconnect and succeeds.
<acoburn>awoods: I'll give this a try12:10
<awoods>acoburn: the error scenario is when fcrepo-camel-toolbox (or fcrepo-message-consumer) start in tomcat7 before fcrepo12:11
<acoburn>awoods: can't reproduce. see this: https://gist.github.com/acoburn/61a147c49248a062609912:19
awoods: camel starts first, errors on connection attempt12:20
awoods: then fcrepo starts and the connection succeeds
<awoods>acoburn: is this in tomcat or karaf?
<acoburn>awoods: tomcat7
awoods: karaf is turned off
awoods: and the audit message route succeeds12:21
<awoods>acoburn: which toolbox war are you using?
<acoburn>awoods: just "at" (that's what I had available)12:22
<awoods>acoburn: try -at-it-is.war
<acoburn>awoods: will do
* ksclarke leaves12:24
<acoburn>awoods: still works12:30
awoods: the camel routes can't connect initially, but then are able to successfully reconnect
awoods: that's with -at-it-is.war
<awoods>acoburn: that is good news. Can you try it in vagrant?12:31
acoburn: you can copy the war into the fcrepo4-vagrant directory...
acoburn: which will then make it available within the vagrant VM at: /vagrant12:32
acoburn: which version of tomcat are you using?
<acoburn>awoods: apache-tomcat-7.0.4212:33
awoods: with java8
awoods: I'll need to set up vagrant first (looks like I have an old version)12:34
* ksclarke joins12:39
<acoburn>awoods: you should be careful with those profile names12:40
awoods: -it-is-at.war shouldn't be expected to cooperate
<awoods>acoburn: it does locally
acoburn: when fcrepo is deployed first.
<acoburn>awoods: sorry, that was an attempt at a joke12:41
<awoods>acoburn: comedy, thanks.
acoburn: without worrying about vagrant, here is a test you can do...
acoburn: start tomcat with only it-is-at.war
acoburn: you should see: ERROR 12:41:05.406 (DefaultJmsMessageListenerContainer) Could not refresh JMS Connection for destination 'fedora' - retrying in 5000 ms. Cause: The JMS connection has failed: Connection refused12:42
acoburn: then start fcrepo via mvn jetty:
<acoburn>awoods: ok, I've got some time before the vagrant vm is downloaded
<awoods>mvn jetty:run -pl fcrepo-webapp/ -Djetty.port=9090
acoburn: on my side, itisat.war never connects.12:43
acoburn: I see the same thing in vagrant
acoburn: However, if I do the same test with message-consumer, instead of itisat.war, it does successfully connect.12:44
acoburn: I need to step away for a moment.12:45
<acoburn>awoods: tried with jetty (started afterwards) and camel reconnected fine12:49
<awoods>acoburn: wow, something is different.12:50
<acoburn>awoods: I'm going to try with vagrant now12:51
* ajs6f leaves12:54
<acoburn>awoods: whenever I run `vagrant up`, I get an error that "the guest machine entered an invalid state"12:56
awoods: do I need to reinstall virtual box?
awoods: I just reinstalled vagrant
awoods: I have an old version of virtual box, and am installing a new version13:02
* ksclarke leaves13:03
* ksclarke joins
<acoburn>awoods: I have the vagrant env booting up properly now; I have another meeting right now, but I'll be back13:15
* mikeAtUVa leaves13:55
<awoods>acoburn: could you share your itisat.war when you get back?14:08
* acoburn leaves14:17
* ajs6f joins14:18
* acoburn joins14:26
awoods: I put the warfile here: https://www.dropbox.com/s/vcshrsd7bmnxfou/fcrepo-camel-webapp-at-is-it-4.1.2-SNAPSHOT.war?dl=014:27
* awoods_ joins14:28
* awoods leaves
<acoburn>awoods: did you get that last message?14:30
<awoods_>acoburn: no14:31
<awoods>acoburn: was it good?
<acoburn>awoods: of course: the warfile is here: https://www.dropbox.com/s/vcshrsd7bmnxfou/fcrepo-camel-webapp-at-is-it-4.1.2-SNAPSHOT.war?dl=0
<awoods>acoburn: have you had a chance to try it in vagrant?14:33
<acoburn>awoods: I typed `vagrant reload` and it has been going through some sort of system update for the last fifteen minutes14:34
awoods: which is another way of saying "not yet"
* osmandin leaves14:35
<acoburn>awoods: it works for me in vagrant14:44
<awoods>acoburn: I am trying your war locally now...14:45
<acoburn>awoods: I take that back, I didn't try restarting it… just a sec
awoods: confirmed, it works in vagrant14:50
<awoods>acoburn: awesome... but your war does not work for me locally.14:51
<acoburn>awoods: that is, you'll need to adjust the settings for the solr url, since it's port 8983 by default
awoods: java8 or java7?
<awoods>acoburn: yes, I locally updated toolbox application.properties14:52
-solr.baseUrl=localhost:8983/solr/collection1
+solr.baseUrl=${solr.base.url:localhost:8983/solr/collection1}
acoburn: java8
Java version: 1.8.0_25, vendor: Oracle Corporation14:53
Java home: /usr/lib/jvm/jdk1.8.0_25/jre
acoburn: the strange thing is the vagrant setup... which should be identical for us.
<acoburn>awoods: java version "1.8.0_45"
awoods: right, that confuses me
<awoods>acoburn:
acoburn: can you verify that fcrepo started after itisat.war?14:54
acoburn: you are using itisat.war in your vagrant, right?
<acoburn>awoods: correct14:55
<awoods>acoburn: and you are verifying that solr, audit, and resource triples are finding their way into their respective indexes?
<acoburn>awoods: I'll try this sequence again
awoods: I was incorrect, the jms listeners do not reconnect properly15:00
<awoods>acoburn: that is good and bad
acoburn: it works for you locally but not in vagrant?
<acoburn>awoods: yes, but let me verify that sequence again15:01
awoods: so now I'm really baffled. It fails for me locally, too15:06
<awoods>acoburn: I am working on the jetty / tomcat vagrant setup15:07
* acoburn leaves15:21
* acoburn joins15:22
<awoods>acoburn: I am confident about getting the jetty/tomcat setup working...15:26
acoburn: do you have enough to go on for your presentation on Tuesday?15:27
<acoburn>awoods: that's great about tomcat/jetty
awoods: for the presentation, I have plenty to talk about
awoods: are there topics you'd like me to cover?15:28
awoods: I was thinking about this:
1) messaging in general15:29
2) how it fits into the fedora context
3) what you can do with it
4) how to deploy it
5) advanced integrations
5.1) writing custom camel routes
* github-ff joins
[migration-utils] mikedurbin closed pull request #10: First pass at FCREPO-1524. (master...FCREPO-1524) http://git.io/vUT11
* github-ff leaves
<acoburn>5.2) customizing existing camel routes15:30
5.3) options that don't involve writing JAVA code
* awoods leaves15:31
* github-ff joins15:32
[migration-utils] mikedurbin force-pushed master from 1e0cf84 to 02b57af: http://git.io/vULFr
migration-utils/master 02b57af nruest: Added walkthrough to readme.
* github-ff leaves
* travis-ci joins
fcrepo4-labs/migration-utils#26 (master - 1e0cf84 : nruest): The build passed.
Change view : https://github.com/fcrepo4-labs/migration-utils/compare/49f4af11f16b...1e0cf8441237
Build details : http://travis-ci.org/fcrepo4-labs/migration-utils/builds/61810174
* travis-ci leaves
* mikeAtUVa joins15:33
* osmandin joins
* travis-ci joins15:34
fcrepo4-labs/migration-utils#27 (master - 02b57af : nruest): The build passed.
Change view : https://github.com/fcrepo4-labs/migration-utils/compare/1e0cf8441237...02b57af9c98e
Build details : http://travis-ci.org/fcrepo4-labs/migration-utils/builds/61810440
* travis-ci leaves
* github-ff joins15:49
[migration-utils] mikedurbin pushed 1 new commit to master: http://git.io/vULjj
migration-utils/master 17ed883 Michael Durbin: Merge pull request #8 from fcrepo4-labs/legacy-fs-support...
* github-ff leaves
* travis-ci joins15:52
fcrepo4-labs/migration-utils#28 (master - 17ed883 : Michael Durbin): The build passed.
Change view : https://github.com/fcrepo4-labs/migration-utils/compare/02b57af9c98e...17ed883f1075
Build details : http://travis-ci.org/fcrepo4-labs/migration-utils/builds/61812510
* travis-ci leaves
* awoods joins15:55
<acoburn>awoods: I think I know what is going on with the jms connection15:56
awoods: https://github.com/fcrepo4-labs/fcrepo-camel-toolbox/blob/master/fcrepo-camel-webapp/src/main/resources/application.properties#L315:57
awoods: the startupMaxReconnectAttempts is set as 115:58
awoods: If I remove all of that, the reconnection seems to work fine
* osmandin leaves16:01
<acoburn>awoods: ping16:14
* github-ff joins16:23
[fcrepo4] escowles created fcrepo-1531 (+1 new commit): http://git.io/vUtnp
fcrepo4/fcrepo-1531 aba7e4b Esmé Cowles: Using premis:hasMessageDigest for checksums
* github-ff leaves
* github-ff joins
[fcrepo4] escowles opened pull request #790: Using premis:hasMessageDigest for checksums (master...fcrepo-1531) http://git.io/vUtcL
* github-ff leaves
* escowles leaves16:31
<awoods>acoburn: back16:38
<acoburn>awoods: did you see my email?
<awoods>acoburn: reading it now
acoburn: I made the same update to the connection URL and found that toolbox just hung16:39
acoburn: setting startupMaxReconnectAttempts=1 allows toolbox to be non-blocking, therefore allowing fcrepo and solr to deploy.16:40
<acoburn>awoods: did you leave the failover: transport?
awoods: I completely removed that16:41
<awoods>acoburn: interesting. No, I left the failover.
let me try.
* travis-ci joins16:43
fcrepo4/fcrepo4#3639 (fcrepo-1531 - aba7e4b : Esmé Cowles): The build passed.
Change view : https://github.com/fcrepo4/fcrepo4/commit/aba7e4bb66e4
Build details : http://travis-ci.org/fcrepo4/fcrepo4/builds/61816155
* travis-ci leaves
* jgpawletko leaves16:48
* dwilcox leaves16:49
<acoburn>awoods: I'm out for the day
* acoburn leaves
* mikeAtUVa leaves16:50
* whikloj leaves17:44
* awead leaves17:54
* awead joins18:03
* ajs6f leaves18:40
* acoburn joins19:06
awoods: ping
<awoods>acoburn: I was just thinking about you.
acoburn: all is well on the vagrant front
<acoburn>awoods: oh good
<awoods>acoburn: your removal of failover did the trick19:07
acoburn: however...
<acoburn>awoods: yes?
<awoods>acoburn: I now notice that all of the updates to the /audit container show up in Solr and Fuseki from the other two camel modules.19:08
acoburn: fcrepo-audit-triplestore filters those out... but not the other two modules.
<acoburn>awoods: yes, I suppose they would
awoods: we could add a filter easily enough
<awoods>acoburn: I have a PR that changes that, but am not positive what the user wants.19:09
acoburn: let me send you my PR...
<acoburn>awoods: you can make it optional, like the indexing:Indexable predicate
awoods: and set the default with the filtering enabled19:10
awoods: I will happily review that PR this evening19:11
awoods: I'll be in and out for the next few hours19:12
<awoods>acoburn: https://github.com/fcrepo4-labs/fcrepo-camel-toolbox/pull/23
* github-ff joins
[fcrepo-camel-toolbox] awoods opened pull request #23: Allow the solr.baseUrl to be configurable, and (master...fcrepo-1529) http://git.io/vUqlQ
* github-ff leaves
<acoburn>awoods: thanks!
<awoods>acoburn: you are encouraged to submit another PR against mine to make it even better!19:13
<acoburn>awoods: on first glance it looks great; I've promised the little one that I'd play frisbee before it gets dark19:15
awoods: so I'll be back in a bit
<awoods>acoburn: have fun
* acoburn leaves
* awoodsx joins20:00
* awoodsx leaves20:12
* jgpawletko joins20:41
* awoods leaves21:02
* github-ff joins21:43
[fcrepo-camel-toolbox] awoods pushed 1 new commit to master: http://git.io/vUqAx
fcrepo-camel-toolbox/master 0305887 Andrew Woods: Allow the solr.baseUrl to be configurable, and...
* github-ff leaves
* awoodsx joins21:44
* awoodsx leaves
* github-ff joins21:48
[fcrepo4] awoods tagged fcrepo-4.1.1-audit.2 at 4dc1661: http://git.io/vUqx2
* github-ff leaves
* github-ff joins
[fcrepo-webapp-plus] awoods tagged fcrepo-4.1.1-audit.2 at b312ec8: http://git.io/vUqxr
* github-ff leaves
* github-ff joins21:54
[fcrepo-camel-toolbox] awoods tagged fcrepo-4.1.1-audit.2 at 56aba84: http://git.io/vUqhY
* github-ff leaves
* travis-ci joins21:55
fcrepo4-labs/fcrepo-webapp-plus#34 (fcrepo-4.1.1-audit.2 - 1b8cd56 : Andrew Woods): The build passed.
Change view : https://github.com/fcrepo4-labs/fcrepo-webapp-plus/compare/fcrepo-4.1.1-audit.2
Build details : http://travis-ci.org/fcrepo4-labs/fcrepo-webapp-plus/builds/61845035
* travis-ci leaves
* travis-ci joins21:58
fcrepo4-labs/fcrepo-camel-toolbox#71 (fcrepo-4.1.1-audit.2 - 0305887 : Andrew Woods): The build passed.
Change view : https://github.com/fcrepo4-labs/fcrepo-camel-toolbox/compare/fcrepo-4.1.1-audit.2
Build details : http://travis-ci.org/fcrepo4-labs/fcrepo-camel-toolbox/builds/61845196
* travis-ci leaves
* travis-ci joins22:02
fcrepo4/fcrepo4#3641 (fcrepo-4.1.1-audit.2 - 31e068b : Andrew Woods): The build passed.
Change view : https://github.com/fcrepo4/fcrepo4/compare/fcrepo-4.1.1-audit.2
Build details : http://travis-ci.org/fcrepo4/fcrepo4/builds/61844963
* travis-ci leaves
* github-ff joins22:20
[fcrepo-webapp-plus] awoods tagged fcrepo-webapp-plus-4.1.1-audit.2 at 24763ed: http://git.io/vUmJ9
* github-ff leaves
* travis-ci joins22:29
fcrepo4-labs/fcrepo-webapp-plus#35 (fcrepo-webapp-plus-4.1.1-audit.2 - 1b8cd56 : Andrew Woods): The build passed.
Change view : https://github.com/fcrepo4-labs/fcrepo-webapp-plus/compare/fcrepo-webapp-plus-4.1.1-audit.2
Build details : http://travis-ci.org/fcrepo4-labs/fcrepo-webapp-plus/builds/61846405
* travis-ci leaves
* github-ff joins
[fcrepo-camel-toolbox] awoods tagged fcrepo-camel-toolbox-4.1.1-audit.2 at dca3741: http://git.io/vUmUP
* github-ff leaves
* github-ff joins22:32
[fcrepo-webapp-plus] awoods deleted fcrepo-4.1.1-audit.2 at b312ec8: http://git.io/vUmTB
* github-ff leaves
* github-ff joins22:33
[fcrepo-camel-toolbox] awoods deleted fcrepo-4.1.1-audit.2 at 56aba84: http://git.io/vUmTo
* github-ff leaves
* travis-ci joins
fcrepo4-labs/fcrepo-camel-toolbox#72 (fcrepo-camel-toolbox-4.1.1-audit.2 - 0305887 : Andrew Woods): The build passed.
Change view : https://github.com/fcrepo4-labs/fcrepo-camel-toolbox/compare/fcrepo-camel-toolbox-4.1.1-audit.2
Build details : http://travis-ci.org/fcrepo4-labs/fcrepo-camel-toolbox/builds/61846831
* travis-ci leaves
<f4jenkins>Project fcrepo-camel-toolbox build #82: UNSTABLE in 5 min 13 sec: http://jenkins.fcrepo.org/job/fcrepo-camel-toolbox/82/22:39
* jgpawletko leaves23:14
* awoods joins
* jgpawletko joins23:32
* ksclarke leaves23:58
* awoods leaves00:01
* awoods joins

Generated by Sualtam