Log of the #fcrepo channel on chat.freenode.net

Using timezone: Eastern Standard Time
* dwilcox joins06:58
* anarchivist_ joins07:02
* Iome_ joins07:04
* anarchivist leaves07:05
* Iome leaves07:06
* dwilcox leaves07:11
* dwilcox joins07:13
* dwilcox leaves07:47
* dwilcox joins07:49
* arebenji joins08:06
* dwilcox leaves08:59
* jrgriffiniii joins
* ajs6f joins09:06
* dwilcox joins
* acoburn joins09:14
ajs6f: do you have an opinion on this: https://jira.duraspace.org/browse/FCREPO-199509:15
<ajs6f>acoburn: Yes. We should do it.
<acoburn>ajs6f: cool, just wanted to make sure you were in favor of it09:16
<ajs6f>acoburn: <sarcasm> NO! I just LUUUUUUVVVV the broker older Java Date API. </sarcasm> Seriously.09:17
* dwilcox leaves
<ajs6f>afk bbl09:18
* ajs6f leaves
* bseeger joins09:32
* peichman joins09:49
* awoods joins09:52
* dwilcox joins10:33
* dwilcox leaves10:34
* dwilcox joins10:35
* whikloj joins10:51
* edf joins10:57
* aelkiss joins
* bseeger leaves11:11
* dshalvi joins11:13
* jcoyne joins11:20
* bseeger joins11:25
* bseeger leaves11:28
JAVA_OPTS="-Djava.awt.headless=true -XX:+DisableExplicitGC -Xms512m -Xmx14g -XX:NewSize=256m -XX:MaxNewSize=2g -XX:MetaspaceSize=64m -XX:MaxMetaspaceSize=2g -Dfile.encoding=UTF-8 -Xloggc:/var/log/tomcat7/java-gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Dfcrepo.home=/mnt/test"11:32
* mhaye joins
See http://www.oracle.com/technetwork/tutorials/tutorials-1876574.html11:38
* tecoripa joins11:48
thanks sprater for this link!11:52
<sprater>you're welcome!
<ruebot>awoods: https://wiki.duraspace.org/display/FF/2016-05-16+Performance+-+Scale+Meeting12:05
* aelkiss leaves12:32
* mhaye leaves12:53
* dwilcox leaves13:08
* jcoyne leaves13:12
* sprater leaves13:19
* tecoripa joins13:24
* ajs6f joins
<awoods>ruebot: minutes are up: https://wiki.duraspace.org/display/FF/2016-04-18+Performance+-+Scale+Meeting13:27
<ruebot>awoods: cool. i'll send out after the april CLAW sprint kickoff call. thanks!
* tecoripa leaves13:29
<ajs6f>awoods: How do I go about getting a YourKit license?13:31
<awoods>ajs6f: I can send you one if you are interested13:32
<ajs6f>awoods: Ish. It's only for version 12, from 2012?
<awoods>ajs6f: It looks like the current license is good for the current release: "You may use the latest version YourKit Java Profiler 2016.02"13:34
<ajs6f>awoods: O, cool. In that case, please do send me a copy, thank you!13:35
<awoods>ajs6f: done13:36
<ajs6f>awoods: Wow, and it's already slammed into my inbox like Ricky "The Dragon" Steamboat with a flying crossbody! POW!13:37
acoburn: Is this right? Currently, if I change a property in a description, the described binary's ETag does not change. After your PR, it does.13:55
<acoburn>ajs6f: see this for the current behavior: https://gist.github.com/acoburn/c12d07cb67143caa37009d02d955e3a013:56
ajs6f: and yes, if you change a property in the description, the etag for the binary changes13:57
ajs6f: curiously, the etag for the description doesn't, but the headers won't tell you what that etag is
ajs6f: see the gist, it's completely &%*#*@ up
<ajs6f>acoburn: Currently, it changes? BEcause that's what I think is correct. (I looked at the gist, but I don't understand it at all. You wold have to walk me through that.)13:58
<acoburn>ajs6f: you create a binary
ajs6f: you make a HEAD request on both the binary and its description
ajs6f: both responses give you a last-mod date and an etag; those values are identical13:59
<ajs6f>acoburn: Sounds good.
<acoburn>ajs6f: right, so far, so good
ajs6f: now send an If-None-Match header with the advertised etag
you get a 304 for the binary and a 200 for the description14:00
that's wrong
<ajs6f>acoburn: Yep.
<acoburn>ajs6f: of course, if you send an If-Modified-Since header with the last-mod date, you get a 304 for both14:01
that's correct
<ajs6f>acoburn: Okay, that's certainly a bug.
<acoburn>but…. in the response from the description you get a _different_ etag
<ajs6f>acboruN; Without having issued any mutation?
<acoburn>no, no mutations
<ajs6f>acoburn: That's cray-cray.
<acoburn>if you send _that_ etag to the binary description, then you get a 30414:02
so that's clearly broken, but it gets worse
now, if you modify the description with some new property...
<ajs6f>acoburn: Our software is so helpful, it does the mods you wanted to do before you knew you were going to do them.
<acoburn>you get a new etag and last-mod header for both the binary and the description
the binary works as you'd expect (i.e. given the correct last-mod date or etag, you get a 304 in response)14:03
<ajs6f>acoburn: Which I think you should get, since you changed the underlying resource. (Even if the representation doesn't change, you can still change the ETag, just not the other way around.)
<acoburn>but the description is completely screwy
<ajs6f>acoburn: You mean there are phony triples?!?!14:04
<acoburn>if _claims_ to have a new etag and last-mod (from the JCR-CONTENT node), but it's pulling that value from the parent jcr node14:05
look through that gist toward the bottom, you'll see what I mean
basically, for the description, you get a 304 only if you sent the "secret" etag value — the one it never advertises14:06
<ajs6f>acoburn: This is beyond cray-cray, it's cré-cré. So this is definitely a bunch of bugs, and what does your PR do?
<acoburn>or if you send an if-modified-since as the _original_ last-mod date
my PR simply proxies the getLastModifiedDate() and getEtagValue() for NonRdfSourceDescriptions to the JCR node that contains those values14:07
look here: https://github.com/fcrepo4/fcrepo4/pull/1022/files14:08
the changes are all at the top, in the first listed file
the rest are just modifications of existing unit test code
<ajs6f>acoburn: And that node would be the node that actually has the bitstream, right?
<acoburn>ajs6f: honestly, I don't really know where the bitstream lives — I try to steer clear of modeshape as much as possible14:09
ajs6f: basically, there's a jcr node that has the fedora:binary mixin
<ajs6f>acoburn: And we are the experts. That really says something.
<acoburn>ajs6f: and there's a child node called something like jcr-content. that's where all the properties are stored14:10
<ajs6f>acoburn: Okay, yeah, that's what I meant.
acoburn: I think your PR is right, and it's not clear to me why we were doing anything else…14:11
<barmintor>wait the fcr:metadata ETag and LMD are the same as the nonRdfSource?14:12
<acoburn>barmintor: yes, that's what this discussion has been about: https://github.com/fcrepo4/fcrepo4/pull/102214:13
<barmintor>but that's not true.
<ajs6f>barmintor: See the discussion at the PR. The whole point is that we don't think that's right, but it's better than the craziness going on now.
<acoburn>barmintor: right now it's completely broken
<ajs6f>barmintor: And there's no reason that both ETag and last-mod have to go together.
<acoburn>barmintor: that is, the values are actually different, but they're advertised as being the same
barmintor which leads to this nonsense: https://gist.github.com/acoburn/c12d07cb67143caa37009d02d955e3a014:14
<ajs6f>barmintor: In fact, they almost certainly shouldn't go together. Last-mod is about the resource, Etag is about a representation.
<acoburn>at present, the etag is derived from the last-mod value: https://github.com/fcrepo4/fcrepo4/blob/master/fcrepo-kernel-modeshape/src/main/java/org/fcrepo/kernel/modeshape/FedoraResourceImpl.java#L67214:15
that's a problem, but it's a separate problem
<barmintor>I am inclined to regard the 2 resources as distinct resources.
* jcoyne joins14:16
<ajs6f>barmintor:acoburn: But escowles and I would both argue that it shouldn't be a simple ETag = f(last-mod). There are many more parameters to the function.
<acoburn>ajs6f: it should at least be f(content-type, last-mod)
ajs6f: but you may need some more prefer headers represented
<ajs6f>acoburn: sure, and there are more
barmintor: We don't even have to get into that (and anyway, it depends on what you mean by "resource"). The immediate task to hand is to stop blocking the release.
<acoburn>ajs6f: I don't think this is a blocker (for the release)14:17
<ajs6f>acoburn: Yeah, escowles and I talked in the conv you linked about needed some controls for this.
acoburn: I thought it was? Oh, then the urgency is less. I still think your PR is better than the current zaniness.
<acoburn>ajs6f: it's just a blocker for other work I'm doing, and yes, from my perspective this PR simply brings some sanity to the current behavior14:18
<ajs6f>barmintor: So the question is not whether you think acoburn's PR is the best possible thing. We can have the longer discussion. Is it better than the craptacular current state of affairs?
barmintor: That's the question of immediate import.14:19
<barmintor>I'm trying to figure out what to say that this PR fixes14:23
I get that it makes things less opaquely wrong14:24
<acoburn>barmintor: did you look at this: https://gist.github.com/acoburn/c12d07cb67143caa37009d02d955e3a0
<barmintor>but IMO they are still left in a broken state
* jcoyne leaves
* jcoyne joins14:25
<acoburn>barmintor: the goal of this PR was to bring this to a less broken state without changing the _design_ of LDP-NRs/descriptions14:27
<barmintor>acoburn: I'm reading through it. the first bug I see is that it reports the nonRDFS ETag erroneously on HEAD to nonRDFS/fcr:metadata14:28
<acoburn>barmintor: once we can reach a consensus on the design, I expected some other impl would take precedence.
<barmintor>acoburn: but I am only down to PATCH
acoburn: so far that seems to be the heart of the matter14:29
<acoburn>barmintor: yes, exactly
<ajs6f>barmintor: I wouldn't disagree with your characterization, but I would also say less _bizzarely_ wrong14:30
<acoburn>barmintor: the issue is that the HTTP response headers advertise an ETag/last-mod value that is different that the one used when deciding whether the If-None-Match value matches
<barmintor>ajs6f: let me plod through this
<ajs6f>barmintor: Plod like Andre the Giant.14:31
<barmintor>ok and the other bug is that updating the fcr:metadata changes the data/ETag of the nonRDFS14:34
but then the rest is the same misrporting behavior14:35
the thing that makes me uncomfortable about this PR is that it trades what I regard as the correct behavior with a buggy implementation to an incorrect behavior without a bug14:37
<awoods>barmintor: I feel the same way14:38
<ajs6f>barmintor: In that case, we should back off and have the longer discussion. I think we cannot agree on the "correct" behavior without separating last-mod and ETag and complexifiying the calculation of ETag.
<acoburn>barmintor: that's fair, personally, I think the nonRDFS and description should have separate lastmod values and _definitely_ separate ETag values
<ajs6f>barmintor: as part of the longer conversation, we will get into the same morass about whether LDP is more important than anything that's left of the Fedora model.14:39
<barmintor>ajs6f: no, no we don't
<ajs6f>barmintor: The one we never get through and which just tires us out? Remember that one?
<barmintor>ajs6f: even in Fedora 3 we tried not to collapse these changes when we tried to care about cache headers14:40
<ajs6f>barmintor: I'm not worried about ETags. I frankly don't care that much about them, because I think people who are worried about signiificant caching are probably overestimating the popularity or intrinsic interest of their repository contents.
barmintor: I care about last-mod.14:41
<barmintor>ajs6f: but more importantly, re-entering that conversation is retro-forwardly changing the design, when we ought really to be fixing this bug
<ajs6f>barmintor: If the design is wrong, that's how we fix the bug.
<barmintor>ajs6f: but this bug is not a wrong design, it is a concrete implementation errir
<ajs6f>barmintor: There, we disagree. The fact that the last-mod can slip between the two URIs is wrong, to me.14:42
<barmintor>or at least, the design as it stands does not require this bug, and we can separate the reconsideration of the design from fixing this bug
<ajs6f>barmintor: That sounds like work that will nee to be redone. That's not a good use o scarce dev resources.
barmintor: Tell me about why you think that the bitstream and the properties have different last-mods.14:43
<acoburn>as a question: say the bitstream and description have different lastMods; now, when I request the description and I see the fedora:lastModified triple, what does that value refer to?14:44
the bitstream or the description?14:45
<barmintor>ajs6f: I am not biting. This is a 26 lines of code that changes the current design rather than fix a bug. acoburn knows (I hope) that I appreciate his work, but that's not how we should go about this.
<ajs6f>acoburn: Right. Either we reify the description fully, or the last-mods are the same, because there is only one underlying resource.
barmintor; No one is trying to make you bite on anything. You claim to know about the current design. I don't think you do, because there isn't one. acoburn is presenting a first draft at one, as we struggle onwards towards actually publsuhing designs in the form of the spec.14:46
barmintor: We are trying to establish what the design _is_.14:47
<whikloj>I hope this is on the agenda for Thursday, cause I have vertigo now
<barmintor>ajs6f: I'm only trying to say that acoburn's whole report is that 1) fcr:metadata doesn't report the ETag that it otherwise predictably respects, and that 2) updating fcr:metadata changes another resource's ETag. The minimal change for a ptach release here is to fix the ETag reporting.14:49
<ajs6f>barmintor: Let's leave it for the meeting. I don't feel like IRC is helping here. It's too low bandwidth. Also, I have a hangout with awoods in a few minutes on something totally unrelated.14:50
* github-ff joins14:53
[fcrepo4] ajs6f opened pull request #1023: FCREPO-1989: Minor cleanup of compiler warnings (DEV...FCREPO-1989) https://git.io/vwYC8
* github-ff leaves
* github-ff joins14:54
[fcrepo4] ajs6f closed pull request #1020: FCREPO-1989: Minor cleanup of compiler warnings (master...FCREPO-1989) https://git.io/vwe7a
* github-ff leaves
* bseeger joins15:08
* cmmills joins15:13
* jcoyne leaves15:14
* dwilcox joins15:16
* bseeger leaves15:48
* bseeger joins15:49
* jcoyne joins16:26
<ajs6f>dwilcox:awoods: After this release finally goes out, we should resurrect the plan for album covers per release. We could even get one out for OR.16:34
Print a few for shwag.
<dwilcox>ajs6f: That would be so much cooler than USB drives and coffee mugs.16:35
<ajs6f>dwilcox: That's what I'm saying. And we could make snide remarks about other software projects using the phrase "legacy technology".16:36
<dwilcox>ajs6f: Maybe we should record a diss track to hand out with the album covers16:37
<ajs6f>dwilcox: On cassette. Or better… minidisc.16:38
<dwilcox>ajs6f: It might make people question where their membership dollars are going though16:39
<ajs6f>dwilcox: Are they not already doiing that?
<dwilcox>ajs6f: So far people seem to like it when we print t-shirts. The album covers and cassettes might be a harder sell16:41
<ajs6f>dwilcox: Maybe if the t-shirt and album cover designs are aligned. Then it's more a of a full media blitz.16:42
<dwilcox>ajs6f: That could work - it's like the Fedora World Tour. We could put conference dates on the back of the shirts
<ajs6f>dwilcox: There's going to be lots of groupies and blow for this, right?16:43
dwilcox: Because _that's_ why I got into Fedora.
<dwilcox>ajs6f: That's why we're all here
<ajs6f>dwilcox: I leave it you. Got to run, see y'all tomorrow.16:44
* ajs6f leaves
* jcoyne leaves
* jcoyne joins16:46
* jcoyne leaves16:47
* jcoyne joins
* jackhill joins16:48
* jcoyne leaves16:55
* jcoyne joins16:56
* jcoyne leaves17:00
* jrgriffiniii leaves17:13
* dwilcox leaves17:14
* jcoyne joins17:16
* peichman leaves17:19
* jcoyne leaves17:24
* bseeger leaves17:29
* github-ff joins17:30
[fcrepo4] acoburn opened pull request #1024: Fix ETag handling for Binaries and Binary descriptions (master...fcrepo-1983.2) https://git.io/vwYHu
* github-ff leaves
* acoburn leaves17:31
* arebenji leaves17:45
* jcoyne joins17:55
* whikloj leaves18:02
* jcoyne leaves18:08
* jcoyne joins
* jcoyne leaves
* jcoyne joins18:09
* jcoyne leaves18:22
* jcoyne joins18:32
* jcoyne leaves20:02
* github-ff joins20:08
[fcrepo4] awoods pushed 1 new commit to DEV: https://git.io/vwOtY
fcrepo4/DEV 8183da8 Andrew Woods: Merge pull request #1023 from fcrepo4/FCREPO-1989...
* github-ff leaves
* jcoyne joins20:16
<f4jenkins>Yippee, build fixed!20:21
Project fcrepo-mint build #103: FIXED in 1 min 51 sec: http://jenkins.fcrepo.org/job/fcrepo-mint/103/
Yippee, build fixed!20:22
Project fcrepo-transform build #122: FIXED in 2 min 38 sec: http://jenkins.fcrepo.org/job/fcrepo-transform/122/
* jcoyne leaves20:24
* jcoyne joins20:25
* jcoyne leaves20:30
* travis-ci joins20:31
fcrepo4/fcrepo4#4420 (DEV - 8183da8 : Andrew Woods): The build passed.
Change view : https://github.com/fcrepo4/fcrepo4/compare/0fb07791dae2...8183da82fcbd
Build details : https://travis-ci.org/fcrepo4/fcrepo4/builds/124061115
* travis-ci leaves
* jcoyne joins
* jcoyne leaves20:33

Generated by Sualtam