Hi,
while fixing some upgrade tests I noticed this method:
RepositoryUpgrade.setEarlyShutdown().
In CopyVersionHistoryTest.performCopy() this flag is set
to true and causes many ERROR and WARN messages during the
copy:
08:37:12.177 ERROR [main] BundleDbPersistenceManager.java:900 failed to
read
The Apache Jenkins build system has built Apache Jackrabbit Oak matrix (build
#399)
Status: Still Failing
Check console output at
https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/399/ to view
the results.
Changes:
[mreutegg] OAK-3344: Commit may add collision marker for commit
The Apache Jenkins build system has built Apache Jackrabbit Oak matrix (build
#398)
Status: Still Failing
Check console output at
https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/398/ to view
the results.
Changes:
[mreutegg] OAK-3313: Many tests leak DocumentNodeStore instance
The Apache Jenkins build system has built Apache Jackrabbit Oak matrix (build
#397)
Status: Still Failing
Check console output at
https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/397/ to view
the results.
Changes:
[mreutegg] OAK-3313: Many tests leak DocumentNodeStore instance
Hi Chetan,
Thanks for your feedback. It was tested with version 1.0.15 which is part
of AEM 6.0 SP2. Good to know that this is fixed now.
Are you aware of any HF for version 1.0.x?
Thanks
Burkhard
On Mon, Sep 7, 2015 at 5:41 PM, Chetan Mehrotra
wrote:
> How did you performed the test? If you
How did you performed the test? If you tested out with explain then
current code in 1.0/1.2 return misleading result and this got fixed in
trunk with OAK-2943. Technically Oak would convert the OR clause to a
union query and then each part of union should then be able to make
use of index.
Chetan M
On 07/09/2015 14:32, Burkhard Pauli wrote:
> ...
> Question: Does the Lucene property index support or conditions? I tried
> even with a oak property index without success.
>
I can be be totally wrong, so please take this carefully, but AFAIR
lucene property index does not support ORs.
This is ma
On 07/09/2015 11:08, Marcel Reutegger wrote:
> ...
> I would like to revert this change and run tests again
> with the pedantic profile. This ensures we check the release
> as documented in the README.md where users are instructed
> to run 'mvn clean install' or 'mvn clean install -PintegrationTest
Hello List,
I created a lucene property index as follow:
{
"async": "async",
"compatVersion": 2,
"evaluatePathRestrictions": true,
"indexRules": {
"dam:Asset": {
"includePropertyTypes": [
"String"
],
"jcr:primaryType": "n
On 2015-09-07 10:27, f...@apache.org wrote:
Author: frm
Date: Mon Sep 7 08:27:18 2015
New Revision: 1701579
URL: http://svn.apache.org/r1701579
Log:
OAK-3201 - Use static references in SecurityProviderImpl for composite services
...
This change causes a test failure in oak-pojosr on my two ma
Hi,
most of us probably use the automated release checker script
we have for Jackrabbit and Oak releases. I recently noticed
the check script returns rather quickly for Oak releases. It
turns out this is due to profiles and configuration we have
in Oak.
The script runs 'mvn verify -Ppedantic'
Fo
before it does the exit it issues a loud log.error - so we'd have to have
access to the log output..
besides resolving OAK-3250 when we know a test fails because of it, the
easiest is to disable the leaseCheck as eg done in [0]
but now test results of '381' are deleted so we can't find out anymor
On 7.9.15 10:03 , Stefan Egli wrote:
so perhaps it's a lease timeout case..
Any way to confirm this on Jenkins? E.g. could we place a println in
front of it? Or replace it with a throws?
Michael
'... System.exit called ...'
what we currently have until OAK-3250 is fixed is a System.exit when the
lease cannot be updated.
so perhaps it's a lease timeout case..
Cheers,
Stefan
On 31/08/15 16:00, "Michael Dürig" wrote:
>
>"The forked VM terminated without saying properly goodbye. VM crash
14 matches
Mail list logo