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

Using timezone: Eastern Standard Time
* dchandekstark joins04:39
* dchandekstark leaves04:43
* dchandekstark joins06:40
* dchandekstark leaves06:45
* manez joins08:04
* dwilcox joins08:18
* dchandekstark joins08:23
* dchandekstark leaves08:27
* dwilcox leaves
* dhlamb joins08:30
* peichman joins08:41
* peichman leaves08:45
* dwilcox joins08:46
* dwilcox_ joins08:52
* dwilcox leaves08:54
* dwilcox_ leaves
* arebenji joins09:08
* mikeAtUVa joins
* ajs6f joins09:14
* apb18 joins09:22
* manez leaves09:33
* bseeger joins
* manez joins09:35
* coblej joins09:41
* dchandekstark joins09:42
* bseeger leaves09:43
* bseeger joins09:47
* peichman joins09:49
* bseeger1 joins10:00
* bseeger leaves10:02
* bseeger1 leaves10:03
* ajs6f leaves10:12
* ajs6f joins10:15
* dwilcox joins10:18
* coblej leaves10:23
* bseeger joins10:40
* thomz leaves10:54
* peichman leaves11:00
* coblej joins11:03
<dchandekstark>awoods: we've got another live example of persistence exceptions on hydra #dev slack channel11:24
CentOS 7 - almost RHEL 7
not sure what db they're on11:26
* awoods reading the slack now
<dchandekstark>awoods: narogers11:27
<awoods>dchandekstark: I agree with jcoyne's recommendation to update the ticket: https://jira.duraspace.org/browse/FCREPO-201111:30
<dchandekstark>awoods: you mean ask narogers to report there?11:31
<awoods>dchandekstark: yes
<dchandekstark>awoods: assuming that's what he's seeing ...11:32
there seem to be other circumstances that produce the same ispn error
* tjohnson joins11:35
* bseeger leaves11:42
<dchandekstark>mikeAtUVa: did something get snipped out of your comment on FCREPO-2011?11:50
* coblej leaves11:56
* manez leaves12:01
* manez joins12:03
<mikeAtUVa>dchandekstark: no, but I abbreviated my change... really I just changed jdbc:connection-pool to jdbc:simple-connection (per http://docs.jboss.org/infinispan/7.0/configdocs/infinispan-cachestore-jdbc-config-7.0.html)12:06
* bseeger joins12:33
* apb18 leaves12:36
* apb18 joins12:40
* chadmills leaves12:41
* coblej joins12:44
awoods: ajs6f: The problem we encountered during FedoraMigrate relationship migration using 4.6.0-RC3 still occurs under 4.6.0-RC412:47
<ajs6f>cablej: I do not know what FedoraMigrate is or what it deos.12:48
<coblej>we haven't dug deep enough to know whether it's really an fcrepo issue, though
<ajs6f>coblej: Is there a ticket for this?
<awoods>https://jira.duraspace.org/browse/FCREPO-209812:49
<ajs6f>coblej: Please reopen the ticket if you determine it to be fcrepo.
<dchandekstark>ajs6f: fwiw coblej is just referencing that our migration happens in phases ...
<coblej>not really ... I originally mentioned it on a hydra-tech post https://groups.google.com/forum/#!topic/hydra-tech/A32vAP_tBZw12:50
I didn't actually open FC-2098 ...
<dchandekstark>the first phase creates objects in F4
<ajs6f>coblej: So this is not FCREPO-2098. I know you didn't open it, but acoburn opened it based on your report.
<dchandekstark>later relationships between the objects are migrated
<coblej>I reported the issue on hydra-tech (https://groups.google.com/forum/#!topic/hydra-tech/A32vAP_tBZw) and acoburn thought it might be the same issue as FCREPO-2098
I think that's how my name got associated with FCREPO-209812:51
ajs6f: if RC4 fixes FCREPO-2098, then what we're seeing is something else12:52
<ajs6f>coblej:dchandekstark: I'm afraid I can't help you very much right now. I have no idea what that Ruby is code is doing or why. Can you investigate further and see if this is in fact repository behavior at play/
?
<coblej>we're seeing it through the Hydra stack ... will see if we can figure out a way to reproduce it outside Hydra
<ajs6f>coblej++12:53
<dchandekstark>ajs6f: the hydra ruby code just uses the REST API - are you suggesting that a client error is possible in this case?12:55
<ajs6f>dchandekstark: I am saying that I literally have no idea what is being shown in that report. It's just a Ruby stacktrace. There is no information at all of any kind about what the repository is doing. I can't do much with that.12:56
dchandekstark: Maybe you/coblej can take it a little further in the Hydra community to figure out whether this is a reposiotry problem or a client problem?12:58
<dchandekstark>ajs6f: fair enough ...12:59
according to the source, it indicates the LDP client received a 412 response: https://github.com/projecthydra/ldp/blob/v0.4.1/lib/ldp/client/methods.rb#L136-L137
<ajs6f>That's probably what made acoburn think of ETags.13:00
<dchandekstark>ajs6f: does this mean an ETag should have been supplied by the client?13:01
ajs6f: evidently the server is not supplying more information, at least not in the response body13:02
since that should have been added to the error message
<ajs6f>dchandekstark: It could mean that— a missing header in the request could lead to that.13:03
<dchandekstark>ajs6f: i'm looking for 412 or PRECONDITION_FAILED in source13:05
unless this is bubbling up from modeshape
<ajs6f>dchandekstark: In Fedora's source?
<dchandekstark>yes
i've only seen in copyObject and moveObject13:06
<ajs6f>dchandekstark: That's not really a good use of your tie. Can we try to get to some minimal eample? One that doesn't involve anything but Fedora and maybe curl?
s/tie/time
<dchandekstark>ajs6f: i guess coblej's on that13:07
<ajs6f>dchandekstark: Excellent.
afk bbl13:10
* ajs6f leaves
* apb18 leaves13:18
* apb18 joins13:25
* bseeger1 joins14:26
* bseeger1 leaves14:28
* bseeger leaves
* bseeger joins14:32
<coblej>ajs6f: awoods: I was able to generate "ETag mismatch" using just curl14:51
https://gist.github.com/coblej/4fb90ec8f4900be2b01da9692d5eecb5
* ajs6f joins14:52
<coblej>don't know which is considered "correct" ... If-Match with the "W/" or without
* bseeger leaves
<ajs6f>coblej: any developments?
<coblej>ajs6f: https://gist.github.com/coblej/4fb90ec8f4900be2b01da9692d5eecb5
<ajs6f>coblej++ # That si a beautiful example.14:53
<awoods>coblej: I have added your script to the ticket. https://jira.duraspace.org/browse/FCREPO-2098
<ajs6f>coblej: I just walked in, so give me a few minutes to settle and get a repo in fron tof me.
<coblej>ajs6f: okay14:54
* bseeger joins
<barmintor>are you supposed to include the weak flag on request headers?14:55
<ajs6f>barmintor: Reading about that now myself.14:57
<barmintor>I see examples online of both
<ajs6f>Wow, this HTTP stuff is pretty cool. We should use this.14:58
<barmintor>Rails 5 has the client transmit the weak flag
semantically kind of weird, but friendly to the client. Worse for the server.
<ajs6f>barmintor: You're talking about GET only, right?
<barmintor>ajs6f: I assume GET and PUT/PATCH would work the same way15:00
<ajs6f>barminto: Hm. The semantics are different, tho. So Rails assumes that every response included ETag? Because how else can it be sure to include it on the request? What about the first request?15:01
<barmintor>what?15:02
no
<ajs6f>barmintor: NM. It doesn't matter. All I care about is whether fcrepo is doing the right thing.
<barmintor>ajs6f: sorry, I meant Rails 5 responses now use weak ETags, and clients of Rails 5 apps are required to include the W/ flag to do the check
<ajs6f>barmintor: Oh, the other way around. NM, then.
Whoa, this "one-click" stuff is slick. Much better than Fedora 3.15:04
Although the icon in my Mac OS X Dock just says "Fed", which is kind of funny.
Holy crap. Instead of coblej's results, I get 409 with a message "The repository type (http://fedora.info/definitions/v4/repository#Container) of this resource is system managed."15:12
That actually seems worse.
* tjohnson leaves15:17
<ajs6f>coblej: Okay, I can reproduce your first (failing) PUT. I cannot reproduce your second (successful, non-weak) PUT.15:20
colej: I get the very strange error above.15:21
<coblej>ajs6f: would it be helpful to post the rdf file I used with the PUT?15:22
<ajs6f>coblej: It just might be. Let's try it and see.
<coblej>ajs6f: https://gist.github.com/coblej/fdea8de6476c0c4557ed3bbce3b4690715:25
as best I recall, I did a GET on the resource, copied the output into a file, and added a namespace and property15:26
<ajs6f>coblej: Interesting, no my first case (weak ETag) still does not work (ETag mismatch), and the second case (non-weak ETag) fails with 409 and message "Could not remove triple containing predicate http://fedora.info/definitions/v4/repository#created to node /2f/37/79/e6/2f3779e6-226d-4775-b2cd-f69263076138/f7/64/a1/d8/f764a1d8-61de-4312-8057-b3ec6c9a2611"15:27
That _is_ the URI of the resource I'm working with, so that makes sense.15:28
Fedora 4: We are exploring nondeterministic durability. Come with us.15:29
<coblej>ajs6f: with 4.5.1, we would get occasional ETag mismatch errors and an even more occasional error that, as best I recall, was sort of like the 409 message you cite15:30
<ajs6f>coblej: But the cases you show in your gist are the norm for you now, right?
<barmintor>coblej: I think the previous errors were the bug acoburn was referencing. Here we have a server/client disagreement about what the appropriate content for an If-Match header is15:31
<coblej>yes, with 4.6.0-RC3 and 4.6.0-RC4, we have not had a successful "relationship migration" (which, as I understand it, is essentially the type of PUT in my example)
<barmintor>but I think per https://tools.ietf.org/html/rfc7232#section-2.3.2 the RC is too strict
<ajs6f>barmintor: Too strict? Meaning it should allow weak vs. strong matching?15:32
<barmintor>coblej: that's what I was suggesting about fedora-migrate
ajs6f: it's in the spec
<coblej>barmintor: I think dchandekstark noted that it Ldp that is adding the If-Match rather than Fedora-Migrate per se (for what that's worth)15:33
<ajs6f>barmintor: I believe you— I just want to be sure of your meaning. In other words, I like the cut of your jib but I want to be sure to catch your drift.15:35
coblej:barmintor: But we didn't get strcit until RC_4, and they saw this with RC-3, right?15:36
they = Duke
<coblej>ajs6f: I thought the substantive ETag change was from 4.5.1 to 4.615:37
but maybe that's something else
yes, we saw this error with RC315:38
<ajs6f>coblej: No, see https://github.com/fcrepo4/fcrepo4/commits/fcrepo4-4.6.0-RC-3 vs. https://github.com/fcrepo4/fcrepo4/commits/fcrepo-4.6.0-RC-4 . See that last fellow: https://github.com/fcrepo4/fcrepo4/commit/ee2bd468fa08f03236031491bfd66e013855654115:39
"Properly support HTTP Patch with If-Match header checking"
So the fact that you were seeing this already (pre-RC-4) is dosconcerting.15:40
as well as disconcerting
<coblej>ah, okay ... we were seeing some kind of ETag mismatch with RC3 ... might not have been the same error
<ajs6f>coblej: Okay, hm.
coblej:barmintor: Well, do you think we should un-de-reverse-strictify it and see if that fixes the problem for Duke?15:41
<barmintor>ajs6f: no
<ajs6f>barmintor: You'd rather actually understand the problem?
<barmintor>ajs6f: yes
<ajs6f>barmintor: Well, to each his own.15:42
barmintor: On the assumption that the earlier problems _weren't_ this same thing (and coblej writes above that such might indeed be the case) then we _do_ understand the problem. We are being too strict.15:43
<barmintor>ajs6f: we're15:44
<ajs6f>Oh no! barmintor's been attacked in the middle of a sentence!15:45
coblej: I have to run to a meeting and I won't be back today. But I'll be back on this tomorrow morning. In the meantime, anything that barmintor has to say is going to be a lot more valuable than anything I would have said, anyway.15:47
afk bb tomorrow
* ajs6f leaves
* dwilcox leaves15:49
* bseeger leaves15:54
* bseeger joins15:58
* dwilcox joins16:11
* coblej leaves16:20
* manez leaves
* bseeger leaves16:24
* dwilcox leaves16:39
* mikeAtUVa leaves16:58
* github-ff joins17:02
[fcrepo4] escowles created containers-never-match (+1 new commit): https://git.io/v6Cgj
fcrepo4/containers-never-match 2d719df Esmé Cowles: Refuse updates to containers that include If-Match headers
* github-ff leaves
* github-ff joins17:05
[fcrepo4] escowles opened pull request #1088: Refuse updates to containers that include If-Match headers (master...containers-never-match) https://git.io/v6C2u
* github-ff leaves
* github-ff joins17:20
[fcrepo4] escowles created containers-never-match-RC (+1 new commit): https://git.io/v6Cwo
fcrepo4/containers-never-match-RC 58c7293 Esmé Cowles: Refuse updates to containers that include If-Match headers
* github-ff leaves
* github-ff joins
[fcrepo4] escowles opened pull request #1089: Refuse updates to containers that include If-Match headers (4.6.0-RC...containers-never-match-RC) https://git.io/v6Cw7
* github-ff leaves
<f4jenkins>Project fcrepo4 build #3365: FAILURE in 8 min 3 sec: http://jenkins.fcrepo.org/job/fcrepo4/3365/17:28
* travis-ci joins17:44
fcrepo4/fcrepo4#4658 (containers-never-match-RC - 58c7293 : Esmé Cowles): The build passed.
Change view : https://github.com/fcrepo4/fcrepo4/commit/58c729302175
Build details : https://travis-ci.org/fcrepo4/fcrepo4/builds/151053058
* travis-ci leaves
* apb18 leaves18:01
* dchandekstark leaves18:58
* dchandekstark joins20:07
* dchandekstark leaves20:12
* apb18 joins20:41
* dchandekstark joins20:42
* arebenji leaves21:25
* github-ff joins21:31
[fcrepo4-vagrant] awoods opened pull request #52: Add configuration support for AuthZ and no-AuthZ (4.6.0-RC...fcrepo-2110) https://git.io/v6WeO
* github-ff leaves
* apb18 leaves21:38
* dchandekstark leaves21:55
* apb18 joins22:38
* apb18 leaves23:01
* dchandekstark joins23:06
* dchandekstark leaves23:11
* dhlamb leaves23:12
* apb18 joins23:44

Generated by Sualtam