jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Francesco Mari (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (OAK-6894) org.apache.jackrabbit.oak.segment.upgrade.UpgradeIT.offRCUpgradesSegments failing
Date Wed, 01 Nov 2017 17:33:00 GMT

    [ https://issues.apache.org/jira/browse/OAK-6894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16234433#comment-16234433
] 

Francesco Mari commented on OAK-6894:
-------------------------------------

[~mduerig], regardless the failure reported in the description, the test logs show a weird
behaviour. The {{Compact}} tool invokes {{FileStore#compactFull}}, which results in a successful
compaction. Please note the record IDs of the two head states.

{noformat}
14:39:37.618 INFO  [main] LoggingGCMonitor.java:44          TarMK GC #196: compaction cycle
0 completed in 574,6 ms (574 ms). Compacted bc63786f-c698-4613-a6bf-c41c23476678.000010ef
to 946c3817-039a-4fde-a9b5-f8e25de15c71.00001db2
14:39:37.618 DEBUG [main] TarWriter.java:185                Writing segment 946c3817-039a-4fde-a9b5-f8e25de15c71
to C:\projects\apache\oak\trunk\oak-segment-tar\target\junit139811748279926107\data00001a.tar
14:39:37.618 INFO  [main] LoggingGCMonitor.java:44          TarMK GC #196: compaction succeeded
in 576,1 ms (576 ms), after 0 cycles
{noformat}

After that, a cleanup is run, and it completes successfully to. The {{Compact}} tool rewrites
the journal, but the uncompacted head state is used instead of the compacted one.

{noformat}
14:39:37.818 INFO  [main] LoggingGCMonitor.java:44          TarMK GC #196: cleanup completed
in 189,5 ms (189 ms). Post cleanup size is 8.4 MB (8411136 bytes) and space reclaimed 5.2
MB (5199872 bytes).
    -> writing new journal.log: bc63786f-c698-4613-a6bf-c41c23476678:4335 root 1509543577818
{noformat}

The head state appearing in the rewritten journal should have been {{946c3817-039a-4fde-a9b5-f8e25de15c71.00001db2}}
instead. A call to {{FileStore#flush}} right after {{FileStore#compactFull}} solves the problem,
but I don't think that this is a proper course of action. I think that, after a successful
compaction, the {{FileStore}} should persist and flush every piece of data so that a call
to {{FileStore#flush}} is not necessary. What do you think about it?

> org.apache.jackrabbit.oak.segment.upgrade.UpgradeIT.offRCUpgradesSegments failing
> ---------------------------------------------------------------------------------
>
>                 Key: OAK-6894
>                 URL: https://issues.apache.org/jira/browse/OAK-6894
>             Project: Jackrabbit Oak
>          Issue Type: Bug
>          Components: segment-tar
>            Reporter: Julian Reschke
>            Priority: Normal
>         Attachments: TEST-org.apache.jackrabbit.oak.segment.upgrade.UpgradeIT.xml
>
>
> {noformat}
> [ERROR] offRCUpgradesSegments(org.apache.jackrabbit.oak.segment.upgrade.UpgradeIT)  Time
elapsed: 7.446 s  <<< FAILURE!
> java.lang.AssertionError: Segment version mismatch. Expected V_13, found V_12 expected:<V_13>
but was:<V_12>
>         at org.apache.jackrabbit.oak.segment.upgrade.UpgradeIT.checkSegmentVersion(UpgradeIT.java:141)
>         at org.apache.jackrabbit.oak.segment.upgrade.UpgradeIT.offRCUpgradesSegments(UpgradeIT.java:107)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Mime
View raw message